This web performance glossary explains the terms you’ll see in Lighthouse reports, PageSpeed Insights and Search Console, in plain language, with a line on what usually fixes each problem on an Astro site. It’s written for people who build and run websites, not browser engineers. Terms are grouped into metrics, loading, caching and delivery, and measurement.
Key Takeaways
- Core Web Vitals are three field metrics: LCP (loading), INP (responsiveness) and CLS (visual stability).
- Lab data (Lighthouse) is for debugging; field data (real users) is what Google evaluates.
- Most fixes on content sites are images, fonts, third-party scripts and caching.
- Astro’s static, zero-JS default helps every metric, but doesn’t fix oversized images or heavy tags.
Metrics
Core Web Vitals. Google’s three user-experience metrics: LCP, INP and CLS. Measured from real Chrome users. See Google’s Web Vitals overview.
LCP (Largest Contentful Paint). Time until the largest image or text block in the viewport appears. Good: 2.5 s or less. Usual fix: optimise and prioritise the hero image; see the Astro performance guide.
INP (Interaction to Next Paint). How long the page takes to respond visibly to clicks, taps and key presses. Good: 200 ms or less. Usual fix: less JavaScript on the main thread, especially third-party scripts and eagerly hydrated islands.
CLS (Cumulative Layout Shift). How much content jumps around while loading. Good: 0.1 or less. Usual fix: width and height on images, reserved space for embeds, fonts with matched fallbacks.
TTFB (Time to First Byte). Time from request to the first byte of the response. Static pages on a CDN are fast; on-demand pages depend on server work and caching.
FCP (First Contentful Paint). When the first text or image appears. Affected by render-blocking CSS and fonts.
TBT (Total Blocking Time). A lab metric: how long the main thread was blocked by long tasks during load. A lab proxy for INP problems.
Speed Index. A lab metric for how quickly the visible page fills in.
Loading
Render-blocking resource. CSS or synchronous scripts in <head> that must load before the page can paint. Astro inlines small stylesheets and defers its scripts by default.
Critical rendering path. The sequence of downloads and work needed before the first paint.
Preload. A <link rel="preload"> hint telling the browser to fetch a resource early, such as the LCP image or a font. Astro’s Fonts API can add these.
Prefetch. Fetching a likely next page before navigation. See prefetch links in Astro.
Lazy loading. Deferring offscreen images (loading="lazy") or components (client:visible) until needed. Never lazy-load the LCP image.
Fetch priority. fetchpriority="high" raises a resource’s priority; Astro sets it on images with priority.
Code splitting. Breaking JavaScript into chunks loaded only where needed. Astro does this per island automatically.
Hydration. Running JavaScript to make server-rendered HTML interactive. More hydration means more main-thread work.
Third-party script. Code from another domain: analytics, chat, ads, A/B testing. Often the largest INP cost. See privacy-friendly analytics.
Web font. A downloaded font file. Costs a request and can cause invisible text or layout shift until loaded.
FOUT / FOIT. Flash of unstyled text / invisible text: what users see while a web font loads.
Responsive images. Serving different image sizes to different screens with srcset and sizes. See responsive images in Astro.
WebP / AVIF. Modern image formats, usually smaller than JPEG at similar quality.
Caching and delivery
CDN (content delivery network). Servers around the world that hold copies of your files close to visitors. Static hosts like Cloudflare Pages, Netlify and Vercel include one.
Cache-Control. The HTTP header that says how long browsers and CDNs may reuse a response.
Immutable assets. Files with a content hash in the name (Astro’s /_astro/ files) that can be cached for a year because a change produces a new name.
stale-while-revalidate. A caching rule that serves a slightly old copy while fetching a fresh one in the background. Useful for on-demand pages.
Edge. Running code or caching at CDN locations rather than one origin server.
Compression. Gzip or Brotli applied to text responses by the host. Usually automatic.
HTTP/2, HTTP/3. Newer protocol versions that load many small files efficiently. Hosts enable them by default.
Measurement
Lab data. Measurements from a controlled test, such as Lighthouse. Repeatable and good for debugging, but not real users.
Field data (RUM). Measurements from real visitors. The Chrome UX Report (CrUX) is Google’s public field dataset.
Lighthouse. Chrome’s automated audit tool for performance, accessibility, SEO and best practices.
PageSpeed Insights. Google’s web tool showing Lighthouse lab data and CrUX field data for a URL.
Performance budget. A limit you set, such as total JavaScript under 100 KB, and check in CI. See finding what’s bloating your Astro bundle.
75th percentile. Core Web Vitals are judged at the 75th percentile of page loads, so most visitors must have a good experience, not just the average.
For Astro terms, see the Astro glossary. For a checklist of fixes in order, see the Astro performance guide.
FAQ
Which Core Web Vital matters most?
All three count. On content sites, LCP is the most common problem, usually because of a large hero image.
Why does my Lighthouse score change between runs?
Lab tests vary with network and CPU conditions. Compare the median of several runs, and rely on field data for trends.