Performance

Speed is part of the experience, and it's measured from the user's side. Google's Core Web Vitals name the three things users feel most, each judged at the 75th percentile of real visits.

• LCP (loading): when the largest image or text block appears. Good is 2.5 s or less.
• INP (responsiveness): the delay from a click, tap or key press to the next paint, for the slowest interaction. Good is 200 ms or less.
• CLS (visual stability): how much visible content moves unexpectedly. Good is 0.1 or less.
• Lab vs field: Lighthouse and DevTools test one load on your machine (lab); real users on slower phones and networks give field data (CrUX, the web-vitals library). Fix with lab tools, judge with field data.

Every page starts with one HTML request, and nothing else can start before its first bytes arrive. Time to First Byte (TTFB) covers redirects, DNS, the connection and the server's work; good is 0.8 s or less.

• Avoid redirects: each one is another request, often on a new connection (http → https, a missing www, a trailing slash). Link to the final address.
• Cache HTML briefly: a short Cache-Control lifetime plus ETag or Last-Modified lets browsers and CDNs revalidate cheaply. Never cache personalised pages in a shared cache.
• Compress text: Brotli (about 15–20% smaller than gzip) with gzip as a fallback; pre-compress static CSS and JS at build time, compress HTML on the fly.
• Use a CDN: edge servers near your users cut every round trip, cache static files (and HTML when allowed), and bring HTTP/2–3, TLS 1.3 and compression by default.
• Measure the server: the Server-Timing header shows where TTFB goes (database, rendering); stream the HTML so the <head> leaves early.

Before the first paint the browser needs the HTML, then every stylesheet and every classic script in <head>: this chain is the critical rendering path. Shorten it, and help the browser find important files early.

• The clock starts with the HTML itself (see HTML delivery and CDNs); everything below can only begin once it arrives.
• CSS blocks rendering and classic scripts block parsing (see How the browser renders a page). Use defer (or async for independent scripts), and inline the small CSS needed above the fold.
• The browser can only fetch what it has found. preload resources it finds late (CSS backgrounds, fonts), preconnect to the one or two other origins you will need right away, and use the cheaper dns-prefetch for origins needed later.
• fetchpriority="high" tells the browser which image is the LCP, so it isn't queued behind less important ones.

Images and video are usually the largest bytes on a page, an image is often the LCP element, and media that arrives late is the usual cause of layout shift.

• Send the right size: srcset and sizes let the browser pick a file for the screen. Prefer AVIF or WebP.
• Always set width and height (or CSS aspect-ratio) so space is reserved before the image arrives.
• Lazy-load images and <iframe>s below the fold with loading="lazy", but never the LCP image (see practice 11).
• Heavy embeds (video players, maps, chat widgets): show a light facade (a poster image and a play button) and load the real iframe on click.
• Video: set a small poster, use preload="none" (or metadata) unless it plays at once, lazy-load it below the fold, and replace animated GIFs with a muted, looping <video>, often several times smaller.

Text set in a web font can't be drawn in that font until the file arrives. What the reader sees meanwhile, invisible text or a fallback font, is chosen with font-display.

• swap shows text at once in a fallback font (good for body text); optional uses the font only if it is there almost at once (no late swap, best for CLS); block hides text for up to 3 s.
• Send fewer bytes: WOFF2 only, subset to the characters you use (unicode-range), one variable font instead of many weights.
• Find fonts early: self-host them on your own origin, preload the one or two the first paint needs, or preconnect to the font host.
• Keep the swap from shifting the layout: match the fallback's size with size-adjust and ascent-override (next/font does this for you).

Every kilobyte of JavaScript is downloaded, parsed and run on the main thread. Ship only what the current page needs, and fetch the rest (or the next page) just before it is needed.

• Split by route (Next.js does this per page) and by interaction: load a heavy dialog, editor or chart with import() when the user opens it.
• Prefetch on intent: start loading when the pointer hovers or a link enters the viewport (next/link does this), so the click finds it ready.
• <link rel="prefetch"> fetches a likely next resource at low priority, for later use.
• Speculation Rules (<script type="speculationrules">) prefetch or even prerender likely next pages, so they open instantly. Prerendering costs data and CPU, so keep it to links the user is very likely to follow (for example on hover).
• A service worker can precache the files for the next visit and work offline (Workbox makes this easier).
• Check what you ship with a bundle analyzer; one large dependency often outweighs everything else.

The main thread runs your JavaScript, styles, layout and paint, one task at a time. A task over 50 ms is a long task: while it runs, clicks and key presses wait, which is what INP measures.

• Break long work into chunks and yield between them so input and painting can happen in between: scheduler.yield() resumes first (good for input), a new task (setTimeout, MessageChannel) lets rendering go first.
• Move pure computation (parsing, filtering, image processing) to a web worker. Workers have no DOM access and messages are copied, unless you transfer an ArrayBuffer, which moves it between threads for free.
• A concrete use case: the course reads Exif metadata from JPEGs in a worker; the demo below blurs a photo there, sending its pixels both ways as a transferable.
• In React, keep input urgent with useTransition or useDeferredValue and render less (see practice 14).