Web Performance

Busted

• 75th percentile (p75)The value that 75 out of 100 visits come in under. Google grades speed with it because averages quietly hide your slowest quarter.
• Asset fingerprinting (content hashing)A content hash in each asset filename makes changed files get new URLs, while unchanged files stay safely cached.
• Async vs deferBoth download scripts without blocking HTML; defer preserves order after parsing, while async runs each file whenever it arrives.
• Back/forward cache (bfcache)The browser keeps a whole page ready in memory, so Back and Forward can restore it instantly with its state and scroll position intact.
• Bundle analyzerA treemap of the packages and modules inside each bundle, with the biggest byte hogs drawn as the biggest boxes.
• Bundle sizeHow many kilobytes of JavaScript and CSS a page actually ships, and therefore how long a phone spends parsing it.
• Caching headers (Cache-Control / max-age)Response headers that tell browsers and CDNs how long they may reuse a file instead of asking your server for it again.
• Compression (Gzip / Brotli)Squeezing text files smaller for the trip over the network, so a 300KB bundle travels as 80KB and unpacks in the browser.
• Content-visibility / CSS containmentCSS can skip laying out and painting offscreen sections, then render them as they approach the viewport instead of doing the whole page upfront.
• Core Web VitalsGoogle's three-metric report card for how a page feels to real users: load speed, tap responsiveness, and visual stability.
• Critical CSSInlining just the styles the first screen needs, then loading the rest of the stylesheet later so nothing blocks the first paint.
• Critical rendering pathThe exact chain of work a browser must finish (HTML, CSS, layout, paint) before anything at all appears on screen.
• Critical request chainA download waiting on another download that was waiting on another, turning the route to the first useful screen into a slow staircase.
• Cumulative Layout Shift (CLS)A score for how much content jumps around across the whole visit, not just the load. Under 0.1 passes; if you notice it, it is too high.
• First Contentful Paint (FCP)The moment the browser paints the first bit of real content and the blank white screen ends. Under 1.8 seconds passes.
• Font loading strategy (font-display: swap, FOUT/FOIT)The rule for what a browser shows while your custom font downloads: blank text, fallback text that swaps in later, or neither.
• Idle callbacks (requestIdleCallback)A browser callback for optional work that can wait until the main thread has a quiet moment, without competing with the current screen.
• Image optimization (WebP/AVIF, responsive srcset)Shipping each visitor the smallest image that still looks right: modern format, sized for their screen, not one giant JPEG for everyone.
• INP phasesThe three places a tap can lose time: waiting for the main thread, running its handlers, and getting the next frame onto the screen.
• Interaction to Next Paint (INP)A near-worst delay between tapping something and the screen visibly changing. Under 200ms feels instant, past 500ms feels broken.
• JavaScript execution costThe on-device CPU time needed to parse, compile, and run JavaScript, which can hurt even after a small compressed bundle downloads.
• Lab data vs field data (synthetic vs RUM)The gap between a speed test you ran on a simulated device and the numbers your actual visitors produce. Lab is repeatable, field is true.
• Largest Contentful Paint (LCP)How long until the biggest thing on the first screen (usually the hero image or headline) actually renders. Under 2.5s passes.
• Layout shift reservation (aspect-ratio, width/height)Telling the browser how big something will be before it loads, so text stops jumping around when images, ads, and embeds arrive.
• Layout thrashing (forced reflow)Reading a layout value right after changing one, in a loop, forcing the browser to recompute the page's geometry every single time.
• Layout, paint, and compositeLayout places boxes, paint draws them, and composite stacks the finished layers. The earlier in that chain a change lands, the more work a frame costs.
• Lazy loadingNot fetching something until it is about to be needed: images below the fold, or a chart component nobody has clicked yet.
• LCP image prioritization (fetchpriority)Telling the browser the hero image is the one that matters so it fetches it first instead of queueing it behind everything else.
• LCP phasesThe four clocks inside LCP: server response, waiting to start the key resource, downloading it, and waiting for it to render.
• Long taskAny uninterrupted stretch of main-thread work over 50ms, script plus the layout it drags along, long enough for a tap to feel ignored.
• Lossy vs lossless image compressionLossy images trade some detail for far fewer bytes; lossless images keep every decoded pixel but usually cost more to download.
• Main thread blockingJavaScript hogging the single thread that also handles clicks and painting, so the page ignores you until it finishes.
• Memory leak / detached DOM nodesMemory the page has finished with but still holds onto, often through removed DOM nodes, making a long-lived tab steadily heavier.
• MinificationA production build strips comments, spacing, and long local names so the same JavaScript or CSS ships in fewer bytes.
• Network and CPU throttlingMaking a fast test machine behave more like a slow phone or connection, so performance problems appear under repeatable conditions.
• Page weightThe total data a page downloads across HTML, scripts, styles, images, fonts, and third parties.
• Perceived performanceHow fast an interface feels, shaped by immediate feedback, visible progress, and whether useful content arrives before the wait ends.
• Performance budgetA hard number your pages are not allowed to cross, checked automatically in CI so a slow pull request fails instead of shipping.
• Performance profilingRecording the browser's work so a vague slowdown becomes a specific script, long task, layout, paint, or network request.
• PerformanceObserverA browser listener that receives paint, resource, layout-shift, interaction, and long-task measurements as performance entries appear.
• Real User Monitoring (RUM)Speed data collected from real visitors' browsers while they use your site, instead of from a test you ran on your own machine.
• Render-blocking resourceA CSS or JS file the browser must fully download and parse before it will paint anything, so one slow file blanks the page.
• Resource hints (preload, prefetch, preconnect)Tags that tell the browser to fetch a file, or warm up a connection, before it would have discovered the need on its own.
• Resource Timing APIThe browser's per-file stopwatch for images, scripts, styles, fonts, and fetches, including connection, response, download, and size data.
• Speed IndexHow quickly the first screen visibly fills in, not just when its final large element finishes loading.
• Third-party script taxThe speed you quietly pay to scripts you did not write: analytics, chat, ads, A/B tools, all running on your main thread.
• Time to First Byte (TTFB)How long from the click until the very first byte of HTML comes back. Everything else has to wait for it. Aim under 800ms.
• Time to Interactive (TTI)The old lab timestamp for when a page was not just visible, but quiet enough to keep answering input without long stalls.
• Total Blocking Time (TBT)A lab score summing every millisecond past 50ms that the page spent too busy to answer a click while loading.
• Tree shakingYour bundler deletes the exports nothing imports, so a huge library ships as only the handful of functions you actually call.
• Unused JavaScript / CSSJavaScript or CSS the browser downloads for a page but never executes or applies during the visit.
• Virtualized list (windowing)A huge list that keeps only the visible rows in the DOM, swapping rows as you scroll so thousands of items do not freeze the page.
• Waterfall chartThe staircase of bars in DevTools, one row per request, showing when each file started, waited on the server, and finished.
• Web Worker / offloading the main threadA separate browser thread for heavy JavaScript, keeping the main thread free to paint, scroll, and answer taps.

