Short answer
A good experience, by Google's definition, means the main content appears within 2.5 seconds, responses to taps arrive within 200 milliseconds and layout shift stays at 0.1 or below, for at least three in four page loads. This service works through the causes of a failing metric on your key templates until it passes in the lab, then watches field data as it updates.
The three metrics this service targets
Core Web Vitals describe three parts of a visit. Largest Contentful Paint measures loading: web.dev says it "should occur within 2.5 seconds of when the page first starts loading." Interaction to Next Paint measures responsiveness, where pages "should have a INP of 200 milliseconds or less." Cumulative Layout Shift measures visual stability, with a target of 0.1 or less [1]. Google recommends judging each at "the 75th percentile of page loads, segmented across mobile and desktop devices" [1], which means three out of four visits need to meet the threshold, not just the average one.
Since March 12, 2024, INP has stood in the place First Input Delay used to hold [2]. If an older report or plugin still talks about FID, its advice may be out of date.
How we fix Largest Contentful Paint
web.dev splits LCP into four subparts, from server response through download to the final render. As a rough guide, it suggests server response and download time should each take about 40% of the total, with the two delays under 10% each [3]. Knowing which subpart is too large tells us what to fix.
- A long time to first byte points to the server, the cache or the CDN.
- A long load delay usually means the browser found the main image late, for example because it was set in CSS, injected by JavaScript or lazy-loaded. web.dev is blunt on the last point: "Never lazy-load your LCP image" [3].
- A long download points to an oversized or poorly compressed image.
- A long render delay points to render-blocking CSS, fonts or scripts.
The discovery problem is common: 35% of image LCP elements had source URLs that were not discoverable in the initial HTML, according to HTTP Archive's 2024 Web Almanac, as cited by web.dev [4].
How we fix Interaction to Next Paint
An interaction has three phases: input delay, processing duration and presentation delay [5]. Slow INP is almost always a JavaScript problem. We look for event handlers that do too much at once, third-party scripts that occupy the main thread, and large DOM updates after a click. The fixes include breaking long work into smaller tasks, yielding to the main thread so the browser can paint, deferring work that does not affect the next frame, and removing scripts that are not needed. web.dev puts it simply: "Yielding indiscriminately is better than not yielding at all" [5].
How we fix Cumulative Layout Shift
The usual causes are images, ads, embeds and iframes without dimensions, content injected above existing content, and web fonts that change size when they load [6]. We set width and height or an aspect ratio on media, reserve space for late content, adjust font loading and fallback metrics, and check that pages can use the back/forward cache, which Google credits with the biggest CLS improvement of 2022 [4].
How the work is released
We make changes on a staging copy, test them on the same templates as the starting point, and release them in small groups so any problem can be traced to one change. Lab results confirm a change worked straight away. Field data takes longer: PageSpeed Insights reports the previous 28 days [7], and Search Console's Core Web Vitals report validates fixes over a 28-day monitoring session [8]. We therefore book a follow-up check about four weeks after release.
What success looks like
The goal is that each targeted template passes all three thresholds in field data on mobile and desktop. Where a site has no field data, we test under realistic mobile settings, aiming for a pass in the lab, within the scope agreed in the quote. We do not promise rankings. Google says Core Web Vitals are used by its ranking systems, but also that it "always seeks to show the most relevant content, even if the page experience is sub-par" [9].
A typical sequence of work
Most Core Web Vitals projects follow a similar order. First, confirm from field data which metric fails, on which device type and in which URL groups. Second, pick one representative template per failing group and reproduce the problem in the lab with throttling turned on [10]. Third, fix the largest cause for that metric, retest in the lab, and only then move to the next cause. Working one cause at a time keeps it clear which change produced which improvement.
LCP fixes tend to come first because they often involve server response and images, and because LCP is the metric mobile sites most often fail: HTTP Archive's 2025 Web Almanac found 62% of mobile websites had good LCP, compared with 77% for INP and 81% for CLS [11].
Where this service stops
This service concentrates on the three metrics. If the audit shows that a metric fails because of something broader, such as a theme that ships far more code than any page needs, or hosting that cannot respond quickly even with caching, we explain the options and quote the related work separately, for example technical cleanup or caching and CDN setup. That keeps each quote clear about what it covers.
What you receive
- The starting field data and lab measurements for each targeted template, with dates.
- A log of every change with the metric it targets and how to reverse it.
- Lab results after each group of changes, under the same settings as the baseline.
- A follow-up comparison of field data about four weeks after release.
- Notes for your team on keeping the gains, such as how to add images and scripts without undoing the work.
Questions about Core Web Vitals work
Which metric do you fix first?
The one failing on the templates with the most traffic. Search Console groups similar URLs, and a group takes the status of its worst metric, so one failing metric can mark a whole group as poor.
Why does Search Console still show poor URLs after the fix?
Its data comes from a rolling window of real visits, so older slow visits keep counting for up to four weeks. Starting validation in the report begins a 28-day monitoring session.
Can every site pass all three metrics?
Most can get much closer, but some limits sit outside the code, such as a slow hosting plan or a required third-party tool. We will explain any limit we find and the options for dealing with it.
Sources
Opened and checked on November 3, 2026.
- Web Vitals, web.dev (Google Chrome team). Primary documentation, last updated October 31, 2024.
- Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev blog, Jeremy Wagner and Rick Viscomi. Primary announcement, last updated January 31, 2024.
- Optimize Largest Contentful Paint, web.dev. Primary documentation, last updated March 31, 2025.
- The most effective ways to improve Core Web Vitals, web.dev. Primary documentation (cites HTTP Archive and Chrome data), last updated October 31, 2024.
- Optimize Interaction to Next Paint, web.dev. Primary documentation, last updated September 2, 2025.
- Optimize Cumulative Layout Shift, web.dev. Primary documentation, last updated February 7, 2025.
- About PageSpeed Insights, Google for Developers. Primary documentation, last updated October 21, 2024.
- Core Web Vitals report, Search Console Help. Primary documentation, checked November 3, 2026.
- Understanding Google Page Experience, Google Search Central. Primary documentation, last updated September 22, 2026.
- Throttling, Chrome DevTools documentation. Primary documentation, last updated April 16, 2024.
- Performance, The 2025 Web Almanac, HTTP Archive (Himanshu Jariyal, Prathamesh Rasam, Humaira and Aaron T. Grogg). Research report (secondary analysis of public datasets), published January 15, 2026, last updated May 5, 2026, based on July 2025 data.