The New Page-Experience Ranking Signal

In June, Google is adding Core Web Vitals to its Page Experience ranking signal. This extends the factors that determine search rankings beyond load speed, safe browsing, HTTPS, and mobile-friendliness, putting evaluation weight on how users actually experience a page's speed, responsiveness, and visual stability.

Core Web Vitals consist of three metrics, each targeting a distinct aspect of user experience:

Largest Contentful Paint (LCP)

LCP measures perceived loading speed: the time from when the page begins loading until the largest element (a text block, image, or video) is visible in the viewport. This differs from First Contentful Paint (FCP), which is the time until the first element appears on screen. As the DOM renders, the largest candidate element can change—LCP is recorded once the primary element is actually viewable. The target is an LCP under 2.5 seconds.

First Input Delay (FID)

FID measures interactivity from the user's perspective: the delay between a user action (such as clicking an input box) and the browser handling that event. This delay is caused by the browser's main thread being busy with other work, leaving it unable to respond. A score below 100ms indicates good responsiveness.

Cumulative Layout Shift (CLS)

CLS quantifies layout stability by tracking unexpected movement of page elements after they've been rendered. The score takes into account both the impact and distance of each unexpected shift. If an element changes size or is added to the DOM but existing content stays in place, it doesn't count. The target is a CLS below 0.1.

Performance Tactics That Feed the Signals

Improving these vitals can help pages outrank competitors. Three areas offer substantial wins:

Pre-rendering Content

Pre-rendering server-side HTML in advance means the initial response already contains the markup, so it can be indexed immediately and loaded faster by both users and crawlers. This is especially relevant because while Google can execute JavaScript, server-side or pre-rendered pages are faster for everyone and safer for bots that don't run JavaScript. Adding a pre-rendering service on top of a client-side single-page app is likely to degrade Core Web Vitals rather than improve them. Next.js pre-renders every page by default.

Image Optimization

Images are the most common cause of layout shift and slow rendering. To address this:

  • Set explicit height and width attributes on image elements so the browser reserves the correct space from the start.
  • Implement lazy loading so off-screen images load only when they approach the viewport.
  • Serve modern formats such as WebP and AVIF.
  • Use srcset to provide appropriately sized images per device.
  • Use blur-up placeholders to fill the space while full images load.

Next.js's Image component handles most of these optimizations by default.

Font Optimization

Web fonts are used by 82 percent of desktop pages and can hurt performance if not handled carefully:

  • Use variable fonts—a single file covering all weights, widths, and styles.
  • Preconnect to the font source in the HTML head and declare the loading rules in CSS.
  • Self-host fonts instead of depending on third-party services like Google Fonts.
  • Use font-display: optional so the fallback font is used when the webfont is slow, preventing CLS.
  • Always set a fallback font family in case the primary font fails to load.

Next.js's Automatic Webfont Optimization handles preconnecting and self-hosting for Google Fonts and Typekit out of the box.

Measuring the Vitals

To validate the impact of these changes, Google Lighthouse audits pages across performance, accessibility, SEO, and progressive web app criteria; Core Web Vitals form the bulk of the performance score. For real-user data, Vercel Analytics goes further by assigning a Real Experience Score (RES), an aggregate health check of the Core Web Vitals your actual visitors experience.

The Vercel dashboard also shows how each vital and each route in your application performs over time, making it possible to spot when a regression was introduced and roll back to a previous commit. Those analytics can be enabled for any Next.js, Nuxt, or Gatsby application.

Google's own documentation on Core Web Vitals remains the reference for implementation guidance and thresholds.