The performance inequality gap

Most people aren't on your laptop

Ravi, who looks after the Leaf and Kettle website, has built a new page that lists the shop's teas. He tries it on his laptop, on the office Wi-Fi. The teas appear in about half a second. Fast enough, he thinks.

Then Asha, from the first lesson, opens the same page on the bus, on her cheap phone. For a few seconds she sees nothing. Then the shop's name appears at the top. The teas come a few seconds after that.

It's the same page and the same code. So why does Ravi wait half a second, and Asha nearly eight? And which of the two should Ravi build for?

The course measured the difference. It loaded the page in Chrome on a fast laptop. Then it loaded it on the same laptop, slowed down on purpose to act like a low-end phone on a weak 3G network. Here is when the teas appeared each time:

1// When the teas appeared, in ms, in two loads of the same page2const fastLaptopMs = 564;3const lowEndPhoneMs = 7628;4 5const times = lowEndPhoneMs / fastLaptopMs;6console.log(`The low-end phone waited ${times.toFixed(1)} times as long.`);

• Line 1 is a comment. Times are in milliseconds (ms), thousandths of a second, from the start of the visit.
• Lines 2 and 3 hold the two recorded times: 564 ms on the fast laptop, and 7,628 ms on the low-end phone.
• Line 5 divides the slow time by the fast one.
• Line 6 prints The low-end phone waited 13.5 times as long.

Thirteen and a half times as long, for the same page. Ravi's laptop was the wrong place to judge it. Here are both loads in one picture. In the middle is a third load: the same laptop, slowed down much the way Lighthouse, the test tool from lesson 1.1, tests a phone.

The difference between Ravi's laptop and Asha's phone has a name. Alex Russell, who writes about web performance, calls it the performance inequality gap. It's the gap between the fast devices and networks developers use, and the slower ones most people have. Russell has tracked it in a series of articles since 2017. This lesson uses his 2026 edition.

Which visitor, exactly? Lesson 1.2 met the 75th percentile: line everything up from best to worst, and go three quarters of the way along. Russell lines up visitors by how fast their phone and network are. The one three quarters along is the one he tells you to test with. A full quarter of visitors have something slower still.

In his 2026 edition, that visitor has:

• a phone like the Samsung Galaxy A24 4G, an Android from 2023;
• a network that downloads 9 megabits a second, uploads 3, and takes 100 ms for a round trip.

The next three sections take that visitor apart: the phone, its chip, and its network.

What the median phone really is

Start with the phone in the visitor's hand. Here is what Russell's sales figures show:

• In none of the past twelve years were iPhones more than 20% of the new phones sold.
• Cheap phones outsell expensive ones by more than 3 to 1.
• Some low-end phones now cost less than $100.
• People keep their phones longer than before. The median phone is now kept for more than two years.
• Phones at the 75th percentile may be nearly three years old.

Russell sums it up: most phones in use are Androids more than two years old. So the median phone, the middle one if you line them all up, isn't a new iPhone. The phone at the 75th percentile is slower still.

Russell's test phone, the Galaxy A24 4G, came out in 2023 for $250, when the average phone sold for $353. It may be hard to buy now, so any phone with the same chip will do, such as the Galaxy A16 4G.

Russell follows four groups of phones. A phone's CPU, the chip that runs the code, has several cores: workers that can each run one thing at a time. The table compares one core of each phone, because a page's JavaScript mostly depends on one. Read each row across:

What your analytics can and can't show

Your analytics may show far more than 20% iPhones. Wikimedia, which runs Wikipedia, sees more than 40% of its phone visits come from iPhones. Russell gives two reasons:

• People with more money, who can afford iPhones, show up more in these statistics.
• Used and refurbished iPhones are a big and growing market. So the recent iPhone a developer carries isn't what most iPhone owners have.

