Bug 105919 – Stylesheets that don't match current viewport etc. are no longer deferred

• Component: Page Loading
• Status: NEW

[Andy Davies]

Previous versions of WebKit deferred loading stylesheets where the media query didn't match viewport, orientation etc.

This waterfall illustrates the behaviour in Chrome 23 - http://www.webpagetest.org/result/130102_CQ_0f4cca3d4aa1dff79941bb64eda548c9/1/details/ - where big.css is deferred, due to  media="screen and (min-width : 1200px)"

In Chrome 26, big.css is no longer deferred and so is competing for the network with other resources - http://www.webpagetest.org/result/130102_KJ_2079b3c622753c392584f48052d8a01c/1/details/

Also tested in r138591

[Yoav Weiss]

Created attachment 181459 [details]
Re-enabling the ResourceLoadScheduler

This issue started in the disabling of the ResourceLoadScheduler for Chromium at the git commit 46e22591a4adb6bb42530b2f52e4517cd3b226bf.
This patch reverses part of that commit.
The reasoning for disabling the renderer's load scheduler is explained at https://insouciant.org/tech/throttling-subresources-before-first-paint/ and in short it is destined to move resource scheduling out of the rendering engine and into the browser. Since Chrome's resource scheduling is not yet in place (at least as I can tell), this results in obvious performance regressions, especially when it comes to external CSS files that are not necessary for first paint.

[Yoav Weiss]

I've opened a slightly related bug regarding the PreloadScanner - https://bugs.webkit.org/show_bug.cgi?id=106198

[Alexey Proskuryakov]

From the analysis above, this looks like a chromium-only issue.

[Andy Davies]

I used webpagetest as it was the easiest way to provide waterfalls

I also tested in WebKit r138591 and Safari 6.0.2 (8536.26.17) - Safari behaves the same a Chrome 23, WebKit nightly behaves as Chrome 26

That's why I raised it against WebKit rather than Chromium

[Adam Barth]

This patch appears to be in the inverse of http://trac.webkit.org/changeset/129070

Perhaps you and simonjam should discuss this issue at bit.  :)

[Adam Barth]

Actually CC the folks from http://trac.webkit.org/changeset/129070

[Adam Barth]

> That's why I raised it against WebKit rather than Chromium

It's correct to raise this issue in bugs.webkit.org.  Alexey is just marking the bug as only affecting Chromium so that he can ignore it.  :)

[Alexey Proskuryakov]

> Safari behaves the same a Chrome 23, WebKit nightly behaves as Chrome 26

If it's also broken in nightlies, then perhaps we have multiple issues. A fix that changes REQUEST_MANAGEMENT_ENABLED for Chromium won't fix Safari nightlies.

[James Simonsen]

As Alexey says, it's really only an issue if WebKit nightlies are affected.

For Chrome, we have a browser based scheduler in the works and this bug doesn't affect stable or beta channel users.

[WebKit Review Bot]

Comment on attachment 181459 [details]
Re-enabling the ResourceLoadScheduler

Attachment 181459 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/16156460

New failing tests:
http/tests/css/link-css-disabled-value-with-slow-loading-sheet-in-error.html

[WebKit Review Bot]

Comment on attachment 181459 [details]
Re-enabling the ResourceLoadScheduler

Attachment 181459 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/16150608

New failing tests:
http/tests/css/link-css-disabled-value-with-slow-loading-sheet-in-error.html