Why Core Web Vitals Matter at Scale

Google's Core Web Vitals (LCP, CLS, INP) are a direct ranking signal for search. On a platform like yomimanga, where organic search is the primary acquisition channel, a poor CWV score directly costs users and revenue. This is not abstract SEO theory — when we fixed LCP from 4.2s to 1.4s, organic traffic increased 23% over the following 6 weeks.

Here's what actually moved the scores on a real high-traffic platform.

LCP: It's Almost Always an Image

Largest Contentful Paint measures the time until the largest visible element renders. On a content platform, the LCP element is almost always the hero image or the first content image. The optimizations that matter:

LCP image preloading: Add a <link rel="preload" as="image"> for the LCP image in the document head. This tells the browser to fetch it before the HTML parser reaches the <img> tag. On yomimanga, this alone dropped LCP by 800ms — the image was being discovered too late in the parse order.

Format and compression: WebP with quality 80 is typically 30-50% smaller than JPEG at equivalent visual quality. AVIF is 20-30% smaller than WebP but has slightly worse browser support. On yomimanga, we serve AVIF to supporting browsers and WebP as fallback. Every byte removed from the LCP image is a direct LCP improvement.

CDN cache everything: If your LCP image originates from your server on every request, you're fighting physics. Serve from CDN edge nodes nearest to the user. A user in Tokyo fetching from a US origin adds 150-200ms of irreducible network latency. CDN eliminates this.

Priority hints: Add fetchpriority="high" to the LCP image element. This tells the browser's preload scanner to prioritize this resource over others discovered at the same time.

CLS: The Layout Shifts You Don't Notice Until You Measure

Cumulative Layout Shift measures unexpected layout movement. The shifts that cause poor CLS scores are usually invisible during development (because assets are cached locally) and infuriating for real users (content jumps as they're reading).

The most common CLS sources on yomimanga:

  • Images without dimensions: every <img> needs explicit width and height attributes (or a CSS aspect-ratio). Without them, the browser doesn't reserve space until the image loads. The content below shifts down.
  • Web fonts causing FOUT/FOIT: Font swap causes layout shift if the fallback font has different metrics. Use font-display: optional for non-critical fonts, and match fallback font metrics using size-adjust, ascent-override, and descent-override in the @font-face declaration.
  • Dynamically injected content above existing content: banners, cookie notices, interstitials. If you must show these, reserve space for them before they load, or show them below the fold.

INP: The New Metric Everyone Is Underestimating

Interaction to Next Paint replaced FID in March 2024 and is significantly harder to optimize. INP measures the full interaction latency — from user input to the next frame paint — for all interactions on the page, not just the first.

The root cause of poor INP is almost always long tasks on the main thread. If your JavaScript is running a task that takes 200ms, any interaction during that task will be delayed by up to 200ms before the browser can respond.

What we found on yomimanga: our reading history save (a synchronous operation on every chapter page scroll event) was blocking the main thread for 40-80ms. Moving it off the main thread via a debounced callback + Web Worker dropped INP from 380ms (poor) to 120ms (good).

Tools to find INP issues: Chrome DevTools Performance panel with "Interactions" track enabled, and the PerformanceObserver API with { type: 'event', buffered: true } to log long-duration interactions in the field.

The Server Side That Performance Guides Ignore

Every Core Web Vitals guide focuses on client-side optimization. On a platform with 5M daily requests, server response time is a significant variable that client-side optimization cannot compensate for.

TTFB (Time to First Byte) is not a Core Web Vitals metric, but it directly affects LCP. An LCP of 1.5s is only achievable if TTFB is under 600ms. If your server takes 1.2s to respond, no amount of client-side optimization gets you a good LCP.

The server-side changes that moved our TTFB from 800ms to 180ms: Redis caching for all page-level data, query result caching at the PHP layer, and moving static content delivery entirely to CDN. The database no longer touches hot paths.

Field Data vs. Lab Data

Lighthouse scores (lab data) and real CWV scores (field data from the Chrome User Experience Report) frequently diverge. Lighthouse tests one device, one network, one session. Field data aggregates millions of real sessions across real devices, networks, and geographies.

Your optimization target is the field data. Build a real user monitoring setup: the Web Vitals JavaScript library + your analytics of choice. Measure LCP, CLS, and INP in the field, segmented by device type and geography. The issues you'll find are very different from what Lighthouse surfaces.