Sending performance data

The last report is the hardest

Asha is reading about mint tea at Leaf and Kettle. She clicks Add to cart. Then she closes the tab, and she's gone.

In The web-vitals library, that was the moment two of her numbers became final: INP and CLS. The library handed them to the shop's code as the page was hidden. The shop's code sent them to the shop's server. But the tab was closing at that very moment. Did the numbers get out? Can a page send anything while it's being closed?

Here is what got out when the course closed a tab at that same moment, in three browsers:

It depends on how the page sends them. A plain fetch() got out only in Chrome. The two ways that hand them to the browser got out in all three.

Two words first. A report is one small message with a metric in it, like {"name":"LCP","value":1234}. The server address that receives reports is the collector. Here it's /collect, on the shop's own site.

To find out, the course built a test page that does one thing. When the page is hidden, it sends one report:

1const body = JSON.stringify({ name: "LCP", value: 1234 });2 3addEventListener("visibilitychange", () => {4  if (document.visibilityState !== "hidden") return;5  fetch("/collect", { method: "POST", body });6});

• Line 1 writes the report. JSON.stringify() turns an object into text, so it can travel.
• Line 3 listens for visibilitychange. The browser fires this event when the page is hidden, or shown again.
• Line 4 stops there unless the page is now hidden.
• Line 5 sends the report with a plain fetch(). A POST request is one that carries data to the server.

The real page also put a test id in the report, so the collector could tell the tests apart. Then the course changed two lines:

• Line 5, the way of sending. It tried four: navigator.sendBeacon(), which lesson 12.1 used; fetch() with keepalive: true; the plain fetch() above; and an image. Asking the collector for an image is a request too, so it hears about it. MDN lists that among the old tricks for sending data as a page closes.
• Line 3, the event. It tried visibilitychange, pagehide and unload. The third section explains each one.

It left each page in two ways: by following a link to another page, and by closing the tab. It did all of this in Chrome, and in Playwright's builds of Firefox and WebKit, Safari's engine. Playwright is a tool that drives a real browser. The collector noted every report that reached it. It waited 300 ms before it answered each one, like a server far away.

Here is everything the collector got. Pick a browser and a way of leaving. Start with Chrome, then try WebKit:

In Chrome, every report arrived. In WebKit, one way of sending lost its report every time: the plain fetch(). Why would a report get lost at all?

Every request a page starts belongs to that page. When the page goes away, the browser stops the requests it hasn't finished. So a plain fetch() only counts if the report reached the collector before that.

The Fetch standard, the rulebook for requests, makes one exception. A request marked keepalive isn't stopped. The browser finishes it after the page has gone. sendBeacon() always sets that mark. With fetch(), you set it yourself.

That's the split in the first picture: the page's own fetch on the top row, and the two handed to the browser below it.

Lesson 12.1 called sendBeacon() a sealed envelope you post as you walk out of the door. Now you know why it still arrives: the browser, not the page, carries it the rest of the way.

The rest of the lesson takes these one at a time:

1. How to hand a report to the browser, and how much the browser will take.
2. When to send it: which event.
3. How to send less: batching and sampling.
4. What travels with a report that you didn't write.

sendBeacon and fetch with keepalive

sendBeacon: post it and walk away

navigator.sendBeacon() is made for this job. MDN says it's "intended for analytics and diagnostics code to send data to a server." You give it the collector's address and the report:

1const body = JSON.stringify({ name: "LCP", value: 1234 });2const queued = navigator.sendBeacon("/collect", body);3if (!queued) console.log("The browser refused the report.");

• Line 1 writes the same report as before.
• Line 2 hands it to the browser. sendBeacon() gives back true or false straight away.
• Line 3 checks. false means the browser refused the report, so it won't be sent.

What does true mean, then? The Beacon spec says it means the browser could "successfully queue the data for transfer." Queued, not delivered. The spec adds that the method "does not provide any information whether the data transfer has succeeded or not." A postbox works the same way: it takes your letter, but it can't tell you when it arrives.

A beacon is always a POST request. The spec lets the browser hold a beacon back for a moment, to save energy and network use. But when the page becomes hidden, it must send every waiting beacon at once.

fetch with keepalive: the same idea, more choices

sendBeacon() has no options. The Beacon spec says it can't change the request's method or add your own headers. For those, the spec points you to fetch() with keepalive set to true:

