Web Performance Glossary

A Core Web Vital that measures visual stability by quantifying how much page content shifts unexpectedly during its lifetime. CLS scores the sum of all individual layout shift scores that occur without user interaction. Common causes include images without dimensions, dynamically injected content, web fonts causing text reflow, and late-loading ads. CLS is measured on a scale from 0 (no shifts) upward.

A set of three metrics defined by Google that measure real-world user experience: Largest Contentful Paint (LCP) for loading speed, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. Core Web Vitals are a confirmed Google ranking signal and are measured using real user data from the Chrome User Experience Report (CrUX). As of April 2026, approximately 55.7% of origins pass all three CWV thresholds.

A Core Web Vital that measures responsiveness by tracking the latency of all user interactions (clicks, taps, key presses) throughout the page lifecycle, then reporting the worst interaction (with outliers excluded). INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Unlike FID, INP captures every interaction, not just the first one. The INP value includes input delay, processing time, and presentation delay.

A Core Web Vital that measures loading performance by reporting the render time of the largest image or text block visible within the viewport. LCP elements are typically hero images, background images, or large headings. The metric is recorded when the largest content element finishes rendering, relative to when the page first started loading. LCP is considered the most impactful Core Web Vital for user perception of speed.

The portion of a long task that exceeds 50 milliseconds. If a task takes 200ms, its blocking time is 150ms. Total Blocking Time (TBT) sums all blocking time between First Contentful Paint and Time to Interactive. Blocking time directly correlates with poor INP because the browser cannot process user input while the main thread is blocked.

The time from when the page starts loading to when any part of the page's content is rendered on screen. Content includes text, images (including background images), <svg> elements, and non-white <canvas> elements. FCP marks the first moment the user sees something, while LCP marks when the main content becomes visible. FCP is reported in Lighthouse and CrUX but is not a Core Web Vital.

A deprecated metric that measured the time from a user's first interaction (click, tap, key press) to when the browser begins processing the event handler. FID was replaced by INP as a Core Web Vital in March 2024 because FID only measured the first interaction while INP captures all interactions throughout the page lifecycle. FID is no longer reported in CrUX or used as a ranking signal.

A Lighthouse metric that measures how quickly the contents of a page are visually populated. Speed Index captures the visual progression of rendering as a single number: lower is better. It analyzes video frames of the page loading and calculates an average time at which visible parts of the page are displayed. Speed Index is a lab-only metric, not measured in the field. It is weighted in the Lighthouse performance score but is not a Core Web Vital.

A lab metric that sums all blocking time between First Contentful Paint and Time to Interactive. TBT is the strongest lab-based predictor of real-world INP. If a page has many long tasks during loading, TBT will be high, indicating the main thread is frequently blocked. TBT is weighted heavily in the Lighthouse performance score. Reducing TBT typically requires code splitting, deferring non-critical JavaScript, and breaking up long tasks.

A lab metric that measures the time from page load start until the page is reliably interactive -- defined as the point after which the main thread is free from long tasks for at least 5 seconds. TTI has been de-emphasized in recent Lighthouse versions in favor of TBT and INP. It is no longer a primary optimization target but remains useful for understanding when a page becomes fully usable.

The time between the browser requesting a page and receiving the first byte of the response from the server. TTFB encompasses DNS resolution, TCP connection, TLS negotiation, HTTP request, and server processing time. While TTFB is not technically a Core Web Vital, it directly impacts LCP because the browser cannot render anything until it receives the HTML. Optimizing TTFB involves CDN deployment, server-side caching, database optimization, and efficient rendering strategies.

A build optimization that divides JavaScript bundles into smaller chunks loaded on demand. Instead of downloading the entire application at once, only the code needed for the current page loads initially. Code splitting reduces initial bundle size, improving LCP (less parsing) and INP (less main thread blocking). All modern bundlers (Webpack, Vite, esbuild) support code splitting via dynamic import().

The minimal set of CSS rules required to render above-the-fold content. Inlining critical CSS directly in the HTML <head> eliminates the render-blocking network request for an external stylesheet, improving both TTFB-to-FCP and LCP. Non-critical CSS is then loaded asynchronously. Tools like Critical, Critters, and PurgeCSS help extract and inline critical CSS automatically.

An HTML attribute that hints to the browser the relative priority of a resource fetch. Setting fetchpriority="high" on an LCP image tells the browser to download it before other images. Setting fetchpriority="low" on below-fold images reduces their priority. Supported in Chrome 101+, Edge 101+, and Safari 17.2+. This is one of the simplest and most effective LCP optimizations available.

A CSS descriptor in @font-face rules that controls how fonts are displayed while loading. font-display: swap shows fallback text immediately and swaps to the custom font when ready (prevents invisible text but can cause CLS). font-display: optional uses the custom font only if it loads within ~100ms (prevents CLS but may show fallback permanently on slow connections). Choosing the right strategy involves trading off CLS against visual consistency.

