Phase 2 · ExecutionModule 8 of 15
Speed and Core Web Vitals
Speed is the part of SEO where people spend the most effort for the least ranking movement. It is still worth doing, for a reason that has nothing to do with rankings.
What this actually costs you
- Hours to learn
- 6
- Hours / month
- 1 to 2
- Tools
- Free
- Difficulty
- Medium to diagnose, high to fix
What this looks like when it is done badly. Someone chases a lab score from 71 to 94 over a weekend, on pages Google has never indexed, and reports the win. The score moved. Nothing a visitor experiences moved, and nothing that ranks moved either.
Hours and tool costs are RedSEO’s own estimates from client work and from teaching this material, not industry survey data. They assume a business owner doing the work themselves on a site under about 50 pages.
Speed is where the largest amount of DIY effort produces the smallest amount of ranking movement. I want to say that first, because the rest of this module argues for doing the work anyway, and the reason has almost nothing to do with rankings.
The actual thresholds
Core Web Vitals is three metrics with three published thresholds. From Google’s own definition:
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
That percentile detail matters more than the numbers. An average that looks fine can hide a 75th percentile that fails, and the visitors in that quarter are disproportionately the ones on older phones and worse connections.
Field data beats a lab score
The number most people optimise is a synthetic test: one page load, one simulated device, one connection, from one location. It is a useful diagnostic and it is not what you are assessed on.
The Core Web Vitals report in Search Console uses field data, which is what actually happened to real people visiting your site. When a lab score and field data disagree, the field data is the one that counts, and a weekend spent moving a lab score from 71 to 94 can change nothing at all in the report that matters.
Have us work out whether it is the theme
Why do it anyway
Speed is a ranking factor and a small one. It is a tiebreaker between comparable results rather than a lever that moves you past better content.
Do it because of what happens after the click. A visitor who waits four seconds on a phone and then has the button move under their thumb as an ad loads does not convert, and that loss is invisible in every SEO report you will ever read. Going back to the payback math in module 1: speed does not move your ranking much, but it does move your conversion rate, and conversion rate is a direct multiplier on G. That is a better argument than any ranking claim.
Mobile is the whole thing, not a variant
Assessment is segmented by device, and mobile-first indexing means the mobile version of your page is the version Google evaluates. If your desktop experience is excellent and your mobile experience is not, you do not have a good site with a mobile problem. You have a mobile site with a desktop bonus.
The practical version: test on an actual mid-range phone on cellular data, not on your laptop with the network throttled. The gap between those two is where most of the unpleasant surprises live.
What actually causes the three failures
LCP is almost always one element, usually a hero image that is far larger than it renders, sometimes a web font blocking text, occasionally a paragraph waiting on JavaScript. Find the element before you optimise anything.
CLS is things arriving late and pushing content around. Images without width and height, embeds without reserved space, banners that appear after paint. This is the cheapest to fix and the most obviously irritating to a real person.
INP is the main thread being busy when someone taps. Nearly always third-party JavaScript. The fix is usually removal rather than optimisation, which is why it is a business conversation as often as a technical one.
What I would do in your position
Open the Core Web Vitals report in Search Console and look only at mobile. If you pass, stop and go do module 6, because your time is worth more there.
If you fail, identify which single metric fails and fix only that. Then count your third-party scripts and delete one you cannot justify. Those two actions cover most of the realistic gains available to a non-developer, and everything past them is where the qualifier below starts applying.
Check your own pages
Real-visitor data first, and a plain answer when Google has none for your site, which is common and is true of ours. The lab result comes second, labelled as the diagnostic it is.
Core Web Vitals for a page
Takes 60 to 120 seconds, because Google renders the page in a real browser to produce the result. Anything that answers instantly is not running a real test.
- SSR TestingIf your content renders in the browser, check what arrives in the HTML first.
Find out whether you have a speed problem at all
Most sites do not have the problem they think they have. These steps are ordered to tell you that as cheaply as possible before you spend a weekend on it.
Look at field data, not a lab score
The Core Web Vitals report in Search Console uses data from real visits to your site. A synthetic test scores one load on one connection from one place, which is a diagnostic tool, not a verdict.
Check mobile separately from desktop
Assessment is segmented by device and the two are frequently very different. If most of your traffic is mobile, the desktop number is decoration.
Find which metric is failing before touching anything
LCP, INP and CLS have completely different causes and completely different fixes. Compressing images does nothing for a layout shift problem.
For LCP, find what the largest element actually is
Usually a hero image, sometimes a web font, occasionally a block of text waiting on JavaScript. Fix the specific element rather than the whole page.
For CLS, reserve space for anything that loads late
Width and height attributes on images, fixed heights for ad slots and embeds. This is the cheapest of the three to fix and the most visible to a real visitor.
For INP, look at what runs when someone taps
Long tasks on the main thread, usually third-party scripts. Which is the next step.
Count your third-party scripts and remove one
Chat widgets, heat maps, two analytics packages, a tag manager loading four more things. This is the single most common cause of a slow site and the least technical to fix.
Re-check after 28 days, not after an hour
Field data is a rolling window of real visits. Your change does not appear immediately, and judging it the same afternoon on a lab score will tell you the wrong thing.
Can you do this yourself?
You can do this yourself if
- Your problem is images, third-party scripts or missing dimensions on media. Those three account for most failing sites and none of them need a developer.
- You can remove things. Most speed work on small sites is deletion rather than optimisation, and the hard part is political rather than technical.
- You can read which of the three metrics is failing and resist fixing the other two.
You cannot do this yourself if
- The bottleneck is your theme or your framework. If the platform ships 400KB of JavaScript before your content, the fix is a rebuild and no plugin changes that.
- You are on cheap shared hosting where the server takes a second to respond before anything can render. Nothing you do in the page fixes a slow origin.
- The failing metric is INP and the cause is a script you cannot remove because the business depends on it. That is a trade-off conversation, not a task.
Questions people ask about this
- What are the Core Web Vitals thresholds?
- Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Google assesses at "the 75th percentile of page loads, segmented across mobile and desktop devices", so you are judged on your slower quarter of visits rather than your average.
- Is page speed a ranking factor?
- Yes, and a small one. It behaves as a tiebreaker between otherwise comparable results rather than a lever that moves you past better content. The stronger argument for doing the work is conversion rate, which is a direct multiplier on the payback math in module 1.
- Why does my PageSpeed score not match Search Console?
- They measure different things. A lab score is one synthetic page load from one location on one simulated device. Search Console uses field data from real visits to your site. When they disagree, field data is the one you are assessed on, which is why moving a lab score can change nothing that matters.
- Does mobile speed matter more than desktop?
- For most sites, yes. Assessment is segmented by device and mobile-first indexing means the mobile version is the one Google evaluates. Test on a real mid-range phone on cellular rather than a throttled laptop; the gap between those is where the surprises are.
- What is the most common cause of a slow site?
- Third-party JavaScript. Chat widgets, heat maps, duplicated analytics, a tag manager loading four more things. It is the most common cause and the least technical to fix, because the fix is deletion rather than optimisation.
- When is site speed not a DIY job?
- When the bottleneck is the theme or framework shipping hundreds of kilobytes before your content renders, or when the server itself is slow to respond. Neither is fixable inside the page, and no plugin changes either. That is the rebuild conversation.