In our previous posts (Part I & Part II) we talked about the poor performance of latency with mobile networks as well as a great way for saving a bunch of time on initial page loads by avoiding landing page redirect. Our next tip is to eliminate render blocking resources and prioritize visible content.
In order to eliminate blocking resources it is important to know how the HTML is being painted on the browsers screen.
When the browser makes the initial call to get the HTML document and the DOM starts to parse through the file, it will get to line 3 where it is then stopped and sees that it needs to fetch an external stylesheet. At this point the browser knows that there is CSS that needs to be processed and while the stylesheet is being fetched via more round trips through TCP, the DOM continues to read through the HTML file. The first item it gets to that it could potentially paint to the screen is line 6 with the ‘Hello World!’ div. Since the browser knows that there are stylesheets that are pending being loaded, it will continue on past this line without painting until the external styles are completely loaded. Using the 200 ms latency that was mentioned earlier, this could potentially mean nothing would be painted on the screen for nearly 6-7 seconds depending on the size of the stylesheet. That makes the stylesheet in the head a blocking resource as the browser cannot paint anything to the screen until the resource is loaded.
Blocking resources are bad. To get around this it is recommended to put inline styles and critical JS for above the fold content (the important content you want to display to the user first) in the header. There are a few drawbacks to using inline styles or scripts as opposed to external files. These styles and scripts cannot be cached so the user will need to download them each time they visit the site. Another thing to keep in mind is that in order to make significant gains in how fast content is painted to the screen, the above the fold content, styles, and scripts need to be below 14kb. If it is above 14kb in size, there will need to be another request sent to retrieve the content past the 14kb mark.
Another possibility for prioritizing content would be if there were an image that was high priority, you could inline the image in a very low resolution thumbnail where the real image goes. This makes it so when the page does load the image is visible in its low-quality state but then is replaced when the styles are properly loaded.