← read more

Website Performance: What Actually Moves Core Web Vitals

A practical guide to making websites fast — where the time actually goes, what to fix first, and how we tune Core Web Vitals without chasing meaningless micro-optimizations.

Website Performance: What Actually Moves Core Web Vitals

Nobody clicks a link hoping to wait. Slow pages cost you rankings, conversions, and credibility — and unlike a redesign, performance problems are invisible until you measure them. The good news: making a website genuinely fast is not magic. It's a short list of high-impact fixes, applied in the right order.

Measure before you optimize

The first rule: never optimize a guess. Even the best intuition is wrong about where the time actually goes. Before touching anything, capture a baseline:

  • Lighthouse (built into Chrome DevTools) for a lab snapshot of Core Web Vitals: LCP, INP, CLS.
  • Real-user monitoring for field data — what actual visitors experience on their devices.
  • The Network tab — sort by size and by duration to see what dominates the waterfall.

Optimize what the data points at, then re-measure. A fix you can't measure is a fix you can't defend.

The server side: TTFB is the foundation

Every other metric sits on top of TTFB — the time until the server sends the first byte. If that's slow, nothing downstream can compensate. The usual culprits, in order:

  1. Uncached database queries — the classic. Add indexes, eager-load relations, and cache repeated lookups.
  2. Missing HTTP caching — the browser should not re-download assets that haven't changed.
  3. A heavy framework runtime — sometimes the slow part is simply the request lifecycle itself.

For dynamic pages, a small amount of server-side caching (page-level or fragment cache) usually collapses TTFB on repeat visits. And if the page is public and changes rarely, consider pre-rendering it at build time — static output is the fastest output that exists.

The front end: what users actually see

Core Web Vitals measure the experience, not the code — so the front end matters just as much:

  • Images are the biggest lever. Serve modern formats (AVIF/WebP), set explicit width/height to prevent layout shift, and lazy-load everything below the fold.
  • Fonts must not block rendering. Use font-display: swap and subset fonts to the glyphs you actually use.
  • JavaScript should be a progressive enhancement, not a paywall to the content. Code-split, defer non-critical chunks, and never let a third-party script block first paint.

A typical checklist looks like this:

<img src="hero.avif" width="1200" height="630" alt="Hero" loading="lazy" decoding="async">
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Caching: the cheapest performance on the internet

Proper Cache-Control headers are nearly free and give you the largest win-per-effort ratio. The pattern:

  • Cache-Control: public, max-age=31536000, immutable for hashed assets like app-8f3c2a.js.
  • A short max-age with cache revalidation for HTML pages.
  • HTTP/2 (or HTTP/3) so the browser can fetch many assets in a single connection instead of queueing them.

If visitors are geographically far from the server, a CDN fronting the static assets is usually the next step — it makes cache hits physically closer to the user.

The realistic order of operations

  1. Measure and pick the one worst metric.
  2. Fix the server side first — TTFB compounds everything.
  3. Optimize images and fonts — biggest visible gain per hour of work.
  4. Add or fix caching headers.
  5. Re-measure, compare with the baseline, repeat.

Performance work is never truly finished — pages change, content grows, new scripts appear. But a team that measures and applies these basics in order ends up with fast sites as a habit, not a project. And fast is a feature users feel on every single visit.