PERF

<a href="http://shop.example/sale">Sale</a><!-- → https://shop.example/sale → https://shop.example/sale/ -->

<a href="https://shop.example/sale/">Sale</a>

Each hop is a round trip, often a new connection, before the first byte. Link to the final URL, trailing slash included; HSTS turns the http hop into none.

Spot it Lighthouse: “Document request latency”

Cache-Control: no-store # the origin rebuilds the HTML every visit

Cache-Control: public, s-maxage=60, stale-while-revalidate=600

Nothing paints before the first byte, so every millisecond on the server is added to LCP. Let a CDN serve cached HTML and revalidate in the background; keep no-store for pages that are truly per-user.

Spot it Network panel → Timing: “Waiting for server response” over 0.8 s

<script src="/app.js"></script>

<script src="/app.js" defer></script>

Nothing below the tag renders while the script downloads and runs. defer runs it after parsing, in order; async runs it on arrival, for scripts nothing depends on.

Spot it Lighthouse: “Render blocking requests”

@import url("https://fonts.googleapis.com/css2?family=Inter:wght@400;700");

@font-face {  font-family: "Inter";  src: url("/fonts/inter-latin.woff2") format("woff2");  font-weight: 100 900;}

Text stays invisible until the font arrives, and the font is found only after two stylesheets and a new connection. Caches are partitioned by site, so no visitor arrives with it. Self-host one variable file; preconnect to any origin the first paint still needs.

Spot it Network panel → Font: requests to a second origin, starting after two stylesheets

<link rel="stylesheet" href="/site.css"> <!-- 300 KB, every page -->

<link rel="stylesheet" href="/home.css"> <!-- 20 KB, this page -->

Nothing paints until every stylesheet in the <head> has downloaded and parsed. Give each page the CSS it uses, split by route or component, and inline the little the first paint needs.

Spot it Coverage panel: most of the stylesheet unused on load

<img src="hero.avif" loading="lazy" alt="…">

<img src="hero.avif" fetchpriority="high" alt="…">

The image that decides LCP waits until layout proves it is on screen. Never lazy-load above the fold; a hero set as a CSS background needs <link rel="preload">.

Spot it Lighthouse: “LCP request discovery”

<img src="photo-4000w.jpg" alt="…">

<img src="photo-800w.avif" alt="…"  srcset="photo-800w.avif 800w, photo-1600w.avif 1600w"  sizes="(min-width: 60rem) 50vw, 100vw">

A phone downloads 4000 pixels to show 400. srcset lists the sizes, sizes says how wide the image renders, and the browser picks the smallest sharp one.

Spot it Lighthouse: “Improve image delivery”

Cache-Control: no-cache # app.3f9a1c.js, asked for every visit

Cache-Control: max-age=31536000, immutable

Each repeat visit revalidates a file whose hash guarantees it never changed. Cache hashed files for a year; only the HTML that names them stays short-lived.

Spot it Lighthouse: “Use efficient cache lifetimes”

<div id="root"></div><script type="module" src="/app.js"></script>

<div id="root"><h1>Summer sale</h1><img src="hero.avif" alt="…"></div><script type="module" src="/app.js"></script>

An empty <div> gives the browser nothing to paint and nothing to preload. The bundle downloads, runs, fetches its data, and only then asks for the hero. Prerender or server-render the HTML; the script can still take over.

Spot it Performance panel → LCP breakdown: a long load delay, the image requested only after the script runs

const user = await getUser();const posts = await getPosts();

const [user, posts] = await Promise.all([getUser(), getPosts()]);

Two awaits, two round trips. Start independent requests together; the same staircase hides in components that fetch after their parent and in CSS @import chains.

Spot it Network panel: requests that start as the previous one ends

<img src="banner.avif" alt="…">

<img src="banner.avif" width="1200" height="400" alt="…">

An image with no size takes no space until it loads, then shoves the text down. width and height reserve the ratio, and height: auto keeps it responsive; embeds need aspect-ratio.

Spot it Performance panel: Layout shift clusters on image load

{loading ? <Spinner /> : <Feed posts={posts} />}

{loading ? <FeedSkeleton rows={5} /> : <Feed posts={posts} />}

A 40-pixel spinner gives way to a 2 000-pixel feed, and everything below it jumps; banners, ads and embeds do the same. Reserve the space up front with a skeleton the size of the result or a min-height on the slot, or keep late content below the fold.

Spot it Performance panel → Insights: “Layout shift culprits”

.drawer { transition: left 300ms; }

.drawer { transition: transform 300ms; }

left, width and margin move the layout itself: every frame reruns layout and paint, and whatever moves without a recent input counts as a shift. transform and opacity stay on the compositor and count as neither.

Spot it Rendering drawer → Paint flashing: green on every frame

@font-face { font-family: "Brand"; src: url(brand.woff2); font-display: swap; }

@font-face { font-family: "Brand fallback"; src: local("Arial"); size-adjust: 104%; }body { font-family: "Brand", "Brand fallback"; }

When the web font arrives with different metrics, the text reflows. A fallback tuned with size-adjust takes the same space, so the swap moves nothing. Astro’s font API and next/font generate one.

