Your toolkit and the course project

A toolkit, a store and a log

Ravi looks after the Leaf and Kettle website. In lesson 1.3, he saw Asha wait nearly eight seconds for the tea list on her phone, while his laptop showed it in about half a second. Now he has an idea for a fix. He changes the code, reloads the page on his laptop, and it feels quick.

So, did his change work?

He can't tell yet. "It feels quick" isn't a number, and his laptop isn't Asha's phone. Watch what happens if he measures the page one way before his change, and another way after it. These are two real loads from lesson 1.3. Nobody touched the page between them:

1// Two loads of the same page from lesson 1.3. Nothing in it changed.2const before = { lcp: 7628, setting: "a low-end phone on 3G" };3const after = { lcp: 564, setting: "a fast laptop" };4 5const saved = before.lcp - after.lcp;6console.log(`"My change saved ${saved} ms!"`);7console.log(`Measured the same way? ${before.setting === after.setting}`);

• Line 1 is a comment. The numbers are LCP times in milliseconds (ms). A millisecond is a thousandth of a second. LCP, from lesson 1.1, is the moment the largest text or picture appears on the screen.
• Line 2 is the "before": the page loaded on a laptop slowed down to act like a low-end phone on 3G. Its LCP was 7,628 ms.
• Line 3 is the "after": the same page, loaded on a fast laptop. Its LCP was 564 ms.
• Line 5 subtracts one from the other. Line 6 prints "My change saved 7064 ms!".
• Line 7 compares the two settings and prints Measured the same way? false.

Seven seconds "saved", and the page didn't change at all. The whole difference came from how it was measured. That's the trap. A number only means something next to another number measured the same way.

So before Ravi changes a single line, he needs three things:

• tools that measure, each one answering the question he has;
• a practice page he can break and fix as often as he likes;
• a habit: measure the same way every time, before and after each change, and write it down.

This lesson sets up all three. You'll use them for the rest of the course. Here is the habit in one picture:

One tool for each question

Read about web performance, and you'll meet a crowd of tool names: DevTools, Lighthouse, WebPageTest, CrUX, PageSpeed Insights, web-vitals. It can feel as if you must learn them all at once. You don't. Each one answers a different question. You pick the tool that fits the question you have.

The tools fall into two groups. You met both in lesson 1.1, as the café owner's stopwatch and her till:

• Lab tools are the stopwatch. You run a test on one computer, with settings you choose. You can repeat it and watch every step.
• Field data is the till. It comes from real people's visits, on their own phones and networks.

Each row of this table is one tool, the question it answers, and which group it belongs to:

Here they are one at a time, each with the lesson that teaches it in depth.

DevTools and its Performance panel

Chrome comes with a set of tools for web developers, built into the browser. They're called DevTools. To open them, right-click anything on a page and choose Inspect. One of their panels is the Performance panel. It records what the browser did while a page loaded, or while you clicked: the files it fetched, the scripts it ran, and what it painted.

When you open it, it also shows the page's three Core Web Vitals from lesson 1.1 live: LCP, CLS and INP. This lesson uses it more than any other tool. Lesson 7.1, The Performance panel, gives the full tour.

Lighthouse

Lighthouse is an open-source test from the Chrome team, with its own panel in DevTools. You give it a page, and it tests it the way lesson 1.1 described: as a phone, with the CPU 4 times slower and a slow network. Then it runs a list of checks, called audits, and writes a report with a score. Each failed audit explains why it matters and how to fix it. Lesson 8.1, How Lighthouse works, shows what happens during a run.

WebPageTest

WebPageTest, at webpagetest.org, runs the test on a computer somewhere else. It loads your page in a real browser, on a test computer in a place you pick from its list, over a connection speed you pick. It records a video of the load. That answers a question your own computer can't: how does the page load for someone far from where you sit? Lesson 9.1, WebPageTest basics, covers it.

CrUX and PageSpeed Insights

Lesson 1.2 met the Chrome UX Report (CrUX): Google's public record of how real Chrome users' visits went, on sites with enough visitors. It's field data. It answers "How fast is my site for the people who really visit it?"

