From onload to user-centric metrics

Four questions about a page load

Asha is on the bus again. She opens the Tea of the week page at Leaf and Kettle: the blank version from lesson 2.2. The shop's name and the heading appear. Under the heading, the space stays empty. She waits. About three seconds later, the mint tea and its reviews appear at last.

That evening, Ravi checks the page's speed the old way, by its load time. It says the page loaded in 1,225 ms. But Asha waited more than four seconds for her tea. So who is right, the number or Asha?

Both are. They measured different moments. The course recorded this page loading the way Asha's phone loads it. Here are two moments from that load:

1// One recorded load of the Tea of the week page, in milliseconds (ms)2const loadEvent = 1225;3const teaAppeared = 4248;4 5console.log(`The load event fired at ${loadEvent} ms.`);6console.log(`The tea appeared at ${teaAppeared} ms.`);7console.log(`After the load event, the tea took another ${teaAppeared - loadEvent} ms.`);

• Line 1 is a comment. The times are in milliseconds (ms), counted from the start of the load. A millisecond is a thousandth of a second.
• Line 2 is when the page's load event fired. Line 3 is when the tea appeared on the screen.
• Lines 5 and 6 print them: The load event fired at 1225 ms. and The tea appeared at 4248 ms.
• Line 7 subtracts one from the other and prints After the load event, the tea took another 3023 ms.

So what is this load event? An event is a signal the browser gives the page's code when something happens: a click, a key press, a file arriving. The load event is its signal that the page has loaded its own files: the HTML, the styles, the scripts and the images. Code can listen for it by putting a function in window.onload. That's where the old name "onload" comes from.

Here is what Asha's screen showed during that load, frame by frame:

By the time the header was drawn, the load event had already fired. By its load time, the page was finished. Asha still had nothing to read but the shop's name and the headings.

Why did it fire so early? The page's script asks the shop's server for the tea and its reviews with fetch(). That's the function a script uses to ask a server for data. The load event didn't wait for those answers. It fired once the HTML, the styles and the script itself were in.

web.dev, Google's site for web developers, describes the same problem. For a long time, speed was measured with the load event. But that moment, it says, "doesn't necessarily correspond with anything the user cares about." Its example is a page like Asha's: one that "loads" quickly and only then fetches its content.

So Ravi needs a different kind of number. A metric is a number that measures one thing about a page, the same way every time, so you can compare. Load time is a metric. A user-centric metric is centred on the user, the person using the page. It measures a moment that person notices: something appears, the main content arrives, a tap gets an answer.

Which moment, then? There isn't just one. Think about waiting for a parcel.

Lesson 1.1 told the same story as a café visit: a string of moments. In 2017, Philip Walton of Google turned those moments into four questions a visitor asks while a page loads. web.dev still uses them. Read each row across: the question, what the visitor wants to know, and the metric the course uses for it today.

Each metric in the table measures something the visitor notices. On Asha's page, the first question got its answer at 1,228 ms, when the header was drawn. The second had to wait until 4,248 ms, for the tea. The load event answered neither.

You'll meet these metrics all through the course. Lesson 3.1, Core Web Vitals, takes LCP, INP and CLS one by one, with the numbers to aim for. Lesson 11.3, Paint, LCP, and layout shift APIs, shows how to read FCP, LCP and CLS from JavaScript.

onload and DOMContentLoaded

A page gets two signals while it loads, not one. Picture a new house. The first signal comes when the walls and the roof are up. The second comes when every piece of furniture has been delivered, down to the last chair.

• DOMContentLoaded is the walls and the roof. It fires when the browser has read all of the HTML. By then it has built the DOM: its model of the page, with one object for each element.
• load is the last chair. It fires when the page's own files have arrived too: stylesheets, scripts and images.

One more word before the table. A deferred script is a script whose tag has the defer attribute. The browser downloads it while it reads the HTML, and runs it once the HTML is read. Each row of the table is one event: when it fires, and what it doesn't wait for. The facts come from MDN, Mozilla's reference site for web developers.

