Digital Marketing

Landing page speed: the Core Web Vitals fixes that matter

9 min readBy Davinder Kumar Meen

A phone lying beside an alarm clock and a pot of orange pencils on a white desk

A landing page passes Core Web Vitals when, for real visitors at the 75th percentile, the main content appears within 2.5 seconds (LCP), the page responds to taps and clicks within 200 milliseconds (INP) and the layout barely moves (CLS of 0.1 or less). On most landing pages the fixes that matter are few: make the hero image small and load it first, cut the scripts that run when people tap, reserve space for anything that loads late, and make sure ad clicks with tracking parameters are still served from cache.

Key takeaways

  • The three Core Web Vitals and their "good" thresholds, from web.dev: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop separately.
  • Lab tests (Lighthouse) help you debug; field data from real visitors is what Core Web Vitals are. A new or low-traffic landing page often has no field data yet.
  • LCP is usually the hero image or headline. Do not lazy-load it, give it fetchpriority="high", and size it for phones. On our own site, responsive images, WebP and preloading took the home page's lab LCP from 6.7 s to 2.0 s.
  • INP suffers from heavy JavaScript in event handlers and from too many third-party tags. Break long tasks up and remove tags nobody uses.
  • CLS comes from images without dimensions, embeds and banners that push content down, and web fonts. Reserve the space.

What are Core Web Vitals, and what counts as good?

They are three measures of the experience of loading and using a page, defined by Google and documented on web.dev:

Metric What it measures Good Usual culprit on a landing page
Largest Contentful Paint (LCP) When the largest image or text block in view finishes rendering 2.5 s or less An oversized hero image, slow server, render-blocking CSS
Interaction to Next Paint (INP) How quickly the page shows a response after a tap, click or key press 200 ms or less Heavy scripts, chat widgets, tag bloat, large forms
Cumulative Layout Shift (CLS) How much visible content moves unexpectedly 0.1 or less Images without size, late banners, ads, font swaps

A page passes only if all three meet the target at the 75th percentile. INP replaced First Input Delay as the responsiveness metric in March 2024, so older advice that mentions FID is out of date.

Lab or field data: which numbers should you trust?

Field data, for judging; lab data, for debugging. Core Web Vitals are field metrics, and PageSpeed Insights takes its real-user data from the Chrome User Experience Report (CrUX). It shows field data for the page when there is enough of it, falls back to data for the whole site, and shows a Lighthouse lab test underneath. Lab tests run on a simulated phone and connection, so they vary between runs and never match any one visitor.

Landing pages built for a campaign are often new and get modest traffic, so there may be no field data at all. In that case, test in the lab on a mobile profile, run it three times and take the median, and fix the problems the report points to. Then measure real visitors yourself if you need certainty.

How do you fix a slow LCP?

Find the LCP element first (Lighthouse and Chrome DevTools both name it), then work through the four parts web.dev splits LCP into:

  1. Time to first byte. Serve the page from a CDN cache close to the visitor and remove redirects. web.dev warns against URL parameters that stop responses being served from cache.
  2. Resource load delay. Make the browser find the hero image early: put it in the HTML as an img element, not only as a CSS background, or preload it. web.dev's guidance is that lazy-loading the LCP image "will always lead to unnecessary resource load delay".
  3. Resource load duration. Make the file small: serve WebP or AVIF, provide srcset sizes so phones download a phone-sized image, and compress.
  4. Element render delay. Trim render-blocking CSS, inline small critical styles, and defer scripts in the head.

Add fetchpriority="high" to the one image you expect to be the LCP element; web.dev notes that setting it on more than one or two images makes it unhelpful.

A real example: when we moved impingesolutions.com from WordPress to Astro in October 2026, the first build of the new home page had a lab LCP of 6.7 seconds because images shipped at full size. Responsive images, WebP and preloading the hero brought it to 2.0 seconds (Lighthouse, simulated mobile, median of three runs). The full before-and-after is in our WordPress to Astro migration write-up.

Why can ad clicks be slower than your own tests?

