Learn Frontend Part 9: Browser Rendering and Web Performance - Critical Rendering Path and Core Web Vitals

A fast site is not just nice to have: slow pages lose users, rank lower in search, and fail Core Web Vitals. To make pages fast you need to know how the browser turns code into pixels, what blocks that process, and which optimisations actually move the numbers. Performance questions are a favourite in senior frontend interviews for exactly this reason.

This is Part 9 of the Learn Frontend series. We cover the critical rendering path, reflow and repaint, smooth animations, Core Web Vitals, and practical loading and runtime optimisations.

1. The critical rendering path

1. Parse HTML into the DOM. A normal <script> pauses parsing until it downloads and runs (use defer or async, Part 2).
2. Parse CSS into the CSSOM. CSS is render-blocking: nothing is painted until the CSS for the page is ready.
3. Render tree: combine DOM and CSSOM, keeping only visible elements (not display: none ones).
4. Layout (reflow): calculate the size and position of every box.
5. Paint: fill in pixels for text, colours, borders, shadows and images, in layers.
6. Composite: the GPU combines the layers in the right order onto the screen.

To show something useful sooner: keep critical CSS small (inline it for above-the-fold content), defer non-critical JavaScript, preload the hero image and key fonts, and avoid long chains of requests that each wait for the previous one.

2. Reflow, repaint and layout thrashing

• Reflow (layout) happens when geometry changes: width, height, margins, font size, adding or removing elements. It can cascade to many elements and is the most expensive step.
• Repaint happens when only appearance changes (colour, background, visibility) without changing layout.
• Composite-only changes, namely transform and opacity on an element in its own layer, skip layout and paint entirely. That is why animations should use them.

Layout thrashing happens when code alternates between writing styles and reading layout properties (offsetHeight, getBoundingClientRect()), forcing the browser to recalculate layout again and again in a single frame.

// Bad: read, write, read, write... forces a layout on every iteration
items.forEach(el => {
  const h = el.offsetHeight;          // READ (forces layout)
  el.style.height = h * 2 + 'px';     // WRITE (invalidates layout)
});

// Good: batch all reads, then all writes
const heights = items.map(el => el.offsetHeight);      // all READS
items.forEach((el, i) => {
  el.style.height = heights[i] * 2 + 'px';              // all WRITES
});

// Animate with transform instead of top/left
card.style.transform = 'translateX(200px)';             // composite only

3. Core Web Vitals

These come from real-user (field) data at the 75th percentile, so a perfect Lighthouse score on a fast laptop does not guarantee good field results. Our detailed guide covers each metric for React and Next.js apps.

4. Loading performance: ship less, ship smarter

• Code splitting: load JavaScript for a route or feature only when needed, using dynamic import() or React.lazy.
• Compression and caching: serve Brotli or gzip, use long-lived caching for hashed files, and a CDN (Part 1).
• Images: modern formats (WebP, AVIF), responsive srcset, correct dimensions, lazy loading below the fold, and fetchpriority="high" for the LCP image.
• Fonts: self-host or preconnect, subset them, preload the key file and use font-display: swap or optional.
• Third-party scripts: analytics, chat widgets and tag managers are frequent culprits; load them late or with async.
• Bundle analysis: find and remove large or duplicated dependencies; prefer tree-shakeable libraries (Part 15).

// Load a heavy module only when the user needs it
button.addEventListener('click', async () => {
  const { openEditor } = await import('./editor.js');   // separate chunk
  openEditor();
});

// React: split a route or heavy component
const Chart = React.lazy(() => import('./Chart'));
// <Suspense fallback={<Spinner />}><Chart data={data} /></Suspense>

5. Runtime performance

• Long tasks: any task over 50 ms blocks input. Split work into chunks, yield to the browser between them, or move heavy computation to a Web Worker.
• Large lists: rendering thousands of rows is slow; virtualisation (windowing) renders only the visible rows.
• Animations: animate transform and opacity, use requestAnimationFrame, and use will-change sparingly.
• Memory leaks: remove event listeners, clear timers and observers, and abort requests when components unmount (Part 11).
• Frameworks: in React, avoid unnecessary re-renders and keep expensive work out of render; our React rendering article explains how.

6. Measuring before optimising

• Lighthouse (DevTools) gives lab scores and specific suggestions.
• The Performance panel records a timeline of tasks, layout, paint and long tasks; look for red-flagged long tasks and forced reflows.
• The Network panel with throttling shows how the page loads on slow connections and devices.
• Real user monitoring (the web-vitals library, Search Console, analytics) shows what actual visitors experience.

Practice problems

Use Chrome DevTools on your own project or any website to practise these.

1. Run Lighthouse on a site, note LCP, CLS and Total Blocking Time, and list the top three opportunities.
2. Record a Performance profile while scrolling and find long tasks and forced reflows.
3. Create a layout-thrashing loop, measure it, then fix it by batching reads and writes.
4. Animate an element using left and then transform; compare frame rates in the Performance panel.
5. Add width and height to images on a page and measure the change in CLS.
6. Code-split a large component with dynamic import and compare bundle sizes.
7. Render 10,000 rows, then switch to a virtualised list and compare.