Site speed gives increased revenue, so should be a priority for all companies in our mobile first world. But, speed does not get fixed by engineers alone. They need the collaboration from several departments, and the buy-in and resources from stakeholders.
This is the organizational setup that I’ve seen the best results from:
That’s what each department needs to do, but let’s also go through it step by step.
Step 1: Start tracking speed and set KPIs
The analytics team, in collaboration with the engineers, need to start with choosing how to track speed and which KPIs the company should have.
There are different tools to measure speed and they have different metrics, but in my opinion, it doesn’t matter too much if you use Lighthouse or WebPageTest.org. The important thing is that you start setting targets that the departments can work towards. Lighthouse is great since you can measure pages that aren’t public yet, and WebPageTest is good since its metrics can intuitively be understood without much explanation. I would recommend that the analytics team set these targets (and here you’ll find instructions on how to measure speed with WebPageTest):
Load time: <5 s (measured on 3G Fast)
Speed Index: <3 s (measured on 3G Fast)
Load time is when the page is visually complete, and Speed Index measures how long it takes to load the content that’s above the fold, which of course shows if you’ve optimized the code in a smart way to show the content that visitors need first.
Step 2: Measure correlation between speed and conversions – and show stakeholders
Stakeholders don’t care about Speed Index. They need to focus on business critical metrics. But, by showing them the correlation between speed and conversions, stakeholders will see that site speed actually is business critical in a mobile world. And that will make them invest more in developers and the upkeep of the site. All win!
So, a quick way to create this calculation is to use this spreadsheet script that me and my great colleague Freddie Jansson have created. Follow the instructions in the spreadsheet and you’ll be up and running!
The script connects to Google Analytics, and this is what you need to know about that:
Field data: Google Analytics shows you field data (or real user monitoring) so the metric will be a mix of the speed given by WiFi/4G/3G and different devices. GA is also not perfected to measure speed, since it’s a script in itself that needs to be loaded. Thereby, only use the spreadsheet script to see correlations over several months of data.
Lab data: Lighthouse and WebPageTest use lab data instead, which means that it’s measured in a controlled environment creating stable metrics. This way, you can see how your site always loads on 3G Fast, and use that to track progress.
If you want to estimate the uplift in advance, use the Impact Calculator from Google.
Step 3: Give engineers time and resources to fix speed
Speed won’t get solved if the developers don’t have time to work on it. Create a timeline of what needs to get done and go to the stakeholders with the calculations from the Impact Calculator or the spreadsheet script. We need to start calculating how much revenue we lose by waiting six months for the backlog to clear out, and see that speed is an investment that pays off – so don’t wait.
Step 4: Give the creative team a performance budget
Engineers can not solve speed alone. If the creative team design huge pages with lots of images and video, it doesn’t matter how much the engineers optimize the code – the page will still be slow.
The solution is to give the creative team a performance budget. One target can be to make sure that each page is below 1Mb (at least 1.5Mb), and to have the creative team check every page themselves.
That way, the engineers don’t have to play bad cops all the time, and the creative team becomes self-regulating and hopefully find creativity in designing for performance.
Step 5: Align with marketing and clean out scripts
Yes, data is amazing. Believe me, I’m an analytics nerd. But, the speed needed for mobile devices puts a limit on how many tracking scripts we can put on the site. Get engineers and marketing in a room, and do this:
- Check if all scripts are being used. If nobody knows what it’s for – then it can probably get cleaned out. And if a script doesn’t have an owner, then it’s most likely an old relic.
- Prioritize. Does any of the scripts do similar things? For instance, having both Google Analytics and Adobe Analytics. Or both Hotjar and Optimize. These are huge tools that give insights that we might need, but few sites are so fast that they can handle duplicates.
- Pause and clean out. Don’t have for instance visitor recording or heat maps running as a default. If you want to investigate something, go in, get the stats you need during a limited time range, then pause the tracking and clean out the script. Also, are you really using the data to increase conversions or your user experience? If not, don’t weigh down the site with heavy tools.
- Find alternatives. Track speed with external tools instead of having data insights tools as a script on the page. Use usability tests in real life instead of doing general visitor recording that nobody has the time to look through. Investigate other ways of collecting your data, and choose tools and collaborations that are focused on speed.
The companies who make speed a priority and manage to create collaboration in the above way will see an improvement! So let’s start today.
Let me know if you have any thoughts you want to discuss, or advice regarding how your organisation has succeeded!