When I run a test from a server geographically close to our servers, with no bandwith cap, the site-resources loads fast, but there is a big delay before the site is visually loaded (http://www.webpagetest.org/video/compare.php?tests=140612_NS_1d7c9fa70440c974d0d999e4028e1476-r%3A3-c%3A0&thumbSize=200&ival=100&end=visual
However, when I cap the bandwith and add latency, it loads the way I would expect it: As soon as the JS in head and CSS is downloaded, http://www.webpagetest.org/video/compare.php?tests=140612_NB_f9da520ea691b4f4197b76fb3d4de6c2-r%3A4-c%3A0&thumbSize=200&ival=100&end=visual
(Seen even more clearly here, http://www.webpagetest.org/video/compare.php?tests=140612_ET_6e2d6fa5e3c8222e2a8c76ef205630c9-r:2-c:0)
In this test, http://www.webpagetest.org/video/compare.php?tests=140612_SG_89b861a5923c60aa4ee26110b8529dfb-r:1-c:0 we se a bit of the same. The blocking resources (CSS + small JS in head) is loaded at 0.7 sec, but the site is visually available first at 0.9 sec. Is this the time the browser needs to parse/render?
It kind of depends on the browser but Chrome is greedy for processing content and may not yield to do a paint if it still has content to process. There were some changes made in 34 to help a bit but there are still cases where giving the browser all of the content sooner will actually make the initial paint happen later as it processes the increased data (html, css, js, fonts, etc). It’s something they’re actively looking into to see about improving.
btw, if you capture a timeline (or a trace) you’ll get more information about what it is doing. If you capture traces of the “good” and “bad” scenarios you can file a bug at crbug.com (they really like traces because it gives them the actual code flow).
Thanks for your explanation. I’ll try with timeline/trace. I’ll also try canary to see if there are any noticeable differences.
I know it is best practices to only load the CSS needed by the page, and ideally only what’s needed over the fold. The reason we chose to put all the css in one bundle, is two-fold: First, it will hopefully give us faster subsequent pageloads, since the bundle will be cached for the next requests. Our typical user is a customer (we’re a bank) that logs in and does quite a few number of page requests.
The other reason is ease of development and maintainability. Now every developer knows that the css “is there” when developing a page (or part of it). Maybe this could be solved with a more sophisticated system, but one big bundle solves this for us.
And it spends a lot of time doing so.
For most of our pages, this is not needed. That’s why we put the main chunk of JS at the bottom.
Defer is effectively the same as async (IE 9 had a broken implementation that didn’t guarantee execution order). If you can load them async then I recommend it but if there are dependencies that can be more difficult than it’s worth.
If you look at the filmstrip you can align the video frames with the timeline activity (bottom of the waterfall has the timeline activity): http://www.webpagetest.org/video/compare.php?tests=140618_AV_5a6734bf6e76ff9358206976ae890445-r%3A1-c%3A0&thumbSize=200&ival=500&end=full
It doesn’t look like the JS parse and execution is blocking the render - looks like it happens well after. There’s some really expensive painting for the background image but it looks like the browser isn’t trying to do anything at all while it’s fetching the resources.
If it’s quite reproducible and always looks like that it’s worth getting a trace and filing a bug - it just looks like Chrome didn’t signal something somewhere to do the paint.
It seems reproducible. Here is a test from a different part of our site, but with the same html-structure. A small script and css in head, and the majority of scripts in the bottom of the document.
The blocking resources (“loadfirst” and “global”) is fetched within .4 seconds, but nothing on the screen until 3.9 seconds. Is it the “browser main thread” that is the timeline activity?
I’m not that familiar with the details of the timeline, but it seems it finished fetching the document at 3.6 seconds, and is done loading the css/js in head around 3.85. It then spends over 300ms rendering, and does a paint at 4.2 sec. Am I reading this correctly? (http://www.webpagetest.org/chrome/timeline.php?test=140619_HX_493809ae0c6912254973469623d28e53&run=1).
The paint at 4.2 fits with the waterfall, but why does the timeline claim to load the initial document at 3.6, while waterfall says around .4? I just want to make sure I understand this, before submitting a bug-report.
Here is a different test from the same location, where chrome seems to parse the scripts in the bottom of the page, rather than doing a paint (http://www.webpagetest.org/chrome/timeline.php?test=140619_7M_d269a63a547c77b6e47d716e0533fc39&run=5, http://www.webpagetest.org/video/compare.php?tests=140619_7M_d269a63a547c77b6e47d716e0533fc39-r:5-c:0
Firefox has the page on screen in under a second, http://www.webpagetest.org/video/compare.php?tests=140619_RB_8ca5ec60c577dc24f25f42bc5fbcefd4-r%3A1-c%3A0&thumbSize=200&ival=100&end=visual, so does ie8 (http://www.webpagetest.org/video/compare.php?tests=140619_MB_f71dcd7767bf2e020122968d4b6676e5-r:1-c:0
I tested Chrome on Android vs Canary on desktop.
Chrome on android does it the way I would expect, it renders the page after the two blocking resources in head are fetched and parsed. Canary on desktop seems to wait around quite a bit before rendering anything.