Scripting Lighthouse

Lighthouse from your own code

Leaf and Kettle now has accounts. When Asha signs in, she sees her orders: mint tea, 120 grams, delivered. That page lives at /account, and it should be fast too.

In the last four lessons, you read one Lighthouse report at a time. You can make each one by hand: open DevTools, click a button, and wait. That works once. But the store changes every week, and nobody wants to click that button after every change. So you write a script: a small Node program that runs Lighthouse for you, the same way every time.

The course wrote that script, with Lighthouse 13.6.0, and pointed it at a small copy of the account site. It came back with a Performance score of 100. Then the course looked at which page Lighthouse had really tested:

1// The script's first run on the account page, as the course recorded it.2const run = { asked: "/account", tested: "/login", score: 1 };3 4console.log(`Asked for ${run.asked}.`);5console.log(`Tested ${run.tested}.`);6console.log(`Performance score: ${run.score * 100}.`);

• Line 1 is a comment.
• Line 2 holds three things the run recorded: the page the script asked for, the page Lighthouse really tested, and the Performance score, from 0 to 1.
• Lines 4 to 6 print Asked for /account., Tested /login. and Performance score: 100.

The script asked for the account page. Lighthouse tested the sign-in page instead, and gave it 100. Nothing crashed. The score looked perfect. Two questions follow:

• How did a test of the account page end up on the sign-in page?
• How do you get Lighthouse past the sign-in, and make it check the store's own rules too?

The answers share one idea. A script can control three moments of a run: before it starts, the run itself, and after it ends. Here is the whole plan at once:

Before the run, the script can sign in. During the run, it chooses the settings and adds checks of its own. After the run, it reads the result: which page was tested, the scores, and the reports to save.

The rest of this lesson builds the script one piece at a time:

• The Node API: call Lighthouse, get the reports back, and run it more than once.
• Logins: get past the sign-in page, and check that you did.
• User flows: measure the sign-in itself.
• Custom audits: add the store's own rules.

The Node API

An API is the set of functions a library lets you call. Lighthouse's Node API is mainly one function, lighthouse(). How Lighthouse works called it with two things. It can take three:

1. The address of the page to test.
2. Flags: settings for this one run, written as an object. Most are the same settings you can type on the command line, such as onlyCategories.
3. A config, if you want one. It's a longer set of instructions, such as extra checks to run. The section on custom audits writes one.

A few flags work differently from Node. Lighthouse's docs list them in a table. Two of them matter here:

• port: "Only specifies which port to use, Chrome is not launched for you." So your script starts Chrome itself. The port is the numbered door that lets Lighthouse drive that Chrome.
• configPath: "Ignored, pass the config in as the 3rd argument to lighthouse." On the command line you name a config file. From Node, you pass the config itself.

Here is a script that asks for two kinds of report from one run:

1import { writeFileSync } from "node:fs";2import lighthouse from "lighthouse";3import * as chromeLauncher from "chrome-launcher";4 5const chrome = await chromeLauncher.launch({ chromeFlags: ["--headless=new"] });6const flags = { port: chrome.port, onlyCategories: ["performance"], output: ["json", "html"] };7const { lhr, report } = await lighthouse("http://127.0.0.1:8080/login", flags);8 9writeFileSync("report.json", report[0]);10writeFileSync("report.html", report[1]);11console.log(lhr.categories.performance.score);12await chrome.kill();

• Lines 1 to 3 load three things: a function that writes files, Lighthouse, and chrome-launcher, a small package that starts Chrome.
• Line 5 starts Chrome without a window.
• Line 6 sets the flags. port says where that Chrome is. onlyCategories asks for Performance only. output asks for two formats: JSON, for code to read, and HTML, for people.
• Line 7 runs Lighthouse. It gives back two things. lhr is the Lighthouse Result: one big object with everything the run found. report holds the reports as text.
• Lines 9 and 10 save the two reports to files.
• Line 11 prints the Performance score, from 0 to 1. Line 12 closes Chrome.

With one format, report is one string. With two, the course's run gave back an array of 2 strings, in the order asked: the JSON first, then the HTML. Why it matters: lines 9 and 10 rely on that order. Swap the formats in line 6, and each file gets the other report.

Run it more than once

Remember the bathroom scale from The Lighthouse score. Step on it twice, and you can get two different readings. So you weigh yourself a few times and take the middle one. Lighthouse's scores wobble the same way, so a script should run it several times too.