1const body = JSON.stringify({ name: "LCP", value: 1234 });2fetch("/collect", {3  method: "POST",4  body,5  keepalive: true,6});

• Line 1 writes the report.
• Lines 2 to 6 send it with fetch(), as a POST, with the report as the request's body.
• Line 5 is the one that matters. MDN says that with it, "the browser will not abort the associated request if the page that initiated it is unloaded before the request is complete."

To abort is to stop. A page is unloaded when the browser throws it away. So this request outlives the page, just like a beacon. Firefox added keepalive later than the other browsers, in version 133:

Which one should you use? Read each row as a question, and compare the two answers:

For a small report to your own collector, either one works. The web-vitals README uses sendBeacon(). Reach for fetch() when you need a choice the beacon doesn't give you.

What reached the collector

Now the recording. Here is what arrived when each page sent its report on visibilitychange:

1// Recorded: which reports reached the server. [sendBeacon, keepalive, plain fetch, image]2const arrived = {3  "Chrome, link": [1, 1, 1, 1],4  "Chrome, close": [1, 1, 1, 1],5  "Firefox, link": [1, 1, 1, 1],6  "Firefox, close": [1, 1, 0, 0],7  "WebKit, link": [1, 1, 0, 1],8  "WebKit, close": [1, 1, 0, 1],9};10 11const methods = ["sendBeacon", "fetch and keepalive", "a plain fetch", "an image"];12methods.forEach((method, i) => {13  const got = Object.values(arrived).filter((row) => row[i] === 1).length;14  console.log(`With ${method}, ${got} of ${Object.keys(arrived).length} reports arrived.`);15});

• Line 1 is a comment. It names the four ways of sending, in the order each row lists them.
• Lines 3 to 8 are recorded. Each row is one browser and one way of leaving. A 1 means the report arrived, and a 0 means it was lost.
• Lines 11 to 15 count the 1s for each way of sending, and print one sentence each.
• They print With sendBeacon, 6 of 6 reports arrived. and With fetch and keepalive, 6 of 6 reports arrived. Then With a plain fetch, 3 of 6 reports arrived. and With an image, 5 of 6 reports arrived.

Read the picture one column at a time:

• sendBeacon and keepalive arrived every time, in every browser. Both hand the report to the browser.
• The plain fetch arrived in Chrome both times. Firefox lost it when the tab closed. WebKit lost it both ways. So a plain fetch can look fine when you test in Chrome, and still lose reports in other browsers.
• The image lost one report: in Firefox, when the tab closed. MDN lists the image as an old trick that holds up leaving the page. That makes the next page seem slow, though it's the old page's fault.

The postbox slot: 64 KiB

A beacon can't carry just anything. MDN says: "The total size of queued data is limited to 64 KiB (65,536 bytes)." A KiB, or kibibyte, is 1,024 bytes. In a report's text, each plain letter or digit takes one byte.

The Fetch standard sets the rule. Before a keepalive request starts, the browser adds up the bodies of the page's keepalive requests that are still on their way. If that sum, plus the new body, is more than 64 KiB, the new request fails. The Beacon spec says beacons and keepalive fetches share this one limit.

The course tested it. It sent a 60,000-byte beacon to a collector that took 2 seconds to answer, so the beacon stayed on its way. Then it sent 10,000 bytes more:

1// Recorded: 60000 bytes by sendBeacon, then 10000 more while the first was still on its way.2const queued = {3  Chrome: [true, false],4  Firefox: [true, true],5  WebKit: [true, false],6};7 8for (const [engine, [first, second]] of Object.entries(queued)) {9  console.log(`${engine}: the first beacon was ${first ? "queued" : "refused"}, and the second was ${second ? "queued" : "refused"}.`);10}

• Line 1 says what was sent. 60,000 bytes fit under the limit. 60,000 and 10,000 together don't.
• Lines 3 to 5 are recorded: what sendBeacon() gave back each time.
• Line 9 prints Chrome: the first beacon was queued, and the second was refused. Then Firefox: the first beacon was queued, and the second was queued. and WebKit: the first beacon was queued, and the second was refused.

Chrome and WebKit refused the second beacon, though it was small. The box was nearly full. Next, the course tried 70,000 bytes, over the limit on its own. It tried them twice, by sendBeacon() and by a keepalive fetch():

