Core Web Vitals Explained for Engineers

What Typically Counts as the LCP Element

LCP candidates are usually:

• Block-level text elements: <h1>, <h2>, <p>, etc.
• Images: <img>, background images on block elements, poster images of <video>.
• Block-level containers with background images.

The browser tracks the largest candidate in the initial viewport until the user scrolls or until a cutoff time. If your hero image or main headline is slow to render, LCP degrades.

How Rendering Strategy Affects LCP

Rendering strategy significantly influences how quickly the LCP element appears:

• Traditional CSR (Client-Side Rendering): The browser receives a mostly empty HTML shell, downloads JS, parses, compiles, and executes it to produce DOM. LCP is delayed until hydration is sufficiently complete to render the main content.
• SSR (Server-Side Rendering): The server sends HTML with rendered content. The LCP element can appear much earlier, often gated mainly by HTML delivery, CSS, and critical images.
• SSR + Hydration: HTML is visible quickly (improving LCP) but JS still needs to download and hydrate to make components interactive. Hydration itself doesn’t directly affect LCP, but blocking resources during hydration can.
• Streaming SSR / React Server Components / HTML streaming: Allows the head and initial shell to appear earlier, and potentially the LCP element to be flushed as soon as it’s ready.

From an LCP perspective, SSR (or static generation) plus a lean critical path is often the most effective strategy. CSR-heavy architectures typically require aggressive optimization (code splitting, prioritized chunks, preloading) to approach similar LCP performance.

Asset Loading and LCP

LCP is highly sensitive to what blocks the rendering of the main content:

• Critical CSS:
  • Render-blocking CSS in the head delays first render and therefore LCP.
  • Inlining above-the-fold CSS or using code-splitting for CSS ensures key styles are available early.
  • Avoid large monolithic CSS bundles for all routes when only a small subset is needed above the fold.
• JavaScript:
  • Render-blocking JS (synchronous scripts without defer or async) delays LCP.
  • Overly large bundles increase TTFB-to-LCP time, especially on mobile CPUs.
  • Non-critical scripts should be deferred, loaded asynchronously, or dynamically imported post-LCP.
• Images:
  • The hero image is often the LCP element; its size, format, and delivery path are crucial.
  • Serve appropriately sized images (no oversizing), use modern formats (WebP, AVIF) when possible.
  • Use <link rel="preload" as="image"> for hero images and fetchpriority="high" when supported.
  • Configure a CDN close to users to reduce latency.
• Fonts:
  • Blocking font downloads and layout shifts due to late font loading can delay when the LCP text looks “final”.
  • Use font-display: swap or optional to avoid blocking rendering.

Overall, LCP improves when the network and CPU cost to get the primary content visible is minimized.

Layout Decisions and LCP

While LCP is primarily about timing, layout and component design still matter:

• Above-the-fold density: If the top of the page is cluttered with many large elements, the “largest” content block might be heavier (e.g., a carousel) and take longer to render.
• Conditional content: If you initially render a small placeholder and then swap in a large component after data fetch, the LCP element might be deferred until that swap.
• Hero carousels and complex hero components often delay LCP due to JS-heavy initialization or large images; prefer simple, static hero elements when performance is a priority.

Designing simpler, static above-the-fold layouts with minimal runtime logic helps ensure the LCP element is cheap to render.

What Causes Layout Shifts

A layout shift occurs when a visible element changes its position or size between two rendered frames, without a corresponding user interaction that explicitly triggered it.

• Images or videos without fixed dimensions.
• Ads, embeds, or iframes injected late into the DOM.
• Web fonts swapping from fallback to final font, changing text metrics.
• Late-injected components (e.g., banners, consent prompts) pushing content down.
• Client-side rendering that inserts content above existing content after data loads.

CLS punishes unexpected shifts the user did not initiate; it ignores shifts that occur within a short window after user input if they are clearly related.

Rendering Strategy and CLS

SSR vs CSR can influence how much layout reflows as data appears:

• SSR / Static HTML: If the server-rendered HTML already contains the correct layout with stable dimensions, fewer shifts will occur when the client hydrates. However, hydration mismatches or client-only changes can still cause shifts.
• CSR with skeletons: Often uses placeholders for content. If the skeleton dimensions are not representative of final content, CLS can be high when items expand/contract.
• Streaming / Progressive rendering: Partial templates might initially use placeholders; again, mismatch between placeholder and real size can cause shifts.

The key idea is to render stable layout containers early, with correct dimensions or reserved space, regardless of when the actual content loads.

Asset Loading and CLS

How and when assets are loaded can trigger reflows:

• Images and videos:
  • Always specify width and height (or aspect-ratio) in CSS or HTML attributes.
  • Responsive images should preserve aspect ratio, e.g., using CSS aspect-ratio or containers with padding hacks.
  • Avoid letting images “push” content as they load; reserve space.
• Ads and embeds:
  • Reserve static slots with fixed dimensions or maximum bounds.
  • Load third-party content within these slots; do not let them dictate layout dynamically.
• Fonts:
  • Late font loading can cause text to reflow, especially when fallback fonts differ in metrics.
  • Use font-display: swap with metric-compatible fallbacks, or use font-display: optional if it’s acceptable for users to keep the fallback.