Lighthouse's docs on variability put a number on it: "The median Lighthouse score of 5 runs is twice as stable as 1 run." The median is the middle value, once the values are sorted. The same page gives three tips:

• Run them one after another. The docs say, in capitals: "DO NOT collect multiple Lighthouse reports at the same time on the same machine." Runs at the same time compete for the same processor.
• Let Lighthouse pick the middle run. From Node, it has a helper called computeMedianRun. Give it several results. It picks the run closest to the middle on two metrics: when the first text or image appeared, and when the page became fully interactive.
• Or use Lighthouse CI. It's a separate tool. The docs call it "the simplest way to run Lighthouse multiple times and also get a median run".

Why it matters: a script that fails when the score drops below a line can fail on a day when nothing changed, if it reads one run. The docs advise basing such lines on "aggregate values like the median", "instead of single test results."

Testing pages behind a login

Back to the first run. Why did Lighthouse test /login? Lighthouse's docs explain: "Default runs of Lighthouse load a page as a 'new user', with no previous session or storage data."

Here is what that means on the account site. When Asha signs in, the server gives her browser a session cookie. A cookie is a small note the browser keeps for a site, and sends back with every request to it. This one says, in effect, "this is Asha, and she signed in".

The account site sends /account only to a browser that has signed in: one with that cookie, or with a token in a header. Any other browser gets a redirect: an answer that says "not here, go to /login". The script's Chrome had never signed in. So it had no cookie, the server sent it to the sign-in page, and Lighthouse tested the page it ended up on.

Check which page was tested

The result says which page Lighthouse tested. Two fields of lhr hold it. requestedUrl is the address you gave. finalDisplayedUrl is the address of the page Lighthouse ended up testing. A script can compare them:

1// Two fields of the first run's Lighthouse Result, shortened to their paths.2const lhr = { requestedUrl: "/account", finalDisplayedUrl: "/login" };3 4if (lhr.finalDisplayedUrl !== lhr.requestedUrl) {5  console.log(`Careful: asked for ${lhr.requestedUrl}, but tested ${lhr.finalDisplayedUrl}.`);6}

• Line 2 holds the two fields from the first run, shortened to their paths.
• Line 4 checks whether they differ.
• They do, so line 5 prints Careful: asked for /account, but tested /login.

Why it matters: put this check in every script. Without it, the sign-in page's score can stand in for your account page's, and nothing in the score tells you.

Ways past the sign-in

So the script has to sign in, or prove who it is some other way. Lighthouse's docs on authenticated pages list five ways:

1. Script the sign-in with Puppeteer. The docs call this "the most flexible approach".
2. Use the Lighthouse panel in DevTools. It "will never clear your cookies", so you can sign in first, then run it.
3. Send a header with every request. A header is a line of extra information that travels with a request. In Node, the flag is extraHeaders.
4. Open a Chrome with a debugging port, sign in by hand, and run Lighthouse on it with --disable-storage-reset.
5. Reuse a Chrome user profile you prepared beforehand. A profile is the folder where Chrome keeps one person's cookies, history and bookmarks.

Start with the first. Puppeteer is a library that drives Chrome from code: it opens pages, types, and clicks. Here it signs in, in the same Chrome that Lighthouse will use:

1const page = await browser.newPage();2await page.goto("http://127.0.0.1:8080/login");3await page.type("#user", "tea-lover");4await Promise.all([page.waitForNavigation(), page.click("#sign-in")]);5 6const { lhr } = await lighthouse("http://127.0.0.1:8080/account", { port: chrome.port });7console.log(lhr.finalDisplayedUrl);

• Line 1 opens a new tab. browser is Puppeteer's connection to the Chrome the script started.
• Line 2 goes to the sign-in page. Line 3 types a name into the form.
• Line 4 clicks Sign in, and waits for the page the click leads to. On the way, the server hands Chrome the session cookie.
• Line 6 runs Lighthouse on the account page, in the same Chrome. Line 7 prints the page it tested.

The course's run ended on /account: the page it asked for. The cookie was already in that Chrome, so it went with the request.

The course tried other ways too, and logged every request the account site received. Pick a way to see what the site saw, and which page Lighthouse tested:

Here are five of those runs side by side:

