LCP under 2 seconds, CLS under 0.1, INP under 200ms — with measurable organic traffic lift. Same engineer who took Cuez from 3 seconds to 300ms.
- Design
- Build
- Launch
fixed-price project
Who this is for
You're an e-commerce owner or B2B marketer watching organic traffic slip after a Core Web Vitals downgrade: LCP stuck above 4 seconds on mobile, Search Console full of flagged URLs, and a paid search quality score that keeps eroding. A cache plugin hasn't moved the needle. You need someone who finds the actual bottleneck and fixes it, not another report that explains what a bottleneck is.
The pain today
- LCP stuck above 3 seconds on mobile despite cache plugin claims
- Google Search Console flagging hundreds of poor URLs in Core Web Vitals
- Paid search quality score dropping because landing pages load slowly
- INP failures from heavy JavaScript — tag manager, hydration bundles, third-party chat
- No single person owns front-end performance, so nothing gets fixed
The outcome you get
- Sub-2-second LCP on target pages, verified in both lab and real-user field data
- Green Core Web Vitals in Search Console within 28 days of changes shipping
- Before/after deliverable: Lighthouse, PageSpeed Insights, and CrUX comparison
- Speed budget and regression alerts so the site stays fast after I leave
- Organic traffic lift on improved pages within 60 days, tracked in Search Console
Why Core Web Vitals move rankings in 2026
Google uses LCP, INP, and CLS as ranking signals on commercial queries. When a site drops from "Good" to "Needs Improvement" across those three, Search Console flags the URLs and organic traffic typically softens within 4–8 weeks on competitive terms. INP became a full ranking signal in March 2024, replacing FID, and it catches something FID never did: slow responses caused by heavy JavaScript bundles long after the page has loaded.
The fix window mirrors the damage window. Reverting from "Needs Improvement" to "Good" tends to recover rankings within a similar 4–8 week period once field data updates. That's the business case for speed work — it's measurable, reversible, and the timeline is predictable.
Sub-2-second LCP on target pages, verified in both lab and real-user field data
Three tiers of audit I run before touching a line of code
Tier one: synthetic lab tests against the top 5–10 pages by traffic. Lighthouse, WebPageTest, PageSpeed Insights — a clean baseline of scores across LCP, INP, CLS, and TTFB. Fast to run, shows the biggest offenders immediately.
Tier two: field data from the Chrome UX Report over 28 days. This is what Google actually uses for ranking. Lab scores and field scores often diverge, sometimes by more than a second on LCP, because real users have slower devices and worse connections than a lab test assumes.
Tier three: a waterfall teardown of the slowest page. Which resource is blocking LCP? Which script pushes INP into the red? Which element is shifting layout after the hero image loads? Tier three is where I find the real root cause. Most of the time, the Lighthouse report points at a symptom — the waterfall shows the source.
3s → 300ms: API response time.
The five fixes that move the needle fastest
I've run this pattern on enough sites to know where 60–80% of the gain usually lives.
First: hero images served as AVIF or WebP with explicit width and height attributes declared in HTML. Missing dimensions cause CLS; oversized images cause LCP. Both are common, both are fixable in a day.
Second: critical CSS inlined above the fold, the rest deferred or loaded async. Render-blocking stylesheets are still the single most frequent LCP killer I see in audits.
Third: server response time (TTFB) below 500ms. If the HTML itself takes 1.2 seconds to arrive, no amount of image optimization closes the gap. CDN caching, edge routing, or switching to static generation often cuts TTFB by 60–80% in a single deployment.
Fourth: third-party scripts — analytics, chat widgets, ad pixels — loaded with correct priority hints or migrated server-side. A tag manager firing 12 scripts before page paint can add 800ms to INP alone.
Fifth: font loading with font-display: swap and a preconnect hint to the font host. Web fonts are responsible for LCP delays on a surprising share of marketing sites. The fix takes about 20 minutes. The gain is often 300–600ms.
The Cuez benchmark: 3 seconds to 300ms
At Cuez, the core API was responding in 3 seconds. I took it to 300ms — a 10x speedup. The work combined query optimization, Redis caching at strategic layers, and removing work from the hot request path. Infrastructure cost dropped roughly 40% as a side effect.
The same diagnostic instinct applies to front-end performance. Slow LCP usually comes from one or two resources, not twenty. Slow INP usually comes from one long-running JavaScript task. Slow TTFB usually comes from one uncached database query or one missing CDN rule. My job on a speed engagement is to find that one thing quickly, fix it surgically, and prove the win in production data before moving to the next layer.
What the deliverable looks like
Every speed engagement ships the same package at close. An audit report covering lab and field baselines for LCP, INP, CLS, and TTFB on every target page. A change log documenting what was changed, why, and what was measured before and after each change. A before/after comparison: Lighthouse scores, PageSpeed Insights scores, and CrUX field data once the 28-day window clears. A speed budget — target thresholds per metric per page type — so your team knows when a future deploy has regressed performance. And a 28-day Search Console check-in after all changes are live.
Timeline for a focused scope of 5–10 pages: 2–3 weeks. Larger sites take longer. Pricing fits the Websites Starter or Business tier — typically $2,999–$7,999 fixed-price depending on scope and platform complexity.
What happens if the platform is the problem
Speed work is surgical. I don't re-theme the site, I don't rebuild the CMS, and I don't re-scope content strategy unless one of those is genuinely the bottleneck. The engagement stays focused on performance metrics.
Sometimes it isn't. WordPress sites running 30 active plugins, old PHP stacks with no caching layer, or JavaScript frameworks hydrating 2MB of client-side state on every page load — these are platform-level problems that a performance pass can mask but not fix. When I find that situation, I say so directly and scope a separate replatform engagement instead of shipping partial wins that regress in two weeks.
I've turned down speed work for exactly this reason. The 14-day money-back guarantee exists for the cases where the honest answer only becomes clear a week in.
Recent proof
A comparable engagement, delivered and documented.
Rescued a slow API that was blocking user growth
Cuez is a live broadcast production tool used by TV teams on air across Europe. I inherited a backend API averaging 3 seconds per response and cut it to 300ms, while reducing infrastructure costs by 40% and leaving the system stable under real production load.
Read the case studyKeep reading
Frequently asked questions
The questions prospects ask before they book.
For a focused scope of 5–10 pages, the typical timeline is 2–3 weeks: a few days for the audit, a week for implementation, and a few days for testing and a final review pass. Larger sites or platforms with complex build pipelines take longer. Field data in Search Console then takes a further 28 days to reflect the changes, since Google's CrUX report is a rolling 28-day window.
Yes — Google has confirmed Core Web Vitals as ranking signals since 2021, and INP joined as a full signal in March 2024. The effect is most visible on competitive commercial queries where multiple pages have similar content quality. Sites in the 'Needs Improvement' band tend to rank 2–5 positions below equivalent pages that are in the 'Good' band on mobile.
Google's 'Good' threshold is LCP under 2.5 seconds at the 75th percentile of real users on mobile. I aim for under 2.0 seconds on target pages to leave headroom for content changes and third-party scripts that inevitably get added later. Static marketing pages with a CDN can often hit under 1.0 second. E-commerce category pages with dynamic content typically land in the 1.5–2.0 second range after optimization.
Core Web Vitals in Search Console are derived from 28 days of real-user field data, so the Google-facing numbers update gradually rather than all at once. Lab scores in Lighthouse and PageSpeed Insights update immediately after fixes ship. I track both and report weekly until the full 28-day field window has cleared, at which point the Search Console status should show the improved rating.
Common situation. Many scripts can be moved server-side — GTM server containers, analytics via Measurement Protocol, conversion pixels via server-to-server API. For scripts that genuinely have to fire client-side, I defer them with correct priority attributes and measure the INP and LCP cost. If a script is non-negotiable and costly, I document the performance tradeoff so the marketing team can make an informed decision rather than leaving it as an invisible tax on rankings.
All three. LCP gets the most attention because it tends to show the biggest gains, but INP and CLS are both ranking signals and both show up in Search Console reports. INP failures are usually caused by long-running JavaScript tasks — a common culprit is tag manager firing too many scripts before the main thread is free. CLS failures are usually caused by images or embeds without declared dimensions, or by fonts that swap and shift text.
Site speed rescue fits the Websites Starter or Business tier, typically $2,999–$7,999 fixed-price depending on the number of pages, platform, and complexity of the root cause. The scope is defined after the initial audit, so you know the full price before any implementation work begins. The 14-day money-back guarantee applies: if the audit reveals a platform problem I can't fix within that scope, you get a full refund.