Web Performance

Web performance is how quickly a page loads, becomes usable, and responds to interaction. It directly affects business outcomes — faster sites convert better, retain users longer, and rank better in search, because Google uses Core Web Vitals as a ranking signal. It's also an accessibility and equity issue: many users browse on mid-range phones over slow or expensive connections.

Most slow sites are slow for the same reasons: too much JavaScript, oversized images, render-blocking resources, poor caching, layout shifts from late-loading content, and heavy main-thread work. The fixes are well understood; the discipline is in measuring real users, setting budgets, and preventing regressions.

TL;DR

Quick Example

A page head that prioritizes what matters for first render:

Lazy-loading a heavy, rarely used feature and yielding to the main thread during long work:

Core Concepts

Core Web Vitals

Supporting metrics: Time to First Byte (TTFB), First Contentful Paint (FCP), and Total Blocking Time (TBT, a lab proxy for INP).

The Critical Rendering Path

The browser must download HTML, discover and fetch CSS (render-blocking), build the DOM and CSSOM, run blocking scripts, lay out, and paint. Shortening this path — fewer blocking resources, earlier discovery of critical assets, smaller payloads — speeds up first render.

JavaScript Cost

JavaScript is the most expensive resource byte for byte: it must be downloaded, parsed, compiled, and executed on the main thread, often on slow mobile CPUs. Reduce it with code splitting, tree shaking, removing heavy libraries, server rendering or React Server Components, and islands architectures like Astro.

Images and Fonts

Images are usually the largest bytes on a page. Use AVIF or WebP, serve responsive sizes, compress, set width/height to prevent CLS, and lazy-load below-the-fold images. For fonts, self-host WOFF2, subset, preload the critical file, and use font-display: swap or optional with size-adjusted fallbacks.

Caching and Delivery

Rendering Strategies

Static generation and server rendering improve LCP by delivering content in the initial HTML; client-side rendering delays content until JavaScript runs. Streaming SSR sends early parts of the page immediately. Choose per page based on how dynamic it is.

Measuring: Lab vs Field

Field data is the source of truth; lab data explains why.

Best Practices

Set Performance Budgets

Limit JavaScript per route (e.g. 170 KB compressed), image weight, and LCP targets, and fail CI when budgets are exceeded (Lighthouse CI, bundler size limits).

Make the LCP Element Discoverable Early

Put the hero image in the HTML (not injected by JavaScript), preload it, set fetchpriority="high", and never lazy-load it.

Break Up Long Tasks

Split work into chunks, yield to the main thread, move heavy computation to Web Workers, and keep event handlers minimal to improve INP.

Reserve Space for Everything

Set dimensions or aspect-ratio on images, video, embeds, and ad slots to prevent layout shift.

Audit Third-Party Scripts

Analytics, tag managers, chat widgets, and ads often dominate main-thread time. Load them after interaction or idle, or move them server-side.

Monitor Real Users Continuously

Collect Core Web Vitals from real sessions segmented by page type, device, and country.

Common Mistakes

Optimizing Lighthouse Scores Only

A perfect lab score on a fast laptop can hide poor field performance on real devices.

Lazy-Loading the Hero Image

loading="lazy" on the LCP image delays the most important content.

Shipping Entire Libraries

Importing all of a date, icon, or utility library for one function adds hundreds of kilobytes.

Client-Rendering Content Pages

Blog posts and product pages that render only after JavaScript runs have slow LCP and weaker SEO.

Ignoring Caching Headers

Unhashed assets with short cache lifetimes force repeat downloads on every visit.

FAQ

What is web performance?

How fast web pages load, render, and respond to user interaction, measured with metrics such as Core Web Vitals.

What are Core Web Vitals?

Google's user-centric metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability.

How do I find what's slowing my site down?

Start with field data (CrUX or RUM) to find slow pages, then use Lighthouse, WebPageTest, and the DevTools Performance panel to inspect network waterfalls, long tasks, and layout shifts on those pages.

Does JavaScript framework choice affect performance?

Yes, but architecture matters more. Server rendering, code splitting, and shipping less client JavaScript help in any framework.

How much does performance affect SEO?

Core Web Vitals are part of Google's page experience signals. They're a tiebreaker rather than the dominant factor, but slow pages also lose users before they engage.

Related Topics

References