Page Speed for SEO: How to Diagnose and Fix It

A B2B prospect clicks your ad, lands on a page that takes five seconds to paint, and leaves before your headline finishes rendering. You paid for that click. Google watched the bounce. Both cost you.

Speed touches two things at once: how Google ranks the page and whether a visitor sticks around long enough to convert. The ranking effect is real but modest, a tiebreaker more than a lever. The conversion effect is bigger and easier to feel in the pipeline. This guide walks through both, then gets concrete about diagnosis and fixes.

We will use the metrics Google actually measures (Core Web Vitals), pull the data from the right places, and work through the fixes that move the numbers. No generic "compress your images" checklist. The specific bottlenecks, in the order worth attacking them.

What Google measures, and what it ignores

Search ranking uses field data, the loading experience of real Chrome users on your site over the trailing 28 days. That distinction matters. You can score 100 in a lab test and still fail in the field, because your real visitors are on mid-range phones and patchy 4G, not a data-center connection.

Three metrics make up Core Web Vitals:

Largest Contentful Paint (LCP) measures when the biggest element above the fold (usually a hero image, heading, or video poster) finishes rendering. Good is 2.5 seconds or less. This is the one most sites fail.
Interaction to Next Paint (INP) measures responsiveness: the lag between a user tapping or clicking and the page visibly reacting. Good is 200 milliseconds or less. INP replaced First Input Delay in March 2024 and is stricter, it watches every interaction, not just the first.
Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around as the page loads. Good is 0.1 or less. The classic cause is an ad or image that loads late and shoves your text down.

Here is what Google does not care about directly: your PageSpeed Insights score out of 100. That number is a lab simulation, useful for debugging, irrelevant for ranking. Chase the field Core Web Vitals, treat the lab score as a flashlight.

Metric	What it tracks	Good	Needs work	Poor
LCP	Main content render time	≤ 2.5s	2.5s to 4.0s	> 4.0s
INP	Interaction responsiveness	≤ 200ms	200ms to 500ms	> 500ms
CLS	Visual stability	≤ 0.1	0.1 to 0.25	> 0.25

A page passes Core Web Vitals only when at least 75% of visits hit "good" on all three. One weak metric fails the whole assessment.

Field data versus lab data: use both, for different jobs

These two data sources answer different questions, and mixing them up wastes hours.

Field data (also called real user monitoring, or RUM) comes from the Chrome User Experience Report, CrUX. It is what Google ranks on. You find it in Google Search Console under the Core Web Vitals report, or in the top section of PageSpeed Insights when enough traffic exists. Field data tells you whether you have a problem. It does not tell you why, and it lags by up to 28 days, so a fix you ship today will not show up for weeks.

Lab data comes from a single simulated load: Lighthouse, the PageSpeed Insights diagnostics, or WebPageTest. It runs on demand, gives you a waterfall of every request, and points at specific culprits. Lab data tells you why a page is slow and lets you test a fix in minutes. It cannot tell you whether real users are affected, because it is one synthetic run on one simulated device.

The workflow that works: find the failing page group in Search Console (field), then load a representative URL in PageSpeed Insights or WebPageTest (lab) to diagnose, fix, redeploy, and confirm in the lab. Then wait for the field data to catch up before declaring victory. If your site lacks the traffic for CrUX data, lean on lab tools and your own RUM, more on that below.

Diagnose: find what is actually slow

Run a real URL through PageSpeed Insights and read the Opportunities and Diagnostics sections. They are ranked by estimated savings. But the score is an average across metrics, so go one level deeper and ask which metric is failing, because the fix differs entirely.

If LCP is the problem

Open the LCP element it identifies. Then check the four phases that make up LCP time:

Time to first byte (TTFB). How long the server takes to respond. If this is over ~600ms, your problem is hosting, server-side rendering, or a missing cache, not your images.
Resource load delay. The gap before the browser even starts fetching the LCP image. Caused by the image being discovered late, hidden behind JavaScript or a CSS background.
Resource load time. How long the LCP image takes to download. Caused by an oversized or wrong-format file.
Render delay. The browser has the content but cannot paint it, usually blocked by render-blocking CSS or fonts.

WebPageTest's waterfall makes this visible: you can see the exact request that gates the paint.

If INP is the problem

INP is almost always JavaScript. A heavy third-party tag, an unoptimized analytics or chat widget, or your own event handlers doing too much work on the main thread. The Chrome DevTools Performance panel, recorded while you click around the page, shows you the long tasks (anything over 50ms) that block responsiveness. Sort by total blocking time and you usually find one or two scripts eating the budget.

If CLS is the problem

Load the page, watch what jumps. The PageSpeed Insights filmstrip and the DevTools "Layout Shift Regions" overlay highlight the shifting elements. The usual suspects: images and iframes without width and height attributes, ad slots with no reserved space, web fonts that swap and reflow text, and content injected by JavaScript above existing content.

A quick mistake to avoid: testing only your homepage. Google evaluates page groups, and your money pages (landing pages from ads, product or service pages, blog posts) often behave very differently. Pull the worst-performing group from Search Console and start there. A well-built landing page that converts earns back the engineering time fast.

Fix LCP: the work that pays back most

LCP failures are the most common and usually the most fixable. Work top to bottom.

Optimize the hero image. This single change moves LCP more than anything else for most sites. Serve modern formats (WebP or AVIF), which cut file size 30 to 50% versus JPEG at the same quality (illustrative range, your savings depend on the source). Size the image to its actual display dimensions, a 3000px photo rendered at 800px wastes most of the bytes. Use responsive srcset so phones get a smaller file.

Preload the LCP image. Tell the browser to fetch it early instead of discovering it late:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

The fetchpriority="high" hint pushes it ahead of less important requests.

Do not lazy-load above the fold. Lazy loading is great for images below the fold and a disaster for the LCP element, it delays the very thing LCP measures. Mark the hero image loading="eager" and never apply blanket lazy-loading to everything.

Cut render-blocking resources. Inline the critical CSS needed for the first paint and defer the rest. Add font-display: swap so text renders in a fallback font immediately instead of waiting. Defer non-essential JavaScript with defer or async.

Fix slow TTFB at the source. If the server is the bottleneck, no front-end tweak saves you. Add page caching, use a CDN to serve assets from a location near the user, and check that your hosting tier matches your traffic. For server-rendered sites, cache the rendered HTML.

Fix INP: tame your JavaScript

Responsiveness problems come from the main thread being busy when a user tries to interact. Three moves cover most cases.

Audit third-party scripts. Every chat widget, heatmap tool, analytics tag, and A/B testing snippet runs JavaScript. Open DevTools, record an interaction, and find the heaviest. Then ask a blunt question of each tag: is the data it produces worth the responsiveness it costs? Most sites carry two or three tags nobody looks at anymore. Remove those first.

Load tags so they do not block. Defer non-critical third-party scripts so they run after the page is interactive. A tag manager helps you control firing order and conditions, so analytics does not compete with the first paint.

Break up long tasks. If your own code runs a long synchronous task, split it so the browser can respond between chunks. Yielding to the main thread (with setTimeout or scheduler.yield()) lets a queued click run instead of waiting. This is developer work, but it is the cleanest fix for INP on JavaScript-heavy pages.

INP and your technical SEO foundation overlap here: clean, lean rendering helps both crawlers and users.

Fix CLS: stop the page from jumping

CLS is usually the quickest win because the fixes are small and mechanical.

Set dimensions on everything. Add width and height attributes (or a CSS aspect-ratio) to every image, video, and iframe. The browser then reserves the space before the file loads, so nothing shifts.

Reserve space for dynamic content. Ad slots, embedded widgets, and cookie banners need a fixed container sized in advance. If a banner injects itself at the top after load, it pushes everything down and tanks your CLS.