So check your own numbers, but know what they can't show. People who gave up on a slow site don't appear in its usage numbers at all. Russell describes a fast-growing site that added nearly 100 KiB of JavaScript to what its pages loaded first, every month for six months. A KiB is 1,024 bytes. Each month, a smaller share of its visits came from phones. Then the team removed code nobody used, and files fetched too early. The phone visitors came back.

So speed isn't a finishing touch for people with fast phones. It decides who can use your site at all.

Computers are part of the picture too

Laptops and desktops are only 15 to 18% of the devices sold that can browse the web. And not all of them are fast. About 80% run on batteries, so to save power and stay cool, their chips often run below full speed. Microsoft Edge sorts the computers it runs on into three tiers. Read each row across:

Nearly a third are low-end, and only 10% are high-end.

CPU speed: 3.5 to 9 times slower

Remember the one person behind the counter from lesson 1.1? That's the page's main thread. It runs the page's JavaScript one task at a time, and a tap waits until the current task is done. The main thread runs on one core at a time. So for JavaScript, how fast one core is matters more than how many there are.

Russell finds that the speed of JavaScript-built pages closely follows the speed of one core. The cheapest phones have had eight cores since 2019, but eight slow cores don't make the main thread faster.

Russell compares phones with Geekbench, a test that scores how fast a CPU works. On one core, a mid-range Android is more than 3.5 times slower than a recent iPhone. A low-end Android is 9 times slower. Say a tap runs 40 ms of JavaScript on a recent iPhone:

1const iphoneMs = 40;2const phones = [3  { name: "a recent iPhone", slower: 1 },4  { name: "a mid-range Android", slower: 3.5 },5  { name: "a low-end Android", slower: 9 },6];7 8for (const phone of phones) {9  const ms = iphoneMs * phone.slower;10  console.log(`${phone.name}: ${ms} ms${ms > 50 ? ", a long task" : ""}`);11}

• Line 1 is the work's time on a recent iPhone: 40 ms.
• Lines 2 to 6 list three phones, each with how many times slower its core is.
• Line 9 multiplies the iPhone's time by each phone's slowdown.
• Line 10 prints the time. When it's over 50 ms, it adds a long task.
• It prints a recent iPhone: 40 ms, a mid-range Android: 140 ms, a long task and a low-end Android: 360 ms, a long task.

A long task, from lesson 1.1, is the main thread busy for more than 50 ms in a row. A tap during it waits. So the same code makes no long task on the iPhone, and makes Asha wait over a third of a second.

Why it matters: every bit of JavaScript you add costs the slowest phones the most. And the gap isn't closing on its own. Russell finds that the chips in budget phones haven't really got faster since 2022.

Time some real work on your own device. The panel does the same start-up work as the shop page later in this lesson:

1const start = performance.now();2buildShop();3const ms = performance.now() - start;4 5showTime("this device", ms);6showTime("a mid-range Android, at least", ms * 3.5);7showTime("a low-end Android", ms * 9);

• Line 2 of the panel's code builds a catalog of 1,800 teas, sorts 200,000 prices, and builds 24 cards.
• Lines 1 and 3 time it with performance.now(), the milliseconds since the page started loading.
• Lines 6 and 7 multiply your time by 3.5 and by 9. They're estimates that treat your device as a recent iPhone.

The panel's heading also shows two numbers the browser reports:

• navigator.hardwareConcurrency: the number of logical processors, or how many threads the CPU can run at once.
• navigator.deviceMemory: about how many gigabytes of memory the device has. Only Chromium browsers report it, and they round it so sites can't use it to recognize you.

You can't carry every phone around. So, as lesson 1.1 showed, tools slow your computer down on purpose: that's throttling. Lighthouse makes the CPU 4 times slower for its phone test. Since Chrome 134, DevTools can measure your computer and offer CPU settings matched to a low-tier and a mid-tier phone. Lesson 8.3, Throttling and simulation, shows how both work.

How big is the gap on real sites? The Web Almanac 2025, HTTP Archive's yearly study of the web, tested pages on a desktop setting and a phone setting. It measured Total Blocking Time: how long, in total, long tasks kept the main thread from answering during a load. For the median page, that was 92 ms on desktop, and 1,916 ms on the phone: nearly two seconds.