The easiest way to see it is PageSpeed Insights, a web page from Google. Type in an address, and it shows the CrUX numbers for that page or site, next to a Lighthouse test of it. Lesson 10.1, The Chrome User Experience Report, covers CrUX. Lesson 10.2, PageSpeed Insights and Search Console, covers the page.

The web-vitals library

CrUX only counts Chrome users, and only those whose browser settings allow it. To measure every visit yourself, you add a small script to your own pages. web-vitals is a tiny JavaScript library from the Chrome team that does this. In each visitor's browser, it measures LCP, INP and CLS the way Chrome does. Your page then sends the numbers to a server you choose. Lesson 12.1, The web-vitals library, sets it up.

For now, you only need DevTools. The other tools get their own lessons. Why it matters now: a Lighthouse score and a CrUX number can disagree, and both can be right, because they answer different questions. Lesson 3.3, Lab data vs field data, explains why.

Chrome, Firefox and Safari for testing

Most of those tools live in Chrome. But your visitors don't all use Chrome. Every browser has an engine: the part that reads a page and draws it. There are three big ones:

• Blink, in Chrome and Edge;
• Gecko, in Firefox;
• WebKit, in Safari.

Remember the recipe from lesson 1.3? It was written in a restaurant kitchen, and took far longer on a small hob at home. Three engines are three different kitchens. The same page can be quick in one and slow in another. So check your important pages in all three.

First, find out what each browser can measure. Browsers hand their measurements to JavaScript as entries. Each entry has a type, such as "largest-contentful-paint" for LCP. This example asks your browser, the one you're reading this in, which types it has:

1const types = PerformanceObserver.supportedEntryTypes;2const vitals = [3  ["LCP", "largest-contentful-paint"],4  ["INP", "event"],5  ["CLS", "layout-shift"],6];7 8for (const [vital, type] of vitals) {9  console.log(`${vital}: ${types.includes(type) ? "this browser reports it" : "not reported here"}`);10}

• Line 1 reads PerformanceObserver.supportedEntryTypes. PerformanceObserver is the browser's tool for watching entries arrive; lesson 11.1, The performance timeline, covers it. supportedEntryTypes is its list of the entry types this browser can report.
• Lines 2 to 6 pair each Core Web Vital with the entry type it's built from. INP is built from "event" entries: the browser's timings of taps, clicks and key presses.
• Lines 8 to 10 go through the three pairs. Line 9 prints whether the list has that type.

Press Edit & run. In Chrome or Edge, it prints this browser reports it three times. Other browsers don't report all three:

Each row of this table is one browser, its tool for recording a page load, and the Core Web Vitals it reports, with the first version that does:

This panel runs a fuller check in your own browser. Open this page in another browser to compare:

1const types = PerformanceObserver.supportedEntryTypes;2const hasInteractionId = "PerformanceEventTiming" in window && "interactionId" in PerformanceEventTiming.prototype;3 4showList(types);5showVitals({6  lcp: types.includes("largest-contentful-paint"),7  inp: types.includes("event") && hasInteractionId,8  cls: types.includes("layout-shift"),9});

In the panel's code:

• Line 1 reads the entry types, as in the first example.
• Line 2 checks for interactionId. One tap fires several events, such as pointerdown, pointerup and click. INP groups them into one interaction by giving them the same id number, interactionId. So a browser needs it to report INP, not only event entries.
• Lines 4 to 9 show the list, and whether each Core Web Vital can be measured.

Firefox and Safari have their own recording tools too: the Firefox Profiler and Safari's Timelines tab. Lesson 9.5, More lab tools, shows both. Why it matters: measure CLS in Chrome or Edge, and check LCP and INP in all three.

DevTools settings for performance work

Ravi's laptop is much faster than Asha's phone. DevTools can slow it down, so it acts more like her phone. That only helps if it's slowed by the right amount, and the same way every time.

Here is the adjusting, in DevTools. Its CPU slowdown setting makes your computer's processor, the chip that runs the code, work slower on purpose. But "4 times slower" is measured from your own computer's speed. A fast laptop and an old one, both slowed 4 times, still end up at different speeds.