1// Recorded: 70000 bytes, more than 64 KiB, sent by sendBeacon and then by fetch with keepalive.2const tooBig = {3  Chrome: [false, "TypeError"],4  Firefox: [true, "TypeError"],5  WebKit: [false, "TypeError"],6};7 8for (const [engine, [beacon, keepalive]] of Object.entries(tooBig)) {9  console.log(`${engine}: sendBeacon gave back ${beacon}, and fetch failed with a ${keepalive}.`);10}

• Line 1 says what was sent.
• Lines 3 to 5 are recorded: what sendBeacon() gave back, and how fetch() failed.
• Line 9 prints Chrome: sendBeacon gave back false, and fetch failed with a TypeError. Then Firefox: sendBeacon gave back true, and fetch failed with a TypeError. and WebKit: sendBeacon gave back false, and fetch failed with a TypeError.

Every keepalive fetch() of 70,000 bytes failed, and none reached the collector. But Firefox queued and delivered all three beacons, 140,000 bytes in all. Don't count on that. Keep each report small, far under 64 KiB, and check what sendBeacon() gives back.

visibilitychange and pagehide

The way of sending is settled. Now, when? A page gets several events as a visit ends. These are the three the course tried:

• visibilitychange fires when the page is hidden, or shown again. MDN lists the ways a page gets hidden. The visitor goes to another page, switches tabs, or closes the tab. Or they minimize or close the browser, or switch to another app on a phone. document.visibilityState then says "hidden".
• pagehide fires when the visitor leaves the page, reloads it, or closes the window. Chrome's guide says it doesn't fire when you only switch tabs.
• unload fires when the browser throws the page away. MDN's page on it shows sending analytics from unload as the thing to avoid.

In the recording, all three fired every time, and each one delivered the same reports. So does the event matter? It does, for two reasons. The recording couldn't show the first one, because Playwright only followed links and closed tabs. It could show the second.

Some visitors never reach the till

Phones work the same way. On a phone, people can switch to another app instead of closing the tab. Later, the phone closes the browser to save memory, or the person closes it from the phone's app manager. MDN says unload and pagehide don't fire then. The page was hidden when its visitor switched apps, and that was its last event.

The Beacon spec puts it plainly. It calls visibilitychange "the only event that is guaranteed to fire on mobile devices when the page transitions to background state". Background state means hidden. This is also why web-vitals reports INP and CLS when the page is hidden, as lesson 12.1 showed.

Hidden doesn't always mean gone. A visitor can switch tabs and come back, so a page can be hidden more than once. Send what you have each time. The next section shows how.

unload costs you the back/forward cache

Lesson 12.1 met the back/forward cache, or bfcache. When you leave a page, the browser can keep it whole in memory. Press Back, and the page is shown again at once, like Asha's table, still as she left it when she came back for her scarf.

Chrome's guide to the unload event says it "has a negative impact on a site's performance by preventing the usage of bfcache". The same guide says "pagehide does not make a page ineligible for the back/forward cache." Ineligible means not allowed in. The course tested both in Chrome. Each page sent a beacon from one listener. Playwright left the page, then pressed Back:

1// Recorded in Chrome: a page with one listener that sends a beacon. Leave it, then go back.2const pages = {3  unload: { beaconArrived: true, restored: false },4  pagehide: { beaconArrived: true, restored: true },5};6 7for (const [listener, { beaconArrived, restored }] of Object.entries(pages)) {8  console.log(`${listener}: beacon ${beaconArrived ? "arrived" : "lost"}, ${restored ? "restored from" : "not restored from"} the back/forward cache`);9}

• Line 1 is a comment: what each page did.
• Lines 3 and 4 are recorded in Chrome, with its back/forward cache switched on.
• Line 8 prints unload: beacon arrived, not restored from the back/forward cache and pagehide: beacon arrived, restored from the back/forward cache.

Both beacons arrived. But the page with an unload listener was loaded again from the start when Playwright pressed Back. The pagehide page came straight back. So one unload listener, even one that only sends a report, can make Back slower for every visitor.

One surprise. Chrome's guide says Chrome had switched unload off for every site by Chrome 155: "The unload event will no longer fire by default." Yet the unload beacon arrived in Chrome 156, started by Playwright. It arrived again in a Chrome started on its own, with a new profile. Either way, unload lets you down. If it doesn't fire, the report is lost. If it does, the page can lose its back/forward cache.

