How fast your website loads and performs can have a direct impact on customer engagement and can be the difference between someone sticking around to make a purchase or abandoning and looking elsewhere. Studies from major online retailers have shown the positive impact improving the loading time of your site has on conversions.
Moreover, the explosion in traffic from comparatively low-powered mobile devices on unreliable cellular networks has brought into sharp focus the need to address web performance issues. Somewhat surprisingly, a study by web monitoring company Gomez found that users expect websites to load faster on mobile devices than desktops.
Back in the early 90s, research from respected software usability consultant Jakob Nielsen found that users become distracted after 1 second of assumed inactivity. Although the research was discussing desktop apps, the findings are just as relevant to the web. What this research tells us as web designers, developers and producers is that we have no more than a second to keep a user’s focus by ensuring that we begin painting to the screen within this timeframe.
This challenge is greater still when we consider that it can take around 300ms (or longer) just to carry out the initial communication with the server. Taking this into account, we only have in the region of 700ms to begin painting to the screen.
<head> the impact is compounded.
Therefore, your first step should be to move all script calls to the bottom of the page, just before the closing
CSS is also render blocking but shouldn’t be included at the bottom of the page unless you are happy with your raw HTML being displayed to users only for it to change dramatically once the stylesheet has been downloaded and parsed. This isn’t a particularly pleasant user experience.
So, what can we do if one of the first items the browser needs to download prevents it from doing anything else while it’s doing so? In recent years, a technique has emerged whereby you extract your critical, or “above the fold”, CSS and “inline” it into the
<head>. This technique produces a subset of your CSS, just enough to render the content in the visible part of the user’s display. Additionally, by inlining the code, we prevent the browser from having to make another request to the server, negating the associated latency that comes with such a request.
This means the browser is given just enough CSS to render this visible content as intended and we can then dynamically load the remaining CSS after the document has finished downloading. Tools such as Critical can help to automate this process.
Compression and Minification
Your server should be configured to use Gzip to dynamically compress all assets prior to being sent over the network. This reduces bandwidth and download times with just a simple configuration change to your server.
Images are often the biggest cause of overweight web pages. Your images should also be compressed and optimised appropriately as discussed in our other post, Choosing the Right Image Format. But there are other techniques we can use to optimise images as well.
We’ve always had a “one size fits all” approach to images; whether the user’s display is 300 pixels wide or 3000, we send the same-sized image over the network and let the browser scale it up or down accordingly. In today’s world of of mobile browsing and expensive cellular data, that just isn’t practical any more. We shouldn’t be sending 2000px wide “hero” banners to devices with small screens or poor connections or both.
Unfortunately, the information we need to deliver right-sized images to the user – screen size, pixel density, connection speed – just isn’t available to us when we are building our sites. Although server-side solutions to this problem have existed for a while, these techniques rely on assumptions being made about the user’s device and browser and so can only get us part way to a desirable solution. A client-side solution based on information the browser has about the user’s conditions is what we need.
And as luck would have it, that’s exactly what we have! A group of industrious designers and developers, known as the Responsive Images Community Group, worked on a solution to the problems discussed above and had their work added into the official HTML specification which has now been implemented in all major browsers.
The RICG solution is comprised of two new features: a new HTML element,
<picture>, and two new attributes,
sizes which can be used on the existing
<img> element. Oftentimes, using
sizes will be enough and you won’t need to use the
<picture> element at all.
A detailed article on Responsive Images can be found on Mozilla Developer Network, but in a nutshell the solution allows you to provide a list of different sized images to the browser along with hints as to their dimensions and how big they should be on the page. Given this information and the information the browser has about the user’s current browsing context, it is able to pick the most appropriate image to download and display.
Similar to the idea behind critical CSS, why send images to the user if they aren’t going to see them right away? Lazy loading is a technique which allows us to replace non-visible images with a basic placeholder which is then replaced when the image scrolls into view.
Web fonts can add a lot of personality to your site but add extra weight and can slow down the rendering of the page. Using a font service such as Google Fonts or Adobe Fonts is probably a more sensible idea than hosting and serving the fonts from your own infrastructure. These services work hard to ensure they deliver fonts quickly in a way which doesn’t impact page render times too much, saving you time to work on other optimisations! Hosting fonts on a separate domain to your own also allows browsers to download more assets in parallel, which is yet another performance enhancement.
Using a Content Delivery Network
Just as using a font service can increase performance, so too can using a Content Delivery Network (CDN) for the same reasons.
Additionally, if you are using animation make sure that you’re taking advantage of improvements in CSS and hardware optimisations in modern browsers.
Thanks to CSS3, animation can and should be done with CSS, which is the appropriate technology to use for presentational aspects of your site. Using CSS for animation also means the browser can leverage hardware acceleration by offloading the animation calculations to the user’s GPU which is much better optimised to handle such code over the CPU. This reduces CPU load, improves visual performance and helps prolong battery life on portable devices.
On the Server
The majority of performance improvements occur on the client side, but there are still things you can do on your server to speed things up as well. First and foremost, you should enable HTTP/2 which dramatically increases the number of parallel downloads a browser can make and secondly, if you don’t have a CDN in place, ensure your static assets have far-future caching enabled. This tells a user’s browser that these assets are unlikely to be undated regularly so it can safely store them in its local cache. On return visits to your site, the browser will pull these assets from its cache rather than your servers to significantly reduce load times.
Tools & Resources
Most web browsers have performance monitoring built into their dev tools, which can help you to pin point issues on a specific page. Beyond that, tools such as WebPagetest and Google Lighthouse can give you powerful insights into performance bottlenecks and also help you test performance on multiple browsers and devices. These services also provide APIs which can be used for automated testing and monitoring purposes.