So since Chrome 134, DevTools can calibrate. It measures your computer first, then works out how much to slow it. After that, it offers two settings that act like a low-tier and a mid-tier phone.

Calibrating is one setting of several. Each row of this table is one setting, where to find it, and why it matters:

Two words from the table need explaining. The browser's cache is where it keeps files from earlier visits. With the cache off, every reload is a first visit, like Asha's. Field data in the Performance panel means your real visitors' CrUX numbers, shown next to yours.

Firefox and Safari can slow things down too. Firefox's Network Monitor has network presets, from GPRS to Wi-Fi. Its docs warn that they give an approximate idea, not exact measurements. Safari's Web Inspector records loads and interactions in its Timelines tab.

Why it matters: if two numbers in your log used different settings, you can't compare them. That's the trap from the first example.

The course's slow store

Ravi now has tools and settings. He still shouldn't practice on the real shop. If a fix goes wrong, Asha and every other customer would see it.

The course's practice page is the slow store. It's the Leaf and Kettle tea shop again, built from the first three lessons:

• the shop page and its styles from lesson 1.1;
• the heavy picture from lesson 1.2;
• the list of 1,800 teas from lesson 1.3.

Then it got one problem on purpose for each of three qualities from lesson 1.1: loading, responding and stability. Here is its HTML:

1<!doctype html>2<html lang="en">3<head>4  <meta charset="utf-8">5  <meta name="viewport" content="width=device-width, initial-scale=1">6  <title>Leaf and Kettle</title>7  <link rel="stylesheet" href="styles.css">8  <script src="app.js"></script>9</head>10<body>11  <header>Leaf and Kettle</header>12  <div id="news"></div>13  <main>14    <img id="hero" src="hero.svg" alt="A glass of mint tea" width="360" height="270">15    <h1>Mint tea</h1>16    <p>Fresh mint leaves, picked this week. 120 grams, 450 cents.</p>17    <button id="add">Add to cart</button>18    <p id="cart">Cart: 0</p>19    <section id="teas"></section>20  </main>21</body>22</html>

• Line 8 loads app.js, the store's script, inside the <head>. It has no defer or async, so it's a classic script. When the browser meets it, it stops reading the HTML. It downloads the script, runs it, and only then reads on. Nothing can be drawn until then. Lesson 5.3, Render-blocking and parser-blocking resources, explains why.
• Line 12 is an empty box with the id news. A promotion appears in it later.
• Line 14 is the picture: the heavy one from lesson 1.2. It weighs 580 KB, because of a texture of 14,000 dots.

And its script, shortened:

1const catalog = [2  { name: "Mint No. 1", garden: "Assam", notes: "bright and fresh", cents: 250 },3  { name: "Green No. 1", garden: "Nilgiri", notes: "citrus and honey", cents: 1169 },4  // … 1,798 more teas …5];6 7document.addEventListener("DOMContentLoaded", () => {8  buildIndex();9  showTeas(24);10 11  let count = 0;12  document.querySelector("#add").addEventListener("click", () => {13    count = count + 1;14    document.querySelector("#cart").textContent = `Cart: ${count}`;15    // Every click rebuilds the index and draws all 1,800 teas again.16    buildIndex();17    showTeas(catalog.length);18  });19 20  // A promotion that arrives a second later, with no space kept for it.21  setTimeout(() => {22    document.querySelector("#news").innerHTML = '<p class="promo">Free delivery on every order this week. Use the code LEAF at checkout.</p>';23  }, 1000);24});25 26// Start-up work, like building a search index: sort 200,000 past order prices.27function buildIndex() {28  const prices = Array.from({ length: 200000 }, (_, i) => (i * 7919) % 1000);29  return prices.sort((a, b) => a - b);30}31 32function showTeas(howMany) {33  const sorted = [...catalog].sort((a, b) => a.cents - b.cents);34  const cards = sorted.slice(0, howMany).map((tea) => `<article><h2>${tea.name}</h2><p>${tea.garden}: ${tea.notes}. ${tea.cents} cents.</p></article>`);35  document.querySelector("#teas").innerHTML = cards.join("");36}

• Lines 1 to 5 are the catalog, the list of 1,800 teas from lesson 1.3. Only two are shown here.
• Line 7 waits until the browser has read all the HTML. That moment has a name: DOMContentLoaded.
• Lines 8 and 9 do the start-up work: build a search index, then show the 24 cheapest teas.
• Lines 12 to 18 run on every click of Add to cart. Lines 13 and 14 update the cart. Then lines 16 and 17 do the start-up work all over again, for all 1,800 teas, though only the cart changed.
• Lines 21 to 23 add a promotion one second later, above everything else, with no space kept for it.
• Lines 27 to 36 are the two functions behind the start-up work. The first sorts 200,000 prices. The second sorts the catalog and draws a card for each tea.

Its problems, one by one:

• Loading: app.js is a classic script in the head, so the page can't be drawn until it has downloaded and run.
• Loading: The picture, the main content, is 580 KB, because of a texture of 14,000 dots.
• Responding: Each click on Add to cart rebuilds the index and draws all 1,800 teas again.
• Stability: A promotion arrives a second after the page is ready, above the content, with no space kept for it.

Open the store in a new tab and try it. It's published on this site, exactly as it's measured below. Later lessons load this same store. Lesson 7.1 records it in the Performance panel, and lesson 8.2, The Lighthouse score, scores it.

Run the store on your computer

Opening the store on this site is enough to measure it. To change it, you need your own copy. That takes three steps:

1. Make a folder called leaf-and-kettle.
2. Save the store's four files into it: index.html, styles.css, app.js and hero.svg.
3. Start a small web server in the folder. A web server is a program that hands files to the browser when it asks, the way a real site's server does.

With Node.js installed, two commands do it:

cd leaf-and-kettle
npx serve .

Line 1 goes into the folder. Line 2 runs serve, a small web server from npm. npx fetches it from npm and runs it, without adding it to a project. It prints the address to open, usually http://localhost:3000. localhost means your own computer.

With Python instead:

cd leaf-and-kettle
python3 -m http.server 8000

Line 2 starts Python's built-in web server on port 8000. A port is like a numbered door on your computer, and the server waits behind door 8000. So the store is at http://localhost:8000.

Why not just double-click index.html? A file opened straight from the disk skips the network completely, so a server is closer to the real thing. Even a local server is very fast, though: the files never leave your computer. So always turn on the network slowdown in DevTools when you measure locally.

Take your first baseline

Now Ravi can measure. Before he changes anything, he measures the store with fixed settings. That first measurement is the baseline: the first cake, before any change.

One load isn't enough, because no two loads are exactly alike. Lighthouse's docs list some reasons. Other programs on the same computer, browser extensions and antivirus software can all change the numbers. So load the page several times. Five is a common choice: the same docs say the median score of 5 runs is twice as stable as 1 run.

The median is the middle value, once the runs are in order. It's like timing your walk to the bus stop on five mornings, and quoting the middle one, not the morning a neighbour stopped you for a chat. Here are the store's five recorded loads:

1// The store's five recorded loads: LCP in ms, smallest first2const lcpRuns = [5560, 5568, 5568, 5572, 5576];3const middle = lcpRuns[Math.floor(lcpRuns.length / 2)];4 5console.log(`The middle run: ${middle} ms`);6console.log(`Fastest to slowest: ${lcpRuns.at(-1) - lcpRuns[0]} ms`);

• Line 1 is a comment. The runs are already sorted, smallest first. If yours aren't, sort them first, as exercise 2 does.
• Line 2 holds the five LCP times the course recorded for the store.
• Line 3 finds the middle. lcpRuns.length is 5. Half of it, rounded down by Math.floor, is 2. So it reads lcpRuns[2], the third run, because counting starts at 0.
• Line 5 prints The middle run: 5568 ms. That's the store's baseline LCP.
• Line 6 subtracts the fastest run from the slowest, and prints Fastest to slowest: 16 ms.

All five runs were within 16 ms of each other. Runs aren't always this close. With other programs busy on the same computer, one run can come out much slower. The middle run barely moves when that happens, which is why the baseline uses it. Lesson 9.4, Noise and variability, measures how much runs move, and how many you need.

Here is how the course took the store's whole baseline. It loaded the store in real Chrome 156, on an Apple M1 Pro laptop, with:

• the CPU 4 times slower;
• DevTools' Slow 4G network;
• a phone-sized screen;
• nothing saved from earlier visits.

It loaded the store 5 times, and clicked Add to cart once after each load. Then it kept the load with the middle LCP. Each row of this table is one measurement from that load, with its rating:

What the numbers say, one finding at a time:

• Nothing was drawn until 3,092 ms. app.js took until 2,888 ms to arrive, and the page waited for it. That's the loading problem on line 8 of the HTML.
• At 4,043 ms, the promotion pushed everything down: a layout shift, scored 0.14. That's the stability problem.
• The picture finished arriving at 5,271 ms, and appeared at 5,568 ms: the store's LCP. Most of that wait was the 580 KB picture crossing a slow network.
• One click on Add to cart took 296 ms to show its next frame. With only one click, that's the visit's INP. That's the responding problem.

Why it matters: these are the numbers every fix to the store will be compared with. A fix that doesn't move them didn't help.

Try it yourself. Open the store in an Incognito window, use the settings from the checklist, and reload it 5 times. Keep the middle LCP for your log, in the next section. Or download the baseline's trace, a file of everything Chrome did during that load, and open it in the Performance panel. Your numbers will differ from the course's, because your computer does. That's fine. What matters is that your baseline and your later fixes are measured the same way.

Keep a performance log

A baseline kept in your head is soon forgotten. So Ravi writes it down, like the baker's notebook. A performance log is a plain text file, such as performance-log.md in your project. It gets one entry each time you measure. It turns "I think it got faster" into "LCP went from this to that, measured the same way".

Each row of this table is one part of an entry, with the store's baseline as the example:

Here is one entry, written as a single line of text:

1const entry = {2  date: "2026-11-06",3  change: "baseline: nothing changed yet",4  setting: "Chrome 156, CPU 4x slower, Slow 4G, cache off",5  lcp: 5568,6};7 8console.log(`${entry.date} | ${entry.change} | ${entry.setting} | LCP ${entry.lcp} ms`);

• Lines 1 to 6 describe one measurement as an object.
• Line 2 is the date. Line 3 says what changed: nothing yet, so this entry is the baseline.
• Line 4 is the setting, so anyone can measure the same way again. Line 5 is the middle LCP from the previous example.
• Line 8 prints the entry as one line. A bar, |, separates the parts: 2026-11-06 | baseline: nothing changed yet | Chrome 156, CPU 4x slower, Slow 4G, cache off | LCP 5568 ms.

Every later entry has the same shape. Only the change and the numbers move. When two entries are close, lesson 13.2, Proving a change worked, shows how to tell a real improvement from noise.

Now write a real entry, for the page you're reading. This panel reads this page's own load from your browser:

1const [paint] = performance.getEntriesByName("first-contentful-paint");2const lcp = await lastEntry("largest-contentful-paint");3const cls = cumulativeLayoutShift(await allEntries("layout-shift"));4 5writeLine(logLine({6  date: today(),7  change: "baseline: this lesson page",8  setting: `${browserName(navigator.userAgent)}, this device, no slowdown`,9  numbers: `FCP ${paint.startTime} ms, LCP ${lcp.startTime} ms, CLS ${cls}`,10}));

Line 1 of the panel's code reads the first contentful paint: the first moment any text or picture appeared. Lines 2 and 3 read LCP and CLS. Lines 5 to 10 write them into one line, in the same shape as the example above.

What goes in a log entry

An entry only helps if someone can repeat it later: maybe you, three months from now. Sort each item: does it belong in the log?

Common mix-ups

• "One tool tells me everything." No. Each tool answers one question. The Performance panel shows one load step by step. CrUX shows how real visits went.
• "One load tells me how fast it is." No. Loads vary. Take 5 with the same settings, and keep the middle one.
• "Firefox and Safari can't measure Core Web Vitals." No. Both report LCP and INP. Only CLS is Chromium-only.
• "Fast in Chrome means fast everywhere." No. The engines differ, and so do the devices people use them on. Check important pages in all three.
• "The Lighthouse score is my baseline." No. The score blends several metrics, and Lighthouse has changed how much each one counts over time. Log the metrics themselves.
• "Opening the page from my computer measures it." No. Local files arrive almost at once. Slow the network and the CPU in DevTools, or the numbers say nothing about your visitors.
• "A log is only for big teams." No. Without one, you can't tell which of your changes helped, even on your own.

Practice exercises

Answer first, then use the hints.

const types = PerformanceObserver.supportedEntryTypes;
const vitals = [
  ["LCP", "largest-contentful-paint"],
  ["INP", "event"],
  ["CLS", "layout-shift"],
];

for (const [vital, type] of vitals) {
  console.log(`${vital}: ${types.includes(type) ? "this browser reports it" : "not reported here"}`);
}

const lcpRuns = [3100, 2900, 3000, 4400, 3050];
const sorted = [...lcpRuns].sort((a, b) => a - b);

console.log(sorted[Math.floor(sorted.length / 2)]);

const baseline = 4000;
const afterFix = 3000;

const better = (baseline - afterFix) / baseline;
console.log(Math.round(better * 100) + "% faster");

Check your understanding

For each question, ask: which tool answers it, and was the number measured the same way, more than once, and written down?

Key takeaways

• Each tool answers one question. Lab tools, such as the Performance panel, Lighthouse and WebPageTest, test one load on one computer. Field data, from CrUX or web-vitals, comes from real visits.
• Chrome, Firefox and Safari all report LCP and INP. Only Chromium browsers report CLS.
• Measure in a clean window, with the cache off, the CPU and network slowed, and a phone-sized screen. Do it the same way every time.
• The slow store has a problem for loading, responding and stability. Open it on the site, or serve its folder with npx serve.
• A baseline is the middle of several runs with fixed settings, taken before you change anything.
• The store's baseline: LCP 5,568 ms, CLS 0.14, and 296 ms for one click, on Slow 4G with the CPU 4 times slower.
• Write every measurement in a log, with its date, version, change, settings and numbers.

Sources

The facts on this page come from these docs, specifications and source code:

• Chrome DevTools, Chrome for Developers.
• Open Chrome DevTools, Chrome for Developers.
• Performance panel: analyze your website's performance, Chrome for Developers.
• Introduction to Lighthouse, Chrome for Developers.
• Network and CPU throttling, the Lighthouse docs.
• WebPageTest: the code that runs webpagetest.org, Catchpoint, on GitHub.
• WebPageTest agent: supported browsers, video capture and traffic shaping, Catchpoint, on GitHub.
• locations.ini.sample: WebPageTest's location dropdown, Catchpoint, on GitHub.
• Overview of CrUX, Chrome for Developers.
• About PageSpeed Insights, Google for Developers.
• web-vitals README, Google Chrome, on GitHub.
• Rendering engine, the MDN glossary.
• PerformanceObserver.supportedEntryTypes, MDN.
• Event Timing (interactionId), W3C.
• Analyze runtime performance (why to measure in Incognito), Chrome for Developers.
• What's new in DevTools, Chrome 134 (calibrated CPU throttling), Chrome for Developers.
• Firefox Profiler documentation, Mozilla.
• Network Monitor throttling, Firefox DevTools docs.
• The Timelines tab, WebKit.
• serve, Vercel, on npm.
• npx, the npm docs.
• http.server, the Python docs.
• Score variability, the Lighthouse docs.
• First Contentful Paint, web.dev.
• Cumulative Layout Shift, web.dev.
• Lighthouse performance scoring, Chrome for Developers.

Coming next: 0.1 seconds, 1 second, 10 seconds. It looks at how people feel waits of different lengths, and the time budgets that follow for every interaction and frame.