Site speed is one of the key factors that affects site rankings in search results, and user experience. If you monetise with ads, it also affects earnings. This article will describe the areas that are addressable by web developers, with some recommendations on how to improve each area.
There are many posts and articles that talk about how to speed up websites out there already, but they don’t properly explain why compressing images, minifying js, etc all help towards better site speeds. They don’t explain how a website is rendered in the first place, and also don’t put enough of an importance on data, specifically for mWeb (mobile-web) sites.
Why is site speed important?
There are so many reasons, and similar to the domino effect, boosting site speed indirectly improves many things such as ads earnings (if you have ads on your site), user engagement, search rankings and the amount your website eats into your users mobile data plans.
The life of a page view
From the moment a user types an address in the browser, to the moment the page has finished loading, there are many steps happening in the background. Some of those steps are addressable in terms of speeding them up, and some are not. So let’s take a generalised look at the typical life of a page view, and detail out what we can do in each step to speed it up.
DNS lookup
The Domain Name System (DNS) protocol is basically the internet’s Yellow Pages. It’s a decentralised system that contains domain to IP address information (amongst other things) that is used every time a user visits any website.
As the first port of entry to any website, the faster this works the better. Usually there’s not much you can do since the user’s network operator will control which DNS is used, but if you notice that your DNS lookup times are consistently taking longer than 200ms, you should look into it further. It may be the case that changing your nameservers can help.
As an example, the DNS lookup for amirhr.com takes on average 98ms. On the other hand google.com takes 50ms…
TCP connection
TCP stands for Transmission Control Protocol and is one of the main internet protocols. This is the stage in the whole life cycle where the browser and the server are establishing a connection, once they’ve found each other after the DNS lookup.
You can imagine it to be like a fighter jet refuelling in mid-air. The DNS lookup is the plane finding the refuel aircraft. The TCP connection is when they establish a link with each other to transfer fuel.
Again, there’s not much that can be done in this stage by a web developer, since none of it impacts the server just yet. It’s all in the hands of the network operators.
HTTP request and response
Once the TCP connection has been established, developing on the earlier analogy, this is the stage where the fighter jet asks for fuel, and the refuel plane responds with a status update, e.g. “ok it’s coming”.
As the initial HTTP request, the URL which was typed into the browser is requested in the form of a GET request, e.g.:
- Request URL: http://amirhr.com/
- Request Method: GET
And the server may respond with:
- Content-Length: 1610
- Content-Type: text/html; charset=utf-8
- Status Code: 200 OK
- Date: Thu, 05 Oct 2017 12:56:11 GMT
Followed by the actual content, which in the above case is the HTML for the root of this domain.
Once the HTML has loaded, each and every single resource in the HTML will be requested separately. These include any CSS and JavaScript files, and tracking tags, such as Google Analytics.
This process continues until all resources have been loaded, and the page declares it is ready.
Just like the last few stages, this is something that can’t be controlled or influenced directly by a developer since the speed depends on the network operators. However, the server configuration, and actual delivery of the content of the HTTP responses can be heavily influenced, which has been detailed in the next section.
Server response
When a HTTP request comes in, it’s up to the server to respond appropriately with either redirects, or content. This is one of the stages where you can have the most impact to reduce site loading times, and here are the recommendations:
1. Reduce the number of redirects
A redirect will cause the entire process to start from scratch, from a potential DNS lookup, to TCP connection, to a HTTP request.
The most important thing at this stage is to deliver the HTML of the page as soon as possible. So anything is up for grabs to make this process happen sooner.
2. Reduce the number of round-trips to your server
TCP tries to optimise how bits of information are passed between the browser and the server, and hence on the first trip will limit the server to only be able to send 10 TCP packets (~14 KB). The server must then wait for acknowledgement from the browser before sending more packets.
Now how to squeeze the entire site into 14 KB? Well, take the ATF (above-the-fold) content and reduce the HTML to be around 14KB. This’ll allow the browser to start painting that portion of content first.
Please note that the 10 TCP packet limit is a new increase in the standard – it used to be 3 to 4 packets. Make sure your server is upgraded to the latest version to take full advantage.
3. Avoid external blocking JavaScript and CSS in above-the-fold content
In order for a browser to display the page to the user, it needs to fetch all blocking resources (non async resources) such as javascript, CSS and images. Each time a new resource is fetched, a network round trip is added, which delays the rendering of the page furhter.
Hence any JavaScript or CSS needed to render the ATF content of the page should be written inline as much as possible, and all JavaScript or CSS files should be loaded in later (after the ATF content has been delivered).
Client-side rendering
4. Optimize CSS
This almost goes without saying, but remove any CSS you’re not using. But in addition to that:
- Place CSS that gets used above-the-fold at the top of the file
- avoid using CSS @import
- combine CSS files into one file
- compress your CSS file(s), there are many online tools, e.g. cssminifier.com
5. Optimize JavaScript execution and rendering time
JavaScript is great, but it is also very easy to create complicated scripts and inefficient code that can take a lot of time to execute. The best analysis tools are right in the browser, leverage the profiling tools available in the Chrome Developer Tools suite to see how you can improve your JavaScript files. The Google Developers website has a great post on doing just this.
And one additional point is to not use JavaScript for animations. Full stop. Most animations are possible to do in CSS, so just do that.
6. Leverage browser caching
You can tell the browser how often to re-download resources once they’ve been downloaded once already. For example, any static CSS, image and JavaScript files should have a Cache-Control header set to at least a week in the future. For example, 1 week in seconds is 604800:
Cache-Control: max-age=604800
If you do update one of those resources and you want to invalidate the cache, you can’t. The only way for the browser to fetch the entire resource again is either for the user to have cleared their browser cache, or you update the location of the file. For example if the file location is /css/some-style.css, you can use versioning to ensure new updates to specific files are pushed to users as soon as they’re available. The location would remain the same, but the src in the HTML would be updated to:
/css/some-style.css?v=20171004
Where the version string can be the day the file was updated. Or even better a proper timestamp.
Site speed analysis tools
There are many tools available for diagnosing and testing your website. Here’s a great list to get you started:
I hope this article has added a bit of colour to the usual recommendations that are available in the above tools, and other articles around the web!