We used one of Littledata's own benchmarks to identify an issue with mobile page load speed and fix the underlying problems. Here's how we did it.
Page load speed benchmark
Overall we are above average, but against one benchmark - delay before page content appears - we are close to the median. That means 35 sites in our sector manage faster page load speeds. As website professionals, we can't let that rest!
We care because Google cares about speed. If our landing pages take a long time before first 'paint' - before the content is visible - then more visitors will bounce or pick another article to answer their questions.
If we invest time into writing articles like this one on our analytics blog, we should also invest time in making sure they are fast to load, and fast for Google to crawl and index.
Here's how we acted on the benchmark data.
Benchmark your site
How fast were pages loading?
We used the excellent PageSpeed Insights tool to pinpoint what was going wrong with the pages loading.
For mobile browsers, where traffic increasingly comes from, we were in the bottom 10% for speed, and below average for desktop. That sucks, and was definitely penalising our organic search rankings.
Fixes to improve page load speed
By visualising the bundles for our Meteor App we found 2 very large modules which were blocking page load for all pages: the D3 library, used to visualise our industry category coverage, and the autoform package used for a single signup form.
2. Using Webp images for Chrome and compatible browsers
Google prefers you to use the more efficient .webp image filetype, which is typically half the file-size of older .png or .jpeg filetypes. We found our chosen image server, Cloudinary, includes a simple feature to automatically chose the best file type for the browser it detects. Very quick fix!
3. Lazy-loading of landing page images
Even if the images are efficiently served, trying to fetch all the images for a long-form landing page takes time - and is wasteful for users who only read the first few paragraphs.
Instead, we can wait until the user scroll down before images are loaded for that section. This results in a small flicker as the user scrolls the first time, but faster initial load time.
4. Caching pages from our blog
WordPress is a great CMS, but the PHP + MySQL stack it uses is not the fastest for generating the pages. Luckily there are some great cache plugins, including WP Fastest Cache which we set up.
What this does is save a rendered HTML file on the WP server, and only refresh the cache when the post is edited or new comments are added.
5. Cleaning up unused CSS and HTML templates
Like all sites that have evolved their design and content over a few years, ours had lots of redundant code that no-one had spring-cleaned. Generally it's easier with older projects just to leave code, but for Meteor apps particularly it can slow down every page (see fix 1).
So a new front-end developer starting was a good chance to rewrite templates from scratch, and chuck out the trash.
The page load speed improvements
Those 5 improvements, plus a database upgrade, let to some pretty good speed improvements - above average for mobile and top 2% for desktop speed!
Even a few days after the release we saw a boost in the visibility of our landing pages in Google Search.
Looking at Littledata's benchmarks for February, included in the newly released mobile vs desktop benchmarks, we can see the delay before content appears has dropped from 2.6 to 1.8 seconds (down by 40%). And the desktop speed is now in the top 10% of all sites at 1.7 seconds.
The only area we still lack is the mobile page speed, so maybe we will look at some AMP versions in the next sprint.