In 2021, at StrategiQ, a full stack digital agency based in the UK, we made it a target of ours to start developing each and every website we develop and launch to pass Google’s Core Web Vitals (CWV) and PageSpeed Insights (PSI) performance report.
Core Web Vitals show how your website performs in a variety of ways. This includes the speed of loading the first content on a page (First and Largest Contentful Paint), the speed of how long a user has to wait before they can interact with it (Time to Interactive), and layout shifts (Cumulative Layout Shift).
Testing your CWV is as easy as pie – simply head over to https://pagespeed.web.dev/ and enter your address. The top area displays the latest real-world data from the last 28 days, whilst the lower section (a score out of 100, both for mobile and desktop), is lab-generated data.
Why does this matter? Well, because Google says so.
In July 2018, Google announced that speed is a factor for how a site appears in Search results, especially on mobile. Source.
In 2020, they also announced that the user experience metrics (which make up the Core Web Vitals / CVW) are now used in how they rank sites. Source.
It’s simple: the faster and better performing a site, the better it’s likely to rank.
So the development team at StrategiQ decided it was our turn to help out the SEO department. The SEO experts can work their little bums off as hard as they possibly can, but a site that performs dreadfully can do much more harm than good. A site that passes CWV and PSI, however, will ensure that their excellent work has a brilliant springboard.
What’s worth noting, is that CWV and PSI are notoriously difficult to pass. The vast majority of sites don’t, even many of the most high-profile websites in the world. Think YouTube, BBC, even WP Engine themselves struggle to get a pass on both mobile and desktop (sorry guys).
So what did we do to ensure we saw those delightful green pass donuts of delight?
We stripped everything back and worked to one simple mantra:
Load as little as possible, as quickly as possible.
Whilst I won’t go into the minutest nitty gritty, I’ll go through our primary methods to keep our bespoke WordPress themes as streamlined as possible.
Firstly, let’s talk hardware. We can’t continue without first talking about WP Engine. Without a doubt, they are one of, if not the best WordPress-specific hosting suppliers out there. We have been delighted with the impressive support, the uptime, the environments for each install, backups, and how easy SSL certificate and domains are to manage amongst many other features. In addition, their caching and hard-baked speed optimization ensure the site performs as fast as it can at a server level.
With a high-performing server at its core, we know that it’s now up to us to get a website to work as fast as possible.
Like most agencies, we have our own hand-crafted base template we use as a starting point for all of our bespoke websites. Each site we create is designed and coded in-house – not a pre-built theme in sight.
Our base template has our speed optimization methods hard-baked in, as well a number of clever functions and reusable components we find ourselves requiring on every project. Having that starting point saves us time in the long run, and ensures every site will perform the best it can with little overhead required by the developer.
I know what you’re thinking – get to the good stuff!
I’m not going to bother listing the usual boring stuff you see on every blog post out there, such as “lazy load images”. But if you don’t, that is indeed a must – we have an image function that prints out our images lazy loaded with srcset and sizes tags (known as responsive images).
Let’s get right into it.
Method 1: chunk & enqueue
It happens a lot: a project just has one css file, and one js file, and they end up bloating to the size of a small planet. What next? Google asks you “why are you loading styles and javascript not being used on this page?”. Why? Why?!
It’s a valid point. Why should you load masses of css and javascript for an entire website when you only need a fraction of that per page?
All of our sites are entirely built with Gutenberg blocks. This means that for each block, you can utilise the brilliant power of enqueuing your css and js files.
For each block, we create a separate css and js file just for that file (if required). These are then minified (see the next point for more info) and enqueued on a block by block basis.
The result? We only load what’s actually there on each page.
Method 2: use a task runner such as gulp to combine and minify your assets
All assets generated are minified by a gulp function (others are available, such as grunt). It’s worth noting that many moons ago, Google would have preferred concatenation to minification (one large request would have been preferable to 5 small requests), but since the rise of HTTP/2 (which multiplexes multiple requests at once) this is no longer an issue.
Again, we do this to keep the files as small as possible. So now not only are we only loading assets that are on the page, they’re also miniscule in size.
Method 3: stop render blocking assets
We make sure all of these enqueued assets are at the bottom of the page, and therefore not render blocking.
We even dequeue the jQuery that comes with WordPress and enqueue a new version (one that doesn’t have security vulnerabilities), also at the bottom of the page.
But what about a FOUC (Flash of Unstyled Content) I hear you say?
Method 4: above the fold css
A Flash of Unstyled Content occurs when a page initially loads without any styles, as the stylesheet is at the bottom of the page. Once the stylesheet loads, the styles are applied, the site flashes and it finally looks correct.
To fix this, we split out the above the fold styles and add it as an inline