Because ad clicks arrive with extra parameters. Google Ads auto-tagging adds a click ID (the gclid parameter) to the URL, and campaigns often add UTM tags, so every click can have a unique address. If your CDN or page cache treats each unique URL as a new page, every ad visitor misses the cache and waits for the server, while your test of the clean URL looks fast.

Check by testing the landing page with a sample click ID and UTM tags on the URL. If the first byte is much slower than on the clean URL, configure the cache to ignore those tracking parameters when deciding what to serve (the analytics tags can still read them in the browser). This is the "cache-busting URL parameters" problem web.dev describes, and it is easy to miss on pages that only ever receive paid traffic.

How do you fix a poor INP?

web.dev splits every interaction into three phases: input delay (waiting for the main thread to be free), processing duration (your event handlers running) and presentation delay (the browser drawing the next frame). The fixes follow from that:

  • Do less on the main thread at load. Long tasks during load are why the first tap on a fresh landing page often feels slow. Defer non-essential scripts until after the page is usable.
  • Break up long event handlers. Do the visible update first, then yield to the main thread before the rest of the work; web.dev says yielding at all is better than not yielding.
  • Avoid layout thrashing. Do not read layout values straight after changing styles in the same task.
  • Keep the DOM small. Large pages cost more to update on every interaction.
  • Audit third-party tags. Tag managers make adding tags easy and removing them rare. Chat widgets, heatmaps, multiple analytics tools and old pixels all compete for the same thread. Keep the tags that feed a decision and remove the rest.

Test interactions that matter on a landing page: opening a menu, focusing the first form field, choosing an option, pressing submit.

How do you fix layout shift (CLS)?

Reserve space for everything before it arrives. The main causes and fixes from web.dev:

Cause Fix
Images and video without dimensions Always set width and height attributes, or a CSS aspect-ratio
Ads, embeds and iframes Reserve space with min-height or aspect-ratio; keep the space if nothing loads
Content injected above what the visitor is reading Place late content lower, or show it only when the visitor asks for it
Web fonts swapping in Use a close fallback font with size adjustments, preload the critical font, or font-display: optional
Animations of top or left Animate with transform instead

Banners are a common source on landing pages: a cookie notice, a promotion bar or a form validation message that pushes the page down. Show them as overlays or in reserved space. web.dev also recommends making pages eligible for the back/forward cache, so returning visitors see the page restored without load-time shifts.

Which fixes should you do first?

If this fails Start with
LCP The hero image: size, format, priority, no lazy-loading; then caching and redirects
INP The heaviest third-party scripts and any work done on the first tap
CLS Image dimensions and the banner or embed that moves
All three on a WordPress page builder Our guide to speeding up WordPress covers hosting, caching and plugins

Does landing page speed affect ads and SEO?

It affects both, though neither as a single switch. Google Search's documentation says achieving good Core Web Vitals, along with other page experience aspects, "aligns with what our core ranking systems seek to reward". For Google Ads, Google's landing page guidance tells advertisers to make pages load quickly, and landing page experience is one of the three parts of Quality Score. Our article on Google Ads landing pages and Quality Score covers the ads side.

The more direct effect is on the visitors you have already paid for: a page that is slow to show its offer or slow to respond to a tap loses some of them before they read anything. Our website solutions team builds and tunes landing pages with these targets in the brief from the start.

FAQ

What is a good LCP for a landing page?

2.5 seconds or less for the 75th percentile of real visits, measured separately for mobile and desktop. That is the "good" threshold on web.dev.

My Lighthouse score changes every run. Which one is right?

None exactly. Lab tests vary with the test machine and network. Run three tests and take the median, and prefer field data when PageSpeed Insights has it.

Why does my landing page have no field data?

Field data needs enough real Chrome visits. New and low-traffic pages often do not have it. Use lab tests to fix problems and check field data once traffic builds.

Should I lazy-load all images?

No. Lazy-load images below the first screen, but never the hero or any image likely to be the LCP element.

Do tag managers slow pages down?

The tag manager itself is usually small; the tags inside it are what cost time, especially on INP. Review the tags you load on landing pages and remove any that no one uses.

Is page speed a Google ranking factor?

Google says good Core Web Vitals align with what its core ranking systems reward, but relevance and content matter more. Treat speed as necessary, not sufficient.

Sources (10 links)
Share this article