Go from building components to shipping production front-ends: architecture, TypeScript, state, performance, testing, CI and code review.

Front-End Engineering

Open Chrome in a guest or incognito window (so extensions do not skew the results) and load the page you chose.

Open DevTools (F12), go to the Lighthouse panel, choose Mode: Navigation, Device: Mobile, Category: Performance, and click Analyze page load. Note LCP, CLS, TBT and the score.

Expand the Largest Contentful Paint element diagnostic. Write down which element it is and which part of the LCP breakdown (TTFB, load delay, load time, render delay) is largest.

Expand Avoid large layout shifts. Write down the element that shifted most and a likely cause (missing image size, injected banner, font swap).

Open the Performance panel, start recording, click a button or open a menu on the page, then stop. Find the interaction in the Interactions track and note how long it took and whether long tasks (over 50 ms) ran under it.

If the site is popular enough, paste its URL into PageSpeed Insights (pagespeed.web.dev) and compare the field data (real users) with your lab numbers.

Write one concrete fix for each of LCP, CLS and INP (for example: remove loading="lazy" from the hero and add fetchpriority="high"; add width and height to card images; defer the chart library).

If it is your own project, apply one fix, re-run Lighthouse with the same settings, and record the before and after numbers.

## Why it matters

Users judge a site in the first few seconds: did the main content show up quickly, did the page jump around, did the button respond when I tapped it? Google measures exactly those three things as the **Core Web Vitals**, uses them as a search ranking signal, and reports them for real visitors in the Chrome User Experience Report. On a front-end team, "LCP regressed on the course page" is a normal ticket, and you are expected to know how to find the cause.

## The three metrics

