---
title: "How to Improve Core Web Vitals: A Field-Data Playbook"
description: "Find the failing metric and template in Search Console, fix LCP, INP and CLS by cause, and confirm it in field data, with notes for 3D sites."
url: "https://dardo.studio/en/blog/pass-core-web-vitals/"
language: "en"
translations: {"es":"https://dardo.studio/es/blog/mejorar-core-web-vitals/","pt":"https://dardo.studio/pt/blog/melhorar-core-web-vitals/"}
updated: "2026-10-15T13:33:12.800Z"
---

[Blog](https://dardo.studio/en/blog/)

# How to improve Core Web Vitals: a field-data-first playbook for marketing sites

Find the failing metric and template in Search Console, fix LCP, INP and CLS by their cause, then confirm the result in field data about 28 days later.

By [Nicolás Cerón](https://dardo.studio/en/nicolas-ceron/) ·October 15, 2026

![A misty railway yard at blue hour under amber lamps, where one crimson rail line curves through rows of grey tracks toward a lit signal box at an open gate.](https://dardo.studio/_astro/01M4YY262MHNX487SWZ7QSA1V6_Z1igRsR.webp)

## Key takeaways

- Start in Search Console's Core Web Vitals report: it groups similar URLs, labels each group by its worst metric and lists its pages by impressions, so you fix a template, not a page.
- In Google's analysis of Chrome field data, the median site with poor LCP waited 1.29 seconds before requesting its LCP image and spent 350 milliseconds downloading it, so fix discovery and priority before compression.
- INP counts only clicks, taps and key presses; on marketing sites the slow one is often a consent banner's Accept button or a tag that runs during load.
- Lighthouse sees one page load, while CrUX counts layout shifts for the whole visit, including content that lazy-loads during scrolling and shifts triggered by hovering.
- Google's field data is a rolling 28-day window, so note each release date and judge a fix about four weeks later.

## The short answer

Improving Core Web Vitals starts with Google's field data, not with a Lighthouse score. Find which metric fails, on mobile or desktop, and on which page template, in Search Console's Core Web Vitals report. Then fix the cause behind that metric: for Largest Contentful Paint (LCP) it's usually how late the browser discovers the main image or text, for Interaction to Next Paint (INP) a script that keeps the main thread busy when someone taps, and for Cumulative Layout Shift (CLS) content that arrives without reserved space. Fix the template, write down the release date and judge the result about 28 days later, once Google's rolling window holds only visits to the new code.

This is the playbook we follow on our own site and in client audits. If you'd rather hand it over, it's what our [website speed optimization](https://dardo.studio/en/services/website-speed-optimization/) service does; that page also covers cost and rankings.

On phones, LCP is the metric sites fail most often. HTTP Archive's [2025 Web Almanac](https://almanac.httparchive.org/en/2025/performance), built on Chrome field data, found good LCP on 62% of mobile sites, against 77% for INP and 81% for CLS; 48% passed all three.

## Step 1: find the failing metric and the template

A page passes when 75% of its visits get LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, measured separately for mobile and desktop. Open Search Console's Core Web Vitals report and start with mobile. It groups similar pages and gives each group the status of its worst metric, so a group with good LCP and poor CLS is poor ([Search Console Help](https://support.google.com/webmasters/answer/9205520)). Each example URL stands for a group whose pages are listed by impressions, which tells you which template to fix first.

To see how your platform's sites do on average in your visitors' country, our [website platform speed report](https://dardo.studio/en/tools/website-platform-speed-report/) ranks 31 platforms by real-user Core Web Vitals, updated monthly from the HTTP Archive.

Then narrow it down:

- **PageSpeed Insights** shows one URL's last 28 days, updated daily, and falls back to the whole origin when the page has too few visits. Check which one you're reading.
- **CrUX Vis**, at cruxvis.withgoogle.com, charts the same data week by week for the past 40 weeks ([Chrome for Developers](https://developer.chrome.com/docs/crux/history-api)). A metric that turned poor in one week usually points to a release, a new tag or a campaign.
- **The CrUX API** also reports the LCP resource type and, for image LCPs, each LCP subpart at the 75th percentile, so you can see where the time goes before you open DevTools.

When there's no field data at all, the site is usually below Chrome's popularity threshold. That's our own case: on 14 October 2026, PageSpeed Insights had no field data for dardo.studio, either for the page or the origin. So we measure our visits with Google's open-source web-vitals library, without cookies, grouped by page type and screen size. Two rules from running it: a visit with no tap or key press has no INP, so never record it as zero, and our small and large screen groups aren't Google's mobile and desktop, so we don't compare them one-to-one with CrUX. Setting this up is part of our [analytics setup](https://dardo.studio/en/services/analytics-setup/) work.

## Step 2: reproduce it in the lab and read the cause

Lab tools find causes; field data says whether you pass. Record a trace in the Chrome DevTools Performance panel with CPU throttling calibrated to a mid-tier phone, available since Chrome 134. Throttling slows the processor, not the graphics chip, so effects that are heavy on the GPU only show their real cost on a physical phone ([Chrome for Developers](https://developer.chrome.com/blog/devtools-grounded-real-world)).

Our homepage shows why the score is only a starting point. In that PageSpeed Insights run, Lighthouse's emulated Moto G Power on slow 4G put LCP at 6.0 seconds, while our own measurement, from a small sample, had the homepage's LCP at 1.1 seconds at the 75th percentile on small screens over the seven days to 3 October. The useful part was the diagnosis: the LCP element is the h1 headline, not the 3D scene, and the breakdown showed a 10-millisecond server response followed by 1,460 milliseconds of element render delay. That points to fonts and render-blocking work, not to images.

## Fix LCP by the subpart that's too long

Every LCP splits into four consecutive parts: time to first byte, resource load delay until the browser requests the LCP resource, the resource's load duration and element render delay ([web.dev](https://web.dev/articles/optimize-lcp)). Fix the part that's out of proportion.

| LCP subpart            | Healthy share of LCP | What usually makes it long                                                                             | First fix                                                                           |
| ---------------------- | -------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- |
| Time to first byte     | About 40%            | Redirect chains, uncached HTML, a distant server, query strings that bypass the cache                  | Cache the HTML at a CDN and remove redirect hops                                    |
| Resource load delay    | Under 10%            | A hero image set in CSS or JavaScript, lazy-loaded, inside a carousel or on another host               | An img tag in the HTML with fetchpriority="high", or a preload when CSS must set it |
| Resource load duration | About 40%            | Oversized files and a single size for every screen                                                     | Responsive sizes in AVIF or WebP                                                    |
| Element render delay   | Under 10%            | Render-blocking CSS and scripts, web fonts for a text LCP, a hero that waits for JavaScript to fade in | Inline critical CSS, defer scripts, render the hero in HTML, set font-display       |

The shares are web.dev's guideline for a well-optimized page, not targets in seconds.

Start with the delays. In Google's analysis of Chrome field data, the median site with poor LCP waited 1,290 milliseconds between the first byte and the request for its LCP image, then spent 350 milliseconds downloading it; most sites with poor LCP spend less than 10% of it on the download ([web.dev](https://web.dev/blog/common-misconceptions-lcp)). Compress the hero anyway; alone, it rarely fixes a failing LCP. The Almanac still found about 16% of pages lazy-loading their LCP image.

Two details catch marketing sites:

- **Full-screen hero images don't count.** LCP treats elements that cover the whole viewport as background and skips them, so the LCP is often the headline instead; text was the LCP element on 23.7% of mobile pages. Text isn't counted as painted while its web font is in its block period, so font loading becomes your LCP work.
- **Priority is relative.** Setting fetchpriority="high" on more than one or two images cancels the benefit, and every preload competes with what paints first. The 3D section below shows that trade-off on our homepage.

## Fix INP by naming the script first

INP is the slowest click, tap or key press in a visit, ignoring one for every 50 interactions; hovering and scrolling don't count ([web.dev](https://web.dev/articles/inp)). Each interaction has three parts: input delay while other work finishes, processing in your event handlers, and presentation delay until the next frame is painted.

Find the interaction and the script before changing anything. The attribution build of [web-vitals](https://github.com/GoogleChrome/web-vitals) reports the element that was tapped, the three parts, whether the page was still loading and the long animation frames that overlapped it. Since Chrome 123, those frames name each script that ran longer than 5 milliseconds by its URL, which is how you tell your code from a vendor's ([Chrome for Developers](https://developer.chrome.com/docs/web-platform/long-animation-frames)). Scripts inside cross-origin iframes aren't named.

On marketing sites, the slow interaction is usually one of these:

- **The consent banner's Accept button.** Accepting often starts every marketing tag at once. The Chrome team has worked with consent platforms to yield right after the click, so the browser acknowledges it in the next frame ([web.dev](https://web.dev/articles/cookie-notice-best-practices)); if yours doesn't, ask the vendor.
- **Tags that fire during load.** A tap that lands while tags are running waits for them. In Google Tag Manager, image tags cost the least and Custom HTML tags the most, and non-essential tags should fire after Window Loaded ([web.dev](https://web.dev/articles/tag-best-practices)).
- **Menus, accordions and filters** that change styles and then read layout in the same handler, which forces the browser to lay out the page on the spot.

To fix your own long tasks, split them and yield to the main thread right after the visual update. scheduler.yield() does that with priority in Chrome and Edge 129 and later and Firefox 142 and later; Safari doesn't support it as of October 2026, so fall back to setTimeout ([web.dev](https://web.dev/articles/optimize-long-tasks)). Check deeper pages too: in the Almanac, 80% of mobile home pages had good INP but only 69% of other pages, where filters, carousels and widgets pile up.

## Fix CLS by reserving space, including after load

Lighthouse measures one page load. CrUX counts shifts for the whole visit, grouped into bursts of up to five seconds, and reports the worst burst ([web.dev](https://web.dev/articles/cls)). That's why a page can look stable in the lab and fail in Search Console. Shifts within 500 milliseconds of a click, tap or key press are excluded, but shifts triggered by hovering aren't, and neither is content that lazy-loads into place while someone scrolls.

The fixes:

- Give every image and video width and height attributes, or a CSS aspect-ratio. In 2025, 62% of mobile pages had at least one image without dimensions.
- Reserve a slot with min-height or aspect-ratio for embeds, forms and other late content, and keep the space if nothing loads into it.
- Show cookie and promotion banners as overlays instead of pushing the page down.
- Match the fallback font to the web font with size-adjust and the ascent and descent overrides, or use font-display: optional.
- Animate with transform, not with top, left, width or height.

Then make back and forward navigations free. One navigation in five on mobile is back or forward, and a page restored from the back/forward cache returns exactly as it was left, without shifting again ([web.dev](https://web.dev/articles/bfcache)). Remove unload handlers, add Permissions-Policy: unload=() so third parties can't add them, avoid Cache-Control: no-store on public pages, and test in DevTools under Application, Back/forward cache.

## Page transitions change what gets measured

If your site swaps pages with JavaScript, as single-page apps, Astro's client router, Next.js links and page-transition libraries do, Chrome has long treated the whole visit as one page load: every interaction and layout shift after the first page counts against the URL the visitor landed on. Chrome 151 introduced soft navigation APIs that measure each route separately. As of October 2026, Chrome publishes experimental soft navigation metrics in CrUX and aims to make them standard in May 2027, but most tools don't show them yet ([web.dev](https://web.dev/articles/vitals-spa-faq)).

This affects our own numbers: in a 24-hour sample on 3 October, 29 of the 45 views of dardo.studio were soft navigations. Until your tools report routes separately, test INP and CLS on the pages people reach after landing, not only on the landing page.

## 3D and motion-heavy pages need their own marks

Our guide to [3D websites](https://dardo.studio/en/blog/3d-websites/) covers model and texture budgets. Four lessons from measuring our homepage's real-time 3D scene:

- **LCP doesn't measure the scene.** Our LCP is the headline, so LCP can be good while the scene is still dark. Add a User Timing mark when the first 3D frame appears and report it alongside your vitals.
- **Look for import waterfalls.** Our opening loaded its modules one after another, each one discovering the next. Requesting them together cut the dark interval before the scene from a median of 1,214 to 697 milliseconds, in five interleaved cold runs of each local production build with 150 ms of latency, 9 Mbps and a CPU slowed four times.
- **Test preloads both ways.** Low-priority modulepreload hints for the same modules made the scene ready about 60 milliseconds sooner but delayed the first paint by about 120, so we left them out.
- **Watch the first interaction with a section.** With the CPU slowed four times, the first hover over our services section produced a 92-millisecond task, a setup cost later hovers didn't pay. Hovering doesn't count toward INP, but a tap that lands during that task waits for it.

Building scenes like this is our [interactive 3D websites](https://dardo.studio/en/services/interactive-3d-websites/) service.

## Verify in field data about 28 days later

Lab tests confirm a fix the day it ships; Google's field data, a rolling 28-day window, takes weeks.

1. **Ship one fix per release where you can, and note the date.** Two fixes in one release can't be told apart afterwards.
2. **Read your own measurement first.** Compare visits after the release with visits before it; a rolling 28-day report blends the old build with the new one.
3. **Read CrUX weekly, not daily.** The CrUX History API updates on Mondays with data to the previous Saturday, and each weekly point shares three weeks of visits with the one before. The first point built only from visits after the release arrives about four weeks after you ship.
4. **Start validation in Search Console** once every URL in the group is fixed. It monitors for 28 days and fails if any URL still shows the issue.
5. **Check the margins.** A group near a threshold can flip after a traffic swing or a slower image host with no code change, as Search Console's help notes.

Keep the gains by reviewing Core Web Vitals every month against new tags, images and embeds; our [website maintenance](https://dardo.studio/en/services/website-maintenance/) plans include that monthly report. If rankings are the goal behind the work, pair it with [technical SEO](https://dardo.studio/en/services/seo/), since Core Web Vitals are one signal among many. And if you'd like a second look, [send us the URL and the template that fails](https://dardo.studio/en/contact/?service=website-speed-optimization): we'll tell you which metric and which part of it to start with.

## Common questions

**How long does it take for Core Web Vitals improvements to show in Search Console?**

About four weeks. Search Console and PageSpeed Insights read Chrome's field data as a rolling 28-day window, so visits to a fix shipped today are blended with older visits until the window rolls over. Lab tests and your own real-user measurement show the change within days. Once every URL in a group is fixed, start validation in the Core Web Vitals report, which monitors the group for 28 days.

**Why does PageSpeed Insights show no field data for my site?**

Chrome's field data only includes pages and origins that are publicly discoverable and visited by enough eligible Chrome users. A page with too few visits falls back to origin-level data, and a small site may have none at all; dardo.studio had none on 14 October 2026. In that case, measure LCP, INP and CLS on your own visits with the open-source web-vitals library and use lab tests to find causes.

**My Lighthouse score is low but my Core Web Vitals pass. What should I fix?**

Field data decides whether you pass; Lighthouse is one simulated load on a mid-tier phone over a slow connection. Use its diagnostics, such as the LCP element and its breakdown, to find causes that also appear in field data, and don't chase the score itself. The opposite happens too: a page can score well in Lighthouse and fail INP or CLS in the field, because Lighthouse sees neither taps nor shifts after load.

**Which Core Web Vital should I fix first?**

The one that's poor for the most visits, starting with the mobile groups that get the most impressions in Search Console. On phones that's most often LCP: in HTTP Archive's 2025 data, 62% of mobile sites had good LCP, against 77% for INP and 81% for CLS. Within LCP, start with the subpart that's out of proportion, usually resource load delay or time to first byte, before compressing images.

**Can a plugin or a CDN fix Core Web Vitals automatically?**

Partly. A CDN that caches HTML shortens time to first byte, and image optimization shortens the download. Neither decides which element becomes your LCP, which scripts run when someone taps, or where space is reserved for an embed or a banner, and those are the usual causes of poor LCP, INP and CLS. They live in templates and tag settings, so that's where they're fixed.

**Do Core Web Vitals measure each page of a site with page transitions?**

Not in most tools yet. When JavaScript swaps pages without a full load, Chrome has counted every later interaction and layout shift against the URL the visitor landed on. Chrome 151 added APIs that measure each soft navigation separately, and Chrome began publishing experimental soft navigation metrics in CrUX in October 2026, aiming to make them standard in May 2027. Until then, test INP and CLS on the pages people reach after landing.

## Sources & further reading

Sources behind this page, with further detail from the original publishers.

- [web.dev: Web Vitals](https://web.dev/articles/vitals) · web.dev
- [Search Console Help: Core Web Vitals report](https://support.google.com/webmasters/answer/9205520) · support.google.com
- [Chrome for Developers: CrUX History API](https://developer.chrome.com/docs/crux/history-api) · developer.chrome.com
- [Google for Developers: About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) · developers.google.com
- [web.dev: Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp) · web.dev
- [web.dev: Common misconceptions about how to optimize LCP](https://web.dev/blog/common-misconceptions-lcp) · web.dev
- [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) · web.dev
- [Chrome for Developers: Long Animation Frames API](https://developer.chrome.com/docs/web-platform/long-animation-frames) · developer.chrome.com
- [web.dev: Optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls) · web.dev
- [web.dev: Back/forward cache](https://web.dev/articles/bfcache) · web.dev
- [web.dev: Core Web Vitals and single-page apps FAQ](https://web.dev/articles/vitals-spa-faq) · web.dev
- [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) · almanac.httparchive.org

[Nicolás Cerón](https://dardo.studio/en/nicolas-ceron/)

Nicolás Cerón is the founder of Dardo, a brand, web design and development studio in Bogotá, Colombia.

## Related articles

- [**3D websites: when they're worth it and how to keep them fast**When a 3D website earns its place, when video or images work better, and how we kept Janus Observatory's ten 3D worlds fast, accessible and usable.](https://dardo.studio/en/blog/3d-websites/)
- [**PostHog vs Google Analytics: which one a marketing site or SaaS product needs, and when to run both**GA4 links to Google Ads and Search Console; PostHog adds replay, feature flags and experiments. Which one you need, what each costs and how to run both.](https://dardo.studio/en/blog/ga4-vs-posthog/)
- [**Webflow vs WordPress in 2026: real costs, editing, SEO and speed**What a bilingual 20-page site with a 300-post blog costs over three years on Webflow and WordPress, and how editing, SEO, speed and security compare.](https://dardo.studio/en/blog/webflow-vs-wordpress/)
- [**Core Web Vitals in Latin America: how many sites pass in each country, and why mobile fails (2026 data)**In September 2026, a third of sites passed Core Web Vitals for mobile visitors in Colombia and Brazil, against 63% in the US. Data by country and what to do.](https://dardo.studio/en/blog/core-web-vitals-latin-america/)

## Keep exploring.

- [Service · **Website speed and Core Web Vitals optimization**](https://dardo.studio/en/services/website-speed-optimization/)

- [Your project · **Start a conversation**](https://dardo.studio/en/contact/)