A technique that defers loading off-screen images until the user scrolls near them. Native lazy loading uses the loading="lazy" HTML attribute. Lazy loading reduces initial page weight and network contention, improving LCP for above-fold content. However, applying lazy loading to the LCP image itself is a common mistake that worsens LCP because the browser waits to start the download until the image enters the viewport.

A rendering strategy that combines the performance of static generation with the freshness of server-side rendering. ISR serves static pages from CDN cache and regenerates them in the background on a configurable schedule (e.g., every 60 seconds). First introduced by Next.js, ISR is now supported by Nuxt 3 and other frameworks. ISR achieves near-zero TTFB while keeping content reasonably fresh.

A strategy that defers loading non-critical resources until they are needed. Applies to images (loading="lazy"), JavaScript (dynamic import()), iframes, and components (React.lazy, Vue defineAsyncComponent). Lazy loading reduces initial page weight and main thread work, improving LCP and INP. However, over-aggressive lazy loading can hurt performance if critical resources are deferred unnecessarily.

A resource hint (<link rel="preconnect">) that tells the browser to establish an early connection to a third-party origin. Preconnect handles DNS resolution, TCP handshake, and TLS negotiation before the resource is actually needed, saving 100-500ms per connection. Use preconnect for origins you know will be needed (font providers, CDNs, API servers). Limit to 2-4 origins to avoid connection contention.

A resource hint (<link rel="prefetch">) that tells the browser to download a resource at low priority during idle time, anticipating it will be needed for a future navigation. Unlike preload (which is for the current page), prefetch is for upcoming pages. Prefetching the next likely page's HTML, CSS, or data can make subsequent navigations feel instant. Use sparingly to avoid wasting bandwidth.

A resource hint (<link rel="preload">) that tells the browser to start downloading a resource immediately with high priority. Preloading is essential for resources the browser discovers late (e.g., fonts referenced in CSS, LCP images specified in CSS background). The browser normally discovers these resources only after parsing the CSS file. A preload hint makes the download start during HTML parsing, shaving 200-500ms off LCP.

HTML link elements that give the browser advance notice about resources it will need. The four resource hints are: dns-prefetch (resolve DNS only), preconnect (DNS + TCP + TLS), prefetch (download at low priority for future navigation), and preload (download immediately at high priority for current page). Proper use of resource hints can improve LCP by 200-500ms by eliminating network waterfalls.

An approach that serves different image sizes based on the user's screen size and resolution. Implemented via the srcset and sizes attributes or the <picture> element. Responsive images prevent mobile devices from downloading desktop-sized images, reducing bandwidth and improving LCP. Modern frameworks (Next.js Image, NuxtImage, Astro Image) generate responsive images automatically at build time.

A rendering strategy where the server generates the complete HTML for a page on each request, sending a fully rendered document to the browser. SSR improves FCP and LCP compared to client-side rendering because the browser receives ready-to-display HTML instead of an empty shell. The tradeoff is increased server load and potentially higher TTFB. Streaming SSR (used in React 18+ and Remix) mitigates this by sending HTML incrementally.

A rendering strategy where all HTML pages are generated at build time, producing static files that can be served directly from a CDN with no server-side processing at request time. SSG provides the fastest possible TTFB and LCP because pages are pre-built and cached at edge locations. SSG is ideal for content that does not change frequently (documentation, blogs, marketing pages). Frameworks supporting SSG include Astro, Next.js, Nuxt, SvelteKit, and Eleventy.

An optimization of server-side rendering where the server sends HTML to the browser incrementally as it becomes available, rather than waiting for the entire page to render. The browser starts parsing and rendering the initial HTML immediately while the server continues generating the rest. Streaming SSR significantly reduces TTFB and FCP. React 18 introduced streaming with renderToPipeableStream, and Remix and Next.js use it by default.

A dead code elimination technique used by JavaScript bundlers (Webpack, Rollup, esbuild) to remove unused exports from the final bundle. Tree shaking analyzes ES module import/export statements to determine which code is actually used, then excludes the rest. Effective tree shaking requires using ES modules (not CommonJS), avoiding side effects in modules, and marking packages as side-effect-free in package.json.

The portion of a web page visible without scrolling. Content above the fold loads first and has the greatest impact on user perception of speed. LCP elements are almost always above the fold. Optimizing above-the-fold content -- inlining critical CSS, preloading hero images, and deferring below-fold JavaScript -- is the single most impactful performance strategy.

The sequence of steps the browser takes to convert HTML, CSS, and JavaScript into rendered pixels on screen. The critical rendering path includes: HTML parsing, DOM construction, CSSOM construction, render tree creation, layout, and paint. Optimizing the CRP means reducing the number and size of critical resources, minimizing round trips, and deferring non-essential work.

A tree-structured representation of an HTML document that browsers construct during parsing. JavaScript interacts with the page through the DOM API. Large DOM trees (10,000+ nodes) slow down layout calculations, style recalculation, and garbage collection, negatively impacting all Core Web Vitals. DOM size is a key factor in INP because style and layout computations scale with DOM complexity.

The process of attaching JavaScript event handlers and state to server-rendered HTML in the browser. During hydration, the framework (React, Vue, Svelte) re-executes component logic to make the static HTML interactive. Hydration can be expensive, blocking the main thread and delaying INP. Strategies to mitigate hydration cost include partial hydration (Astro islands), progressive hydration, and React Server Components.