So which event should you send on? MDN's page on pagehide puts them in order: "The best event to use to signal the end of a user's session is the visibilitychange event. In browsers that don't support visibilitychange the pagehide event is the next-best alternative." Chrome, Firefox and Safari all have visibilitychange:

Batching and sampling

Reports now arrive, at the right moment. The next question is how much to send. web-vitals measures five metrics: TTFB, FCP, LCP, INP and CLS. Each report could go in its own beacon, and each could carry the whole metric. That costs bytes and requests you don't need.

Send only the fields you need

In lesson 12.1, each metric came as an object with fields such as name, value, id and entries. The entries are the browser's raw timing records. TTFB's holds the whole navigation entry. The web-vitals README warns that JSON.stringify "will likely include more data than you need."

The course put web-vitals on a small mint tea page. Playwright loaded it, clicked Add to cart, and followed a link away. The page sent its reports two ways:

1// Recorded in Chrome: web-vitals' reports from one visit, each in its own beacon. [requests, bytes]2const sent = {3  "the whole metric": [5, 3917],4  "three fields": [5, 315],5};6 7for (const [what, [requests, bytes]] of Object.entries(sent)) {8  console.log(`Sending ${what}: ${requests} requests, ${bytes} bytes.`);9}

• Line 1 says what was recorded: one beacon per report, in Chrome.
• Line 3 is the whole metric, turned into text with JSON.stringify(metric). Line 4 is three fields only: name, value and id.
• Line 8 prints Sending the whole metric: 5 requests, 3917 bytes. and Sending three fields: 5 requests, 315 bytes.

Three fields took about a twelfth of the bytes. Sending the whole metric is like photocopying your whole notebook when a friend asked for three numbers. Keep the id, though: lesson 12.1 used it to put a metric's reports together.

One envelope, not five

The web-vitals README suggests the same. It says you can "minimize your network usage by batching multiple metric reports together in a single network request." A batch is several reports sent together.

But the metrics become final at different times, so you can't wait until all five are ready. The README's answer: keep a queue, a list of reports waiting their turn. Then send all of it, and empty it, "whenever the page is backgrounded or unloaded." The course's batching page did this:

1const queue = new Set();2 3function addToQueue(metric) {4  queue.add({ name: metric.name, value: metric.value, id: metric.id });5}6 7addEventListener("visibilitychange", () => {8  if (document.visibilityState === "hidden" && queue.size > 0) {9    navigator.sendBeacon("/collect", JSON.stringify([...queue]));10    queue.clear();11  }12});

• Line 1 makes the queue. A Set is a list that holds each item once.
• Lines 3 to 5 are the callback you give each web-vitals function, like onLCP(addToQueue). It adds three fields of the metric to the queue. It sends nothing.
• Line 7 listens for visibilitychange. Line 8 goes on only if the page is hidden and the queue isn't empty.
• Line 9 sends the whole queue in one beacon, as one JSON array.
• Line 10 empties the queue. If the visitor comes back, new reports start a new batch.

Here is what Chrome sent with the batch, against one beacon per report:

1// Recorded in Chrome: the same visit's reports, three fields each. [requests, bytes]2const sent = {3  "one beacon per report": [5, 315],4  "one batch when hidden": [1, 338],5};6 7for (const [how, [requests, bytes]] of Object.entries(sent)) {8  console.log(`${how}: ${requests} ${requests === 1 ? "request" : "requests"}, ${bytes} bytes`);9}

• Lines 3 and 4 are recorded in Chrome: the requests and bytes the collector got.
• Line 8 prints one beacon per report: 5 requests, 315 bytes and one batch when hidden: 1 request, 338 bytes.

Five requests became one, for almost the same number of bytes. That's the README's point: less use of the visitor's network. Here are all three ways side by side:

Firefox and WebKit have no CLS, as lesson 12.1 found. So they had fewer reports, and the batch was one request there too.

Sampling: keep whole visits

A busy shop gets many visits. You may not need reports from all of them. Keeping reports from only some visits is called sampling. The share you keep is the rate: a rate of 0.1 keeps one visit in ten.

Decide once per visit, not once per report. Otherwise you could keep a visit's LCP and drop its INP, and that visit's numbers wouldn't line up. It's like asking every tenth table in the café for feedback: you hear from the whole table, not from one person at each.