Network speeds around the world

The bytes still have to reach the phone. Here the gap is about money as well as speed.

Start with the price. In lesson 1.2, a data plan was a taxi meter: every byte counts against it. The International Telecommunication Union (ITU), a United Nations agency, compares the same kind of mobile data plan in every country. People in low-income countries spend about 22 times as large a share of their income on it as people in high-income countries.

Then the road. Russell takes his network numbers from Cloudflare Radar, Cloudflare's public report on internet speed and quality around the world. At the 75th percentile, a connection:

• downloads 9 megabits a second (Mbps);
• uploads 3 Mbps;
• takes 100 ms for a round trip: a message to a server and its answer back.

A megabit is a million bits, and a byte is 8 bits, so 9 Mbps brings about 1.1 million bytes a second. Each row of this table is one network you'll meet in this course:

Two findings stand out:

• The gap is growing. Since early 2024, the slowest quarter of connections improved from about 7 to 9 Mbps. Over the same time, the gap between the slower quarter and the faster quarter grew from 15 to 21 Mbps.
• 5G isn't everywhere. 5G covered just over half the world in 2025, says the GSMA report Russell quotes. And many people need a newer, more expensive phone to use it. Russell puts it this way: "4G is a miracle, and 5G is a mirage."

What do these speeds mean for a page? Take the median mobile page, which Russell puts at 2.6 MiB, and download it on three networks:

1const networks = [2  { name: "a fast office line", mbps: 100, rttMs: 10 },3  { name: "the 75th percentile", mbps: 9, rttMs: 100 },4  { name: "DevTools' Slow 4G", mbps: 1.44, rttMs: 150 },5];6const bytes = 2.6 * 1024 * 1024;7 8for (const network of networks) {9  const ms = network.rttMs * 4 + (bytes * 8) / (network.mbps * 1000);10  console.log(`${network.name}: about ${Math.round(ms / 100) / 10} s`);11}

• Lines 1 to 5 are three networks: a made-up fast office line for comparison, the 75th percentile, and DevTools' Slow 4G.
• Line 6 is the page's size in bytes. A MiB (mebibyte) is 1,024 × 1,024 bytes, a little more than a million.
• Line 9 is a simple model. It spends 4 round trips to find the server, connect, make the line private and ask for the page. Then the bytes come at full speed: bytes × 8 gives bits, and 1 Mbps carries 1,000 bits each millisecond.
• Line 10 prints a fast office line: about 0.3 s, the 75th percentile: about 2.8 s and DevTools' Slow 4G: about 15.7 s.

Same page: under half a second, or nearly sixteen. Why it matters: on a slow road, every byte you don't send saves the visitor time and money. Real loads are messier, because new connections start slowly. Lesson 4.1, Latency vs bandwidth, and lesson 4.3, TCP connections and slow start, cover that. The system design lesson Back-of-the-envelope numbers for frontend practises estimates like this.

One page, three experiences

Back to Ravi's tea page. Which part of the gap made Asha wait? The page's content is built by JavaScript, as on many sites. Its HTML holds only a header and an empty <main>:

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" defer></script>9</head>10<body>11  <header>Leaf and Kettle</header>12  <main id="app"></main>13</body>14</html>

• Line 8 loads app.js. Its defer attribute tells the browser to run it once the HTML has been read.
• Line 12 is the empty <main> that app.js fills in.

Here is app.js, 153 KB in all, 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 7// Start-up work, like building a search index: sort 200,000 past order prices.8const prices = Array.from({ length: 200000 }, (_, i) => (i * 7919) % 1000);9prices.sort((a, b) => a - b);10 11// Sort by price, then show the intro and the cheapest 24 teas.12const sorted = [...catalog].sort((a, b) => a.cents - b.cents);13const gardens = new Set(catalog.map((tea) => tea.garden));14const cards = sorted.slice(0, 24).map((tea) => `<article><h2>${tea.name}</h2><p>${tea.garden}: ${tea.notes}. ${tea.cents} cents.</p></article>`);15 16document.querySelector("#app").innerHTML = `<h1>Our teas</h1>17<p id="intro">${catalog.length} teas from ${gardens.size} gardens, from ${sorted[0].cents} cents. Every tea is packed the week you order it and sent in a paper bag you can compost.</p>18${cards.join("\n")}`;