Notice what's missing from both rows: the screen. Neither event says anything about what the visitor can see. On Asha's page, both fired together, at 1,225 ms. Its HTML, its styles and its script were all in. The tea came 3,023 ms later.

The load event can be wrong the other way too. The course built a second page to show it. All its text is in the HTML, so nothing waits for a script. But far down the page sits the heavy picture from lesson 1.2, about 580 KB. It's below the fold: further down than the first screen, so you only see it if you scroll. Here are two moments from one recorded load:

1// The below-the-fold page: two moments from one recorded load, in ms2const everythingDrawn = 1240;3const loadEvent = 4760;4 5console.log(`Everything on the screen was drawn at ${everythingDrawn} ms.`);6console.log(`The load event fired ${loadEvent - everythingDrawn} ms later.`);

• Line 2 is when everything on the first screen was drawn. Line 3 is when the load event fired.
• Line 5 prints Everything on the screen was drawn at 1240 ms.
• Line 6 subtracts one time from the other and prints The load event fired 3520 ms later.

Here is the same load as a filmstrip. It has only one frame, because the whole first screen was drawn at once:

So what happened in those 3.5 seconds? Step by step:

• DOMContentLoaded fired at 611 ms. The screen was still blank. Nothing was drawn until styles.css had arrived, at 1,180 ms.
• All the text appeared at 1,240 ms. It was the first text drawn and also the largest, so that moment was both the FCP and the LCP.
• load waited for mint-tea.svg, the picture below the fold. It arrived at 4,413 ms, and load fired at 4,760 ms. Nobody had scrolled down to see it.

In the house picture, load waited for a piano to be carried up to the attic, while the family was already living downstairs. You can open the page and scroll down to the picture yourself.

Here are both recorded pages on one time line:

WebPageTest, a free tool for testing how pages load, puts it plainly. Content below the fold pushes the load event later, "even if the user-visible content has long-since rendered."

Why does this matter? If Ravi tracks load time, it can change without Asha noticing anything. A smaller picture below the fold could make load fire sooner, and Asha's screen would look exactly the same. The load event is still good for one job: knowing that the page's own files have all arrived. It just doesn't measure what the visitor saw.

The browser writes down the time of both events for every page. Lesson 5.1, The navigation timeline, shows where to read them.

Speed Index and visual progress

If one moment can mislead, why not measure the whole wait? In April 2012, WebPageTest added a metric that tries: Speed Index. It asks how quickly the screen fills in, from the start to the finish. Lower is better.

Picture two people painting the same fence. They finish at the same time. One paints nearly all of it at the very end. The other paints a little at a time. Speed Index counts how much fence stayed bare, and for how long. The second fence was bare for less time, so it scores lower.

Here is the first kind of load in numbers. Nothing appears for 3 seconds, then the whole page at once:

1// Nothing on the screen for 3 seconds, then the whole page at once2const shareMissing = 1;   // all of the page is missing...3const howLong = 3000;     // ...for 3,000 ms4 5console.log(`Speed Index: ${shareMissing * howLong} ms`);

• Line 2 is the share of the page still missing. 1 means all of it.
• Line 3 is how long it stayed missing: 3,000 ms.
• Line 5 multiplies the two and prints Speed Index: 3000 ms.

When a page shows nothing and then everything, its Speed Index is simply the time it took. Now the same 3 seconds, bit by bit:

1// The same 3 seconds, but the page fills in bit by bit2const firstSecond = 1000 * 1;    // nothing drawn: all of it missing3const secondSecond = 1000 * 0.5; // half drawn: half missing4const thirdSecond = 1000 * 0.2;  // 80% drawn: a fifth missing5 6console.log(`Speed Index: ${firstSecond + secondSecond + thirdSecond} ms`);

