14. How to fix speed
In chapter 2 we covered the importance of speed for improving mobile conversion rates. It’s now time to sit down with the developers and resolve your site’s load times.
Video course
Infographic
Step 1: Make speed a KPI
Speed has a direct impact on conversions but there are several ways to measure it. You’ll have to decide which makes most sense for your business. Here are some suggestions for setting speed as a KPI and communicating this throughout your company.
Testing with WebPageTest
WebPageTest provides lab data — which is the metric produced in a controlled environment. This is great for measuring your progress and benchmarking.
Perform a speed test with these simple steps:
1. Enter your site’s URL
2. Chose a test location close to your target market
3. Chose connection, for example 3G fast, or 4G (keep in mind that coverage and speed outside of large urban areas can be poor).
4. Click the Chrome tab and tick the box “Emulate mobile browser” and “Capture Lighthouse Report” for recommended fixes.
Two frequent speed targets
Proposed target for load time on 3G Fast: <5s
Proposed target for speed index on 3G Fast: <3s
Exercise:
Use WebPageTest to see if your important pages reach the speed targets. It’s possible to build an API connected to WebPageTest to get regular tracking. Make sure you communicate the results with your team and stakeholders. It’s also possible to purchase tools that will keep track of your urls.
Testing with Lighthouse
Lighthouse provides lab data in the form of a score which is calculated from several important speed metrics. The tool also produces recommendations for what needs fixing.
Exercise
Run an audit with Lighthouse and evaluate if the Lighthouse Performance Score is the best metric for your business to keep track of.
Testing with Google Analytics
Google Analytics monitors real user behaviour, this means that the speed metric will vary depending on your audience’s web connection — WiFi, 4G, 3G etc, and the user’s device.
Google Analytics is not a controlled environment but you can use the tool for calculating correlations between speed and conversions in large amounts of data, looking at big changes.
Conversion rates alter with campaigns and seasons, so you can use the metric relative mobile conversion rate (Rel mCvR) which is the mobile conversion rate divided by the desktop conversion rate. Since the same campaigns reach both mobile and desktop, Rel mCvR will show if your mobile site is stronger or weaker without the influence of campaigns or seasons.
Exercise
Use this script to discover any correlation between your mobile Avg. Page Load Time and the relative mobile conversion rate. This will allow you to see if big speed fixes on your mobile sites impacts conversion rates.
Step 2: Check problem areas
Exercise
Run an audit with Lighthouse and go through the recommendations for speed optimisation.
Exercise
Check one of your pages with Chrome Dev Tools and follow this Google guide on how to analyse the page.
Step 3: Optimising images
Studies have shown that web pages are getting bigger and bigger, with images and videos being the main reason. Here’s a checklist for optimising images.
Prioritise: Review your design and decide if you really need all the images on your site.
Off-screen images: Check if your mobile site is loading any images that aren’t visible on the page.
Compress: Use the image analysis in WebPageTest to see how much you can compress images by.
Lazy load: Improve the user experience by making sure that images in the upper part of the page load fast, and images further down load when the visitor scrolls.
Skip sliders: In general, sliders are not ideal for ensuring that images appear quickly.
Exercise
Introduce a performance budget. Engineers can not solve speed alone. Until you’ve optimised the site, consider giving the creative team a performance budget with a page weight limit. Aim for making all pages weigh below 1Mb. Work across departments, and you will succeed.
Step 4: Optimise usual problem areas - the critical rendering path
The critical rendering path means making sure that the content that is visible to visitors is displayed first. The trick is to go through your render-blocking resources.
Construction of DOM: Ensure you have the correct DOM construction.
CSS: Go through your CSS and only load what is needed on the actual page. If possible, you can even inline the critical CSS and load the rest in a script. This can make a big difference in how your page is loaded.
JavaScript: Make sure you only have the necessary JavaScript, and use defer or async on anything that you can load later. Defer means that the resources are loaded after everything above and async means that it doesn’t block the rendering path but loads at the same time. JavaScript is a common issue so be sure to review and check if tags are still in use. Talk to the marketing team and decide if it’s time to do some tag spring cleaning.
How TUI in the Nordics decreased load times with 78%
Want to hear from someone who've gone through these steps in a live environment? Read this exclusive blog post from TUI Lead Frontend Developer, Emil Wiklund, where he explains how they decreased load times with 78% step by step.
The success factor for TUI in the Nordics was that the developers received trust and support from the management. Here you can read about the organizational setup that was crucial for their speed success.