Spot it Performance panel: a layout shift right as the font request finishes

addEventListener("unload", () => navigator.sendBeacon("/log", stats));

addEventListener("pagehide", () => navigator.sendBeacon("/log", stats));

Back and forward could restore the page from memory, laid out and scrolled where the reader left it. An unload listener rules that out, so the page loads again from the network, shifts and all. pagehide fires in the same places and keeps the cache.

Spot it Application panel → Back/forward cache: “Test back/forward cache”

hydrateRoot(document, <App />) // every paragraph too

<Article /><Comments client:visible />

The page looks ready, but clicks do nothing until every component has run again. Ship JavaScript only for the interactive parts, and hydrate them when needed.

Spot it Performance panel: one long Evaluate Script task after first paint

import _ from "lodash";

import { debounce } from "lodash-es";

One function costs the whole library: CommonJS can’t be tree-shaken. Use ES module builds with named imports, or the platform: structuredClone, Intl, toSorted.

Spot it A bundle visualiser: one import, one giant block

import { Editor } from "./editor"; // 400 KB, used on one page

const { Editor } = await import("./editor"); // on click

A static import ships 400 KB to every visitor on every route. A dynamic import() moves it into a chunk fetched only when needed.

Spot it Coverage panel: most of the main bundle unused on load

<script src="https://chat.example/widget.js" async></script>

chatButton.addEventListener("click", () => {  const script = document.createElement("script");  script.src = "https://chat.example/widget.js";  document.head.append(script);}, { once: true });

Chat, A/B tests and tag managers run long tasks while the page is waking up, and early clicks queue behind them. Load a widget when it is asked for, behind a facade that looks like it.

Spot it Performance panel → Insights: “3rd parties”, and their long tasks

import { Button } from "@/components"; // index.ts re-exports 200 modules

import { Button } from "@/components/button";

The bundler must load every re-exported module, and drops one only if it can prove it has no side effects. The dev server loads them all, every time. Import from the file itself.

Spot it A bundle visualiser: modules the page never renders, pulled in by one index file

{ "dependencies": { "moment": "^2.30", "dayjs": "^1.11", "date-fns": "^4.1" } }

new Intl.DateTimeFormat("en", { dateStyle: "medium" }).format(date);

Each team picked its own date library, and every visitor downloads all three. Mismatched versions add second copies of the same one. Pick one, or none: Intl formats dates, numbers and lists.

Spot it npm ls: the same job done by several packages, or one package at several versions

// browserslist"> 0.25%, ie 11"

// browserslist"baseline widely available"

ES5 output turns classes and async into longer helpers and ships polyfills to browsers that have the feature. Target what visitors actually run; Baseline is a sane default.

Spot it Lighthouse: “Legacy JavaScript”

for (const el of items) el.style.height = el.offsetWidth / 2 + "px";

const widths = items.map((el) => el.offsetWidth);items.forEach((el, i) => (el.style.height = widths[i] / 2 + "px"));

In a loop, each read after a write forces layout, once per item. Read everything, then write everything, and layout runs once.

Spot it Performance panel: purple Layout blocks flagged “Forced reflow”

button.addEventListener("click", () => {  saveDraft(); // 300 ms  status.textContent = "Saved";});

button.addEventListener("click", async () => {  status.textContent = "Saving…";  await scheduler.yield(); // paint first  saveDraft();});

Nothing paints until the handler returns, so the click feels dead for 300 ms. Answer first, yield, then work. Safari has no scheduler.yield() yet; fall back to setTimeout.

Spot it Performance panel: Interactions track, long processing duration

function App() {  const [query, setQuery] = useState("");  return <><Search value={query} onChange={setQuery} /><Feed /></>;}

function App() {  return <><Search /><Feed /></>; // query state lives in Search}

State at the top re-renders everything below it on each keystroke, though only the search box changed. Keep state beside what reads it; memoise the expensive parts that truly share it.

Spot it React DevTools Profiler: the whole tree renders on each keystroke

input.oninput = () => render(search(index, input.value)); // 200 ms

input.oninput = () => worker.postMessage(input.value);worker.onmessage = (e) => render(e.data);

Each keystroke waits 200 ms for the search. Work that doesn’t touch the DOM belongs in a Web Worker; send it the query, not the whole index.

Spot it Performance panel: long tasks on every keystroke

list.append(...rows) // 10 000 rows, all rendered

.row { content-visibility: auto; contain-intrinsic-size: auto 3rem; }

10 000 rows cost style, layout and memory, on screen or not. content-visibility: auto skips rendering the off-screen ones and keeps them findable; the nodes still exist, so for very long lists, virtualise.

Spot it Performance panel: long Recalculate Style and Layout after the list renders

showAll.onclick = () => list.replaceChildren(...rows.map(toRow)); // 5 000 rows

showAll.onclick = () => list.replaceChildren(...rows.slice(0, 50).map(toRow)); // more on scroll

The handler is quick; styling, laying out and painting 5 000 new rows is not, and the next frame waits for all of it. Render what fits on screen and add the rest as the reader scrolls.

Spot it Performance panel → Interactions: a long presentation delay after a short handler