Core Web Vitals are Google’s metrics for real-user experience and a factor in search rankings:

Metric Measures Good
LCP (Largest Contentful Paint) When the main content appears ≤ 2.5 s
INP (Interaction to Next Paint) Responsiveness to clicks/taps ≤ 200 ms
CLS (Cumulative Layout Shift) Visual stability ≤ 0.1

Most advice focuses on front-end code. But the server determines the starting line for LCP, and good server configuration makes the front-end fixes easier. Here’s what you control on a VPS.

TTFB: the foundation of LCP

LCP can’t happen before the HTML arrives. Time to First Byte is part of LCP for every visitor:

LCP ≈ TTFB + resource load delay + resource load time + render delay

A TTFB of 1 s leaves only 1.5 s for everything else. Reduce it with:

Check TTFB in the field data (Chrome UX Report) and with:

curl -o /dev/null -s -w 'ttfb: %{time_starttransfer}s\n' https://example.com/

Deliver the LCP resource quickly

The LCP element is usually a hero image, a large heading, or a video poster.

  • Don’t lazy-load it — loading="lazy" on the hero image delays LCP. Use fetchpriority="high" instead.
  • Preload it if it’s discovered late (CSS background images, JS-rendered heroes):
<link rel="preload" as="image" href="/images/hero.avif" fetchpriority="high">
  • Serve it compressed and sized — AVIF/WebP, correct dimensions, srcset. See WebP and AVIF.
  • Cache it long and serve from a CDN.

103 Early Hints

Servers and CDNs can send 103 Early Hints with Link: <…>; rel=preload headers before the final response is ready, so the browser starts fetching CSS, fonts and the hero image while the server is still generating HTML. Cloudflare and other CDNs support it; it’s most useful when TTFB is unavoidably high.

Compression and caching

  • gzip/Brotli for HTML, CSS and JS — smaller files, faster LCP. See Nginx compression.
  • Long Cache-Control lifetimes for hashed assets so repeat views skip the network. See browser caching.

Fonts and render-blocking resources

  • Self-host fonts on your own domain (no extra DNS + TLS to a font CDN), preload the main font, use font-display: swap — see WordPress local fonts.
  • Keep render-blocking CSS small; defer non-critical JS.

CLS: what the server can do

Layout shifts are mostly front-end issues (images without dimensions, late-loading ads, injected banners). Server-side contributions:

  • Render width/height attributes on images in templates.
  • Avoid injecting cookie banners or notices above content after load; reserve space.
  • Serve fonts quickly to minimise swaps.

INP: mostly front-end, but…

INP depends on JavaScript main-thread work in the browser. The server helps indirectly:

  • Smaller JS bundles (compression, code-splitting) parse and execute faster.
  • Fast API responses for interactions that fetch data — a slow API makes interactions feel sluggish even if INP technically measures the next paint.
  • Fewer third-party scripts.

Measure correctly

  • Field data (what Google uses): Search Console’s Core Web Vitals report, PageSpeed Insights “Discover what your real users are experiencing”, CrUX.
  • Lab data: Lighthouse, WebPageTest — reproducible, good for debugging, but not what ranks.
  • Your own RUM: the web-vitals JavaScript library sends real-user metrics to your analytics.

Field data aggregates 28 days, so improvements take weeks to show.

Server-side checklist

  • TTFB under ~600 ms at the 75th percentile (well under for cached pages)
  • Full-page caching for anonymous visitors
  • HTTP/2+, TLS 1.3, Brotli/gzip
  • Long caching for hashed assets, CDN for global audiences
  • Hero image not lazy-loaded, preloaded if late-discovered, modern format
  • Self-hosted, preloaded fonts
  • Image dimensions in HTML

Related: website speed optimization and website speed optimization.

  • Core Web Vitals
  • Performance
  • SEO