Web Performance: Deep Notes

Performance work has a failure mode that shows up long before any technical mistake: optimising the thing that wasn't slow. What makes the difference is knowing which metric describes the problem, which tool measures it, and which fix actually moves it.

This covers Core Web Vitals, loading strategies, runtime performance, the network layer, and a method for diagnosing a slow page rather than guessing at it.

---

1. Core Web Vitals

Google's three user-centric metrics. One important change: INP replaced FID in March 2024, and they measure meaningfully different things.

LCP — Largest Contentful Paint

The render time of the largest image or text block in the viewport. Usually a hero image, a large heading, or a banner.

It goes bad from slow server response, render-blocking CSS and JavaScript, large unoptimised images, client-side rendering that delays the main content, and — the classic own goal — lazy-loading the hero image, which delays the exact element the metric is measuring.

The fixes:

• Optimise the LCP image: compress it, serve AVIF or WebP, use responsive srcset.
• preload it so the fetch starts early rather than after CSS parsing discovers it.
• Never put loading="lazy" on it.
• Reduce TTFB with a CDN, caching, and a faster backend.
• Inline critical CSS and defer the rest.

HTMLindex.html
1<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
2<img src="/hero.avif" fetchpriority="high" alt="..." />

INP — Interaction to Next Paint

The metric that replaced FID, and a much harder one to game. FID measured only the delay before the first interaction's handler began — which flattered pages that were sluggish everywhere except the first click. INP measures the full latency — input delay, processing time, and the next paint — across every interaction during the page's lifetime, then reports a near-worst-case value.

It goes bad when long-running JavaScript occupies the main thread while the user is trying to interact: heavy synchronous work in handlers, large re-renders, expensive computation triggered by a click.

The fixes:

• Break up long tasks. Anything over 50ms blocks the main thread; yield with setTimeout, requestIdleCallback, or scheduler.yield().
• Move heavy computation to a web worker.
• Debounce or throttle expensive handlers.
• In React, cut unnecessary re-renders, and use useTransition or useDeferredValue to mark updates as non-urgent so interactions stay responsive.

JSfile.js
1// Yield periodically so a long loop doesn't freeze interaction
2async function processInChunks(items) {
3  for (let i = 0; i < items.length; i++) {
4    doWork(items[i]);
5    if (i % 100 === 0) await new Promise((r) => setTimeout(r, 0));
6  }
7}

CLS — Cumulative Layout Shift

How much visible content moves unexpectedly. This is the metric behind the universally hated experience of reaching for a button just as an ad loads and pushes it out from under your finger.

It goes bad from images and videos without dimensions, ads and embeds injected without reserved space, web fonts causing reflow as they swap in, and content inserted above what the user is already reading.

The fixes:

• Always set width and height, or aspect-ratio, on images and media so space is reserved before the file loads.
• Give ads and embeds a fixed-size container.
• Use font-display: optional or swap, and preload fonts, to limit text reflow.
• Never insert content above the user's current viewport position.

CSSstyles.css
1img { aspect-ratio: 16 / 9; width: 100%; height: auto; }

Field data versus lab data

Worth keeping straight. Lab data is a synthetic run under controlled conditions — Lighthouse. Field data is what real users on real devices and real networks experienced — CrUX and RUM.

They diverge, often dramatically, because your laptop on office wifi is not a mid-range Android phone on a congested mobile network. Both are useful, but Core Web Vitals scoring uses field data, so that's the one that counts.

---

2. Loading Strategies

Code splitting

Ship only what the user needs for the current view.

Route-based splitting gives each route its own chunk. It's the highest-impact and easiest form, and usually the first thing to do.

Component-based splitting lazy-loads heavy components — modals, charts, rich text editors — at the moment they're needed.

JSXcomponent.jsx
1const Dashboard = lazy(() => import('./Dashboard'));
2
3<Suspense fallback={<Spinner />}>
4  <Dashboard />
5</Suspense>

Tree shaking

Dead-code elimination at build time: the bundler drops exports nothing imports. It depends on ES modules, because static import/export can be analysed without running the code — CommonJS require is dynamic and cannot.

It also depends on how you import. import { debounce } from 'lodash-es' lets the bundler keep one function; importing the whole library defeats it.

Resource hints

HTMLindex.html
1<link rel="preconnect" href="https://api.example.com" />
2<link rel="preload" as="font" href="/inter.woff2" type="font/woff2" crossorigin />
3<link rel="prefetch" href="/checkout.chunk.js" />

Images

Images are the largest payload on most pages, which makes them the biggest available win:

• Modern formats — AVIF and WebP are dramatically smaller than JPEG and PNG.
• Responsive images — srcset and sizes so a phone doesn't download a desktop-resolution file.
• loading="lazy" for anything below the fold, and never for the LCP image.
• decoding="async" so decoding doesn't block rendering.

HTMLindex.html
1<img
2  src="/photo-800.jpg"
3  srcset="/photo-400.jpg 400w, /photo-800.jpg 800w, /photo-1200.jpg 1200w"
4  sizes="(max-width: 600px) 400px, 800px"
5  loading="lazy"
6  decoding="async"
7  width="800" height="600"
8  alt="room" />

---

3. Runtime Performance

Batch reads and writes

