Guessing what is slow is how people waste hours. Measure first, fix the biggest problem, measure again.
> The numbers on this page are things you measure yourself. Any timing you see depends on your computer, browser and data, so there are no universal benchmark numbers to quote.
performance.now()
performance.now() gives a high-resolution time in milliseconds. Subtract two readings to time a piece of code.
function sumTo(n) {
let total = 0;
for (let i = 0; i <= n; i++) total += i;
return total;
}
const start = performance.now();
const result = sumTo(1_000_000);
const elapsed = performance.now() - start;
console.log(result); // → 500000500000
console.log(typeof elapsed); // → number
console.log("took", elapsed.toFixed(2), "ms"); // varies on every computer
Run it a few times: the result changes slightly each time, which is normal. For fair comparisons, repeat the test several times and compare averages.
Comparing two approaches
function time(label, fn, runs = 5) {
const times = [];
for (let i = 0; i < runs; i++) {
const t0 = performance.now();
fn();
times.push(performance.now() - t0);
}
const average = times.reduce((a, b) => a + b, 0) / runs;
console.log(label, "average ms:", average.toFixed(2));
}
const data = Array.from({ length: 100000 }, (_, i) => i);
time("for loop", () => { let s = 0; for (let i = 0; i < data.length; i++) s += data[i]; return s; });
time("reduce ", () => data.reduce((a, b) => a + b, 0));
These numbers will differ on every machine, and small differences between ordinary loops almost never matter for real pages.
performance.mark and measure
Named marks and measures show up in the DevTools Performance panel timeline.
performance.mark("start-render");
// ... work ...
performance.mark("end-render");
performance.measure("render", "start-render", "end-render");
const [measure] = performance.getEntriesByName("render");
console.log(measure.name, typeof measure.duration); // → render number
console.time
A quick alternative for debugging: console.time("label") and console.timeEnd("label") print the elapsed time to the console.
The browser’s tools
| Tool | Shows |
|---|---|
| Performance panel | a timeline of everything: scripting, layout, paint, long tasks, frames. Record, interact, stop, and look for long red blocks. |
| Network panel | what is downloaded, how big, how long, in what order (Network Panel) |
| Memory panel | memory use and leaks |
| Lighthouse | an automated audit with scores and suggestions (performance, accessibility and more) |
| Coverage | how much JavaScript and CSS is actually used on a page |
What users feel: Core Web Vitals
Browsers and Google describe loading experience with metrics such as LCP (how soon the main content appears), INP (how quickly the page responds to interaction) and CLS (how much the layout jumps). Lighthouse and the browser’s own tools report them, and they are useful, human-centred targets.
A sensible process
- Define the problem: “Typing in the search box feels laggy”, not “make it faster”.
- Measure with the Performance panel to find where time goes.
- Change one thing at a time.
- Measure again to confirm it helped.
- Stop when it is good enough.
Test where users are
Your laptop is faster than many phones. Use the DevTools options to throttle the CPU and network to see a slower device’s experience.