What could cause this? Is this an issue with the tool, or our site? We try to follow best practices. The html is generated server-side, Javascript is for enhancement only.
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.
We apparently did not put enough thought into the fact that the bundles needs to be parsed for each request, even though it is cached. I knew this is the case for Javascript, but did not think about it for CSS.
For most of our pages, this is not needed. That’s why we put the main chunk of JS at the bottom.
would the defer keyword help here? Or do I need some more hand-crafted Javascript? The thing is we cannot have inline Javascript (CSP-headers), and it feels a bit silly to load a script just to load more scripts. Also, there seems to be many different opinions of how to defer loading. Waiting until all images are loaded seems a bit too late. I don’t want scripts not executing for seconds because one image is slow to load.
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.
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?
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.
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.