The three metrics that decide the verdict
Google evaluates three Core Web Vitals. To pass, a page must hit the good threshold on all three at the 75th percentile of real user experiences, measured over a rolling 28 day window from the Chrome User Experience Report.
| Metric | Good | Poor | What it measures |
|---|---|---|---|
| Largest Contentful Paint | Under 2.5s | Over 4.0s | How long until the largest visible element, usually the hero image or headline, has rendered. The user's sense of "has this loaded yet" |
| Interaction to Next Paint | Under 200ms | Over 500ms | How long the page takes to visibly respond to taps and clicks, across every interaction rather than only the first. Replaced First Input Delay in March 2024 |
| Cumulative Layout Shift | Under 0.1 | Over 0.25 | How much content jumps around during load. This is the metric behind tapping a button and hitting an ad instead |
The 75th percentile detail is where most teams get caught out. It is not your average visitor. It means one in four real users must still be having a good experience, which is a far stricter bar than a single test on fast office broadband suggests.
Why your PageSpeed Insights score is not the target
The number in the coloured circle is a Lighthouse lab score: a simulation run on a synthetic device under synthetic network conditions. Google does not use it for ranking. Google uses field data from real Chrome users. The two regularly disagree. When they do, the field data is the one that counts.
Two consequences follow. First, a page can score 95 in Lighthouse and still fail Core Web Vitals, usually because real users are on mid range Android devices on mobile networks rather than on the simulated machine. Second, after you deploy a fix, the field data takes weeks to reflect it because the 28 day window has to roll forward. Judging a fix after two days is judging mostly old data.
What actually slows a landing page down
| Root cause | Metric it damages | What we do about it |
|---|---|---|
| Oversized hero images | LCP | Convert to AVIF or WebP, generate correct sizes for each breakpoint, set fetch priority high on the hero and remove lazy loading from it, because lazy loading the LCP element is one of the most common self inflicted wounds we find |
| Third party scripts | INP | Inventory every tag, remove the ones nobody reads reports from, defer the rest and move what can be moved to server side. Chat widgets, session recorders and tag managers are the usual offenders |
| Render blocking CSS and JavaScript | LCP | Inline the critical CSS needed for the first screen, defer the rest and split JavaScript so the page is not waiting on code it will not use above the fold |
| Web fonts | LCP and CLS | Subset to the characters actually used, preload the primary weight, apply font display swap and match the fallback metrics so text does not reflow when the real font arrives |
| Images and embeds without dimensions | CLS | Explicit width and height on every image, video, iframe and ad slot, plus reserved space for anything injected after load |
| Slow server response | LCP | Caching, a CDN in front of the origin and static delivery wherever the page does not genuinely need to be dynamic |
| Long JavaScript tasks | INP | Break long tasks up, yield to the main thread during interactions and reduce DOM complexity. INP is the hardest of the three to fix because it needs architectural change rather than configuration |
| Builder platform overhead | All three | Strip unused blocks and plugins and where the builder itself is the ceiling, tell you plainly rather than optimising around a limit that cannot be moved |
Why this is a revenue question and not a technical one
Performance work is usually filed under engineering hygiene and funded accordingly. That is a mistake. Every visitor lost during load was already paid for, either through ad spend or through the effort that earned the click. They leave before the headline is read, before the offer is seen and before anything you tested has a chance to work. A slow page does not reduce your conversion rate so much as quietly shrink the audience your conversion rate is calculated on.
This is also why performance sits underneath every other service. There is no point running conversion rate optimisation on a page that a quarter of visitors abandon before it renders, because you are testing a message most of your sample never saw.
On page SEO for a landing page
Landing page SEO is narrower than site wide SEO and the constraints are different, because the page usually has to serve paid traffic and organic search at the same time. What we handle:
- Title and meta description. Written for click through rate and not only for keyword presence. The title carries the primary term near the front, the description sells the click.
- Heading structure. One H1 that states what the page is. H2s that reflect the questions searchers actually ask, so the page can be lifted into featured snippets and AI overviews.
- Answer first opening. A direct definition or answer within the first hundred words, which is the block Google most often extracts.
- Entity coverage. Naming the platforms, standards, tools and concepts a genuinely knowledgeable page would name. Search engines increasingly match on topical completeness rather than on keyword repetition.
- Internal linking. Descriptive anchor text pointing to related pages, which distributes authority and helps crawlers understand how the site fits together.
- Structured data. Service, FAQPage and BreadcrumbList markup where it genuinely reflects page content, which improves how the result is displayed.
- Crawl and index hygiene. Canonical tags, XML sitemap inclusion, correct robots directives and no accidental noindex left behind from staging.
The conflict nobody warns you about
Pages built for paid campaigns and pages built for organic search want opposite things and running one page for both jobs causes problems that are easy to prevent and painful to diagnose later.
| Situation | What to do |
|---|---|
| Multiple near identical pages for different ad sets | Apply a canonical tag pointing at the primary version or noindex the campaign variants. Left alone they compete with each other in organic search and split whatever authority the page earns |
| A paid page with navigation stripped out | Fine for paid, weak for organic, because the page has no internal links in or out. If it must rank, it needs contextual links even if the main navigation stays hidden |
| Thin page that converts well on paid | Leave it thin and noindex it. Do not bulk it up with filler to chase rankings. Build a separate page for the organic query instead |
| Seasonal or expired campaign pages | Redirect them to the closest live page rather than deleting them or leaving them to return errors. Accumulated dead campaign URLs are a quiet drag on a domain |
Speed and Google Ads Quality Score
If the page serves paid search, performance has a second commercial effect. Landing page experience is one of the components Google Ads uses to calculate Quality Score and Quality Score influences both your cost per click and your ad position. The practical consequence is that a slow page costs you twice: once in visitors lost during load and again in a higher price for every visitor you do get. Faster pages with strong message match against the ad reduce both.
How an engagement runs
| Stage | What happens |
|---|---|
| Audit | Field data from Search Console and the Chrome User Experience Report, lab traces to find causes, a full third party script inventory and a technical SEO crawl. You get a written diagnosis ranked by impact rather than a tool export |
| Prioritisation | Fixes ordered by effect on the metric that is actually failing. Whatever sits in the poor band first, then INP, then LCP, then CLS. We do not optimise a metric that already passes |
| Implementation | Fixes applied in your stack, with before and after lab traces on every change so the effect is attributable |
| Verification | Field data reviewed after the 28 day window has rolled forward, because that is when the real result becomes visible |
| Monitoring | Alerting on regression, since performance decays quietly every time a new tag or plugin is added by someone who did not know the budget existed |
If your page has structural problems rather than fixable ones, we will say so. Sometimes the honest recommendation is a rebuild and how we build landing pages explains what that involves.