• Lines 1 to 5 are the catalog: 1,800 teas, written out in the file. They make up most of its size.
• Lines 8 and 9 stand in for the start-up work a real shop does, such as building a search index. They sort 200,000 prices.
• Lines 12 to 14 sort the teas by price and build cards for the 24 cheapest.
• Lines 16 to 18 put a heading, an introduction and the cards into the page. Nothing useful shows until they run.

The course loaded this page in real Chrome 156, on a phone-sized screen, 5 times on each of three settings. The CPU slowdowns are compared with the recording computer, an Apple M1 Pro laptop:

• A fast computer: Full CPU speed, DevTools' Fast 4G.
• Lighthouse's phone: CPU 4 times slower, DevTools' Slow 4G.
• A low-end phone: CPU 9 times slower, DevTools' 3G.

The table gives the times behind the picture at the top of the lesson. Each row is one setting, from the load with the middle LCP of its 5. LCP, from lesson 1.1, is when the largest text or image appeared: here, the shop's introduction.

So what made the low-end load 13.5 times as long? Subtract the fast laptop's times from the low-end ones:

1// Two loads of the same page, in ms2const fastLaptop = { scriptArrived: 507, longTask: 0 };3const lowEndPhone = { scriptArrived: 7232, longTask: 366 };4 5const extraWait = lowEndPhone.scriptArrived - fastLaptop.scriptArrived;6const extraWork = lowEndPhone.longTask - fastLaptop.longTask;7console.log(`Extra time waiting for app.js: ${extraWait} ms`);8console.log(`Extra time in long tasks: ${extraWork} ms`);

• Line 2 is the fast laptop. app.js arrived at 507 ms, and running it made no long task.
• Line 3 is the low-end setting. app.js arrived at 7,232 ms, and running it was a 366 ms long task.
• Lines 5 and 6 subtract, to find how much longer each part took.
• Lines 7 and 8 print Extra time waiting for app.js: 6725 ms and Extra time in long tasks: 366 ms.

The teas came 7,064 ms later on the low-end setting. Waiting for app.js to come over the slow network was 6,725 ms of that. The slow CPU added a long task on top.

Why it matters: on this page, the network made the biggest difference, so sending fewer bytes is the first thing to try. The CPU still matters. The same script made no long task on the laptop, a 155 ms one with Lighthouse's settings, and a 366 ms one on the low-end setting.

The filmstrips show what a visitor saw: the header first, then a wait, then the teas.

You can open the shop and measure it yourself. Or download the traces for the fast, Lighthouse and low-end loads, and open them in DevTools' Performance panel.

A realistic budget for bytes and JavaScript

Ravi now knows the page is too slow for Asha. So how big may it be? He needs a performance budget: a limit set in advance, like deciding before a holiday how much you'll spend. It can limit how many bytes a page sends, or how long it takes to load.

Start from a time target and the 75th percentile network. How many bytes fit in 3 seconds?

1const rttMs = 100;2const mbps = 9;3const targetMs = 3000;4 5const setupMs = 4 * rttMs;6const bytesPerMs = (mbps * 1000000) / 8 / 1000;7const budgetBytes = (targetMs - setupMs) * bytesPerMs;8 9console.log("time left for bytes:", targetMs - setupMs, "ms");10console.log("budget:", (budgetBytes / 1024 / 1024).toFixed(1), "MiB");