• Asynchronous widgets (chat bubbles, analytics, consent popups):
  • Inject them into reserved areas or overlay layers rather than pushing main content.

Layout Decisions and CLS

CLS is very sensitive to CSS and component structure:

• Stable containers: Design components so that their outer container’s height is predictable, even before data arrives (e.g., cards with min-heights or consistent image aspect ratios).
• Above-the-fold layout: Since early shifts are often most noticeable, ensure the hero section, nav, and immediate content below are fully stable.
• Lazy loading: Lazy-load content below the fold. If you lazy-load above-the-fold content, reserve the exact space it will take.
• Transitions and animations: Animate transforms (e.g., transform: translateY) rather than changing layout-affecting properties like top, height, margin for elements outside the user-initiated area. CLS ignores animations that are triggered by user input and clearly expected, but random auto-running layout animations can still feel jarring.

Implementing strict CSS contracts (e.g., always-known dimensions, consistent typography scale) is often the most effective structural fix for CLS issues.

Decomposing INP

For each interaction, INP can be broken into three phases:

1. Input delay: Time between the interaction and when the event handler starts executing. High input delay indicates a blocked main thread (e.g., long tasks).
2. Processing time: Time spent within event handlers and related logic. Heavy JS work here increases INP directly.
3. Presentation delay: Time from when handlers finish to when the next paint occurs. Layout, style recalculation, and paint work contribute here.

INP uses (roughly) the worst representative interaction during the session, so a single heavy interaction (e.g., opening a mega-menu or switching a complex tab) can dominate your score.

Rendering Strategy and INP

Rendering strategy influences main thread load and thus how often it is blocked:

• CSR with heavy hydration: Initial hydration can create long tasks (50ms+), blocking input handling and pushing INP up, especially on low-end devices. Interactions during hydration are particularly at risk.
• SSR with partial / selective hydration: Can significantly reduce JS that runs on load, leaving more headroom for responsive interactions.
• Islands architecture / component-level hydration: Only interactive islands are hydrated, reducing global JS overhead and main thread contention.
• Server components / thin clients: Shifting logic to the server and keeping client components light reduces client-side computation per interaction, improving INP.

Architectures that keep the client bundle small and avoid large synchronous work on page load generally see better INP.

Asset Loading and INP

Asset-related decisions affect both initial JS cost and runtime responsiveness:

• JavaScript bundle size and composition:
  • Large hydration bundles or monolithic frameworks can monopolize the main thread.
  • Tree-shake aggressively and avoid unnecessary polyfills or libraries.
  • Split code at route and component boundaries; lazy-load non-critical features only when needed.
• Scheduling and task management:
  • Break long tasks into smaller chunks using requestIdleCallback, setTimeout, or scheduler APIs.
  • Defer non-urgent work (analytics, logging, heavy computation) to idle time.
• Third-party scripts:
  • Ads, analytics, chat widgets, tag managers can inject heavy JS executing during user interactions.
  • Isolate them where possible (e.g., via web workers or iframes) and load them lazily.

Slimmer runtime JS and smarter work scheduling are the biggest levers for improving INP.

Layout Decisions and INP

While INP is measured at the interaction level, layout complexity affects how long the post-interaction update takes:

• DOM size:
  • Very large DOM trees increase the cost of layout and style recalculation on each change.
  • Virtualization (windowing lists, lazy-rendering offscreen components) reduces work.
• Complex layouts:
  • Deep nested flexbox or grid layouts multiply layout computation.
  • Highly dynamic layouts where interactions modify multiple containers can be costly.
• Animations tied to interactions:
  • Hardware-accelerated animations (transform, opacity) are cheaper than layout-affecting ones.
  • Complex JS-driven animation frameworks can add overhead; prefer CSS transitions where possible.
• Component behavior:
  • A single click that triggers many state updates across the tree leads to multiple re-renders.
  • Minimize global state updates; scope state to local components or use memoization.

Design UI interactions so that each user action affects the minimal necessary part of the DOM and avoids heavy recalculations.

For LCP

• Use SSR or static generation for pages with critical LCP requirements.
• Inline minimal critical CSS; lazy-load the rest.
• Defer or async non-critical JS; avoid render-blocking scripts.
• Preload the hero image and key fonts; serve via CDN and modern formats.
• Keep above-the-fold UI simple and minimize heavy components.

For CLS

• Set fixed or aspect-ratio-based sizes for all images and videos.
• Reserve space for ads, embeds, and late-loading components.
• Use font-display with metric-compatible fallbacks; avoid FOIT/FOUT-caused shifts where possible.
• Design stable skeletons whose size matches final content.
• Avoid inserting components above existing content after load; overlay instead of pushing content.

For INP

• Reduce JS bundle size via code splitting and tree shaking.
• Break long tasks; offload heavy work to web workers or idle periods.
• Virtualize large lists and complex components; avoid huge DOM trees.
• Scope state updates; minimize re-renders triggered by a single interaction.
• Prefer CSS transitions (transform/opacity) for interaction-related animations.