• Line 2 is the first second. Nothing is drawn yet, so all of the page is missing: 1,000 × 1.
• Line 3 is the second second. Half the page is drawn, so half is missing: 1,000 × 0.5.
• Line 4 is the third second. 80% is drawn, so a fifth is missing: 1,000 × 0.2.
• Line 6 adds them up and prints Speed Index: 1700 ms.

Both loads end at 3 seconds. The second scores 1,300 ms lower, because less of the page was missing along the way. In this picture, each shaded block is one stretch of time, as tall as the share still missing:

A real load has many frames, so WebPageTest does the same sum in a loop. Here it is as a function you can run:

1function speedIndex(frames) {2  let total = 0;3  for (let i = 1; i < frames.length; i++) {4    const stretch = frames[i].ms - frames[i - 1].ms;5    total += stretch * (1 - frames[i - 1].complete);6  }7  return total;8}9 10const allAtOnce = [{ ms: 0, complete: 0 }, { ms: 3000, complete: 1 }];11const bitByBit = [{ ms: 0, complete: 0 }, { ms: 1000, complete: 0.5 }, { ms: 2000, complete: 0.8 }, { ms: 3000, complete: 1 }];12 13console.log("all at once:", speedIndex(allAtOnce), "ms");14console.log("bit by bit:", speedIndex(bitByBit), "ms");

• Each frame says when it was shown, in ms, and how complete the screen was, from 0 to 1.
• Line 4 works out how long the previous frame stayed on the screen.
• Line 5 multiplies that by the share still missing in the previous frame, and adds it to the total.
• Lines 10 and 11 are the two loads from above. It prints all at once: 3000 ms and bit by bit: 1700 ms.

How complete is a frame?

WebPageTest records a video of the load. For each frame, it needs a number from 0 to 1. It doesn't try to read the page. It counts colours instead: how much red, green and blue each frame has. The closer a frame's colours are to the finished page's, the more complete it counts. The course worked out its own four recordings the same way, from their filmstrips.

Each row of this table is one recorded page: how complete its first frame was, its LCP, and its Speed Index.

• The below-the-fold page drew everything at once, and early. Its Speed Index, 1,238 ms, is almost exactly its LCP.
• The content-first page showed the tea early and the reviews later. Its Speed Index, 1,677 ms, is well below the time it finished.
• The skeleton and blank pages drew the tea at almost the same moment. But the skeleton's grey bars counted as progress. Its Speed Index is 2,164 ms, against 2,519 ms for the blank page.

Those grey bars are lesson 2.2's bread and water. They make the wait feel shorter, and Speed Index rewards them. But the tea came no sooner.

Try it yourself. Pick each recorded load and watch the shaded area: that's its Speed Index.

1const frames = recording.filmstrip;   // { ms, visual } for each change2let total = 0;3let previousMs = 0;4let previous = 0;5for (const frame of frames) {6  total += (frame.ms - previousMs) * (1 - previous);7  previousMs = frame.ms;8  previous = frame.visual;9}10showSpeedIndex(total);

Line 6 of the panel's code is the same sum as line 5 of the function above, done frame by frame.

One number hides the details

Lighthouse is Google's page-testing tool. You can run it from DevTools, the developer tools built into Chrome. It still reports Speed Index, worked out its own way. On phones, it rates a Speed Index fast up to 3.4 seconds, and slow over 5.8 seconds.

By that scale, the blank page's Speed Index of 2,519 ms is fast. Yet its LCP, 4,248 ms, is far past the 2.5 seconds web.dev sets as the goal. How can both be true? The header, the heading and the footer were drawn early. They made the first frame 57% complete by the colour count. The one part that mattered, the tea, came last.

web.dev says the same: "no single metric is sufficient to capture all the performance characteristics of a page." That's why each of the four questions gets its own metric. WebPageTest's own notes add two more limits to Speed Index:

• It needs a video of the load. So it works only in a lab test: one you run on a machine you control, not on your visitors' phones.
• It compares every frame with the last one. A video playing on the page, or a moving slideshow, can confuse it.