• Lines 1 to 3 are the 75th percentile network, 100 ms and 9 Mbps, and a target of 3 seconds.
• Line 5 spends 4 round trips before any bytes arrive, as in the download example: 400 ms.
• Line 6 turns 9 Mbps into bytes each millisecond: 1,125.
• Line 7 fills the rest of the time with bytes.
• Lines 9 and 10 print time left for bytes: 2600 ms and budget: 2.8 MiB.

2.8 MiB is an upper limit. Russell's budget calculator counts more than this simple model, so its budgets are smaller:

• Connections. His budgets assume the page opens two connections, and each one takes time to set up.
• The phone's CPU time. JavaScript costs the most: after it downloads, the slow CPU still has to read it and run it.

Most bytes are like a sandwich: once you've carried it home, you can eat it. JavaScript is like a meal kit: you still have to cook it, and on a slow phone the cooking takes longest.

So the calculator sorts pages into two kinds:

• JavaScript-light pages, where 15% of the bytes are JavaScript;
• JavaScript-heavy pages, where half of them are.

Each row of the table is one time target, with the budget for each kind of page:

A page that opens four connections instead of two loses another 350 KiB from the 3-second budget.

Now compare them with the web today, from the HTTP Archive figures Russell quotes:

• The median mobile page is 2.6 MiB. That's already over the 3-second budget for a JavaScript-light page, 2.0 MiB.
• On mobile, the median page sends 680 KiB of JavaScript. That's more than either 3-second budget allows for JavaScript: 0.3 MiB, or 0.62 MiB, which is about 635 KiB.
• The page at the 75th percentile sends 1.3 MiB of JavaScript.

Why it matters: at least half of mobile pages are already bigger than a 3-second budget allows. Lesson 6.4, The cost of JavaScript, shows where JavaScript's CPU time goes.

Why the 75th percentile, not the average

Ravi has made his page smaller. Is it fast enough for his real visitors now? Every visit has its own time: most are fast, some slow, a few very slow. How do you sum that up in one number? A bus company has the same problem:

Page loads work the same way. To find the 75th percentile, line the loads up from fastest to slowest and go three quarters of the way along. Here it is for ten page loads:

1const lcps = [1200, 1400, 1500, 1700, 1900, 2100, 2600, 3400, 5200, 9800];2const sorted = [...lcps].sort((a, b) => a - b);3 4const place = Math.ceil(0.75 * sorted.length);5console.log(`75th percentile: load ${place} of ${sorted.length}, ${sorted[place - 1]} ms`);

• Line 1 holds ten LCP times, one per page load.
• Line 2 copies them and sorts them, fastest first.
• Line 4 works out the place three quarters along. 0.75 × 10 is 7.5, and Math.ceil rounds it up to 8.
• Line 5 prints 75th percentile: load 8 of 10, 3400 ms. An array counts from 0, so load 8 is sorted[7].

So 8 of the 10 loads took 3,400 ms or less. Rounding up to a real load like this is the nearest-rank method.

Now take the average of the same ten loads:

1const lcps = [1200, 1400, 1500, 1700, 1900, 2100, 2600, 3400, 5200, 9800];2const average = lcps.reduce((sum, ms) => sum + ms, 0) / lcps.length;3const faster = lcps.filter((ms) => ms < average).length;4 5console.log(`average: ${average} ms`);6console.log(`loads faster than the average: ${faster} of ${lcps.length}`);

• Line 2 adds up all ten times, starting from 0, and divides by 10.
• Line 3 counts the loads that were faster than the average.
• Lines 5 and 6 print average: 3080 ms and loads faster than the average: 7 of 10.

The average is slower than 7 of the 10 loads. Two very slow loads, 5,200 and 9,800 ms, pulled it up, like the bus stuck in the flood. The median, the 5th load, says something else again: 1,900 ms. It looks fine, because it ignores the slower half.

web.dev, Google's guide to web performance, recommends the 75th percentile of page loads, "segmented across mobile and desktop devices." So phones and computers are judged apart, like the city and village buses. Try it on 1,000 made-up loads:

const sorted = [...loads].sort((a, b) => a - b);
const at = (p) => sorted[Math.ceil((p / 100) * sorted.length) - 1];

