Frontend performance techniques you can drive yourself. The numbers are measured live, not screenshots — change the inputs and they change. More will be added over time.
useMemoThe same calculation (counting primes in a range), with a switch for whether it goes through the useMemo cache, timing the same re-render either way.
Press “force a re-render” — that state has nothing to do with the calculation, yet the right panel recomputes anyway. That is the problem useMemo solves.
Read the write-up →—msthis re-render
React.lazyThe chart component is not in the main bundle — Vite splits it into its own chunk. It is fetched only when you press the button, so the homepage never carries its weight.
Open the Network tab and press it again: a new js file is requested at exactly that moment.
Read the write-up →SuspenseWhen the data is not ready the component throws a promise. React catches it, shows the skeleton, and retries the render once the promise settles. That is the Suspense contract.
Drag the latency and replay — the skeleton stays up for exactly that long. This page itself is prerendered too: its first-paint HTML is generated at build time.
Read the write-up →no request started
虛擬捲動Both sides hold the same 10,000 rows in memory. The left renders every one into the DOM; the right renders only the ~20 in view and offsets them into place.
This is the inverse of demo 02: that one fetches less data, this one paints less DOM.
Read the write-up →A 500x difference in node count, which shows up directly in scroll smoothness and memory use.
Web WorkerThe same prime calculation, once on the main thread and once in a Web Worker. Identical work, identical result — only the thread differs.
Watch the spinner. On the main thread it freezes solid; in the worker it never stops. That freeze is what users experience as a hang.
Read the write-up →Map vs findMapping every order to a user name. One calls find inside the map; the other builds a Map index once and looks up from it. Results are identical and verified against each other.
Calling find inside map is the most common performance trap in list rendering — one innocent line that costs n x m comparisons. Double the data and the find side gets four times slower while the Map side only doubles.
Read the write-up →orders.map(o =>
users.find(
u => u.id === o.userId
)
)users is an array, so it scans from the start until it hits a match — once per order.const index = new Map( users.map(u => [u.id, u]) ) orders.map(o => index.get(o.userId) )Build an id-to-user table once, then fetch by id directly. Like a phone book sorted by surname: you turn straight to the page.
illustration: this order needs user-9
React.memoA task list where each press updates the duration of exactly one row. The number on the right is how many times that row has rendered, counted for real in an effect.
With both switches on, only the changed row flashes and its counter climbs — the other eleven stay at 1. Turn either switch off and every row re-renders, even though one field changed.
Read the write-up →debounce / throttleEvery keystroke counts as one request that would be sent. Three strategies handle the same typing — see how many each actually sends.
Type a burst quickly, then stop. Raw matches your keystrokes; debounce fires once after you pause; throttle fires at a steady rate while you type.
Read the write-up →強制同步版面Both modes do the same work: change every box’s margin and read the layout. Only the order differs — read right after each write, or write everything then read once.
Run transform first, then switch to left/top and watch the FPS drop. transform only touches compositing; left forces layout and paint for every element, every frame.
Read the write-up →Switching to interleaved will visibly freeze the page — that is the point of this demo, not a bug. Stop still works, it just responds a beat late. Stop first if you want to switch modes smoothly.
AVIF / srcsetThese are the actual assets used on /surf, not a made-up example. The same photo as AVIF and WebP at two widths, with bytes measured live.
AVIF typically lands 30-40% under WebP, and a phone only needs the 768 variant — serving it 1920 wastes several times the bandwidth.
Read the write-up →
Click a label to preview. In practice you never pick manually — correct sizes and srcset let the browser choose.