1// Keep 10% of visits: decide once per visit from its id, so all its reports are kept or dropped together.2const RATE = 0.1;3function sampled(visitId) {4  let hash = 0;5  for (const char of visitId) hash = (hash * 31 + char.charCodeAt(0)) >>> 0;6  return hash % 1000 < RATE * 1000;7}8 9const visits = Array.from({ length: 10000 }, (_, i) => `visit-${i}`);10console.log(`kept ${visits.filter(sampled).length} of ${visits.length} visits`);11console.log(`visit-42: ${sampled("visit-42") ? "kept" : "dropped"}, and the same on every report`);

• Line 1 is a comment. Line 2 sets the rate.
• Lines 3 to 7 decide from the visit's id. Line 5 turns the id into a number, called a hash. The same id always gives the same hash.
• Line 6 takes the hash out of 1,000, with % 1000. It keeps the visit if that number is under 100, a tenth of 1,000.
• Line 9 makes 10,000 visit ids. Line 10 prints kept 1038 of 10000 visits.
• Line 11 prints visit-42: kept, and the same on every report. Every report from visit-42 carries the same id, so each one gets the same answer.

The hash kept 1,038 visits, close to a tenth. Make the visit's id once, when the page loads, and put it in every report. When you count visits later, remember the rate: with 0.1, each kept visit stands for ten.

Privacy and consent

Asha's reports should say how fast the page felt. They shouldn't say who she is. But a request carries more than the body your code wrote.

The course tested this too. Its privacy page set a cookie, session=abc123. A cookie is a small piece of text a site stores in the browser. The browser sends it back with requests to that site.

The page was opened with an email address in its own address, in the query string: the part after the ?. Then it sent one beacon to its own site, and one to another site. Each collector noted what came with its beacon:

1// Recorded in all three engines: what came with a beacon to the shop's own site, and to another site.2// {site} is the shop's address. The page's own address had an email in its query string.3const ownSite = { referer: "{site}/privacy?email=ana%40example.com", cookie: "session=abc123" };4const otherSite = { referer: "{site}/", cookie: null };5 6console.log(`Own site: Referer ${ownSite.referer}, Cookie ${ownSite.cookie ?? "none"}`);7console.log(`Other site: Referer ${otherSite.referer}, Cookie ${otherSite.cookie ?? "none"}`);

• Lines 1 and 2 are comments. {site} stands for the shop's own address.
• Lines 3 and 4 are recorded. They were the same in all three browsers.
• Line 6 prints Own site: Referer {site}/privacy?email=ana%40example.com, Cookie session=abc123.
• Line 7 prints Other site: Referer {site}/, Cookie none.

%40 is how an address writes the @ sign. Two things came along that no code put in the report:

• The Referer header says which page sent the request. HTTP spells it with one r. The shop's own site got the full address, email and all. The other site got only the shop's address. That's the browser's default rule, which MDN calls strict-origin-when-cross-origin.
• The cookie. The Beacon spec sends every beacon with its credentials mode set to include, so the shop's cookie went to the shop's collector. The other site got none, because the cookie belongs to the shop's site.

So the shop's collector got the visitor's email address, though no report asked for it. Anything you store, you have to keep safe. Three habits help.

First, report the page without its query string. If you put the page in your reports, keep only the parts you need:

const pageAddress = new URL("https://shop.test/privacy?email=ana%40example.com");
const pageToReport = pageAddress.origin + pageAddress.pathname;
console.log(`Page to report: ${pageToReport}`);

• Line 1 reads a page's address with new URL(), which splits it into parts.
• Line 2 keeps two parts. The origin is the scheme and the site. The pathname is the page's path. The query string is left out.
• Line 3 prints Page to report: https://shop.test/privacy.

In a real page, you'd write location.origin + location.pathname.

Second, leave the cookie and the Referer off when your collector doesn't need them. sendBeacon() has no options for this. A keepalive fetch() does:

1const body = JSON.stringify({ name: "LCP", value: 1234 });2fetch("/collect", {3  method: "POST",4  body,5  keepalive: true,6  credentials: "omit",7  referrerPolicy: "no-referrer",8});

• Lines 2 to 8 are the keepalive fetch from before.
• Line 6 sets credentials to "omit". MDN says that with it, the browser never sends credentials with the request. Cookies are credentials.
• Line 7 sets referrerPolicy to "no-referrer". MDN says the Referer header "will be omitted".

Third, ask before you measure, where you must. Where your privacy policy or the law asks for consent first, keep reports in the queue until the visitor agrees. If they say no, drop them. And store as little as you can.

Keep it or fix it?

