Fast for the visitor on a mid-range phone, not just in the lab.
Lighthouse runs on a fast machine. Your customers don't. We start from field data, find the templates holding your 75th percentile back, and fix what slows them: images, fonts, JavaScript, and the third-party scripts nobody owns.
Three metrics, judged at the 75th percentile
Google assesses each metric at the 75th percentile of page loads, segmented by mobile and desktop. Interaction to Next Paint replaced First Input Delay as a Core Web Vital on March 12, 2024.
| Metric | Good | What it measures | Usual causes when it's poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | How long the main content takes to appear | A heavy or lazy-loaded hero image, slow server response, render-blocking CSS and fonts |
| Interaction to Next Paint (INP) | 200 milliseconds or less | How quickly the page responds to taps, clicks, and key presses | Long JavaScript tasks, heavy hydration, third-party scripts, large DOM updates |
| Cumulative Layout Shift (CLS) | 0.1 or less | How much content jumps around while the page loads | Images without dimensions, late banners and ads, web fonts swapping in |
Lab data tells you why. Field data tells you whether.
Lab data (Lighthouse)
- One simulated load, on one device profile, from one location
- Repeatable, so it's ideal for debugging and for checking a fix before release
- A standard page-load test can't measure INP, because nobody interacts with the page
- Misses what real visitors bring: older phones, congested networks, signed-in states
Field data (Chrome UX Report and real-user monitoring)
- Real visits on real devices, summarized at the 75th percentile
- The data behind the Core Web Vitals report in Search Console and PageSpeed Insights
- The Chrome UX Report uses a rolling 28-day window, so changes take weeks to show fully
- Real-user monitoring adds attribution: which element, which script, which interaction
Diagnose by template, because that's where the fix lives
Search Console groups similar URLs, and so do we. A slow product page is rarely slow alone. Every product page shares its template, its image logic, and its scripts, so fixing the template improves thousands of URLs together.
We pull Chrome UX Report data for your origin and key URLs, add your real-user monitoring if you have it, and map the poor scores to templates. Then we trace each template in the lab, with throttling set to match the devices your visitors actually use, and attribute the time to specific resources and scripts.
That matters across Kentucky. A visitor on a mid-range Android phone over a rural cellular connection sees a very different page than your team does on office Wi-Fi. We test for that visitor, not the one in the conference room.
A busy main thread is also an accessibility barrier
While JavaScript holds the main thread, the browser can't respond to a key press, move focus, or update the accessibility tree that screen readers read. A keyboard user presses Tab and waits. A screen reader announces a cart update late, after the user has moved on. Those are the same long tasks that push INP past 200 milliseconds.
So our fixes serve both audiences. Breaking long tasks into smaller pieces, yielding to the browser with scheduler.yield() where it's supported, trimming hydration, and removing unused third-party code make the page faster for everyone and more predictable for people using assistive technology.
We test interactions with a keyboard and a screen reader during every sprint, not only with performance tools, so a speed fix never breaks focus order or an announcement.
Where the milliseconds usually go
Images
Load the LCP image early with fetchpriority="high", never lazy-load it, size it with srcset, and serve AVIF or WebP. Give every image dimensions so it can't shift the layout.
Fonts
Subset fonts, preload the one or two used above the fold, and pair font-display with metric-matched fallbacks so text appears quickly and doesn't jump when the web font arrives.
JavaScript
Split bundles by route, defer what first interaction doesn't need, and break up long tasks. On a product page, framework hydration can be the largest single cost.
Third-party scripts
Chat widgets, tag managers, and pixels compete for the same main thread. We measure each one's cost and help you remove, delay, or replace it through tag governance.
Layout stability
Reserve space for banners, ads, and embeds before they load, and animate with transform instead of properties that force layout.
Performance budgets
We set limits on bytes, requests, and main-thread time for each template and add them to your build, so a new feature can't quietly undo the work.
One sprint, verified in the field
Core Web Vitals sprint
Starting at
$5,200
Field-data diagnosis, fixes for your worst LCP, INP, and CLS templates, and a 28-day verification window.
Request a quoteThe sprint includes a 28-day verification window, because that's how long the Chrome UX Report takes to reflect a change fully. Larger platforms are scoped individually.
Questions about scores, rankings, and timing
Why does Lighthouse look fine when Search Console says our pages are poor?
They measure different things. Lighthouse runs one simulated load in the lab, while Search Console reports field data from real Chrome users at the 75th percentile. When they disagree, the field data describes your customers, and the lab helps us find out why.
How soon will we see results?
Lab improvements show up as soon as a fix deploys. The Chrome UX Report uses a rolling 28-day window, so the full effect appears in field data about four weeks after release. Real-user monitoring, if you have it, shows the change within days.
Do Core Web Vitals affect search rankings?
Google says its ranking systems use Core Web Vitals as part of page experience, but relevance and content quality matter far more. We treat speed first as a conversion and accessibility problem; any search benefit is a bonus, not a promise.
Can you work on Shopify, WordPress, or a headless stack?
Yes. The levers differ, such as app embeds on Shopify, plugin weight on WordPress, and hydration strategy in Next.js, but the method is the same: field data, template diagnosis, source fixes, and field verification.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.