showLine("average", loads.reduce((sum, ms) => sum + ms, 0) / loads.length);
showLine("median", at(50));
showLine("75th percentile", at(75));
showLine("95th percentile", at(95));

All the loads together have a 75th percentile of 2,490 ms. That's just inside 2.5 seconds, the limit for a good LCP. The phones alone have 2,907 ms: over the limit. Mixed together, the fast computers hid a problem for at least a quarter of the phone loads. That's why Google's tools report phones and computers apart.

Lesson 3.4, Averages lie: reading distributions, goes deeper into these numbers. Lesson 12.5, Segmenting field data, splits real visits into groups.

Benchmarks: the Web Almanac and CrUX

How does the rest of the web do on phones? The Chrome UX Report (CrUX), from lesson 1.2, is Google's public dataset of Core Web Vitals from real Chrome users' visits. The Web Almanac reads it for millions of sites. Lesson 1.2 quoted its latest result: 48% of sites had good Core Web Vitals on phones, and 56% on computers. Each row of this table is one year:

Three findings:

• Phones still trail computers in every year, and most sites still don't pass on phones.
• Popular sites aren't always faster. On phones, 51% of the 1,000 most popular sites passed, but only 37% of the top 100,000.
• Pages after the first do better. On phones, 56% of secondary pages passed, against 45% of home pages. The Web Almanac suggests one reason: files the browser saved on an earlier page can be used again.

Why it matters: if your site passes on phones, it's ahead of about half the web. To see your own site's CrUX numbers, put its address into PageSpeed Insights. CrUX is field data: timings from real visits, like the till in lesson 1.1. Lesson 3.3, Lab data vs field data, compares it with lab tests. Lesson 10.1, The Chrome User Experience Report, covers CrUX in depth. CrUX only counts Chrome users, so lesson 12.2, Field data from every browser, collects your own.

Choose a test setup

Ravi can't test on every phone. But he can test on something close to the 75th percentile visitor: slower than his laptop, but not the slowest there is. Sort each setup by where it falls:

In practice, a setup close to the 75th percentile looks like this:

• A real phone in the Galaxy A24 class, if you can get one. Nothing beats feeling the page in your hand.
• In DevTools, the CPU set to the matched mid-tier phone, and a custom network of 9 Mbps down, 3 Mbps up and a 100 ms round trip.
• Your own visitors' 75th percentile on phones, from CrUX or your own monitoring, to check your guess.

If you build for places where phones and networks are slower, Russell suggests aiming at the 90th or 95th percentile instead. Lesson 9.3, Choosing test conditions, builds a setup step by step.

Common mix-ups

• "Phones are as fast as laptops now." No. The fastest are. But a low-end Android's core is 9 times slower than a recent iPhone's, and cheap phones outsell expensive ones by more than 3 to 1.
• "5G has made networks fast." No. It covers only about half the world, and it needs a newer phone. The 75th percentile connection is 9 Mbps, with a 100 ms round trip.
• "Lighthouse's phone test shows what my slowest visitors get." No. It's one setting, with the CPU only 4 times slower than the computer running it. In the recordings, the low-end setting took 3.4 times as long as Lighthouse's settings.
• "The average load time describes my visitors." No. A few very slow loads pull it up, so it can be slower than most loads. Use percentiles.
• "If all visits together pass, phones pass." No. Fast computers can pull the combined number down. Check phones and computers apart.
• "My analytics show mostly iPhones, so slow phones don't matter." No. Many iPhones in use are old ones. And visitors who gave up on a slow page don't show up in your numbers at all.

Three numbers that describe a set of loads are easy to mix up. Read each row across: the number, what it tells you, and what it hides:

Practice exercises

Answer first, then use the hints.

const iphoneMs = 12;
const phones = [
  { name: "a recent iPhone", slower: 1 },
  { name: "a mid-range Android", slower: 3.5 },
  { name: "a low-end Android", slower: 9 },
];

