I built up a test environment to test some optimization techniques. At the moment I try to find out why the Start Render Time is at about 0,7 seconds in the following example:
To exclude JavaScript as the source of Render blocking I used the WebPagetest blocking feature.
In my opinion the browser should start rendering the site at about 0,4 seconds because I see no reason to wait another 0,3 seconds till 0,7. Any ideas what can cause the blocking behaviour?
I think you’re starting to get into the realm of the performance for the browser itself.
There are probably a couple of things going on:
1 - The video capture is every 100ms so it could have been anywhere between 0.601 and 0.700s.
2 - Browsers tend to try to conserve work and not paint too often (finding a balance can be difficult). As long as it has work to do (building the tree, applying styles, etc) it might decide to defer rendering for a little bit (I know Chrome has a escape on the tokenizer after doing 250ms of work for example - not sure about Firefox’s logic).
3 - Actually drawing the content can sometimes take a significant amount of time and getting it to the GPU and out to the screen is also not trivial.
For the most part you are doing a lot of things right and it’s really up to the browsers to find a better way to get as much of the content to the screen as early as possible without otherwise slowing down the user experience.
The one opportunity that I do see is that if you inline the above-the-fold CSS you could improve the start render pretty significantly (or at least give the browsers the chance to improve it).
E.g. the Fully Loaded Time for the repeat view is 0.194s and the browser starts rendering at 0.295s. The Start Rendering Time for the First View (0.598s) is also behind the Fully Loaded Time of 0.526s.
I will try to inline all the above-the-fold CSS to investigate how the Start Render Time will be influenced.
When you inline the above-the-fold CSS make sure to move the external css down to the end of the body or somewhere where it won’t block the browser’s processing.
As a quick hack just to see if it helps you can inline all of the CSS. You won’t get all of the benefit because it’ll be pretty big but it should give you an idea if it will work.
A little improvement. Start Render Time is now at 0.608s instead of 0.699s.
But it is still far away from the end of downloading the html (with css) which happens at 0.3s.
I think you’re into browser-specific pipelines at this point (though figuring out what blocked the text from rendering right away in Chrome would be good).
Is there any possibility in Chrome to dive into the generation of the CSSOM (or after that) to find out where the time is “lost”? Does the “DOM Content Loaded” event also include the CSSOM?
You will need to capture a Chrome trace to figure out where the time is going (chrome tab in the advanced settings).
“DOM Content Loaded” is just the point when the HTML parser has reached the end of the document which means it has executed any blocking scripts. The CSSOM may not be complete yet.