Lesson 3.2, The supporting metrics, says when Speed Index is still worth a look.

Retired metrics: FMP, TTI and FID

Speed Index wasn't the only try. In 2017, Google answered the four questions with a set of metrics. Two of those metrics have since been replaced. This picture shows the 2017 answers on top, and today's below:

Three metrics from those years have been retired: First Meaningful Paint, Time to Interactive and First Input Delay. Before looking at each one, it helps to ask what a good metric needs.

So a good metric needs three things:

• a clear start, and a clear end that the visitor cares about;
• the same result each time the page loads the same way;
• a definition every browser can measure.

Each retired metric missed at least one of these. The table about them uses a few new words:

• Above the fold is the first screen: the part you see without scrolling.
• The main thread is the one worker that runs the page's JavaScript and handles taps and clicks. While it's busy, a tap has to wait.
• A long task is a piece of work that keeps the main thread busy for more than 50 ms.
• To deprecate a metric is to mark it as on its way out, before it's removed.
• Lighthouse's score mixes several metrics. A metric's weight is its share of that score.
• Total Blocking Time (TBT) adds up how long the main thread was too busy to answer a tap while the page loaded.

Each row is one retired metric: what it measured, why it went, and what replaced it.

First Meaningful Paint: a finish line that moved

FMP tried to answer "Is it useful?". It looked for the paint after the biggest change to the layout above the fold. But its time jumped around from one load to the next. And it was built on Chrome's own drawing code, so no other browser could measure it. The Lighthouse 6.0 release notes say it had "no viable path to standardization". LCP answers the same question today. Lesson 17.1, How LCP works, shows how the browser picks the largest element.

Time to Interactive: one late task moves it

TTI tried to answer "Is it usable?". It started at the first contentful paint. Then it looked ahead for a quiet window: 5 seconds with no long tasks. TTI was the end of the last long task before that window. The real metric also wanted no more than two network requests in the window. This example leaves that part out:

1function timeToInteractive(fcp, longTasks) {2  let tti = fcp;3  for (const task of longTasks) {4    if (task.start - tti >= 5000) break;5    tti = task.end;6  }7  return tti;8}9 10const tasks = [{ start: 1200, end: 1400 }, { start: 2000, end: 2100 }];11console.log("TTI:", timeToInteractive(1000, tasks), "ms");12console.log("one more task:", timeToInteractive(1000, [...tasks, { start: 6900, end: 6960 }]), "ms");

• Line 2 starts TTI at the first contentful paint, fcp.
• Line 4 checks the gap since TTI. A gap of 5,000 ms or more is the quiet window, so the search stops there.
• Line 5 runs otherwise. TTI moves to the end of this task.
• Line 10 lists two long tasks. The last one ends at 2,100 ms, so line 11 prints TTI: 2100 ms.
• Line 12 adds one more task, 60 ms long, starting 4,800 ms after the last one ended. It prints one more task: 6960 ms.

One small task moved TTI by almost 5 seconds. web.dev says TTI proved "overly sensitive to outlier network requests and long tasks". That's the fuzzy end of the referee's watch. Lighthouse 10 removed it.

First Input Delay: it stopped the clock too early

FID tried to answer "Is it usable?" for real visitors. To see what it missed, split one click into three parts:

• Input delay: the wait before the click's code can start, because the main thread is busy.
• Processing: the click's own code running. These functions are its event handlers: code that runs when an event happens.
• Presentation delay: drawing the result on the screen, in the next frame.

1const click = { inputDelay: 12, processing: 280, presentation: 16 };2 3const fid = click.inputDelay;4const wholeClick = click.inputDelay + click.processing + click.presentation;5 6console.log(`FID saw ${fid} ms.`);7console.log(`The visitor waited ${wholeClick} ms.`);

