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
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.
I've opened a slightly related bug regarding the PreloadScanner - https://bugs.webkit.org/show_bug.cgi?id=106198
From the analysis above, this looks like a chromium-only issue.
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
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. :)
Actually CC the folks from http://trac.webkit.org/changeset/129070
> 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. :)
> 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.
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.
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
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