Green Core Web Vitals in 2–3 weeks.
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.
Who this is for
E-commerce or B2B marketer watching organic traffic slip after a Core Web Vitals downgrade — LCP 4s+, ranking drops, AdWords costs climbing.
The pain today
- LCP stuck above 3 seconds on mobile despite 'cache plugin' claims
- Google Search Console flagging poor URLs in Core Web Vitals report
- Paid search quality score dropping because landing pages are slow
- Teams arguing about whether speed actually moves conversion
- No one person owning front-end performance
The outcome you get
- Sub-2-second LCP on target pages, verified against field and lab data
- Green Core Web Vitals in Search Console within 28 days
- Before/after deliverable — Lighthouse, PageSpeed, real user metrics
- Organic traffic lift within 60 days (typical 10–30% on improved pages)
- Speed budget and monitoring so the site doesn't regress
Why Core Web Vitals move rankings in 2026
Core Web Vitals are part of Google's ranking signals and they have real weight on commercial queries. LCP tells Google how fast the main content paints. CLS tells Google how stable the layout is. INP tells Google how responsive the page feels when users interact. When a site drops from 'Good' to 'Needs Improvement' across these three, Search Console flags it, and organic traffic typically softens 10–30% on competitive queries within 4–8 weeks. Fixing the underlying metrics reverses the drop within a similar timeframe. Speed isn't a nice-to-have — on commercial SEO in 2026 it's table stakes.
The 3-tier speed audit I run
Tier one: synthetic lab tests (Lighthouse, WebPageTest, PageSpeed Insights) against the top 5–10 pages by traffic. Produces a clean baseline score across metrics. Tier two: field data from the Chrome UX Report (CrUX) for real-user LCP/CLS/INP over 28 days. This is what Google actually uses for ranking, so it's the number that matters. Tier three: a waterfall teardown of the slowest page — which resource is blocking LCP, which script is pushing INP up, which element is shifting layout. Tier three is where I find the real root cause, which often isn't where the Lighthouse report points.
Fixes that usually move the needle fastest
Pattern over years: most sites get 60–80% of the LCP win from five changes. One: properly-sized hero images served as AVIF or WebP with explicit width/height. Two: critical CSS inlined and the rest deferred. Three: third-party scripts (analytics, chat, ads) loaded with proper priority hints or moved server-side. Four: font loading with font-display: swap and preconnect to the font host. Five: server response time (TTFB) under 500ms via CDN caching or static generation. For INP, the win is usually removing or splitting a long-running JavaScript task — often a tag manager or a heavy hydration bundle. Cuez's 3s-to-300ms win came from API-layer caching and query optimization; the same instinct applies to frontend.
Case studies: Cuez and Imohub
Cuez's core API was 3 seconds. I took it to 300ms — a 10x speedup that also cut infrastructure cost around 40%. The work was a mix of query optimization, Redis caching at strategic layers, and removing work from the request path. Imohub had 120k+ property records and search latency was killing UX. I rebuilt the search layer with Meilisearch and query response dropped under 0.5 seconds, with infrastructure cost down 70%. Both projects share the same pattern: measure first, find the real bottleneck (rarely where the team thinks), fix it surgically, prove the win in production metrics.
Pricing, before/after deliverable
Site speed rescue fits the Websites Starter or Business tier depending on scope — typically $2,000–$5,000 fixed-price. Timeline is 2–3 weeks for a focused scope (top 5–10 pages), longer if the whole site needs work. Deliverable: audit report (lab + field baselines), change log (what was changed and why), before/after Lighthouse + CrUX comparison, 28-day Search Console CWV status check, and a speed budget your team can enforce going forward. 14-day money-back, 1-year bug warranty. If anything I shipped regresses within a year, I fix it at no charge.
What I don't touch (and why)
Speed work is surgical. I don't re-theme the site, I don't rewrite the CMS, I don't re-scope content strategy unless those are the actual bottleneck. The engagement stays focused on performance metrics. If the root cause turns out to be the platform itself (e.g., WordPress with 30 plugins), I'll say so and scope a separate replatform engagement rather than paper over it. Honesty about scope is part of the pitch — I've turned down speed engagements when the real answer was 'this site needs to be rebuilt,' and that's fine. The 14-day money-back exists for exactly that kind of honest mid-course correction.
Recent proof
A comparable engagement, delivered and documented.
Rescued a slow API that was blocking user growth
Refactored the backend architecture, making the system far more responsive and scalable for the growing user base.
Frequently asked questions
The questions prospects ask before they book.
- How quickly will I see results in Search Console?
- Core Web Vitals in Search Console are based on 28 days of real-user field data, so the Google-facing metrics update gradually over 2–4 weeks after the fixes ship. Lab metrics (Lighthouse, PageSpeed) update instantly. I monitor both and report weekly until the 28-day field window clears.
- What LCP target should I aim for?
- LCP under 2.5 seconds for 75th-percentile mobile users is the Google 'Good' threshold. I aim for under 2.0 seconds on target pages to leave headroom for regressions. Under 1.0 is achievable on static marketing pages with CDN caching and optimized images.
- Will you rewrite the whole site?
- No — speed rescue is surgical. I fix the specific resources and patterns blocking Core Web Vitals without rebuilding the site. If the platform itself is the problem (heavy WordPress, old stack), I'll scope a separate replatform engagement rather than chase a losing optimization battle.
- Do you handle INP and CLS, not just LCP?
- Yes. LCP gets most attention but INP became a Core Web Vital in March 2024 and CLS has always been in the mix. Every engagement checks all three against Google's thresholds: LCP < 2.5s, INP < 200ms, CLS < 0.1 for the 75th percentile of real users.
- What if my site is slow because of third-party scripts my marketing team requires?
- Common problem. I can move many scripts server-side (GTM server container, analytics via Measurement Protocol) or defer them with proper priority hints. For a script that genuinely has to fire client-side and cannot be deferred, I'll flag it to the marketing team with a measured performance cost so the trade-off is explicit.
Ready to start?
Tell me what you need in 60 seconds. Tailored proposal in your inbox within 6 hours.