• Line 1 is one click: a 12 ms wait, 280 ms of its own code, and 16 ms to draw.
• Line 3 is FID: the wait, and nothing else.
• Line 4 adds all three parts. That's the time from the click to its result on the screen.
• Lines 6 and 7 print FID saw 12 ms. and The visitor waited 308 ms.

FID stopped its clock when the click's code began. The slow part came after. FID also looked only at the first click of a visit. Its replacement, Interaction to Next Paint (INP), times every click, tap and key press, right up to the next frame. With fewer than 50 of them on a page, it reports the slowest.

1const clicks = [2  { name: "first click", inputDelay: 12, processing: 280, presentation: 16 },3  { name: "later click", inputDelay: 90, processing: 40, presentation: 16 },4];5 6const fid = clicks[0].inputDelay;7const inp = Math.max(...clicks.map((click) => click.inputDelay + click.processing + click.presentation));8 9console.log("FID:", fid, "ms");10console.log("INP:", inp, "ms");

• Lines 1 to 4 are two clicks, each split into the same three parts.
• Line 6 is FID: the first click's wait.
• Line 7 is INP: each click's whole time, keeping the slowest.
• It prints FID: 12 ms and INP: 308 ms.

By FID, this page answered quickly. By INP, one click took 308 ms, more than the 200 ms web.dev counts as good. On March 12, 2024, INP replaced FID as a Core Web Vital, one of the few metrics web.dev asks every site to measure.

Now feel the difference. The Add to cart button below runs its code for 200 ms. Click it once. Then press Keep the page busy, and click Add to cart again straight away:

1new PerformanceObserver((list) => {2  for (const entry of list.getEntries()) {3    if (entry.name !== "click") continue;4    const inputDelay = entry.processingStart - entry.startTime;5    const processing = entry.processingEnd - entry.processingStart;6    showClick({ inputDelay, processing, duration: entry.duration });7  }8}).observe({ type: "event", durationThreshold: 16 });

In the panel's code, line 4 works out a click's wait: what FID measured. Line 5 works out how long its code ran. Line 6 passes on the whole time to the next frame: what INP measures.

How a metric becomes a standard

FMP shows the first thing a metric needs to last: a definition every browser can follow, not just Chrome.

For the web, the recipes are written at the W3C, the World Wide Web Consortium. It's where browser makers and others agree on how web features work. Its Web Performance Working Group writes the standards behind today's metrics, such as Paint Timing, Largest Contentful Paint and Event Timing. web.dev says the Chrome team worked with that group on the new metrics.

The second thing a metric needs is time. Sites need time to measure a new metric and fix what it finds. So web.dev gives every candidate Core Web Vital three stages:

• Experimental: it's being tested, and it can still change.
• Pending: it's nearly ready. It stays here for at least six months, so sites can adapt.
• Stable: it can become a Core Web Vital. From then on, it changes at most once a year, with notice.

INP went through every stage. Each row of the next table is one step on its road. Its last row talks about browser engines. A browser engine is the part of a browser that reads and draws pages. Chrome, Firefox and Safari each use a different one.

The last row is the recipe reaching every kitchen. For years, LCP and INP could only be measured in Chromium browsers, such as Chrome and Edge. Then they joined Interop 2025, a project in which the browser makers worked on the same features together. With Safari 26.2, on December 12, 2025, every major browser engine could measure both. CLS wasn't part of that project. When web.dev announced the news, only Chromium browsers could measure CLS.

Why does it matter? A metric that every browser measures the same way tells you about all your visitors, not only the ones using Chrome.

Which question does it answer?

Each card names something a metric has measured, old or new. Sort it by the question it answers. For each one, ask: what would the visitor notice?

Common mix-ups