| Metric | What it measures | Good (75th percentile of visits) |
|---|---|---|
| **LCP**, Largest Contentful Paint | When the largest image or text block in the viewport finished rendering | 2.5 s or less |
| **CLS**, Cumulative Layout Shift | How much visible content moved unexpectedly (a unitless score) | 0.1 or less |
| **INP**, Interaction to Next Paint | The delay between a click, tap or key press and the next frame the user sees, near the worst of the visit | 200 ms or less |

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Thresholds and guidance live at [web.dev/vitals](https://web.dev/articles/vitals) (checked on 2026-10-23).

## Lab data and field data

- **Lab data** comes from a controlled test, such as Lighthouse in Chrome DevTools. It is repeatable and great for debugging, but it uses one simulated device and network.
- **Field data** (also called RUM, real user monitoring) comes from real visitors. PageSpeed Insights shows it for popular sites, and you can collect your own with Google's small `web-vitals` library.

Lab LCP and CLS approximate field values. INP needs real interactions, so Lighthouse reports **Total Blocking Time (TBT)** as a lab proxy: long JavaScript tasks that block the main thread.

## Diagnosing LCP

LCP time breaks into four parts: server response (TTFB), the delay before the browser **discovers** the LCP resource, the time to **download** it, and the time to **render** it. Common fixes:

- The hero image is discovered late (set as a CSS background, or injected by JavaScript). Use a normal `<img>` in the HTML, and add `fetchpriority="high"` to it.
- The hero image has `loading="lazy"`. Never lazy-load the LCP image.
- The image is far too large. Serve a sized, modern-format image (next lesson).
- Render-blocking CSS or fonts delay the first paint. Inline critical CSS, defer the rest, use `font-display: swap`.
- The page is rendered entirely on the client, so nothing shows until JavaScript downloads and runs (see the rendering strategies lesson).

## Diagnosing CLS

Layout shifts happen when something appears or resizes and pushes visible content. Common causes and fixes:

```html

<img src="/hero.jpg" alt="Students at a workshop">


<img src="/hero.jpg" alt="Students at a workshop" width="1200" height="600">
```

- Images, videos and iframes without dimensions.
- Banners, ads or cookie notices inserted above existing content. Reserve space or overlay them.
- Skeletons that are a different height from the loaded content.
- Web fonts swapping in with different metrics. Use `size-adjust` or a close fallback font.

Shifts within 500 ms of a user's input do not count, so content that expands because the user clicked is fine.

## Diagnosing INP

Slow interactions come from too much work on the main thread between the input and the next paint:

- A click handler that does heavy synchronous work (sorting thousands of items, big JSON parsing).
- A state change that re-renders a huge React tree.
- Long tasks from third-party scripts running when the user taps.

Fixes: do less work per interaction, show feedback first and defer the rest (`await` a yield such as `scheduler.yield()` where supported, or `setTimeout`), virtualise long lists, memoise expensive subtrees, and move heavy computation to a Web Worker. In the DevTools **Performance** panel, record an interaction and look for long tasks (red corners, over 50 ms) under it.

## Worked example: reading a Lighthouse report

You run Lighthouse (DevTools > Lighthouse > Mobile > Performance) on a course page and get LCP 4.8 s, CLS 0.27, TBT 640 ms.

1. Expand **Largest Contentful Paint element**: it is the hero `<img>`. The **LCP breakdown** shows most time in "load delay", and the image has `loading="lazy"`. Fix: remove lazy loading, add `fetchpriority="high"`.
2. Expand **Avoid large layout shifts**: the shifting element is the course grid, pushed down when a promo banner loads. Fix: reserve the banner's height with `min-height`.
3. Under **Reduce JavaScript execution time**, a charting library parses on every page even though the chart is below the fold. Fix: load it on demand (next lesson).

Re-run the audit after each fix and compare. Change one thing at a time so you know what helped.

## Common mistakes

- **Chasing a 100 score.** The score is a summary; the metrics and real-user data matter more.
- **Testing only on a fast laptop.** Use the mobile preset and CPU throttling, and check field data.
- **Running Lighthouse with extensions on.** Use an incognito or guest window so extensions do not skew results.
- **Fixing without measuring.** Record a baseline, change one thing, measure again.

## Quick recap

- LCP (loading, 2.5 s), CLS (stability, 0.1) and INP (responsiveness, 200 ms), measured at the 75th percentile.
- Lab tools debug; field data tells you what users actually experience.
- LCP: make the hero discoverable, prioritised and small. CLS: reserve space. INP: keep the main thread free during interactions.

## Try it

The Do tab walks you through auditing a real page with Lighthouse and the Performance panel and writing up one fix for each metric.

Diagnose LCP, CLS and INP problems with Lighthouse and Chrome DevTools.

Core Web Vitals

Optimize for Core Web Vitals

How to find an INP issue with Chrome DevTools

Create a project: run `npm create vite@latest perf-lab -- --template react`, then `cd perf-lab` and `npm install`.

Install a router and a deliberately heavy library: `npm install react-router-dom chart.js`. Create `src/Stats.jsx` that imports `chart.js/auto` and draws a small bar chart on a canvas, and a simple `src/Home.jsx`.

Wire both pages into `App.jsx` with normal static imports and routes for `/` and `/stats`. Run `npm run build` and write down the size and gzip size of the main JS chunk that Vite prints.

Change the Stats import to `const Stats = lazy(() => import('./Stats'))`, wrap your routes in `<Suspense fallback={<p>Loading…</p>}>`, and build again. Note the new main chunk size and the separate Stats chunk.

Run `npm run preview`, open the app with the DevTools Network panel filtered to JS, and confirm the Stats chunk only downloads when you navigate to /stats.

Take a large photo you own (or a free one from a site such as Unsplash), open it in squoosh.app, resize it to 800 pixels wide and export it as WebP. Also export a 400-pixel version. Note both file sizes against the original.

Put the images in `public/`, and add an `<img>` to Home with `srcset` (400w and 800w), `sizes`, `width`, `height`, alt text and `loading="lazy"` (or `fetchpriority="high"` if it is the first thing on the page).

Write a three-line summary with before and after numbers for the JS chunk and the image, as you would in a pull-request description.

## Why it matters

On a mid-range phone, every kilobyte of JavaScript costs twice: once to download and again to parse and execute on a slow CPU. Images are usually the heaviest bytes on a page and often the LCP element. Shipping less code and smaller images is the most reliable performance work you can do, and it is a routine mid-level task.

## Measure the bundle first

Build your app for production and look at what you ship:

```bash
npm run build          # Vite prints each output chunk with its size and gzip size
```

For a visual map, add a bundle analyser such as `rollup-plugin-visualizer` (Vite) or `@next/bundle-analyzer` (Next.js). You are looking for large libraries used on one page, duplicated dependencies, and things you did not expect at all (a whole icon set, every locale of a date library).

## Code splitting

By default a bundler can put your whole app in one JavaScript file. **Code splitting** breaks it into chunks that load when needed. The tool is the dynamic `import()`, which returns a promise and tells the bundler to create a separate chunk.

**Split by route.** Users on the home page should not download the admin dashboard:

```tsx
import { lazy, Suspense } from "react";

const AdminPage = lazy(() => import("./features/admin/AdminPage"));

function App() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/admin" element={<AdminPage />} />
      </Routes>
    </Suspense>
  );
}
```

Frameworks such as Next.js and Remix split by route automatically.

**Split heavy, rarely used components.** A markdown editor, chart or map that appears after a click can load on demand:

```tsx
const Chart = lazy(() => import("./Chart"));
// render <Chart /> only when the user opens the "Stats" tab
```

**Load libraries at the moment of use:**

```js
button.addEventListener("click", async () => {
  const { default: confetti } = await import("canvas-confetti");
  confetti();
});
```

## Shrinking what you import

- Import only what you use: `import debounce from "lodash/debounce"` instead of the whole library, or use a small native alternative.
- Prefer libraries that support tree shaking (ES modules), and check package size before adding one (bundlephobia.com shows it).
- Replace heavy date libraries with `Intl.DateTimeFormat`, and many utility functions with built-ins.
- Do not split everything: each chunk is a request. Split at routes and at big, optional features.

## Images

Images often outweigh all the JavaScript on a page. Four habits fix most of it.

**1. Right format.** Use AVIF or WebP for photos (often 30–50 percent smaller than JPEG at similar quality), SVG for icons and logos, and PNG only when you need lossless transparency. The free web app Squoosh (squoosh.app) lets you compare formats and quality side by side.

**2. Right size.** Do not send a 4000-pixel photo to a 400-pixel slot. Provide several widths and let the browser choose:

```html
<img
  src="/img/course-800.webp"
  srcset="/img/course-400.webp 400w, /img/course-800.webp 800w, /img/course-1600.webp 1600w"
  sizes="(min-width: 960px) 33vw, 100vw"
  width="800" height="450"
  alt="A learner pair-programming at a laptop">
```

`sizes` tells the browser how wide the image will be displayed, so it can pick the smallest file that still looks sharp on that screen.

**3. Right priority.** Add `loading="lazy"` to images below the fold, so they load only when the user scrolls near them. Do the opposite for the hero/LCP image: no lazy loading, plus `fetchpriority="high"`.

**4. Reserve space.** Always set `width` and `height` (or CSS `aspect-ratio`) so lazy images do not cause layout shift.

Framework image components (for example `next/image`) and image CDNs automate resizing and format negotiation, but you still choose `sizes` and priority.

## Worked example

A course listing page ships a 610 kB JavaScript bundle and 3.2 MB of images. The analyser shows a 180 kB charting library used only on the "Progress" tab and a full icon pack. The images are 2400-pixel JPEG thumbnails displayed at 320 pixels.

- Lazy-load the progress tab's chart component: the initial bundle drops by about 180 kB.
- Import individual icons: another 60 kB gone.
- Export thumbnails at 320, 640 and 960 pixels in WebP with `srcset`, add `loading="lazy"` to every card image except the first row, and set width and height.

Re-measure after each change. A result like "JS 610 kB to 370 kB, images 3.2 MB to 420 kB, LCP 3.9 s to 2.1 s" is a strong pull-request description.

## Common mistakes

- Lazy-loading the hero image.
- Splitting tiny components, which adds requests and loading flashes without saving bytes.
- A `Suspense` fallback with a different size from the content, which causes layout shift.
- Forgetting `sizes`, so the browser assumes the image is full-width and downloads the largest file.
- Optimising without numbers. Record sizes before and after.

## Quick recap

- Measure the production bundle, then split by route and by heavy optional features with `import()` and `React.lazy`.
- Import less: specific modules, smaller libraries, built-ins.
- Images: modern formats, `srcset` plus `sizes`, lazy below the fold, high priority for the hero, and always reserve space.

## Try it

In the Do tab you build a small Vite app, split a heavy route, optimise an image, and compare the numbers.


Reduce JavaScript bundle size and image weight so pages load fast on real phones.

Code splitting and images

Speed Up Your React Apps With Code Splitting

Make Your Site Lightning Fast With Responsive Images

## Why it matters

Where and when your HTML is produced shapes almost everything users feel: how soon they see content, how search engines index the page, how fresh the data is, and how much your servers cost. Modern frameworks such as Next.js, Remix, Nuxt, SvelteKit and Astro let you choose per page, so a mid-level developer is expected to pick the right strategy and explain the trade-off.

## The four strategies

**Client-side rendering (CSR).** The server sends an almost empty HTML shell and a JavaScript bundle. The browser downloads and runs the bundle, fetches data, then renders. A default Vite React app works this way.

- Good for: logged-in dashboards and tools where SEO does not matter and the user stays a long time.
- Costs: nothing useful appears until the JavaScript runs, so LCP suffers on slow devices; crawlers and link previews see an empty page.

**Server-side rendering (SSR).** On each request the server runs your components, fetches data, and sends finished HTML. The browser shows it immediately, then **hydrates**: it downloads the same JavaScript and attaches event handlers so the page becomes interactive.

- Good for: pages that are personalised or must always be fresh, such as search results or a signed-in home page.
- Costs: a server does work on every request (time to first byte depends on your slowest data call), and the page is visible before it is interactive.

**Static site generation (SSG).** HTML is produced once at **build time** and served from a CDN.

- Good for: content that is the same for everyone and changes rarely: docs, blog posts, marketing pages, a course catalog.
- Costs: data is as old as the last build; thousands of pages make builds slow.

**Incremental static regeneration (ISR)** (Next.js name; other frameworks call similar features stale-while-revalidate caching). Pages are static, but the framework regenerates a page in the background after a set time or when you trigger revalidation. The first visitor after the window gets the cached page while a fresh one is built.

- Good for: large catalogs that change occasionally, such as product or course pages.
- Costs: some visitors see slightly stale data; you need a server or platform that supports it.

## Side by side

| | When HTML is made | Data freshness | First content | Server cost per view |
|---|---|---|---|---|
| CSR | In the browser | Live (fetched by the client) | Slowest | Lowest (static shell) |
| SSR | Per request | Live | Fast | Highest |
| SSG | At build | As of last build | Fastest (CDN) | Lowest |
| ISR | At build, then in the background | Within the revalidate window | Fastest | Low |

## Hydration and its cost

SSR and SSG pages still ship the component JavaScript so the browser can hydrate. Until hydration finishes, buttons may not respond, which can hurt INP. Ways frameworks reduce this:

- **Streaming SSR** sends HTML in chunks so the shell appears before slow data is ready.
- **React Server Components** (Next.js App Router) render some components only on the server, so their code never ships to the browser.
- **Islands** (Astro) hydrate only the interactive widgets on an otherwise static page.

## Mixing strategies: a worked example

Coding Help-style learning platform, built with Next.js:

- `/courses` and `/courses/[slug]` (public catalog): **SSG + ISR** with a revalidate window, because the same content is shown to everyone, it must be indexable, and admins edit it occasionally.
- `/dashboard` (signed in, personal progress): **CSR or SSR**. It is behind login so SEO does not matter; CSR with a skeleton keeps the server simple, SSR avoids the loading flash.
- `/search?q=...`: **SSR**, because results depend on the query and should be shareable and indexable.
- `/terms`: plain **SSG**; it changes a few times a year.

In the Next.js pages router this looks like:

```ts
// pages/courses/[slug].tsx
export async function getStaticProps({ params }) {
  const course = await loadCourse(params.slug);
  if (!course) return { notFound: true, revalidate: 60 };
  return { props: { course }, revalidate: 300 };  // rebuild at most every 5 minutes
}

export async function getStaticPaths() {
  return { paths: [], fallback: "blocking" };     // build pages on first request
}
```

## How to choose

1. Is the page the same for every visitor? If yes, start with **SSG**, adding **ISR** if it changes.
2. Is it personalised or does it need to be fresh on every request, and should it be indexable? Use **SSR**.
3. Is it an interactive app behind login? **CSR** is fine; SSR is optional.
4. Within any page, client-fetch the small personalised parts (a "Continue learning" button) instead of making the whole page dynamic.

## Common mistakes

- **SSR for everything** "for SEO", paying server time on pages that could be static.
- **CSR for public content** that needs search and link previews.
- **Reading cookies or user data in a static page**, which then caches one user's data for everyone. Personalised data must come from SSR or a client fetch.
- **Hydration mismatches**: rendering `Date.now()` or random values on the server produces different HTML from the client and triggers warnings.
- **Ignoring the fallback state** for ISR pages that are built on first request.

## Quick recap

- CSR renders in the browser; SSR per request; SSG at build; ISR is static with background refresh.
- Static is fastest and cheapest; SSR gives freshness and personalisation; CSR suits private apps.
- Hydration makes server-rendered pages interactive and has a JavaScript cost; streaming, server components and islands reduce it.
- Mix strategies per route, and never bake personal data into a cached page.

## Try it

Open the Do tab and choose strategies for several real pages.


Compare client-side rendering, server-side rendering, static generation and incremental regeneration.

Rendering strategies

WTF Do These Even Mean

Next.js CSR vs SSR vs SSG vs ISR and now PPR!

Diagnose Core Web Vitals, reduce JavaScript and image weight, and choose a rendering strategy for each page.