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.
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.
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 Analyzer working seamlessly with continuous integration solutions such as Jenkins and Team City (you can find a ready-made solution here or use the Performance Analyzer API to create your own).
Ultimately, though, it comes down to what the business considers to be important.
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.