Just like Core Web Vitals, this article is broken down into three key sections...
Section 1: Understanding updates and where Core Web Vitals sits in that wider context
Sometimes Google takes updates seriously
Section 2: Understanding the wider impact
Page performance and usability
Section 3 : How to tackle it and our approach
Getting the most bang for buck
Feel free to skip to the sections you feel are most relevent to you, or read on for a fuller understanding of the issue.
Google and updates
What many of us don’t realise is that Google rolls out updates on a daily basis. They work on a cycle of continual improvement, making successive small changes and monitoring the results. It’s a methodology that stems back to the agile thinking that has swept through technology companies in the last 15 years.
Separately from these small updates Google also plans in bigger changes which it knows will have a wider impact. These are designed to target specific areas within the algorithm. Usually we don’t know specifically what the changes are or even the type of sites which they are intended to target.
“Several times a year, we make significant, broad changes to our search algorithms and systems. We refer to these as "core updates." They're designed to ensure that overall, we're delivering on our mission to present relevant and authoritative content to searchers. These core updates may also affect Google Discover.
We confirm broad core updates because they typically produce some widely notable effects. Some sites may note drops or gains during them. We know those with sites that experience drops will be looking for a fix, and we want to ensure they don't try to fix the wrong things. Moreover, there might not be anything to fix at all.”
When they release these larger updates (typically referred to as broad or core updates) we are now usually informed on the day via Twitter. This generally doesn’t tell us exactly what the update targets or who is likely to be affected.
We can see from the most recent core update last December, the information we were given was a link to a 2019 article which just explains that updates happen and you should probably ‘focus on content’ if you were affected. It’s generic non-specific advice along the lines of ‘do better’ which can be frustrating when you are badly hit and already following all the best practice information available.
Sometimes Google takes updates seriously
Sometimes though, just once in a while, Google lets us know in advance when an update is happening. This tends to be when it’s an update that does something very specific. For example, one that targets a specific metric.
The last example of this is the Speed Update back in 2018. Google let us know in January of that year that it would be rolling out an update and exactly what pages it would be affecting:
“The "Speed Update," as we're calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries. It applies the same standard to all pages, regardless of the technology used to build the page. The intent of the search query is still a very strong signal, so a slow page may still rank highly if it has great, relevant content.”
Even with this update though, webmasters were pretty much left to figure it out. We were only told an update would be coming and that it would target slow mobile pages. Or, as Google told us at the time:
“there is no tool that directly indicates whether a page is affected by this new ranking factor”
So even where we are told there is going to be a significant update, we’re typically left with limited information and resources.
The Core Web Vitals update
Now let’s talk about about how Google is messaging the Core Web Vitals (CWV) update, and why here at Wordtracker we’re now working on re-engineering our Blog and Academy (more on that later).
Back in May last year everything was difficult for everyone and, in a move I genuinely thank Google for, they announced a new change to the ranking algorithm, but that in recognition of the current situation they would be pushing this change back.
“A note on timing: We recognize many site owners are rightfully placing their focus on responding to the effects of COVID-19. The ranking changes described in this post will not happen before next year, and we will provide at least six months notice before they're rolled out. We're providing the tools now to get you started (and because site owners have consistently requested to know about ranking changes as early as possible), but there is no immediate need to take action.”
The change they were announcing was the launch of the new Core Web Vitals, a set of metrics which measures page performance against user experience. Most of these are related to how quickly and easily users can access content. In general these are focused around page loading speed.
Back in August last year we wrote about how only around 15% of search results were well enough optimised to pass assessments. So this represents a huge problem across the web with many webmasters likely to fall foul of these new metrics.
I also wrote an in-depth piece back in September on Understanding Core Web Vitals and how it might just be time to revisit your site's page performance.
And then Google decided to update their advice on the issue, setting May 2021 for rollout…
“Today we're announcing that the page experience signals in ranking will roll out in May 2021. The new page experience signals combine Core Web Vitals with our existing search signals including mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines.”
Google is treating this update differently from their usual ones. In fact by the time it goes live it will have been three years since we've had one that they have treated in this way. And that was an update that was also specifically targeted at page speed.
Page performance and usability
Google wants the web to be as user friendly as possible. When someone clicks a link on Google they will only show results where they are confident the user is going to have a good experience when they land on the page. As mobile adoption has become more widespread, so has Google's focus on making sure sites give users a good user experience.
The shift to mobile first indexing and Google's updates specifically targeting mobile speed and performance show how important this is. There is even a seperate Mobile Usability report in Search Console for checking your pages are mobile friendly.
Core Web Vitals are Google pushing harder on this same angle, making sure that when a user lands on a page, no matter the device, they are going to get a good experience. Google want to reward sites which do that and may well be penalising those that don't.
Core Web Vitals are split into three key areas Google feels are vital for user experience.
Largest Contentful Paint
This is one of the areas where the Wordtracker site currently falls down (we'll deal with that in the next section) but this measures the overall loading performance. A low score here is 2.5 seconds or lower. This sounds pretty generous, but you'll find a lot of sites are north of 10 seconds on this score and it's very hard to get it down to that sort of mark.
You can find Google's explainer on LCP for more detail here: https://web.dev/lcp/
First Input Delay
This is a measure of usability. Think of it as a score based on how quickly the page responds to the user's actions. Google defines this as being the time between a user first interacting with the page and the browser being able to start responding to the interaction.
You can find Google's explainer on FID for more detail here: https://web.dev/fid/
Cumulative Layout Shift
Ever gone to click on something on the page, but the element moves as you go to click on it and you end up taking an unwanted action? Well that's layout shift! Cumulative layout shift is the score for the total time for every unexpected layout shift in the pages duration.
You can find Google's explainer on FID for more detail here: https://web.dev/cls/
The breadth of the issue
Google has kindly given us a range of tools to see not just the overall problem, but also to individually assess pages in detail. Your first stop should be your Google Search Console account where you can see your Core Web Vitals score.
Taking a look at ours, you can see that we’re pretty much in the orange all round:
So the good news is we’re not solidly in the red. The bad news is, our most important page is:
I’ve found the crossover between the desktop and mobile reports is pretty close. We’re choosing to focus on fixing the mobile issues as this should translate well into solving the desktop issues alongside it.
As you can see from our article on the issue back in September, we’ve known we don’t score particularly well on these factors for a while and it’s been a business decision to leave the homepage alone for the time being. We’ve done extensive Conversion Rate Optimisation work on it, it ranks and converts well and like any business we have limited resources and have to choose carefully where to deploy them.
Your next step should be to group your pages according to how they perform and the business priority of these pages. Depending on the way your site is set up - for instance do you use a separate blog platform to the rest of the site? - you may find very different scores for different areas of the site.
For us, we can see our Blog and Academy content performs better on mobile, with a fully responsive design, and has strong(ish) desktop scores as well. As our tool works best on desktop and this is where we see the majority of conversions, we’ve traditionally concentrated on desktop performance.
However with the CWV update on the horizon, coasting along in these areas which are increasingly becoming mobile dominated just isn’t going to be good enough.
So, once you’ve been through a similar process, identifying which areas are performing worst and which are the most business critical, it’s time to move on to identifying exactly what needs doing.
Getting into the detail
Google’s PageSpeed Insights is the best place to start for looking at individual pages and gives you a cross section of information on page performance, highlighting the aspects relating to CWV.
As mentioned, our desktop performance is much better (this page scores a 60). However there's no point in looking at where the problem isn’t. We need to focus on where our scores are low and need to be better.
So as Google kindly points out, this page ‘does not pass the Core Web Vitals assessment’ and they give scores relating to different areas. The scores with the blue flag against them denote the CWV metrics.
Looking in more detail ,the report tells us not only the areas where we are falling down but also what we can do to fix it. Or not fix it…
“Opportunities - These suggestions can help your page load faster. They don't directly affect the Performance score.”
Or in other words, this stuff is probably having an impact but we give absolutely no guarantee that fixing it will improve your score.
Getting the most bang for buck
There are a few areas such as LCP where most sites are falling down. These also represent a large proportion of how Google calculates the CWV score.
Google actually provides a calculator so you can see your score and then figure out how targeting different areas will affect your overall score:
So let’s say we get some general performance increases and then specifically get the LCP score down. Suddenly things aren’t looking quite so bleak…
You can see from the weightings that LCP and TBT are the two most heavily weighted metrics. They’re also the two that are arguably both the hardest to fix and which most sites perform the worst on. The reason being that they represent a host of other complex performance issues, all of which interact to affect the score.
We've already covered LCP but TBT (Total Blocking Time) is described as follows:
“TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50 ms is a long task. The amount of time after 50 ms is the blocking portion. For example, if Lighthouse detects a 70 ms long task, the blocking portion would be 20 ms.”
In other words, how long until the user can take some form of action on page.
But remember, whilst TBT is a heavily weighted part of the overall performance scoring, it's not actually part of Core Web Vitals. So whilst you will need to get it down in order to gain a higher overall score, it's not a direct part of the May update.
Google has a whole host of information on all the different metrics with dedicated pages on each. These are really more developer centric and this is one of those areas where SEO and Dev teams need to be working closely together:
So what’s our plan?
Many factors will feed back into your decisions: your scores, the feedback from your developers, whether you are a one-person team and need to do it all yourself etc. At Wordtracker, we have decided that the amount of work it would take to bring our current site and framework up to scratch, especially to get it scoring into the green, would be uneconomical.
Over the past 2 years since we last redesigned our site new technologies have come along which allow for faster, lighter and more lightweight websites. For us, the only solution is to look at porting over to an entirely new framework, and we are currently working through possibilities for this, such as combining Gatsby with a headless CMS such as Sanity or Contentful.
Your solution is going to differ massively depending on what your current set up, score, budget and importance of organic traffic to your business is. This is much more than an SEO decision, it’s a business decision and one that’s going to have an impact long after May 2021.