1
Heavy LCP element
Hero image without priority, WebP/AVIF, responsive srcset, and preload — top cause of LCP > 4s.
PERFORMANCE LAB
Core Web Vitals optimization with measurable deltas
LCP, INP, and CLS aren't abstract PageSpeed scores — they're ranking and conversion factors. We find bottlenecks, fix in code and CDN, and measure before/after in lab and field data.
SolidWeb performance sprint for Next.js, React, WordPress, and legacy front ends: critical render path, images, fonts, hydration, third-party scripts. Goal: green CrUX zone and conversion lift from speed — not chasing 100 Lighthouse for a screenshot.
Vitals delta
LCP3.9s → 1.6s
INP290ms → 120ms
CLS0.21 → 0.04
BOTTLENECKS
What usually breaks CWV
Six common causes of poor metrics — and how we fix them in a sprint.
2
Render-blocking CSS/JS
Sync styles and head bundle block first paint. Fix: code split, critical CSS, defer.
3
Third-party scripts
GTM, chat, widgets, A/B — INP and TBT. Lazy load, tag sequencing, consent-gated loading.
4
Hydration and INP
Heavy React hydration, long tasks on click. Partial hydration, Server Components, memoization.
5
CLS from fonts and ads
FOUT, dynamic content without reserved space. font-display, size-adjust, skeleton placeholders.
6
CDN and TTFB
Slow origin, no edge cache. Vercel/Cloudflare, ISR, stale-while-revalidate for HTML.
PROCESS
Performance sprint
Audit → hypotheses → fix → field measurement — in 2–4 weeks.
1
Baseline
CrUX, Lighthouse, WebPageTest, LCP/INP/CLS profiling on key URLs and templates.
2
Bottleneck map
Priorities: maximum delta for minimum effort.
3
Quick wins
Images, fonts, defer JS, CDN — first staging deploys with measurement.
4
Deep fixes
Code split, RSC, third-party facade, critical CSS, backend TTFB.
5
Production deploy
Phased rollout, RUM monitoring, rollback plan.
6
Field validation
28-day CrUX window, before/after report, regression prevention recommendations.
STACK
Optimization stack
Technologies and patterns we apply in performance sprints.
Next.js / React
App Router, Server Components, dynamic import, next/image, ISR, edge runtime.
CDN and edge
Vercel, Cloudflare, static cache, stale-while-revalidate, geo-routing.
Images pipeline
WebP/AVIF, srcset, blur placeholder, CDN resize, lazy below fold.
Fonts
next/font, subsetting, preload critical weights only, size-adjust against CLS.
Monitoring
CrUX, RUM, Lighthouse CI, Web Vitals extension, regression alerts.
Third-party governance
Tag manager policy, facade pattern for widgets, consent before load.
BEFORE / AFTER
Typical shift after sprint
Lab metrics before and after a typical optimization sprint.
Before
- LCP 3.9s — 2.4 MB hero JPG without lazy
- INP 290ms — GTM + chat load synchronously
- CLS 0.21 — web fonts without fallback metrics
- TBT 890ms — single 680 KB JS bundle
After
- LCP 1.6s — AVIF + fetchpriority + CDN
- INP 120ms — third-party after interaction
- CLS 0.04 — font fallback + reserved slots
- TBT 180ms — route-level code splitting
OUTPUT
Sprint deliverables
Code, metrics, and docs — so speed doesn't regress in a month.
- Before/after report
Lab and field: LCP, INP, CLS, TBT by template with charts and notes.
- PR / deploy
Repository changes with each fix described and tied to a metric.
- Performance budget
JS, image, third-party limits — for CI and code review.
- Runbook
How not to break CWV on new features: checklist for dev and marketing.
“«Every second of LCP delay is users who never saw your offer.»”
— SolidWeb Performance Team
FAQ
Core Web Vitals FAQ
LCP, INP, CLS, CrUX, and ties to SEO and conversion.
CWV are three Google metrics: LCP (main content load speed), INP (responsiveness to input), CLS (layout stability). They affect rankings and conversion directly: every 100 ms LCP delay lowers conversion probability. SolidWeb optimizes field data (real users), not just lab score.
FID measured only first interaction. INP (Interaction to Next Paint) looks at all clicks, taps, and keys on the page — p75 of worst interactions. Closer to real UX. INP optimization: code split, fewer long tasks, deferred third-party.
No. Lighthouse is lab on simulated device. Google uses CrUX — 28-day field aggregate. A site can score 95 Lighthouse and red CrUX due to slow regions, 3G, or heavy third-party for real users. We prioritize CrUX.
Typically 2–4 weeks: baseline and quick wins week, 1–2 weeks deep fixes, deploy and CrUX update wait (28-day window). Lab improvements show right after deploy; field — 2–4 weeks after data accumulates.
Yes, within platform limits: caching, CDN, image plugins, defer scripts. Ceiling is often lower than Next.js on Vercel. On diagnostic we honestly say when migration is needed for target CWV.
Not always. Often CDN, image optimization, and JS fixes are enough. If TTFB > 600 ms from origin — we recommend edge (Vercel, Cloudflare) or ISR. Hosting change is a separate decision after baseline.
Sync GTM, Intercom, widgets create long tasks and click delay. We use facade pattern, load after interaction or consent, GTM tag sequencing. Marketing sometimes accepts delayed load — we discuss trade-off in sprint.
Yandex states speed importance. Direct CrUX analog in Yandex SERP is less documented, but fast sites improve behavioral factors. CWV optimization helps both systems and conversion regardless.
Limits on JS bundle size, third-party count, LCP image weight. We embed budget in CI: PR doesn't merge on Lighthouse regression. Runbook explains how not to break metrics with new features.
We guarantee backlog execution and measurable lab delta. CrUX depends on traffic, regions, and audience devices — we don't give 100% field guarantee. Typical sprint brings key templates to green zone with sufficient traffic volume.
Yes. Site audit gives a broad map; CWV sprint is deep speed execution. Often after audit clients order sprint on Critical/High CWV findings only. CWV Diagnostic can stand alone without full audit.
RUM (Sentry, Calibre, web-vitals library), Lighthouse CI, alerts on LCP/INP drop. Full-site package includes 3 months monitoring. Runbook for team on each release.
Slow site? Leave a request.
DEEP DIVE
Core Web Vitals and performance by SolidWeb
LCP, INP, CLS, CrUX, and how we bring sites to the green zone.
Core Web Vitals since 2021 are a Google ranking signal. Since 2024 INP replaced FID as the responsiveness metric. Three metrics: LCP ≤ 2.5s (p75 field), INP ≤ 200ms, CLS ≤ 0.1. Red CrUX zone hurts SEO and conversion — users leave before the offer loads.
SolidWeb doesn't chase 100 Lighthouse on the homepage in lab. Priority is CrUX Report and RUM: how the site behaves for real users on 3G, old Android, and regions without edge CDN.
We optimize LCP via next/image, AVIF/WebP, fetchpriority on hero, preload critical assets, CDN, and lower TTFB. Top culprit — unoptimized hero image and render-blocking CSS.
INP — long tasks from JS, React hydration, sync third-party. Server Components, dynamic import, deferred GTM and chat facade typically yield 150–200 ms delta. We profile in Performance panel before fixes.
CLS — web fonts without metrics override, banners without height reserve, dynamic content. next/font, size-adjust, skeletons, aspect-ratio on media blocks.
Performance sprint: baseline → bottleneck map → quick wins → deep fixes → deploy → 28-day CrUX window. Deliverables: PR, before/after report, performance budget, runbook.
Stack: Next.js on Vercel, Cloudflare, Lighthouse CI, Sentry Performance. For WordPress — caching plugins, CDN, plugin limits; lower ceiling — stated on diagnostic.
Tie to site audit: audit finds CWV issues among six areas. CWV service is execution. Tie to SEO: CWV is SEO's technical layer; without green CrUX content can't reach potential.
ROI: Amazon measured −1% conversion per 100 ms latency. For ad-driven landings slow LCP wastes budget directly. Sprint pays off at given AOV and traffic — we estimate on brief.