Blog

Pages So Fast Your Customers Will Freak Part 3: The Rendering

The average website's total size has doubled in the last 2 years:

"Up and to the right graph of pagesize

All this 'stuff' takes time to download, and users have been shown to dislike slow load times for webpages. Additionally, Google has started using page load times in their calculation of PageRank, meaning a slow site has more objective drawbacks now than ever before.

Luckily Google has provided the internet with their excellent PageSpeed Insights tool. It shows you all of the current networking and application best practices that can be used to shrink your site's download time.

Over a series of posts, we'll cover each category of recommendations made by the Big G, finishing here with how your can adjust your page to suit the painting and rendering cycle of modern browsers.

Part 3 – The Rendering

Prioritize Visible Content

The measurement here is the number of network round trips the browser has to make before it can paint the initial content on the page. I emphasize network round trips because Google will actually make recommendations based on the TCP congestion window, not just on HTTP requests.

The strategy being promoted here is to structure your app so that the required assets for 'critical' content is delivered as fast as possible, and then your browser can async load and backfill more HTML, CSS, and JavaScript after the page is first drawn.

One example would be to load only your main article in the initial document, and use JavaScript to lazy load in your sidebar navigation. (You would need to be careful to not reflow the article though).

Google has a nice page outlining some other techniques to prioritize visible content.

In my opinion, this is a "last 1%" optimization that many or most developers won't ever encounter the need for. If you are a particularly high traffic site or have a very large mobile user base, this could warrant further research.

Remove Render Blocking JavaScript

<script> tags in the <head> are blocking. They need to download before the browser will proceed with parsing your document into a DOM.

Small-but-required-before-DOM scripts can be inlined in your document's <head>. Large-but-required-before-DOM scripts can go in the document's <head>, but only begrudgingly.

Everything else needs to go at the bottom of your <body> as the last children. Some can even get loaded asynchronously, based on user input. If you have dependent scripts in different files, load them with something like Require.js. If you don't care about loading/executing order, you can just use <script async src='main.js'>, but it will get executed literally whenever the browser feels like it. Godspeed.

(Use Require.js.)

Use Asynchronous Scripts

This tightly dovetails into the above point of downloading JavaScript blocking your browser from drawing your page. Google maintains a list of 3rd party JavaScript files that have been updated to work in an asynchronously loaded fashion.

Pick the right 3rd party libraries, and as you add things, make sure to always go back and check out the waterfall of network activity to see if anything is delaying your DOM from being ready.

A potential Culprit?

Conclusion

The browser paint cycle is constantly evolving and not very well specified (or even documented). This to me is the least effective area to spend time optimizing beyond the easy "scripts at the end of body" heuristic that has been known for some time. If you do need to squeeze out small feelings of speed for your users, this can be a fertile new territory for enhancements, but sometimes at the cost of re-architecting your site.

This is part 3 of 3 of the "Pages So Fast Your Customers Will Freak" series

Part 1: The Server Part 2: The Assets Part 3: The Rendering