Reading a layout property — offsetHeight, getBoundingClientRect, scrollTop — forces the browser to synchronously flush any pending layout changes so it can give you an accurate answer. Interleaving reads and writes in a loop is layout thrashing, and it turns a batched operation into one reflow per iteration:

JSfile.js
1// Bad — every read forces a synchronous layout
2items.forEach((el) => { el.style.height = el.offsetHeight * 2 + 'px'; });
3
4// Good — all reads, then all writes
5const heights = items.map((el) => el.offsetHeight);
6items.forEach((el, i) => { el.style.height = heights[i] * 2 + 'px'; });

Animate on the compositor

transform and opacity skip layout and paint entirely and run on the GPU compositor thread. Everything else does not:

CSSstyles.css
1/* Smooth — compositor only */
2.modal { transition: transform 0.2s, opacity 0.2s; }
3
4/* Janky — reflows every frame */
5.modal { transition: top 0.2s, height 0.2s; }

will-change: transform hints the browser to promote an element to its own layer in advance. Use it sparingly — every layer costs memory, and over-applying it makes things worse.

requestAnimationFrame

Schedules visual updates to run immediately before the next paint, synchronised to the display refresh rate. It's the correct primitive for animation, and for batching DOM writes:

JSfile.js
1function animate() {
2  el.style.transform = `translateX(${x}px)`;
3  x += 2;
4  if (x < 300) requestAnimationFrame(animate);
5}
6requestAnimationFrame(animate);

Unlike setTimeout, it pauses in background tabs and never fires more often than the screen can display.

Web workers

JavaScript is single-threaded, so heavy computation on the main thread freezes the UI and destroys INP. Parsing large files, sorting big datasets, image processing — all of it belongs on a worker:

JSfile.js
1const worker = new Worker('parser.js');
2worker.postMessage(largeDataset);
3worker.onmessage = (e) => render(e.data);   // UI stays responsive throughout

Virtualization

Render only the rows currently visible, plus a small buffer, instead of thousands of DOM nodes. react-window and react-virtualized are the usual tools.

The property that matters: DOM node count stays constant regardless of list length. A ten-thousand-row table costs the same as a fifty-row one, so scrolling stays smooth and memory stays flat.

---

4. Network

Caching

Immutable hashed assets. Bundle files carry a content hash in the filename — app.a3f9c.js — and ship with Cache-Control: max-age=31536000, immutable. The hash changes when the content does, so you can cache forever and cache-bust automatically on every deploy.

HTML gets a short cache or no-cache, so users pick up new asset references promptly.

Service workers give you a programmable cache for offline and PWA support, with strategies like cache-first, network-first, and stale-while-revalidate.

CDN

Serving static assets from edge servers geographically near your users cuts latency substantially and takes load off your origin. It pairs naturally with immutable hashed assets, since those can be cached at the edge indefinitely.

Compression

gzip is the universally supported baseline. Brotli achieves better ratios on text — HTML, CSS, JavaScript — and is preferred wherever the client supports it. The server negotiates via Accept-Encoding and Content-Encoding.

Compressing text assets is among the cheapest large wins available.

Bundle size

Tree shaking and code splitting do the structural work. Beyond that: swap heavy dependencies for lighter ones — date-fns instead of moment is the standard example — use dynamic imports for rarely-touched features, and run a bundle analyser to find out what's actually large rather than what you assume is.

---

5. Diagnosing a Slow Page

The principle that governs everything: measure first, optimise second. Intuition about what's slow is wrong often enough that acting on it wastes real time.

Identify the symptom. Is the page slow to load, or slow to respond? These are different problems with different tools and different fixes, and conflating them is the most common wrong turn.

Measure with the right tool:

• Lighthouse — a quick audit surfacing Core Web Vitals and concrete suggestions. Lab data.
• Performance panel — record a session to find long tasks, layout thrashing, expensive scripting, and whatever is occupying the main thread.
• Network panel — slow requests, render-blocking resources, oversized payloads, missing compression, request chains.
• Coverage tab — how much CSS and JavaScript you shipped that never executed.
• Field data — CrUX or your own RUM, for what users actually experience.

Diagnose against the metric:

• Slow LCP → check TTFB, render-blocking resources, and the LCP image. Is it preloaded, optimised, or accidentally lazy-loaded?
• Poor INP → find long tasks and heavy event handlers in the Performance panel.
• High CLS → find what's shifting. Usually missing dimensions or late-injected content.

Fix the biggest bottleneck, then measure again. Optimisation is iterative. Change one thing, confirm it helped, and only then move on. A fix that seemed obvious and did nothing is extremely common, and you'll only know if you re-measure.

---

The Shape of It

Core Web Vitals — LCP for loading, INP for responsiveness (it replaced FID in 2024), CLS for stability. Preload the hero and never lazy-load it, break up long tasks, reserve space for anything that loads late.

Loading — split by route first, tree-shake with ES modules, use the right resource hint, and treat images as the biggest available win.

Runtime — batch reads before writes, animate transform and opacity only, offload heavy work to workers, virtualize long lists.

Network — immutable hashed assets behind a long cache, a CDN, Brotli, and a bundle you've actually measured.

Method — measure, diagnose against the metric that's failing, fix the largest bottleneck, re-measure.