Core Web Vitals

Core Web Vitals are the three field metrics Google uses to score loading, visual stability, and responsiveness: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). This hub explains what each one measures, then links the per-platform fix for WordPress, WooCommerce, Magento, nginx, and ASP.NET Core.

What the three metrics measure

Each metric has a field measurement, taken from real Chrome users over the trailing 28 days in the CrUX dataset, and a lab approximation from Lighthouse or PageSpeed Insights. The two routinely disagree, because real visitors run slower hardware on slower connections than the machine you test on. Optimize toward the field number.

Largest Contentful Paint

LCP

The render time of the largest element visible in the viewport during load — often a hero image, a banner, or the first heading. Under 2.5 s is good; over 4 s is poor.

Typical causes: the hero image is not preloaded, a chain of render-blocking stylesheets delays first paint, or a large unoptimized image takes too long to download.

Cumulative Layout Shift

CLS

The sum of unexpected layout shifts during load, weighted by how much of the viewport moved and how far. Under 0.1 is good; 0.25 and up is poor.

Typical causes: images and embeds without explicit width and height, web fonts that reflow text on swap, and content injected above what the user is already reading.

Interaction to Next Paint

INP

The worst-case latency between a user input — click, tap, keypress — and the next frame the browser paints in response. Under 200 ms is good; over 500 ms is poor.

Typical causes: long JavaScript tasks blocking the main thread, heavy event handlers, and frameworks whose interaction model requires a round-trip before paint.

Per-platform fix guides

The same metric fails for different reasons on different stacks. Pick your platform and your metric to read the diagnosis and the concrete fix.

Core Web Vitals fix guides by metric (rows) and platform (columns)
Metric	WordPress	WooCommerce	Magento	nginx	ASP.NET Core
LCP Largest Contentful Paint	Fix LCP on WordPress WordPress LCP: the server-layer fix	Fix LCP on WooCommerce WooCommerce LCP: shrink the gallery first	Fix LCP on Magento LCP on Magento without breaking RequireJS	Fix LCP on nginx nginx LCP: transport, not content	Fix LCP on ASP.NET Core ASP.NET Core LCP: Razor vs Blazor
CLS Cumulative Layout Shift	Fix CLS on WordPress WordPress CLS: dimensions at the server	Fix CLS on WooCommerce WooCommerce CLS: lock the gallery	Fix CLS on Magento Magento CLS starts with Fotorama	Fix CLS on nginx nginx CLS via insert_image_dimensions	Fix CLS on ASP.NET Core ASP.NET Core CLS: pre-size async holes
INP Interaction to Next Paint	Fix INP on WordPress WordPress INP: plugin discipline	Fix INP on WooCommerce INP on WooCommerce: where the cost lives	Fix INP on Magento Magento INP: Hyvä matters more	Fix INP on nginx nginx INP: a CMS-agnostic plan	Fix INP on ASP.NET Core INP on ASP.NET Core: Razor vs Blazor

How ModPageSpeed helps

ModPageSpeed optimizes responses at the server layer, below the CMS, so a single configuration applies to every URL the origin serves. That maps directly onto LCP and CLS. It maps less directly onto INP, and it is worth being precise about why.

LCP — materially helped

Heuristic critical CSS extraction inlines above-the-fold rules and defers the rest, removing the render-blocking stylesheet chain that delays first paint. Image transcoding to WebP and AVIF, plus responsive variants sized to the viewport, shrinks the hero image so it downloads sooner. The detected LCP image receives a preload hint so the browser starts fetching it earlier. Each of these attacks a distinct part of the LCP timing breakdown.

CLS — materially helped

The worker injects explicit width and height on <img> tags that lack them, using dimensions read from the cached image data. That lets the browser reserve the correct layout box before pixels arrive, which removes the most common source of image-driven layout shift. Inlined critical CSS also stabilizes early layout by making above-the-fold styling available without waiting on external stylesheets.

INP — helped less directly, and here is why

INP is a measure of JavaScript main-thread responsiveness. The dominant cause of poor INP is long tasks in your own application code — event handlers, hydration, framework work — and a server-layer optimizer does not rewrite that logic. ModPageSpeed will not make a slow click handler fast.

What it can do is reduce how much JavaScript competes for the main thread before the user interacts: minifying scripts and deferring those it can prove are safe to defer moves parser-blocking work off the critical path, which can lower INP on pages whose responsiveness was being throttled by startup script execution. Where INP is structural — for example a Blazor Server interaction that is a network round-trip by design, or a heavy client framework — the fix lives in your application, not in the server layer. The per-platform guides above are explicit about which case you are in.

Measure your own pages

Start with a measurement, not a guess. Run a page through the analyzer to see what is driving its Core Web Vitals, then read the matching per-platform guide. When you are ready to fix it at the server layer, the trial requires a card at checkout — 14 days free, cancel before day 15 and pay nothing.

Analyze a page See pricing and start the trial