Website Performance & Technical SEO Engineering, Measured the Way Google Actually Measures It

Three metrics, all measured at the 75th percentile of real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. The "good" thresholds are LCP under 2.5s, INP under 200ms, and CLS under 0.1. Note that INP replaced First Input Delay (FID) in March 2024 — any audit still reporting FID is using a deprecated metric.

The most common cause is a Google core update shifting how much weight existing signals carry — the March 2026 update specifically increased the ranking weight of Core Web Vitals, so sites with poor field data saw movement without any content change. The second most common cause is a technical regression: a new script, plugin, or deploy that hurt performance. We check both before assuming a rebuild is needed, because the fix is often targeted rather than total.

It depends on whether the bottleneck is architectural or asset-level. If your stack is fundamentally outdated — a decade-old theme with no component structure, no CDN, no image pipeline — optimization has a ceiling and a redesign is the honest answer. If the stack is sound but slow in specific places — unoptimized images, missing caching headers, render-blocking scripts — an optimization pass gets most of the value at a fraction of the cost and risk. We give you an explicit recommendation with reasoning before any work starts.

A lab test like Lighthouse runs a single simulated session on a fixed device and connection profile — useful for diagnosis, but not what Google ranks on. Field data comes from the Chrome User Experience Report, aggregated from real visitors on real devices and networks, measured at the 75th percentile. That distinction matters: a site scoring 100 in the lab with poor field data is in a worse position than one scoring 65 with green field metrics across the board. We measure field data first and use lab data to diagnose the cause.

It doesn't have to, and a redesign that improves performance usually helps. The risk is procedural, not inherent: URL structure changes without a redirect map, dropped metadata, or a broken crawl path are what cause post-redesign ranking drops. We treat a complete redirect map, metadata migration, and pre/post crawlability validation as launch-blocking requirements, so the new design keeps the equity the old one earned.

Continuously, not once. Every new plugin, tracking script, third-party embed, or design change can regress a metric that was previously passing — which is why a one-time audit has limited value. We build a recurring Core Web Vitals check into a maintenance cadence, so a regression is caught shortly after it ships rather than months later when rankings have already moved.