• "Load time is how long the page takes." No. It's when the page's own files are in. On Asha's page, load fired seconds before the tea. On the below-the-fold page, it fired seconds after the text.
• "DOMContentLoaded means the page is visible." No. On the below-the-fold page, it fired while the screen was still blank.
• "Speed Index measures content." No. It measures how close the screen's colours are to the finished page's. The skeleton's grey bars lowered it, and they aren't content.
• "A good FID meant the page answered quickly." No. FID saw only the first click's wait. A click whose code ran for 280 ms could still have a 12 ms FID.
• "TTI is the moment the page can be used." Only roughly. One small, late task could move it by seconds. That's why Lighthouse removed it.
• "Google can change the Core Web Vitals any time." No. A new metric is experimental, then pending for at least six months. Stable ones change at most once a year.

Practice exercises

Answer first, then use the hints.

function speedIndex(frames) {
  let total = 0;
  for (let i = 1; i < frames.length; i++) {
    const stretch = frames[i].ms - frames[i - 1].ms;
    total += stretch * (1 - frames[i - 1].complete);
  }
  return total;
}

const allAtOnce = [{ ms: 0, complete: 0 }, { ms: 3000, complete: 1 }];
const bitByBit = [{ ms: 0, complete: 0 }, { ms: 2000, complete: 0.9 }, { ms: 3000, complete: 1 }];

console.log("all at once:", speedIndex(allAtOnce), "ms");
console.log("bit by bit:", speedIndex(bitByBit), "ms");

function timeToInteractive(fcp, longTasks) {
  let tti = fcp;
  for (const task of longTasks) {
    if (task.start - tti >= 5000) break;
    tti = task.end;
  }
  return tti;
}

console.log(timeToInteractive(800, [{ start: 900, end: 1000 }, { start: 5500, end: 5560 }]));

const clicks = [
  { name: "first click", inputDelay: 150, processing: 20, presentation: 16 },
  { name: "later click", inputDelay: 90, processing: 40, presentation: 16 },
];

const fid = clicks[0].inputDelay;
const inp = Math.max(...clicks.map((click) => click.inputDelay + click.processing + click.presentation));

console.log("FID:", fid, "ms");
console.log("INP:", inp, "ms");

Check your understanding

For each question, ask: does this measure a moment the visitor notices, or the page's own work?

Key takeaways

• The load event marks when the page's own files are in, not when the visitor sees anything. In the recordings, it came 3,023 ms before one page's content and 3,520 ms after the other's.
• A user-centric metric measures a moment the visitor notices. Four questions name those moments: is it happening, is it useful, is it usable, is it delightful.
• Speed Index adds up how much of the screen is missing over time. It works only in a lab, and it counts placeholders as progress.
• One number hides which part went wrong. That's why each question gets its own metric.
• FMP, TTI and FID were retired: too jumpy, too easily moved, or stopped too early. LCP, TBT and INP replaced them.
• A metric lasts when every browser can measure it the same way. Core Web Vitals change slowly, and with notice.

Sources

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

• User-centric performance metrics, Philip Walton, web.dev.
• User-centric performance metrics (2017 version, archived), Philip Walton, Google Developers.
• Window: load event, MDN.
• Document: DOMContentLoaded event, MDN.
• <script>: the defer attribute, MDN.
• Lazy loading, MDN.
• Speed Index, WebPageTest documentation.
• Introduction to Lighthouse, Chrome for Developers.
• Speed Index, Lighthouse documentation.
• Lighthouse performance scoring, Chrome for Developers.
• Lighthouse 6.0, Chrome for Developers.
• First Meaningful Paint, Lighthouse documentation.
• Time to Interactive (TTI), web.dev.
• What's new in Lighthouse 10, Chrome for Developers.
• First Input Delay (FID), web.dev.
• Interaction to Next Paint (INP), web.dev.
• Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev.
• Web Performance Working Group, W3C.
• Web Vitals: the Core Web Vitals lifecycle, web.dev.
• LCP and INP are now Baseline Newly available, web.dev.

Coming next: Core Web Vitals. It takes LCP, INP and CLS one by one: what each measures, the numbers to aim for, and how a site passes.