for (const phone of phones) {
  const ms = iphoneMs * phone.slower;
  console.log(`${phone.name}: ${ms} ms${ms > 50 ? ", a long task" : ""}`);
}

const lcps = [900, 1100, 1200, 1300, 1600, 2000, 2800, 6000];
const sorted = [...lcps].sort((a, b) => a - b);

const place = Math.ceil(0.75 * sorted.length);
console.log(sorted[place - 1]);

const rttMs = 100;
const mbps = 9;
const targetMs = 5000;

const setupMs = 4 * rttMs;
const bytesPerMs = (mbps * 1000000) / 8 / 1000;
const budgetBytes = (targetMs - setupMs) * bytesPerMs;

console.log("time left for bytes:", targetMs - setupMs, "ms");
console.log("budget:", (budgetBytes / 1024 / 1024).toFixed(1), "MiB");

const lcps = [700, 800, 900, 1000, 1100, 2700, 3100, 3700];

function rate(lcps) {
  const typical = lcps.reduce((sum, ms) => sum + ms, 0) / lcps.length;
  return typical <= 2500 ? "good" : "not good";
}

console.log(rate(lcps));

const lcps = [700, 800, 900, 1000, 1100, 2700, 3100, 3700];

function rate(lcps) {
  const sorted = [...lcps].sort((a, b) => a - b);
  const p75 = sorted[Math.ceil(0.75 * sorted.length) - 1];
  return p75 <= 2500 ? "good" : "not good";
}

console.log(rate(lcps));

const mobile = [1900, 2300, 2600, 3200];
const desktop = [700, 800, 900, 1000, 1100, 1200, 1300, 1400];

const p75 = (values) => {
  const sorted = [...values].sort((a, b) => a - b);
  return sorted[Math.ceil(0.75 * sorted.length) - 1];
};

console.log("all visits:", p75([...mobile, ...desktop]));
console.log("mobile:", p75(mobile));
console.log("desktop:", p75(desktop));

Check your understanding

For each question, ask who is in the slowest quarter of visits, and what their CPU and network do to the page.

Key takeaways

• The performance inequality gap is the difference between the devices and networks developers test on and the slower ones most people have.
• Most phones in use are Androids more than two years old. Russell's 75th percentile test phone is a Samsung Galaxy A24 4G.
• On one CPU core, a low-end Android is 9 times slower than a recent iPhone, and a mid-range one more than 3.5 times. The same JavaScript costs the slowest phones the most.
• The 75th percentile connection downloads 9 Mbps, uploads 3 Mbps, and takes 100 ms for a round trip. The same bytes cost some people far more than others.
• The same shop page showed its teas in 564 ms on a fast laptop and 7,628 ms on a low-end setting. Most of the difference was waiting for the network.
• At the 75th percentile, a 3-second page can afford about 2.0 MiB if it's light on JavaScript, and 1.2 MiB if half of it is JavaScript.
• Judge speed at the 75th percentile, with phones and computers apart. The average hides the slow visits, and your analytics miss the people who gave up.

Sources

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

• The Performance Inequality Gap, 2026, Alex Russell.
• Network throttling, the Lighthouse docs.
• NetworkManager.ts, where DevTools defines its network presets, Chrome DevTools source code.
• What's new in DevTools, Chrome 134 (calibrated CPU throttling), Chrome for Developers.
• Facts and Figures 2025: Affordability of ICT services, International Telecommunication Union (ITU).
• Cloudflare Radar, internet quality, Cloudflare.
• Web Vitals, web.dev.
• Defining the Core Web Vitals metrics thresholds, web.dev.
• Performance, Web Almanac 2025, HTTP Archive.
• Chrome UX Report (CrUX), Chrome for Developers.
• Navigator: hardwareConcurrency and deviceMemory, MDN.
• High Resolution Time (performance.now), W3C.

Coming next: Your toolkit and the course project. It sets up the browsers and DevTools settings you'll use for the rest of the course, and takes a first baseline.