Can you please clarify if you see this for the WebUI settings (i.e., navigating to chrome://settings or chrome://about in the web browser) or is this related to the native system menu UI (seen when clicking on the system tray widget in the shelf)?

This is clicking on the system tray widget, or the Chrome menu - not
navigating directly to the WebUI in a tab.

Handing over to tbuckley@ for triage.

Had a chat with wez@ and here are further details. Device type is panther with two monitors attached. Repro steps are:

* Open system menu > click on settings gear
or
* Click on chrome (3 dots) button in top chrome > Help > About ChromeOS.

The windows which appear are what's unresponsive here, not the native chrome menu or system menu. According to wez@, while these windows were opening, "Monitoring with Task Manager, it looked like the renderer process for the Settings content was at 100% over that time"

hey wez@: if you flip chrome://flags/#enable-md-settings to Disabled, how long does the page take to load?  1-1.5s?

Material Design Settings wont ship until it's as fast or faster than the old settings page.

Yes, the old Settings page displays *something* within a second or so, and
displays fully after about 1.5s.

The performance numbers will be positively affected by Vulcanizing the settings page (ongoing effort,  issue 673825 , CL https://codereview.chromium.org/2573943002).

From my local testing on my Linux workstation, (ChromeOS build on Linux), chrome://md-settings/help is showing something to the user within

~1.65 seconds when non-Vulcanized
0.55 seconds when Vulcanized

i assume this affects more than just ChromeOS.  we should double-check the chrome://settings/help load performance on all platforms.

I think the blocking bug number had a typo.

hey Tommy, can you add chrome://help (with --disable-features=MaterialDesignSettings) and chrome://md-settings/help to your lighthouse monitoring script?

+paulirish

Yes, it's no problem to add chrome://help to the monitoring script.

However, it will have to wait until Lighthouse supports Uber Page urls (chrome://chrome), which it recently stopped supporting (but Paul is working on).

Alright, we should be in business once https://github.com/GoogleChrome/lighthouse/pull/1777 is tested and merged.

Results should be live now: https://docs.google.com/a/google.com/spreadsheets/d/1-NWS8M6BW6u6VwEYdFypD4SKDVtfW8XN3mtjMLXKQAQ/edit?usp=sharing

Looks like MD Help has 2.3x the load time of Old Help. (at least for the Linux laptop on my desk.)

Lots of room for improvement.

thanks for setting up monitoring / the investigation, Tommy!

No problem! I'm still investigating why the metrics seem to be not very stable.... but regardless the metrics bear out that MD Help is much slower.

Looking at the graphs provided by Tommy at #13 above, we are doing much better compared to when this bug was filed (see attachments). We are at about 1.3-1.5x compared to the old about page.

Deleted: help_comparison.png 63.4 KB

	help_comparison.png 63.4 KB View Download

I'll re-evaluate the situation once the work to split the "advanced" settings into a lazy-loaded module has completed ( issue 597347 ).

\o/

Verified on ChromeOS 9554.0.0, 60.0.3100.0