1// Each way of testing a page behind the login: the page asked for, the page Lighthouse tested, and the score.2const runs = {3  "fresh browser": { asked: "/account", tested: "/login", score: 1 },4  "signed in with Puppeteer": { asked: "/account", tested: "/account", score: 1 },5  "Authorization header": { asked: "/account", tested: "/account", score: 1 },6  "token in localStorage": { asked: "/orders", tested: "/orders", score: 1 },7  "token page, fresh browser": { asked: "/orders", tested: "/login-token", score: 1 },8};9 10for (const [way, { asked, tested, score }] of Object.entries(runs)) {11  console.log(`${way}: asked for ${asked}, tested ${tested}, score ${Math.round(score * 100)}`);12}13const matched = Object.values(runs).filter(({ asked, tested }) => asked === tested).length;14console.log(`tested the page asked for: ${matched} of ${Object.keys(runs).length}`);

• Lines 3 to 7 hold five recorded runs: the page each asked for, the page it tested, and its score.
• Lines 10 to 12 print one line per run. The first is fresh browser: asked for /account, tested /login, score 100.
• Line 13 counts the runs whose two pages match. Line 14 prints tested the page asked for: 3 of 5.

Every run scored 100, including the two that tested a sign-in page. So the score can't tell you which page it's for. Only the final URL can.

The last run shows one more thing. The token page has a script that checks for the token, and sends the browser to /login-token if there's none. So a redirect doesn't have to come from the server. The page's own JavaScript can send Lighthouse somewhere else too.

Why the sign-in lasted

How Lighthouse works showed that Lighthouse resets the browser before each run. So why didn't the reset sign the script out? Because it clears only some kinds of storage:

The reset clears caches and service workers. It doesn't touch cookies, or localStorage: a store where a page's JavaScript can keep small pieces of text, like a token. It's like a cleaner who empties the bins before each visit, but leaves the keys on their hook.

The recording shows it. The session cookie went with the request in two runs, one straight after the other. The token in localStorage was found too.

One warning, about headers. You could send a Cookie header with extraHeaders, "but beware: it will override any other Cookies you expect to be there." For sign-ins that use cookies, the docs point to Puppeteer instead.

User flows with Puppeteer

Once the script was signed in, the account page scored 100. But what about signing in itself? Asha types her name, taps Sign in, and waits. That wait is a page load too, started by a click.

How Lighthouse works compared Lighthouse's modes to a shop's security camera: film the opening, film one customer, or take a photo. A user flow keeps several of those clips in one report, in order. Each clip is a step.

A step that loads a page is a navigation. Usually you give it an address. You can also give it a function that does something on the page, such as a click. The docs say this function "must perform an action that will trigger a navigation." They add: "Any interactions completed before the callback promise resolves will be captured by the navigation." In plain words: everything the function does, until it finishes, belongs to the step.

1const page = await browser.newPage();2const flow = await startFlow(page);3 4await flow.navigate("http://127.0.0.1:8080/login", { name: "Sign-in page" });5await flow.navigate(async () => {6  await page.type("#user", "tea-lover");7  await page.click("#sign-in");8}, { name: "Sign in" });9await flow.snapshot({ name: "Signed in" });10 11writeFileSync("flow.html", await flow.generateReport());

• Line 1 opens a tab. Line 2 starts a flow in it.
• Line 4 is the first step: a plain navigation to the sign-in page, named Sign-in page.
• Lines 5 to 8 are the second step, named Sign in. Instead of an address, it gets a function. Line 6 types the name, and line 7 clicks Sign in. Lighthouse measures the page load that the click starts.
• Line 9 is a snapshot: a look at the page as the sign-in left it, with no timing. It's named Signed in.
• Line 11 writes one report with all three steps.

The course's flow recorded 3 steps: Sign-in page, a navigation; Sign in, a navigation; Signed in, a snapshot.

The Sign in step started at /session and ended at /account. That's how the form works. It sends the name to /session. The server sets the session cookie there, and redirects to /account.

Lighthouse noticed the redirect, and added a warning to the step:

