Performance3 min read
Core Web Vitals explained: what each metric measures and how to move it
Three numbers, each measuring a different way a page can feel bad: slow to appear, slow to respond, and unstable while you use it.
Largest Contentful Paint breaks into four phases: time to first byte, resource load delay, resource load time and render delay. Measure which phase dominates before optimising — a slow TTFB needs caching or server work, a long load delay needs earlier discovery via preload, and a long render delay usually means render-blocking resources or client-side rendering.
| Phase | What it is | Typical target |
|---|---|---|
| Time to first byte | Server response arrives | < 800ms |
| Resource load delay | Gap before the LCP resource starts loading | < 10% of LCP |
| Resource load time | Downloading the LCP resource | < 40% of LCP |
| Render delay | Gap between load finishing and painting | < 10% of LCP |
The web-vitals JavaScript library reports these phases as attribution data. Collect it in your RUM and you will know within a day which phase to attack, instead of guessing from a Lighthouse waterfall.
Make the LCP resource discoverable as early as possible, and give it the highest priority.
<!-- Preload the hero image so it starts loading during HTML parsing -->
<link rel="preload" as="image" href="/hero.avif"
imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
imagesizes="100vw" fetchpriority="high">
<!-- Or, on the element itself -->
<img src="/hero.avif" fetchpriority="high" decoding="async"
width="1600" height="900" alt="…">A common pattern in single-page applications: the HTML arrives quickly, then nothing renders for two seconds while the bundle downloads, parses and hydrates. That entire gap is render delay, and the fix is architectural — server-render the initial view.
In Chrome DevTools, the Performance panel marks the LCP node, and Lighthouse names it in the diagnostics. It is often a hero image, an h1, or the largest text block.
No — preload hints compete with each other. Preload the one LCP resource plus critical fonts. Preloading ten things means prioritising nothing.
Carousels typically load multiple large images at once and often render the first slide via JavaScript. If a hero carousel is required, load only the first slide eagerly and lazy-load the rest.
Yes, by not blocking on it. Server-render the shell with cached or static content and stream the slow region in with Suspense. LCP measures the largest visible element, not the completeness of the page.
ROVQIX Growth
SEO & growth team, ROVQIX
The ROVQIX growth team handles technical SEO, Core Web Vitals and AI-search visibility for the sites we build. Recommendations here are the ones we apply to client projects and to rovqix.in itself.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Three numbers, each measuring a different way a page can feel bad: slow to appear, slow to respond, and unstable while you use it.
next/image solves format, sizing and lazy loading for you — and then hands you two props, sizes and priority, that decide whether your LCP is 1.2s or 4s.
Fonts are usually the second-largest asset on a page and the most common cause of text that appears late, then jumps.
No spam. Just the occasional case study and craft breakdown.