The creeping rise in content that’s slowing down Britain’s retail sites
It’s that time of year when a lot of people are frantically trying to lose the few extra pounds they gained over the festive season. It’s time to be leaner, faster, to cut out the junk food and adopt a healthier lifestyle.
With that in mind, it might also be a good time for retailers cut redundant content from their websites.
Specifically, there’s a steady rise in the volume of scripts and styles that’s contributing to slower and slower load times.
A snapshot of 50 top UK retail sites
We regularly keep an eye on the performance of some of the UK’s top retail sites. And what we found in our most recent investigation was quite striking.
Out of 50 sites, 37 ended 2017 with more CSS than they had at the beginning. 45 had more JavaScript. The average increase in CSS was 22KB, while for scripts it was a staggering 218KB (all figures exclude inlined styles and scripts).
This is important because a browser needs the styles for a page before it can begin to display any content. Other things being equal, increasing the volume of styles will make pages slower to display, damaging user experiences.
Similarly, scripts will often hold up the display a web page, especially if they are blocking (synchronous). Even asynchronously loaded scripts can interfere with how the page displays as they execute. The impact is likely to be greater on low-powered mobile devices, which are slower to process scripts.
Overall performance for this group of retail sites has been deteriorating for a number of years now, and median load time went from 14.37 seconds to 15.71 seconds between January and December 2017. Similarly, median Speed Index (which measures the rate at which a page becomes visually complete) went up from 6,569 to 7,122.
Why it happens
Websites are constantly changing. And developers are under constant pressure to deliver new content and features in limited timescales: features that won’t work without new scripts and styles. At the same time, nothing will stop working if they just leave redundant scripts and styles in place. Indeed, it may be better to be safe than sorry and avoid touching old styles just in case they’re still needed for content elsewhere on the site.
So the temptation is to add what you need to get things working and worry about clearing away old content later. What’s more, it may well be true that each small addition to, say, a core bundle of blocking JavaScript makes only a tiny difference to performance. It only becomes a bigger problem when multiple changes are made, possibly by different people, over a long period of time. One small step at a time, the site sees a serious slowdown. But there’s no single cause, making it harder to see the creeping deterioration in performance.
How to avoid it
One answer is to get the right processes in place – setting budgets for metrics such as page weight, render start times and Speed Index, and building them into the release process.
More and more of our customers are doing this, and we’ve made it easier to get Performance Analyser working seamlessly with continuous integration solutions such as Jenkins and Team City (you can find a ready-made solution here or use the Performance Analyser API to create your own).
Ultimately, though, it comes down to what the business considers to be important.
That means assigning at least the same value to performance as it does to the features and design tweaks that require all that extra CSS and JavaScript. This isn’t always easy, but it is now possible to measure the impact of a change in load times on metrics such as conversion and revenue.
For the most part, though, despite the growing weight of evidence for the business benefits of a fast website, it’s clear that many still have a long way to go.
Published date: 31 January 2018
Written by: Alex Painter