The territory

30 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• Core Web VitalsGoogle's three user-experience speed metrics that affect ranking"the Google speed score" · "the metrics Google grades you on"
• Largest Contentful Paint (LCP)Time until the biggest above-the-fold element renders"how long until the big image shows" · "when the hero finally appears"
• Interaction to Next Paint (INP)Worst-case delay between a tap and visible response"the page feels laggy when I click" · "buttons don't respond right away"
• Cumulative Layout Shift (CLS)Score for content jumping around as the page loads"stuff moves and I tap the wrong thing" · "the page jumps while loading"
• Time to First Byte (TTFB)Delay before the server sends the first byte of HTML"the browser sits there blank" · "the server is slow to answer"
• First Contentful Paint (FCP)When any first pixel of content appears"when something finally shows up" · "the first thing you see"
• Critical rendering pathThe minimum work a browser must do to paint"what's blocking the first screen" · "the stuff needed before anything shows"
• Render-blocking resourceCSS/JS that stops painting until it loads and parses"something up top is holding the page hostage" · "the stylesheet stalls everything"
• Main thread blockingJS monopolizing the single thread that handles UI"the page can't do anything while it thinks" · "everything is stuck on one lane"
• Long taskAny main-thread block over 50ms that freezes interaction"something hogs the browser" · "the page locks up for a second"
• Total Blocking Time (TBT)Lab proxy for interaction delay, sums long tasks"how long the page is frozen in a test" · "total time it can't respond"
• Bundle sizeTotal bytes of JS/CSS shipped to the browser"my JavaScript is too fat" · "how much code am I sending"
• Code splittingBreaking one big JS bundle into on-demand chunks"chop up the big JavaScript file" · "only ship the code this page needs"
• Tree shakingBuild step that drops unused exports from the bundle"strip out code I never call" · "remove the dead library parts"
• Lazy loadingDeferring offscreen images or components until they're needed"only load pictures when you scroll to them" · "load later, not now"
• Image optimization (WebP/AVIF, responsive srcset)Serving right-sized, modern-format images per device"my photos are way too heavy" · "send smaller pictures to phones"
• LCP image prioritization (fetchpriority)Telling the browser which image matters most"tell the browser this image comes first" · "make the hero image load first"
• Layout shift reservation (aspect-ratio, width/height)Reserving space so media doesn't shove content"set width and height so nothing jumps" · "hold the space for the image"
• Critical CSSInlining only the styles needed for the first screen"above the fold styles" · "inline the top-of-page CSS"
• Font loading strategy (font-display: swap, FOUT/FOIT)Controlling whether text hides or flashes while fonts load"text is invisible for a second" · "the font pops in and reflows"
• Resource hints (preload, prefetch, preconnect)Hints telling the browser to fetch things early"tell the browser to grab it sooner" · "warm up the connection"
• Caching headers (Cache-Control / max-age)Rules telling browsers/CDNs how long to reuse a file"make it not re-download every visit" · "tell the browser to remember it"
• Compression (Gzip / Brotli)Shrinking text assets in transit over the wire"zip the files before sending" · "make the download smaller"
• Third-party script taxAnalytics/chat/ads tags dragging down your page"the tracking tags are slowing us down" · "other people's scripts wreck my speed"
• Waterfall chartTimeline diagram showing when each request starts and ends"that staircase graph of requests" · "the network timeline"
• Lab data vs field data (synthetic vs RUM)Simulated lab tests versus metrics from real visitors"it's fast on my machine but not for users" · "real-user numbers"
• Real User Monitoring (RUM)Collecting performance timings from actual visitors' browsers"measure real people, not a test" · "speed data from live traffic"
• 75th percentile (p75)The threshold value 75% of visits fall under"not the average, the slower users" · "how bad is it for most people"
• Performance budgetA hard byte/timing ceiling enforced in CI"fail the build if it gets slower" · "a size limit we can't cross"
• Layout thrashing (forced reflow)Read/write DOM loops forcing repeated recalculation"the page recalculates over and over" · "measuring and changing in a loop"