An unexpected movement of visible page elements after they have already been rendered. Layout shifts are measured as the impact fraction (proportion of viewport affected) multiplied by the distance fraction (how far elements moved). Only shifts that occur without a recent user interaction (within 500ms) count toward CLS. Common causes: images without width/height, dynamically injected content, and web font loading.

Any JavaScript task that runs for more than 50 milliseconds on the main thread. Long tasks block the browser from processing user input, rendering updates, and running animations. They are the primary cause of poor INP scores. The Performance panel in Chrome DevTools flags long tasks with red corners. Breaking long tasks into smaller chunks using scheduler.yield() or setTimeout() improves responsiveness.

The single thread where the browser executes JavaScript, handles DOM updates, processes user events, performs style calculations, and runs layout. Because the main thread handles all these tasks sequentially, expensive JavaScript can block everything else. Keeping the main thread free is essential for good INP. Offload heavy computation to Web Workers, use requestIdleCallback, and break up long tasks to keep the main thread responsive.

CSS and synchronous JavaScript files that prevent the browser from rendering any content until they finish downloading and processing. All CSS is render-blocking by default because the browser needs the CSSOM before it can paint. Synchronous JavaScript in the <head> is also render-blocking. Mitigations include inlining critical CSS, deferring non-critical CSS with media queries, and adding defer or async to scripts.

A browser API that allows running JavaScript in a background thread separate from the main thread. Web Workers cannot access the DOM but can perform CPU-intensive computations (data processing, image manipulation, complex calculations) without blocking user interactions. Offloading heavy work to Web Workers is an effective strategy for improving INP by keeping the main thread free to process user events.

A public dataset of real-user performance metrics collected from Chrome users who have opted in to usage reporting. CrUX data powers the Core Web Vitals assessment in Google Search Console and PageSpeed Insights. Data is aggregated over a rolling 28-day window at both origin and URL level. CrUX is the authoritative source for field data that Google uses in its page experience ranking signal.

An open-source project that periodically crawls millions of web pages and records detailed information about resource loading, page composition, and performance metrics. The HTTP Archive Web Almanac publishes annual reports on web technology trends. Researchers use HTTP Archive data via BigQuery to analyze web performance at scale. It is the largest public dataset for understanding real-world web performance patterns.

An open-source automated tool by Google for auditing web page quality. Lighthouse measures performance, accessibility, SEO, and best practices, generating a score from 0 to 100. The performance score is based on lab metrics including FCP, LCP, TBT, CLS, and Speed Index. Lighthouse runs in Chrome DevTools, as a CLI, or via PageSpeed Insights. Lab scores may differ from field data (CrUX) because they measure in a controlled environment.

A Google tool that analyzes web page performance using both field data (from CrUX) and lab data (from Lighthouse). PSI provides Core Web Vitals assessment at origin and URL level, plus actionable optimization suggestions. The field data section shows real-user metrics over a 28-day period, while the lab section shows a Lighthouse audit. PSI is the recommended starting point for diagnosing Core Web Vitals issues.

A tiny JavaScript library (~2KB) by Google for measuring Core Web Vitals in the field. The library provides functions to capture LCP, CLS, INP, FCP, and TTFB from real users. It uses the same measurement methodology as CrUX, making it the recommended way to collect field performance data. Usage: import { onLCP, onCLS, onINP } from 'web-vitals'; then send the metrics to your analytics endpoint.

An open-source web performance testing tool that provides detailed waterfall charts, filmstrip views, and Core Web Vitals measurements from real browsers in configurable locations and network conditions. WebPageTest offers features not available in Lighthouse, including multi-step testing, scripted interactions, video capture, and detailed TCP-level analysis. It is the go-to tool for deep performance debugging.

A geographically distributed network of servers that caches and delivers web content from locations close to users. CDNs reduce TTFB by minimizing the physical distance between the user and the server. Major CDN providers include Cloudflare, Fastly, Akamai, and AWS CloudFront. Edge computing platforms like Vercel and Netlify deploy to CDN edges by default.

Running server-side code at CDN edge locations geographically close to users rather than in a centralized data center. Edge functions (Vercel Edge Functions, Cloudflare Workers, Deno Deploy) execute with minimal latency, dramatically reducing TTFB. Edge computing enables personalized content delivery without the round-trip penalty to a distant origin server.

A modern image format based on the AV1 video codec. AVIF typically achieves 50% smaller file sizes than JPEG and 20% smaller than WebP at equivalent quality. Supported in Chrome, Firefox, and Safari 16+. AVIF is the recommended format for LCP images when browser support allows, with WebP as a fallback via the <picture> element.

A modern image format developed by Google that provides both lossy and lossless compression. WebP images are typically 25-35% smaller than equivalent JPEG images. WebP supports transparency (like PNG) and animation (like GIF). It has near-universal browser support (98%+ as of 2026). WebP is the recommended minimum format for web images, with AVIF as the preferred format where supported.