The page may not be loading as expected because your test URL (http://127.0.0.1:8080/session?user=tea-lover) was redirected to http://127.0.0.1:8080/account. Try testing the second URL directly.

That warning can mean a test missed its page, like the inspector in the lobby. Here, the redirect is the point: signing in sends you on to your account. Why it matters: read every warning, then decide whether it describes a mistake or the very thing you meant to measure.

Custom audits and plugins

Leaf and Kettle has two rules of its own. No built-in check knows these exact rules:

• The hero image has a size. The hero is the big photo at the top of the page. Its HTML must give it a width and a height. Without them, the page can jump when the photo arrives.
• JavaScript stays under 100 KiB. A KiB is 1,024 bytes. The limit counts the bytes the scripts take on the network.

To teach Lighthouse a rule, you add a check. Remember the inspector's clipboard from How Lighthouse works. During the visit, gatherers take readings and write them on the clipboard. Each reading is an artifact. Back at the office, audits check those readings, one check each. So a new rule needs up to three files:

• an audit: the new check;
• a gatherer, if the check needs a reading Lighthouse doesn't take already;
• a config: the instructions that add both to a run.

Lighthouse's recipe says a config "tells Lighthouse where to find the gatherer and audit files, when to run them, and how to incorporate their output into the Lighthouse report."

A new reading: the hero's size

The course's hero check takes its own reading, with a gatherer it wrote. The reading is the photo's width and height attributes:

1import { Gatherer } from "lighthouse";2 3class HeroImage extends Gatherer {4  meta = { supportedModes: ["navigation", "snapshot"] };5 6  async getArtifact(context) {7    return context.driver.executionContext.evaluate(() => {8      const hero = document.querySelector("#hero");9      return hero && { width: hero.getAttribute("width"), height: hero.getAttribute("height") };10    }, { args: [] });11  }12}13 14export default HeroImage;

• Line 1 loads Lighthouse's Gatherer class. Line 3 makes a gatherer from it, called HeroImage.
• Line 4 says which modes it works in: navigation and snapshot.
• Line 6 is the method Lighthouse calls to take the reading.
• Line 7 runs a function inside the page. Line 8 finds the element with the id hero. Line 9 returns its width and height attributes, or null if there's no hero.
• Line 10 closes that function. It passes no extra arguments into the page.

The audit reads that artifact and decides:

1import { Audit } from "lighthouse";2 3class HeroSize extends Audit {4  static get meta() {5    return {6      id: "hero-has-size",7      title: "The hero image has a width and height",8      failureTitle: "The hero image has no width and height",9      description: "Without them, the page shifts when the photo arrives.",10      requiredArtifacts: ["HeroImage"],11    };12  }13 14  static audit(artifacts) {15    const hero = artifacts.HeroImage;16    const sized = Boolean(hero && hero.width && hero.height);17    return { score: sized ? 1 : 0, displayValue: sized ? `${hero.width} by ${hero.height}` : "no size" };18  }19}20 21export default HeroSize;

• Lines 6 to 9 describe the audit: its id, a title for when it passes, a title for when it fails, and a description. The report shows them.
• Line 10 lists the artifacts it reads: just HeroImage.
• Line 15 takes the artifact. Line 16 asks: is there a hero, with both a width and a height?
• Line 17 returns the result. The score is 1 for a pass, or 0 for a fail. displayValue is the short text the report shows next to it: the size, or no size.

A budget is a smoke alarm

The second rule is a budget: a limit you set on something you can measure, such as bytes or milliseconds. Lighthouse used to have budgets built in. Its changelog for version 12.0.0 lists "remove budgets" under breaking changes. An audit can do the same job.

1import { Audit, NetworkRecords } from "lighthouse";2 3const BUDGET_BYTES = 100 * 1024;4 5class ScriptBudget extends Audit {6  static get meta() {7    return {8      id: "script-budget",9      title: "JavaScript fits the budget",10      failureTitle: "JavaScript is over budget",11      description: "The store's budget is 100 KiB of JavaScript, as transferred.",12      requiredArtifacts: ["DevtoolsLog"],13    };14  }15 16  static async audit(artifacts, context) {17    const records = await NetworkRecords.request(artifacts.DevtoolsLog, context);18    const bytes = records.filter((record) => record.resourceType === "Script").reduce((sum, record) => sum + record.transferSize, 0);19    return {20      score: bytes <= BUDGET_BYTES ? 1 : 0,21      numericValue: bytes,22      numericUnit: "byte",23      displayValue: `${Math.round(bytes / 1024)} KiB of ${BUDGET_BYTES / 1024} KiB`,24    };25  }26}27 28export default ScriptBudget;

• Line 3 sets the line: 100 times 1,024 bytes, which is 100 KiB.
• Line 12 asks for the DevtoolsLog artifact: the log of messages Chrome sent Lighthouse during the run. It holds every network request. Lighthouse already collects it, so this audit needs no gatherer of its own.
• Line 17 turns that log into a list of network requests.
• Line 18 does two things. It keeps only the scripts. Then it adds up each one's transferSize: the bytes it took on the network.
• Line 20 passes at the budget or under it, and fails above it.
• Line 23 shows the total next to the budget, in KiB.

Put both on the card: the config

1export default {2  extends: "lighthouse:default",3  artifacts: [{ id: "HeroImage", gatherer: "hero-gatherer" }],4  audits: ["hero-size-audit", "script-budget-audit"],5  categories: {6    "store-checks": {7      title: "Store checks",8      description: "The course's own checks for the store.",9      auditRefs: [10        { id: "hero-has-size", weight: 1 },11        { id: "script-budget", weight: 1 },12      ],13    },14  },15};

• Line 2 starts from Lighthouse's usual config: the usual checklist.
• Line 3 adds one artifact, HeroImage, made by the file hero-gatherer.
• Line 4 adds the two audit files.
• Lines 5 to 14 add a category, Store checks, with both audits in it. Each has a weight of 1, so they count the same.

A config can also hold settings. Lighthouse's configuration docs say they control things "such as CPU/network throttling and which audits should run." That's the throttling from Throttling and simulation.

The recipe adds one rule about extending: "all arrays will be concatenated and primitive values will override the defaults." In plain words: lists, like the audits, are added to Lighthouse's own lists. A single value, like one setting, replaces Lighthouse's value.

The course ran the config from the command line, in the folder with the four files:

npx lighthouse http://127.0.0.1:8080/ --config-path=custom-config.js --only-categories=store-checks

--config-path names the config file. --only-categories=store-checks runs only the new category. The course ran it on two stores: the store from Performance insights, and the fast store from The Lighthouse score.

1// Each store's two custom audits, from the command line's JSON: the score, and the text the report showed.2const stores = {3  store: { "hero-has-size": [0, "no size"], "script-budget": [0, "152 KiB of 100 KiB"] },4  "fast store": { "hero-has-size": [1, "360 by 270"], "script-budget": [0, "150 KiB of 100 KiB"] },5};6 7for (const [name, audits] of Object.entries(stores)) {8  const [hero, budget] = Object.values(audits);9  const category = (hero[0] + budget[0]) / 2;10  console.log(`${name}: hero image ${hero[1]}, JavaScript ${budget[1]}, Store checks ${category * 100}`);11}

• Lines 3 and 4 are recorded from each run's JSON: each audit's score, and the text the report showed.
• Line 8 takes out the two audits. Line 9 averages their two scores.
• Line 10 prints one line per store. The first is store: hero image no size, JavaScript 152 KiB of 100 KiB, Store checks 0.
• The second is fast store: hero image 360 by 270, JavaScript 150 KiB of 100 KiB, Store checks 50.

Look at the fast store. In The Lighthouse score, it scored 100 for Performance in all five runs. Its hero has a size, so the first check passes. But it still sends 150 KiB of JavaScript, because its app.js carries the whole catalog of 1,800 teas. So the alarm goes off.

Why it matters: a budget catches what a good score can hide. The score sums up five metrics. The budget watches the one thing you chose. A script can read this audit's score from lhr.audits, and stop with an error when it's 0. Then a change that adds too much JavaScript can't slip through.

Try the two rules yourself. Type a width and a height, and slide the JavaScript size. The playground uses the same rules as the audits:

Real visits report the same kind of number through Resource Timing, so you can watch the budget for real users too:

Plugins: checks you can share

A plugin packages audits as an npm package, so other people can install them. The plugin handbook says plugins "are easily shared and have a stable API that won't change between minor version bumps". But they "are also more limited in scope than a custom Lighthouse configuration." A stable API means the parts of Lighthouse a plugin uses don't change in minor updates: the ones where only the middle number of the version goes up.

The handbook's table says what each can do. Read each row across: one ability, then whether a plugin and a custom config have it.

So the course's hero check needs a config, because it uses a gatherer of its own. The budget reads only DevtoolsLog, which the handbook lists as available to plugins. So it could be shared as a plugin. A plugin is like a printed checklist any inspector can follow. Your own card can also ask for new readings.

Which approach?

Each job below needs one of three tools. Does it need steps in the browser, like typing and clicking? Then it's Puppeteer. Does one setting do it? Then it's a flag or a header. Does it need a check Lighthouse doesn't have? Then it's a custom audit.

Common mix-ups

• "A 100 means Lighthouse tested my page." No. The fresh browser's 100 was for the sign-in page. Compare finalDisplayedUrl with requestedUrl.
• "Lighthouse signs you out before each run." No. Its reset clears caches and service workers. The session cookie and the localStorage token both survived it.
• "A Cookie header is the easy way in." No. It replaces the other cookies the page expects. The docs point to Puppeteer for sign-ins that use cookies.
• "One run is enough for a script." No. Scores wobble from run to run. The docs say the median of five runs is twice as stable as one.
• "A redirect warning always means a mistake." No. In the sign-in flow, the redirect to the account page was the point.
• "Plugins can do anything a config can." No. A plugin can't gather new data from the page or change settings.
• "Lighthouse still has budgets." No. Version 12.0.0 removed them. A custom audit can do the job.

Practice exercises

Answer first, then use the hints.

// Each way of testing a page behind the login: the page asked for, the page Lighthouse tested, and the score.
const runs = {
  "fresh browser": { asked: "/account", tested: "/login", score: 1 },
  "signed in with Puppeteer": { asked: "/account", tested: "/account", score: 1 },
  "Authorization header": { asked: "/account", tested: "/login", score: 1 },
  "token in localStorage": { asked: "/orders", tested: "/orders", score: 1 },
  "token page, fresh browser": { asked: "/orders", tested: "/login-token", score: 1 },
};

for (const [way, { asked, tested, score }] of Object.entries(runs)) {
  console.log(`${way}: asked for ${asked}, tested ${tested}, score ${Math.round(score * 100)}`);
}
const matched = Object.values(runs).filter(({ asked, tested }) => asked === tested).length;
console.log(`tested the page asked for: ${matched} of ${Object.keys(runs).length}`);

// Each store's two custom audits, from the command line's JSON: the score, and the text the report showed.
const stores = {
  store: { "hero-has-size": [0, "no size"], "script-budget": [1, "152 KiB of 160 KiB"] },
  "fast store": { "hero-has-size": [1, "360 by 270"], "script-budget": [1, "150 KiB of 160 KiB"] },
};

for (const [name, audits] of Object.entries(stores)) {
  const [hero, budget] = Object.values(audits);
  const category = (hero[0] + budget[0]) / 2;
  console.log(`${name}: hero image ${hero[1]}, JavaScript ${budget[1]}, Store checks ${category * 100}`);
}

Check your understanding

For each question, ask three things. Which page was tested? What kept the sign-in? What can each kind of extension do?

Key takeaways

• A script runs Lighthouse the same way every time. It controls what happens before, during and after the run.
• lighthouse() takes an address, flags for this run, and an optional config. Ask for two outputs, and the reports come back in the order you asked.
• Run it several times, one after another, and use the median, not one run.
• A fresh browser has no session. Sign in with Puppeteer in the same browser, or send a header. Lighthouse's reset keeps cookies and localStorage.
• Always compare the final URL with the one you asked for. A run sent to a sign-in page still scores.
• A user flow can measure the page load that a click starts, sign-ins included.
• A custom audit needs an audit and a config, plus a gatherer when it needs new data. Plugins share audits, but can't gather new data.

Sources

The facts on this page come from these docs and source files:

• Using programmatically, Lighthouse docs.
• Score Variability, Lighthouse docs.
• median-run.js, computeMedianRun, Lighthouse 13.6.0 source.
• Running Lighthouse on Authenticated Pages, Lighthouse docs.
• User Data Directory, Chromium docs.
• constants.js, the default settings, Lighthouse 13.6.0 source.
• User Flows in Lighthouse, Lighthouse docs.
• Basic Custom Audit Recipe, Lighthouse docs.
• Changelog: 12.0.0 removes budgets, Lighthouse.
• Lighthouse Configuration, Lighthouse docs.
• Plugin Handbook, Lighthouse docs.

Coming next: WebPageTest basics, also in Measuring in the lab. Test from real locations and devices, then read the filmstrip, the video, and the waterfall.