Here are eight ways pages send their reports, all from this lesson. Sort each one: keep it as it is, or fix it. Each answer says why.

Common mix-ups

• "A fetch I start always gets out." No. A plain fetch belongs to the page, so it can be stopped as the page goes. WebKit lost it both ways, and Firefox lost it when the tab closed.
• "When sendBeacon() gives back true, the report has arrived." No. It means the browser queued the report. The spec says the method doesn't tell you whether the transfer succeeded.
• "unload is where you send." No. On phones it often doesn't fire. When it fired in Chrome, it kept the page out of the back/forward cache.
• "pagehide is as safe as visibilitychange." No. pagehide keeps the back/forward cache, but MDN says browsers don't fire it reliably, especially on phones. Send on visibilitychange.
• "The 64 KiB limit is for each beacon." No. It's shared by all the page's keepalive requests on their way. Chrome and WebKit refused a 10,000-byte beacon while 60,000 bytes were still on their way.
• "A beacon only carries its body." No. It carried the shop's cookie, and the page's full address in the Referer header, email and all.

Practice exercises

Answer first, then open the hints.

// Recorded: which reports reached the server. [sendBeacon, keepalive, plain fetch, image]
const arrived = {
  "Chrome, close": [1, 1, 1, 1],
  "Firefox, close": [1, 1, 0, 0],
  "WebKit, close": [1, 1, 0, 1],
};

const methods = ["sendBeacon", "fetch and keepalive", "a plain fetch", "an image"];
methods.forEach((method, i) => {
  const got = Object.values(arrived).filter((row) => row[i] === 1).length;
  console.log(`With ${method}, ${got} of ${Object.keys(arrived).length} reports arrived.`);
});

// Keep 10% of visits: decide once per visit from its id, so all its reports are kept or dropped together.
const RATE = 0.2;
function sampled(visitId) {
  let hash = 0;
  for (const char of visitId) hash = (hash * 31 + char.charCodeAt(0)) >>> 0;
  return hash % 1000 < RATE * 1000;
}

const visits = Array.from({ length: 10000 }, (_, i) => `visit-${i}`);
console.log(`kept ${visits.filter(sampled).length} of ${visits.length} visits`);
console.log(`visit-42: ${sampled("visit-42") ? "kept" : "dropped"}, and the same on every report`);

const LIMIT = 64 * 1024;
const batch = 338;
let onTheirWay = 0;
let batches = 0;
while (onTheirWay + batch <= LIMIT) {
  onTheirWay += batch;
  batches += 1;
}
console.log(`${batches} batches fit, using ${onTheirWay} bytes.`);

const queue = new Set();

addEventListener("unload", () => {
  fetch("/collect", { method: "POST", body: JSON.stringify([...queue]) });
});

const queue = new Set();

addEventListener("visibilitychange", () => {
  if (document.visibilityState === "hidden" && queue.size > 0) {
    navigator.sendBeacon("/collect", JSON.stringify([...queue]));
    queue.clear();
  }
});

Check your understanding

For each question, ask four things. Does the request outlive the page? When is it sent? How big is it? What does it carry?

Key takeaways

• A plain fetch() belongs to the page and can die with it. sendBeacon() and fetch() with keepalive are handed to the browser, which finishes them.
• sendBeacon() giving back true means queued, not delivered. false means refused.
• All the page's keepalive requests on their way share 64 KiB. Keep reports small.
• Send when the page becomes hidden, on visibilitychange. pagehide comes next. Avoid unload: it may not fire, and in Chrome it cost the page its back/forward cache.
• Send three fields, not the whole metric. Queue the reports, and send one batch when the page is hidden. Sample whole visits.
• Requests carry cookies and the Referer header. Leave out query strings and personal data, and wait for consent where it's needed.

Sources

The facts on this page come from these specs and docs:

• Fetch Standard: the keepalive flag, WHATWG.
• Navigator: sendBeacon() method, MDN.
• Beacon, W3C.
• RequestInit: keepalive, credentials and referrerPolicy, MDN.
• Document: visibilitychange event, MDN.
• Window: pagehide event, MDN.
• Deprecating the unload event, Chrome for Developers.
• web-vitals 6.2.3 README, Google Chrome.
• Referrer-Policy header, MDN.

Coming next: Building a RUM pipeline. Your reports now arrive. Next, you'll build what they arrive at: an endpoint, storage, percentiles and alerts, by hand.