Deeper in the field

• Speed Index How quickly visible content fills in over time
• Perceived performance How fast it feels regardless of measured time
• Page weight Total transferred bytes required to load a page
• Minification Removing unnecessary source characters to reduce transferred asset bytes
• Async vs defer Script modes that avoid blocking HTML parsing while JavaScript downloads
• Unused JavaScript / CSS Shipped code that never contributes to the current page
• JavaScript execution cost Time spent parsing, compiling, and running JavaScript on-device
• Bundle analyzer Visual treemap showing what's bloating your bundle
• Asset fingerprinting (content hashing) Hashed filenames so updated assets aren't served stale
• Back/forward cache (bfcache) Restores complete pages instantly during back and forward navigation
• Critical request chain Serial dependencies where one fetch triggers the next
• Lossy vs lossless image compression Trading visual fidelity for smaller file size
• Content-visibility / CSS containment Skipping layout work for offscreen sections
• Layout, paint, and composite Three levels of browser rendering cost
• Virtualized list (windowing) Rendering only visible rows in a huge list
• Web Worker / offloading the main thread Running heavy JS on a background thread
• Idle callbacks (requestIdleCallback) Running non-urgent JS when the browser is free
• Memory leak / detached DOM nodes Growing memory that slows a long-lived page
• LCP phases TTFB, resource delay, download time, and render delay composing LCP
• INP phases Input delay, processing time, and presentation delay behind an interaction
• Time to Interactive (TTI) When the page reliably responds to input
• Performance profiling Recording browser work to locate CPU, rendering, and scripting bottlenecks
• Network and CPU throttling Simulating slower devices and connections for repeatable lab tests
• Resource Timing API Browser timings for individual images, scripts, stylesheets, and fetches
• PerformanceObserver Browser API for collecting paint, layout-shift, and interaction entries