Building your WordPress website with Core Web Vitals in mind


OK, by now, you know how important building a fast WordPress site is for users and search engines.

In this post I share what I’ve done to try and establish a realistic goal for Core Web Vitals KPIs from my site without having to call on an engineer to assist.

This means any SEO or web designer should be able to follow a similar approach and achieve some quick wins before delving into deeper issues with their site which might require software development expertise.

This post was created on a test page (since deleted) built from the ground-up testing the performance of the page at every stage using the Google Lighthouse API.  I took screenshots at every stage for mobile and desktop – I’ve spared you these – after all you just want to see the final screenshot with the score of 100 in green!.  I also manually copied the scores into Excel annotating the changes I made along the way – this was tiresome!

This was so tiresome in fact, that I have since got the team to automate this process for me and for you all in a new Page Experience tool coming soon (for free) to all our users!  (This is due to launch shortly).

Anyway, this is the steps I took.  This kind of systematic approach starting with a basic page and checking for improvements or regressions at each stage will work for any site not just a WordPress site.  I know there’s a lot more that can be done, but I wanted to see how far a reasonably tech-savvy user who is not a developer could get without having to call in the cavalry!

Warning:  If you do take a similar approach, you will soon realise that after a certain point you start to reach the law of diminshing returns and you are probably advised to spend time on other optimisation efforts.  The trouble is it’s quite addictive, and the urge to try one more tweak to try and get to 100 is really quite strong!  So be warned, and be strong, you don’t need to get to 100 – just aim to be in the green for Core Web Vitals and slightly faster than your best competitors!

  1. The first test, is just to build a page on your WordPress Site that just loads the Header and menus but does not load the footer, any other content or images. This is designed to give you a best case scenario score for your WordPress theme before you take any further action. If you have page caching plugins or other page accelerators then don’t change them at this time.
    We scored: Desktop 73 ; Mobile 23.
  2. The second test, is then to unload all plugins and JS/CSS files on your site using a plugin such as Asset Clean-up Pro. So you can block .css and .js files loading from plugins simply by clicking ‘check-all’ next to each plugin from within Asset clean-up pro.
    We scored: Desktop 75 ; Mobile 37. A nice improvement on mobile.
  3. The third test was to prevent external .js and .css files from loading or defer them.
    We scored: Desktop 85 ; Mobile 48. A nice improvement on both desktop and mobile.
  4. Next it’s time to remove hardcoded (non-enqueued) styles and scripts of which there were 12. A lot of these related to Google Tag Manager and some theme related scripts for the menu and fonts which I decided to leave in place, so in fact I only ended up unloading one relating to social sharing.
    We scored: Desktop 84 ; Mobile 50 in test #4.You’ll notice this change moved us forward on mobile devices marginally, but it went backwards on desktop. This is where looking at scores can drive you mad, and why it’s worth repeating the report to get an average of a couple of tests.I ran it again (having made no changes) and achieved: Desktop 88 ; Mobile 45 – so now the scores were improving on desktop but not mobile…aaaargh! I told you it could drive you mad if you are not careful. So moving swiftly on to test #5 where we have to start to dive into page speed plugin settings.
  5. There are hundreds of articles out there on how to optimise your WordPress site and recommendations of which plugins you can use and the merits of one plugin over another. I’m not setting out to do that here, I’m looking for easy wins that any SEO can implement on their site without having to call on a developer to help. So I first looked at unwanted .css and .js – there were 3 files here which I unloaded. One was a font file which was fine as I wasn’t using it, but the other two files were the site’s main CSS and JS files. If you unload the CSS clearly you’re going to have an ugly problem, but you can defer it from loading immediately if you don’t mind a FOUC (Flash of Unstyled Content). And whilst unloading the site’s main JS file didn’t break this page, it’s likely to cause problems so I just deferred it from loading. Using Asset Clean up these are the settings I chose: For the site’s .js file I went with “pre-loaded with basic option” but set to “async” and with the site’s .css file, I went with “pre-loaded with basic option” (rather than async which would possibly resulted in faster page speed scores but caused a long FOUC.
    We scored: Desktop 85 ; Mobile 54 in test #5.
  6. Next up, I tweaked one configuration option in Asset Clean-up Pro: Combine loaded JS (JavaScript) into fewer files and in-lined JS files under 3Kb (warning this can break your site so test it first!).
    We scored: Desktop 84 ; Mobile 46 in test #6. Hmm, we seem to be going backwards again!.
  7. I tweaked another configuration option in Asset Clean-up Pro: Disable jQuery Migrate Site-Wide (warning this can break your site so test it first!).
    We scored: Desktop 93 ; Mobile 52 in test #7. Woo-hoo – quite a big difference. And finally, we got our desktop score into the green 🙂
    But there was still plenty of work to do on Mobile.
  8. It was evident that fonts seem to be causing an issue. I notice in my Asset-clean-up Pro settings that these fonts were set to pre-load:
    But they are simply icons from Font Awesome and although I do use them liberally on my site, I don’t need them pre-loaded on every page load.
    So I removed them from the “Preload Local Font Files” settings section.
    Eureka! What a difference in performance:We scored: Desktop 99 ; Mobile 84 in test #8. The excitement was palpable! Almost the perfect 100 for Desktop and a huge improvement on mobile performance heading towards the green!
  9. I next looked at “Apply font-display: CSS property value: font-display: swap.” This means the text is shown immediately (without any blocking period, no invisible text) in the fallback font until the custom font loads, then it’s swapped with the custom font. You get a FOUT (flash of unstyled text).
    We scored: Desktop 95 ; Mobile 82 in test #9. So, as there was no discernible impact, I reverted the change.
  10. Preload Google Font Files was the next candidate to look at. I noticed a few warnings in Dev Console that I was pre-loading 5 font files using link preload, but 3 of these files were not used within a few seconds from the window’s load event so I removed them.
    I also set “Pre-connect” to ‘ON’.
    We scored: Desktop 94 ; Mobile 86 in test #10. OK, so a modest improvement in mobile scores and a slight retrograde step on desktop.Therein lies the problem with the quest for Core Web Vitals. At times, it can feel like a Sisyphean task but you have to remind yourself this is good for users not just Google!
  11. Now, we get into the realms of the “laws of diminishing returns”. I’m not going to drive myself mad trying to achieve 100% on desktop, but I would like to get mobile into the 90s and into the green. So I set the Google Font Settings > Combine Multiple Requests into Fewer Ones > “Asynchronous via Web Font Loader (webfont.js)” and then also tried “Asynchronous by preloading the CSS stylesheet”. The latter seemed to perform better for me.
    We scored: Desktop 94 ; Mobile 84 in test #11.
  12. Preload Google Font Files: In test#10, I only removed 3 of 5 files. So now I removed the remaining two files from being pre-loaded.
    Hey presto, the score for desktop was back to 99 😉 , but mobile was down to 71 again …grrr.
    We scored: Desktop 99 ; Mobile 71 in test #12.
  13. OK, so now I looked again at fine tuning the performance settings in my Impreza WordPress theme. Most of them were set already but there is a nice ‘auto-optimize’ setting which you can click. It updates loads of different tiny things and as you’re probably using a different WordPress theme I’m not going to delve into the details.
    And would you believe it, we scored: Desktop 95 ; Mobile 90 in test #13.
    At last we had both desktop and mobile metrics in the green – yipee!
  14. Clicking on my site’s primary CSS file I noticed that there were a lot of icons loaded that I probably wasn’t using. The Impreza theme has a nice setting that shows you which icons you are using. You can then unload icon sets that you are not using. I managed to change a few icons and unload 2 sets of icons. It seemed to have a positive impact.
    We scored: Desktop 95 ; Mobile 92 in test #14.
  15. Looks like the remaining issues to resolve are the size of my CSS file, some unused CSS within it and testing whether I can load critical CSS above the fold. I decided to cheat and install the Autoptimize plugin – just to test if it worked well for critical CSS. I moved all the settings from Fastest Cache and Asset Clean-up to Autoptimise (minifying CSS, HMTL and JS). So effectively, Asset Clean-up gets rid of unwanted page bloat from plugins, Autoptimize optimises the files and loads critical CSS that’s above the fold and WP Fastest Cache caches the pages. That’s the theory anyway!
    We scored: Desktop 100; Mobile 67 in test #15. Hallelujah – we got top marks on desktop – but what’s happening with mobile?
  16. Looks like it was just a random issue as I tested it again and we scored the best results we’ve had so far:
    We scored: Desktop 100; Mobile 92 in test #16.However, I also deferred loading WPML language selector and this meant the French home page could not be reached! Also the accordion functionality at the foot of the French Home page was no longer working (but it worked in English!). I also broke our embedded React search box. So, I had to uninstall Autoptimize and re-install it just for Critical CSS.So after these minor problems were rectified, I ended up with the best score I could achieve for a simple standard WordPress page with my theme.

Once these steps are complete, you pretty much have a benchmark of the performance levels you can achieve without fundamentally re-building your website and moving to another CMS.

There are of course a whole host of plugins that you can use to improve the page speed from here, including using plugins like SpeedKit which uses service workers to speed up page loading times but we’ll get to that later.

Now, as we add content to our pages we know that this will add to the page weight and slow the page down – so we will be prudent and follow standard best practices, like using a CDN and optimising images using Cloudinary and ensure they are scaled correctly and not by the browser. But at the very least, we know what we can achieve without too much difficulty. It’s just a systematic process of trial and error.

There’s always work to do – and when we have more developer resources available we’ll probably make some further changes to the site and dive into this in more depth.

In the meantime, we’ll soon be launching a new Page Experience tool that consumes the Lighthouse API and allows you to check Core Web Vitals metrics in bulk for your URLs and your competitors. It will also allow you to annotate and record the history of changes to your pages so you can incrementally improve performance.

If you are interested in improving your page performance then why not pick up tips and tricks from technical SEO experts in the Technical SEO group on The Optimisers community.

Leave a Reply

Your email address will not be published.

Fill out this field
Fill out this field
Please enter a valid email address.