It’s well known that users prefer webpages that load quickly, after all we internet users are an impatient lot. In fact, quickly almost doesn’t cover it, perhaps instantly would be a better word. According to Kissmetrics, 47% of online consumers expect a web page to load in less than 2 seconds, and if a website takes more than 3 seconds to load, 40% will abandon it completely.
But it’s not just users that are invested in fast page speeds. As
Search Engine Watch recalls, it was way back in 2010 when Google first announced that site speed was a factor they considered when determining search rankings, and they promptly supplied
the tools for testing it.
Google’s PageSpeed Insights is looking for websites that score over 80/100 for both desktop and mobile devices, in order to consider them fast enough to deliver a good user experience. This page speed testing is something our web development team run as standard during our pre go live checks, to make sure our websites are exceeding the industry standards and expectations.
We did some page speed testing very recently for one of our clients, and we thought we’d share the impact a few changes to your website can have on your page speed performance.
Before Page Speed Optimisations
When we ran our initial page speed test for this particular client, the un-optimised site was fully loaded in 25.726s and required 12,528 KB (around 12.5 Megabytes) of bandwidth. That’s more than 8 times slower than the average user would tolerate! The main culprit causing this slow load time was the website’s images, and this is often the case with the majority of websites.
Here’s the technical stuff…
Images
On the un-optimised site, the website’s homepage featured images which had been uploaded by the user but had not been optimised for the target element. In other words, huge images for example 4000px by 4000px had been uploaded and scaled down or compressed to display at much smaller sizes such as 500px by 500px.
The solution? Our development team used
Dianoga Tools for Kentico 9 to optimise the images as they are being saved to the website’s media library. We also developed a separate in-house tool which forces the web page to render resized images to fit the target element perfectly, and if a resized version of the image doesn’t exists, it systematically creates one.
The benefits of these solutions are twofold. Not only is the page speed improved, but also the solution requires no further work on behalf of our client when they’re uploading new images to the website in the future.
Render Blocking JS
Another factor reducing our page speed performance was render blocking. Render blocking is something a user’s browser does, where it literally blocks the site from rendering (processing) until other elements are in place, namely the basic HTML and a map of the CSS styles on the page.
Our solution to this particular problem was to implement a modified “
Portal Engine Resource Combiner” module, for the purposes of combining HTTP Hander files (.axd), which are generated at runtime whenever you use a Script Manager in a web application. In other words, the ScriptResource.AXD contains all of the client-side JavaScript routines for Ajax.
We modified and improved this module by systematically moving all JavaScript to the bottom of the HTML mark-up, right before the closing body tag. This ensures that all the scripts are not render blocking the page.
Occasionally this can affect the page loading and the initial appearance of the page by causing what’s known as a “Flash of Unstyled Content” (FOUC), but if done correctly by ensuring all other aspects are fully optimised (e.g. the images are compressed and files are minified) the difference is almost imperceptible.
SVG Compression
The final hurdle impacting our page speed performance was the SVGs. We tackled this by compressing the SVGs using
this tool, which removes anything unnecessary from the SVG file such as whitespace, merging path, empty text and hidden elements, in order to reduce its size.
After Page Speed Optimisations
After optimising the images, eliminating render blocking and compressing the SVGs, we ran the page speed test once again and the results are pretty impressive. The optimised site now fully loads in just 6.639s (2,009 KB). That’s 74.19% quicker, or in other words, an 83.96% improvement in bandwidth saving. To put that into Google’s parameters, that’s a score of 96/100!