Back in 2020, Google announced that something called ‘Core Web Vitals’ would be a ranking factor for Google search results from May 2021 onwards.
This announcement caused quite a ruckus among some Webmasters desperate to make sure that:
[a] a poor Core Web Vitals score for their site wouldn’t drag it down in the Google rankings, and,
[b] if a good Core Web Vitals score COULD help Google rankings, then they wanted to take advantage of that new development.
Underlying that concern I believe is the doubtful assumption that Core Web Vitals would be a MAJOR new rankings signal, when in fact Google has at least 200 ranking factors in their current algorithm.
Only the key people at Google know how much weight any of those 200+ ranking factors have in the Google search algorithm, including the new Core Web Vitals factor.
That doesn’t mean we should ignore Core Web Vitals, far from it, but we should also keep it in perspective.
At the heart of Core Web Vitals is the noble attempt to get website owners across the world to clean up their act in terms of site usability, loading speed and mobile optimization.
To create a good visitor experience, you should be following best practices anyway (discussed below) but with the focus on these Core Web Vitals measurements, there are a few extra steps to cover.
We will get to those.
But basically Google wants to test your website and specific pages within it by THREE main measurements, things they call First Contentful Paint, First Input Delay and Cumulative Layout Shift, all unnecessarily complicated terms to describe pretty simple stuff.
In a moment, we will dig into what those terms actually mean but this is the kind of ‘helpful’ advice given by the Google Page Speed Insights tool – this was some of the advice given for optimizing google.com (more on that below), yes the page that looks like this and in my testing, never achieves 100/100 on Mobile – more like 89/100 to 97/100:
According to their own tool, Google needs to fix, among other things, these issues on Google.com:
“Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.”
“Consider instrumenting your app with the User Timing API to measure your app’s real-world performance during key user experiences.”
I will dig into this more on other huge sites with terrible scores below but if Google can’t get 100/100 on its own tool on a simple page with 1 logo and 1 form field, should Google be using this as a ranking signal?
Worst of all, non-technical site owners are going to struggle to fix any of these types of issues on their site without some Web developer help so Google has just added a lot more complexity to Web entrepreneurship, particularly for non-technical solopreneurs, the core audience of WPX.
Let’s also add in one more ingredient to this already difficult recipe: Desktop scores here.
Back in July 2019, Google switched to something called Mobile First indexing and ranking so it indexes and ranks all sites across the Web based on the mobile version of a site, not the desktop version.
So do desktop scores on the Google Page Speed Insights tool actually matter?
It’s also a pity that Google chooses to measure mobile website performance with the assumption that the user has a 3G or slow 5-year-old 4G phone though they make that information pretty hard to find – apparently site owners are now responsible for visitors accessing their site with terrible hardware!
Keep in mind that Google’s Page Speed Insights tool measures single individual pages and NOT a whole website. You may get a great score on one page of your website and terrible scores on others.
Click here for that tool.
For a whole website overview, check your dashboard inside the Google Search Console, assuming you have connected your website to that free tool!
This is just a fancy way of saying, how quickly does most of a webpage load for a normal human visitor to that page.
According to Google, 2.5 seconds or below is the ideal for a green or ‘Good’ rating here.
My own personal site at terrykyle.com (hosted on WPX, of course) is currently showing this ‘Largest Contentful Paint’ score on Desktop (0.6 seconds) – all documented scores below were correct at the time of writing but I encourage you to test these sites yourself here:
and on Mobile (2.3 seconds), I will explain the difference shortly in the way Google measures it:
But I have my doubts about Google’s measurement tools so I tested some megasites with their tool – just because it’s Google’s tool doesn’t mean that it’s perfect, they have produced many duds among their stellar successes.
We can see below that YouTube, the 2nd most visited site in the world, does NOT get a Good sub-2.5 second score here, even though this site loads instantly on almost any device (the overall performance grade of 35/100 also sucks):
Same dealio for the Google Play Store on Mobile testing, a site that hosts 3 million+ apps for Android and, like YouTube, would have an almost limitless budget for site optimization, which also loads instantly on any device, test it for yourself:
So a 2.9 second First Contentful Paint timing which “needs improvement”, according to this tool, even though the site loads instantly on any device as does the site below, Apple.com
Yes the same company that invented the iPhone and also has a few dollars to spare for site speed optimization gets a First Contentful Paint score of 3.7 seconds by one measure and 7.1 seconds by another – is this the same tool that Google will be using to judge the performance of Web pages (partly) for ranking purposes?
Next up we have something called ‘First Input Delay’ which just means how long does it take for a visited webpage to be usable for entering information, such as filling in login information, or clicking on things.
To land in the ‘Good’ range, Google says that this should be 100 milliseconds or less.
If you remember the YouTube example above, Google’s tool said that the webpage took almost 3 seconds to have most of the content loaded but it only took 18 milliseconds to become interactive, getting a green tick in the process.
18 milliseconds is extremely fast and 2.7 seconds for a reported page load time is pretty mediocre AND overall YouTube.com only scored a 35/100 on Mobile, those 2 results seem contradictory to me, maybe it’s just me:
When a Web page is loading on your mobile, often the elements of the page move around a fair bit as it spools up and when you mean to click on one link, you accidentally click on the wrong link and then get taken somewhere you didn’t want to go.
It’s less of an issue on a laptop or desktop but can be annoying on a smartphone.
To encourage better practice in this regard, Google’s Core Web Vitals also measures what they call Cumulative Layout Shift.
According to Google, a score of 0.1 or better (higher, not lower) is the target, which is not a time measure but just a number score.
Interestingly, with a score of 0.35, Google’s own YouTube didn’t do well here (see above image).
That’s very unlikely but nobody outside of Google knows exactly how much weight is applied to any of the 200+ ranking factors in Google’s current and ever-evolving algorithm.
You should also be mindful of making sure that your site is mobile-friendly, has a valid SSL certificate installed and annoying popups should be avoided or kept to a minimum.
I find that a very useful way to quickly diagnose any performance problems (plugins, hosting etc) is to install an empty default WP on a test subdomain in your same hosting account as your main site/s.
In this case, I am using test.terrykyle.com on one of our UK servers at WPX.
Even though the WordPress organization (Automattic) has gotten some flak over their (perceived or real) indifference to this Core Web Vitals change from Google, my empty WP default test site achieved a near perfect score – only 2 plugins live (W3TC for our own CDN integration and Really Simple SSL), all others deleted.
Here are the scores – 99/100 on mobile (note that scores can vary by as much as 20 points on each scan, even if the page is unchanged, who knows which score Google will use as a ranking signal then!):
and 100/100 on Desktop:
I then added the free Elementor plugin (the Elementor page builder gets plenty of blowback for being too heavy) but the scores remained exactly the same, namely 99/100 or 100/100 depending on the scan on Mobile and 100/100 on Desktop.
I then added 10 well optimized, 1,200 pixel wide images to the site homepage and this is the result on desktop (not massively affected -100/100 down to 86/100):
but on Mobile – still way higher than YouTube, the Google Apps store or Apple.com though – down to 69/100:
I then added just ONE – badly UNoptimized image (almost 2 Mb) to the page using the free Elementor page builder and Desktop went down to 84/100:
and Mobile went to 61/100 from 69/100 with only optimized images:
That was a quick and extremely basic test but gives you an idea of how WordPress performs before us site owners start loading it up with stuff: page builders, plugins, scripts, unoptimized images, popups etc.
The simpler and lighter the page is, the better, even if the Web is generally going in the opposite direction!
FOUR IMPORTANT TEST NOTES:
Results always vary a little to a LOT with each scan on the Google Page Speed Insights tool (think 10 to 30 points), that seems to be normal.
If you are testing like this, bear in mind that caching at a site, server or CDN level might still be showing the older, UNupdated version of your test page so double check that.
Personally, I optimize images by resizing them to the column width of the page, e.g. 1,200 pixels in this case AND converting them to .jpeg format (until WP natively supports WebP) AND saving them at 50% quality in paint.net – most images appear unchanged at that quality level to the human eye but the file size will be massively reduced.
In my view, image optimization should be done like that when a new page is created and not lazily handed off to some image-file crushing plugin or 3rd party service.
On the Google Page Speed Insights tool, it is the so-called Field Data from the Chrome User Experience Report that will be factored into Google rankings and not Lab Data.
Site changes could also take up to 28 days to be reflected in Field Data too.
Short of hiring a good front-end Web developer to tackle some of the recommendations from Google’s tool, these 5 steps should help you get (much) higher Core Web Vitals scores:
If you’re looking for a much more detailed, technical guide, this video from the Google Chrome Developers channel on YouTube is helpful: