Web Performance Optimization: Overview and Playbook

A playbook-style entry point to the Web Performance series. The goal is a small set of mental models (a CWV scorecard, a layered dependency stack, and a “which metric is failing → which layer to fix” decision tree) so you can pick the right deep-dive article instead of optimising blindly.

Abstract

Web performance optimisation reduces to three user-centric questions: how fast does the main content appear? (Largest Contentful Paint, LCP), how quickly does the page respond to interaction? (Interaction to Next Paint, INP), and does the layout stay stable while loading? (Cumulative Layout Shift, CLS). These three Core Web Vitals are Google’s user-experience ranking signals, measured at the 75th percentile of real user visits per origin per device class. A URL passes only when p75 hits “good” on all three for both mobile and desktop slices.

The optimisation stack is a layered dependency chain — each layer caps what the next can achieve:

1. Infrastructure (DNS, HTTP/3, CDN, caching) determines the floor for every metric. You cannot optimise your way out of a slow origin or a missing edge cache.
2. JavaScript (bundle size, long tasks, workers) directly gates INP. The 200 ms INP budget at p75 forces you to break work into chunks and move computation off the main thread.
3. CSS & Typography (critical path, containment, font loading) affect both LCP and CLS. Inlined critical CSS unblocks first paint; font-metric overrides eliminate text-swap layout shift.
4. Images (formats, responsive sizing, priority hints) usually dominate LCP on content-heavy pages. AVIF/WebP and fetchpriority="high" target the actual LCP element.

Each layer has diminishing returns without the previous one being sound. A perfectly code-split bundle does not help if TTFB is 2 seconds. Zero-CLS font loading does not help if JavaScript blocks the main thread for 500 ms during the user’s first tap.

Core Web Vitals Thresholds

As of March 12, 2024, the Core Web Vitals are LCP, INP, and CLS — capturing loading, interactivity, and visual stability. INP replaced FID on that date and the deprecation period for FID-based APIs ran to September 9, 2024.

Supporting metrics (not Core Web Vitals):

TTFB is excluded from the Core Web Vitals because fast server response does not guarantee good user experience — a page can have 100 ms TTFB but 5 s of JavaScript blocking LCP. However, slow TTFB makes good LCP nearly impossible: at p75, every millisecond of TTFB is a millisecond unavailable for the rest of the LCP budget.

Why These Metrics?

Google’s threshold methodology targets p75 with two competing constraints: achievability (a meaningful fraction of sites can reach “good” with focused effort) and meaningfulness (users perceive the difference). 2.5 s LCP corresponds to lab and field research on perceived load; 200 ms INP is at the upper end of the 100–200 ms window where interactions still feel instant; 0.1 CLS is the largest shift a typical user does not consciously notice.

Which metric is failing? Start with the bottleneck

Before diving into a layer, identify which metric is failing on field data and which layer is the most likely cause. The decision tree below routes from a failing CWV to the deep-dive article that covers the relevant fix.

1. Infrastructure & Architecture

Infrastructure determines the performance floor. Network round trips, TLS handshakes, server processing, and cache misses create latency that no amount of frontend optimisation can overcome. A 2 s TTFB leaves only 500 ms for everything else against a 2.5 s LCP target.

Detailed coverage: Infrastructure Optimization for Web Performance

Quick reference

Key techniques

• DNS protocol discovery. HTTPS resource records (RFC 9460, published November 2023) advertise alpn=h3 so browsers attempt HTTP/3 on the first request rather than upgrading via Alt-Svc, saving 100–300 ms (Cloudflare).
• HTTP/3 and QUIC. Eliminates TCP head-of-line blocking and merges crypto+transport handshakes. In stable networks the page-load gain over HTTP/2 is modest (single-digit percent) — HTTP/3’s real wins are in lossy or high-RTT conditions, where Cloudpanel’s synthetic benchmarks at 15 % packet loss show ~55 % faster page load vs. HTTP/2 (details). Cloudflare’s own production data showed 12.4 % faster TTFB and small page-load gains on average.
• Edge computing. Runs personalisation, A/B routing, and auth at the CDN edge, removing an origin round-trip for the request paths that touch them.
• BFF pattern. A backend-for-frontend collapses chatty client-to-service calls into one tailored response. Concrete savings vary by workload — typically a meaningful drop in request count and payload, especially for mobile and waterfall-heavy SPAs.
• Multi-layer caching. RFC 9111-compliant edge cache + service worker + IndexedDB + origin object cache. Each layer answers a different request class (cold vs. warm vs. revisit).

2. JavaScript Optimization

JavaScript directly gates INP. Every millisecond of main-thread blocking is a millisecond added to interaction latency. The 200 ms INP budget means: receive input, run handlers, let the browser paint — all within 200 ms. Tasks longer than 50 ms are flagged as Long Tasks and risk exceeding the budget on mid-tier devices.

Detailed coverage: JavaScript Performance Optimization

Quick reference

Key techniques

• Script loading. defer for app code (parallel fetch, in-document-order execution after parse). async for independent scripts (analytics, third-party widgets).
• Code splitting. Route-based with React.lazy() + Suspense; component-level for heavy widgets (rich text, charts).
• Task scheduling. Use scheduler.yield() (Chrome 129+, Firefox 142+) over setTimeout(0) so the continuation jumps to the front of the queue after the browser handles input/render. Yield every ~5 ms or every N items in long loops.
• Worker pools. A pool with bounded concurrency and a task queue beats spawning a worker per call. Use transferable objects to avoid copying large buffers.
• Tree shaking. Mark packages "sideEffects": false, use ES modules end-to-end so bundlers can statically eliminate unused exports (CommonJS is runtime-resolved and resists this).

3. CSS & Typography

CSS is render-blocking by default; web fonts cause layout shift when they swap from a fallback. The critical rendering path needs CSS before first paint, but only the CSS for above-the-fold content. Font loading is the most common preventable CLS source — fallback fonts have different metrics than web fonts, so text reflows on swap.

Detailed coverage: CSS and Typography Optimization

Quick reference

Key techniques

• Critical CSS. Inline above-the-fold styles within the ~14 KB initial congestion window so first paint is unblocked in a single round-trip. Defer the rest with the media="print" → onload swap pattern.
• CSS containment. contain: layout paint style isolates reflows and repaints to the contained subtree, which keeps a misbehaving widget from re-laying-out the entire page.
• Compositor-only animation. Only animate transform and opacity to stay on the compositor thread (60 fps without main-thread work).
• Font subsetting. Strip unused glyphs with pyftsubset (e.g., Latin-only). Single language subsets often save 60–90 % of file size.
• Variable fonts. A single file for all weights/widths is usually smaller than three or more static files combined.
• Font metric overrides. size-adjust, ascent-override, descent-override, line-gap-override on @font-face for the local fallback to match the web font’s box, eliminating font-swap CLS.

4. Image Optimization

Images are typically the LCP element on content-heavy pages. A 2 MB hero served as JPEG when an equivalent-quality AVIF would be 400 KB directly delays LCP. Beyond format, the browser must discover, request, download, and decode the image before it can paint — so loading strategy matters as much as bytes.

Detailed coverage: Image Optimization for Web Performance

Quick reference

Format selection

Key techniques

• Picture element. Negotiate AVIF → WebP → JPEG via <picture><source type="image/avif"><source type="image/webp"><img></picture>. Pagesmith generates this automatically for local raster images in this repo.
• Responsive images. srcset with width descriptors (image-480w.jpg 480w), sizes for layout hints ((min-width: 768px) 50vw, 100vw).
• LCP images. loading="eager" + fetchpriority="high" + decoding="async" on the actual LCP element.
• Below-the-fold images. loading="lazy". Browsers typically pre-fetch a viewport or two ahead.
• Network-aware loading. Adjust quality / format based on navigator.connection.effectiveType where available.

5. Performance Monitoring

Continuous monitoring keeps the optimisations effective and catches regressions before they reach the field. The CWV thresholds are p75 metrics — without field data you cannot prove you pass them.

Detailed coverage: Core Web Vitals Measurement: Lab vs Field Data

Key signals to track

• Core Web Vitals (field). LCP, INP, CLS via the web-vitals library or PerformanceObserver, sliced by device class and route. Field data — not Lighthouse — is what Search uses.
• TTFB and origin health. Server response time and cache hit ratio at the edge and origin.
• Bundle sizes. Track JS/CSS bytes per route in CI; fail the build on regression with size-limit or your bundler’s stats.
• Resource budgets. Use Lighthouse performance budgets (budget.json) or your CDN’s analytics to enforce per-page byte counts.

Monitoring tools

Implementation Checklist

Infrastructure

• Enable HTTP/3 with HTTPS DNS records
• Configure TLS 1.3 with 0-RTT resumption
• Set up CDN with edge computing capabilities
• Implement multi-layer caching (CDN + Service Worker + Redis)
• Configure Brotli compression (level 11 static, level 4-5 dynamic)

JavaScript

• Implement route-based code splitting
• Use scheduler.yield() for tasks >50ms
• Offload heavy computation to Web Workers
• Configure tree shaking with ES modules
• Set up bundle size budgets in CI

CSS & Typography

• Extract and inline critical CSS (≤14KB)
• Apply CSS containment to independent sections
• Use WOFF2 format with subsetting
• Implement font metric overrides for zero-CLS
• Preload critical fonts with crossorigin attribute

Images

• Serve AVIF/WebP with JPEG fallback via <picture>
• Implement responsive images with srcset and sizes
• Use fetchpriority="high" for LCP images
• Apply loading="lazy" to below-fold images
• Set explicit width/height to prevent CLS

Monitoring

• Set up Lighthouse CI in GitHub Actions
• Configure bundle size budgets with size-limit
• Implement RUM with PerformanceObserver
• Create performance dashboards and alerts

Performance Budget Reference

1{2  "resourceSizes": {3    "total": "500KB",4    "javascript": "150KB",5    "css": "50KB",6    "images": "200KB",7    "fonts": "75KB"8  },9  "metrics": {10    "lcp": "2.5s",11    "fcp": "1.8s",12    "ttfb": "200ms",13    "inp": "200ms",14    "cls": "0.1"15  }16}

Series Articles

Practical takeaways

• Measure before you optimise. Use field data (CrUX or your own RUM) to identify the failing metric at p75. Synthetic Lighthouse scores are a debugging aid, not a pass/fail signal.
• Fix the layer that owns the metric. A site with good infrastructure but poor INP needs JavaScript work, not more CDN tuning. A bad LCP on a content-heavy page is almost always images or TTFB, not CSS.
• Respect the dependency chain. Each layer caps what the next can deliver. A 2 s TTFB cannot be hidden by clever code splitting.
• Track regressions in CI, not just dashboards. Bundle-size budgets and Lighthouse CI catch regressions before they reach users; CrUX reports them 28 days later.
• Pick one metric per quarter. Most teams improve more by spending a quarter focused on INP than by spreading effort across all three CWV at once.

Appendix

Prerequisites

• Working knowledge of the browser rendering pipeline (parse, layout, paint, composite)
• Familiarity with HTTP/1.1, HTTP/2, and the basics of TLS
• Mental model of the JavaScript execution model, the event loop, and microtasks

Summary

• Core Web Vitals (as of March 12, 2024): LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 — measured at the 75th percentile of real user visits.
• Optimisation layers form a chain: Infrastructure → JavaScript → CSS/Typography → Images. Each layer caps the next.
• Infrastructure: HTTP/3, edge CDN, multi-layer caching aim for TTFB ≤ 800 ms (web.dev “good”), with ≤ 200 ms as the engineering target on cached origins.
• JavaScript: code splitting, scheduler.yield(), and Web Workers keep INP under 200 ms.
• CSS & fonts: critical CSS inlining within the 14 KB initial congestion window; font metric overrides eliminate font-swap CLS.
• Images: AVIF/WebP via <picture>, responsive srcset, fetchpriority="high" on the LCP element.
• Measurement: field data (CrUX/RUM) is the source of truth; lab tools are for diagnosis.

References

Specifications and standards

• RFC 9110 — HTTP Semantics
• RFC 9111 — HTTP Caching
• RFC 9114 — HTTP/3
• RFC 9000 — QUIC
• RFC 9460 — SVCB and HTTPS DNS resource records
• RFC 8446 — TLS 1.3
• RFC 6928 — Increasing TCP’s Initial Window
• W3C CSS Containment Module Level 2
• W3C Long Tasks API

Official documentation

• Web Vitals overview
• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)
• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Defining Core Web Vitals thresholds
• INP becomes a Core Web Vital, March 12 2024
• scheduler.yield() — Chrome for Developers
• Fetch priority

Implementation references

• Web Workers API — MDN
• CSS Containment — MDN
• Responsive Images — MDN
• Variable fonts — MDN
• web-vitals JavaScript library
• Lighthouse CI
• HTTP/3 Explained (Daniel Stenberg)