Handle fonts carefully. Font swapping causes reflow when the fallback and the web font have different metrics. Preload your main font and use size-adjust in the @font-face rule to match the fallback's dimensions, reducing the shift when the real font arrives.

A simple priority order

When everything looks slow, attack it in this sequence. The earlier items return more per hour spent.

Hero image (format, size, preload, no lazy-load) for LCP.
TTFB and caching if the server response is over 600ms.
Layout dimensions on images and ad slots for CLS.
Render-blocking CSS and fonts.
Third-party script audit for INP.

How speed fits the bigger SEO and revenue picture

Speed rarely outranks relevance and links. A slow page with the best answer still beats a fast page with a thin one. So treat Core Web Vitals as part of a healthy technical SEO setup, not a substitute for content and authority.

The revenue case is cleaner than the ranking case. Faster pages convert better, full stop. Every second of delay on a B2B landing page costs you form fills, and at a high CAC, a few percentage points of conversion lift pays for the engineering many times over. If you are deciding where to spend a sprint, the conversion math usually justifies it before the ranking benefit does.

One caveat worth stating plainly: the exact ranking weight Google assigns to Core Web Vitals is not public, and it shifts. Build for the user, the metrics follow, and you stop chasing a moving target.

FAQ

Does page speed actually affect Google rankings?

Yes, but lightly. Core Web Vitals are a confirmed ranking signal, used mainly as a tiebreaker between pages of similar relevance. A faster page will not outrank a more relevant one. The stronger reason to care is conversion: speed moves your bounce rate and form completions more reliably than it moves your position.

What is a good page speed score?

There is no single "score" Google uses for ranking. Aim to pass all three Core Web Vitals in field data: LCP at 2.5s or less, INP at 200ms or less, CLS at 0.1 or less, for at least 75% of visits. The 0-to-100 Lighthouse score is a debugging aid, not a target.

Why does my site score 95 in Lighthouse but fail Core Web Vitals?

Because Lighthouse is a lab test on a simulated device and a fast connection, while Google ranks on field data from real users, often on mid-range phones and slower networks. Trust the field data in Search Console for the verdict, and use the lab score only to find and test fixes.

How long until a speed fix shows up in rankings?

The field data behind Core Web Vitals is a 28-day rolling average, so a fix takes a few weeks to fully reflect in Search Console, then longer for any ranking effect to settle. Confirm the fix worked in a lab test immediately; wait for the field data before judging the SEO impact.

What slows down most B2B websites?

Three things, in order: oversized hero images and uncompressed media, render-blocking JavaScript and fonts, and a pile of third-party tags (chat, analytics, heatmaps, A/B tools). The marketing tags are often the easiest win because you can remove the unused ones without touching code.

Do I need a developer to fix page speed?

Some fixes need one (splitting long JavaScript tasks, server caching, critical CSS). Plenty do not: compressing and resizing images, setting image dimensions, removing unused third-party tags, and enabling a CDN are within reach for most marketing teams. Start with the no-code wins, bring in a developer for the rest.

The short version

Page speed is worth fixing for conversions first and rankings second, and the work is more tractable than it looks once you read the right data.

Diagnose with field data (Search Console) to find the problem, lab data (PageSpeed Insights, WebPageTest) to find the cause.
Identify which metric fails (LCP, INP, or CLS); the fix is different for each.
Start with the hero image and server response for LCP, the biggest lever for most sites.
Set dimensions on images and ad slots to kill layout shift.
Audit third-party scripts to recover responsiveness.
Confirm fixes in the lab, then wait for the 28-day field data before calling it done.

If your pages are bleeding leads from slow loads and you are not sure which fix to make first, get a focused page-speed audit of your top landing pages. We will tell you the three changes that move your numbers most, with the conversion math to back the priority. Reach out and we will take a look.