The average website's total size has doubled in the last 2 years:
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.
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.
<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 Asynchronous Scripts
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.
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.