Insight and opinion
Understanding website performance
Everyone wants a fast website, and although you may be limited by finite resources, improvements are always out there. Let's understand what makes a fast website and avoid common pitfalls, as well as reaffirm the importance of speed to ourselves, and clients.
The importance
You may be under the impression that your website doesn't need to be faster, or you're building a website that you believe is fast enough. That may well be true, depending on your target demographic, your efforts could be adequate to serve your content efficiently to your favourite users.
If you're of this opinion, consider what brought you to it. Have you developed your website with a strong foundation of knowledge, about what devices your users have, how fast their connection to your server is, how long they would wait for content to load before bouncing?
It's a simple fact of business that to decide where best to invest your resources, you need as much tangible data as possible to inform such decisions. To give a better idea of the benefits of simply improving your page load speeds by a few hundred milliseconds, we can take a look at the objective data available at WPOstats.com. Here's a few of my favourites:
- BBC has seen that they lose an additional 10% of users for every additional second it takes for their site to load.1
- 53% of visits to mobile sites are abandoned after 3 seconds according to research from Google's DoubleClick.2
- Zalando saw a 0.7% increase in revenue when they shaved 100ms off their load time.3
With this in mind, we can add much more substance to our arguments that performance matters to more than just your demographic outliers.
"2 seconds is the threshold for ecommerce website acceptability. At Google, we aim for under a half second."
Maile Ohye GoogleStart as you mean to go on
It's easier to build a fast website than it is to make a slow website fast. As developers we pride ourselves on what we show to the client at the end of a project but too often, performance is an afterthought because it's almost untestable until the site goes into production.
Consider the following during development to ensure your site is the fastest version of itself when it launches:
- Ensure the order your JavaScript loads has a minimal effect on the rendering of the page. Isolate non-essential JS and consider using the defer tag to leave its load until the end. Asynchronously loading JavaScript will also mean users can read your content sooner.
- Scrutinise every asset before using it. Often non-developers will supply images to use on a website without considering the ramifications of a poorly optimised file.
- Tinypng.com is your friend.
- Make use of CDNs, if you're not versed in networking - a Content Delivery Network acts as an intermediary between your website, and the computer trying to access the website. Often a CDN will have the means to server your content from a closer location than your server, to the end-user, meaning massively reduced network communication times.
- Google's Lighthouse tool works locally so you can test as you build.
- Ensure your resources have expiry headers on them, this allows browsers to cache them and deliver a much snappier experience to repeat visitors (usually the most valuable).
- Enable Gzip.
- Concatenate and minify that CSS. It's much quicker for a server to serve a 50kb file than two 25kb files because HTTP requests take time to make. Use this in moderation though, as lots of unused style is worse than making a few extra requests. It's also much quicker for a browser to paint a page from minified CSS.
We're not even scratching the surface here but making these points second nature during development will garner knowledge of the principles of web performance.
There's no test like production
Every developer everPerceived Performance
Sometimes, your site is slow because it has to be. Users on poor connections won't have that snappy experience we crave no matter how many servers you have. You have great big images taken by talented photographers on their fancy DSLR cameras.
Poor connection speed doesn't always mean poor chance of the user converting. Data costs different amounts in different places, use whatdoesmysitecost.org to see what I mean. Some people just have slow internet because it's economically infeasible to upgrade. So what's my point? We need to cater for a wide range of network speeds and that means giving the user the best possible experience of your site as early as possible.
A real world example of this is elevators. Engineers received complaints that their speed was too slow, but instead of trying to make them faster (infeasible), they tackled the problem of why people think the lift is slow. Their solution was mirrors. Because if the user has something to do to distract them, they have less time to consider how slow their ride is.
How can we give an illusion of speed to our website users without detracting from the aesthetics of the site?
Skeleton Screens
Greyed out text boxes give the illusion of text loading and gives the user time to adjust to the site layout, understanding where they'll need to look before the text even arrives. This is also a recurring design pattern used by a lot of highly-used apps and sites so this sort of functionality is well known by the user.
Play the blame game
Facebook engineers found during A/B testing that by unbranding their preloader animation, users shifted their blame from Facebook to the operating system of their device.
#renio interesting! Facebook did A/B testing to determine that users blamed FB on left, iOS on right, for slowness. pic.twitter.com/zEVbTime1Q
— 𝔡𝔢𝔢𝔧𝔢 (@deeje) January 31, 2014
Images
csswizardry.com has a great example of perceived performance on the homepage main image. The site first loads a very low-res blurred version of it first to ensure the user sees something. Once the full quality image loads, it replaces the placeholder. I'll show you what I mean when simulating a really slow connection speed.
What you'll also notice about the above is that the loading of assets has no impact on the most important elements; text blocks and Call To Actions.
Anti-patterns
There are a few things once considered 'best practise' that are now outdated. Avoid these pitfalls:
- Base64 encoding large images.
- Loading a single CSS file with unused style because several http requests take longer.
- Domain sharding - consider using absolute paths for external assets.
- Infinity-scroll. Please never do this. It makes a really long page, is terrible for screenreaders, makes it difficult to use browser back/forward functionality, and doesn't really save anything. Load a little and paginate the rest.
- A bunch of other stuff that changes per environment. Test in production to see where your bottlenecks are.
Concluding
Performance is critical to convincing your users to convert, and there are always improvements to be made.
If you're non-technical, I hope this article gives you the fundamental knowledge of website performance required to make informed decisions about investing resource into improving. If you're a developer, I hope I've shared something new for you. At the very least I hope to have reminded you that performance matters.
If you want to talk about anything in this article, feel free to email me.
Sources
Shoutouts to Harry Roberts who inspired this article with his expert workshop at New Adventures Conference 2019, @deeje on Twitter for sharing that little gem about Facebook, and Featured Photo by Denys Nevozhai on Unsplash.
Awesome links