The navigation timeline

From the address bar to the first paint

You type completefrontend.com and press Enter. About a third of a second later, words appear on the screen. It feels like one step. It isn't. In that third of a second, the browser did about ten separate jobs, one after another, like runners in a relay. Each runner has to finish before the next one can start.

The good news: the browser keeps a stopwatch running the whole time. Each time one job ends and the next begins, it writes down the time. You can read those notes from JavaScript. This lesson follows one real visit, job by job, and reads the stopwatch at every step.

Here are three of the times Chrome wrote down when the course visited completefrontend.com for the first time:

1// The first visit to completefrontend.com, as Chrome wrote it down.2// Every time is in milliseconds (ms) after the visit started.3const visit = { requestStart: 83.9, responseStart: 104.5, loadEventEnd: 309.8 };4 5console.log(`The browser asked for the page at ${visit.requestStart} ms.`);6console.log(`The first piece of the page came back at ${visit.responseStart} ms.`);7console.log(`The page finished loading at ${visit.loadEventEnd} ms.`);

• Lines 1 and 2 are comments. Every time is counted in milliseconds (ms) from the moment the visit started. A millisecond is a thousandth of a second, so 309.8 ms is about a third of a second.
• Line 3 holds three times Chrome recorded. The names come from the browser: requestStart, responseStart and loadEventEnd.
• Lines 5 to 7 print them: The browser asked for the page at 83.9 ms., The first piece of the page came back at 104.5 ms. and The page finished loading at 309.8 ms.

Look at the first line again. The browser didn't even ask for the page until 83.9 ms had passed. What was it doing all that time? And once the first piece arrived, why did it take another 200 ms to finish? The rest of this lesson answers both questions. Here is the whole visit at once, each job as one bar:

Where does this list of times live? Each page has one navigation entry: an object the browser fills in as the page loads. You get it with performance.getEntriesByType("navigation")[0]. Its type is called PerformanceNavigationTiming, after the standard that defines it, Navigation Timing. The jobs fall into four stages:

• Before the request: leave the old page, follow any redirects, start a service worker, and check the browser's own cache.
• The connection: find the server's address, open a line to it, and make the line private.
• The request and response: ask for the page, wait for the server, and download the HTML.
• The document: read the HTML, run scripts, load images, and paint.

The next four sections take one stage each. For the same story without a stopwatch, see From URL to pixels. For the events a page fires while it loads, see Page & resource loading.

Unload, redirect, and service worker phases

Three things can happen before the browser asks a server for anything. Most visits skip at least one of them. When a job is skipped, its times are 0.

Leaving the old page

If you were already looking at a page, the browser has to let it go. Just before it does, it fires an unload event on the old page. That's the old page's last chance to run code. The new page's navigation entry records when it happened, in unloadEventStart and unloadEventEnd.

There's a catch. You only see these times if the old page was on the same origin as the new one. An origin is the scheme, host and port together, like https://completefrontend.com. If you came from a search engine, both times are 0. The browser hides them, so one site can't learn anything about another. The course went from the home page to /web-performance in the same tab:

1// Going from the home page to /web-performance, in the same tab.2const visit = { responseStart: 30.1, unloadEventStart: 37.3 };3 4console.log(`The new page's first byte came at ${visit.responseStart} ms.`);5console.log(`The old page's unload started at ${visit.unloadEventStart} ms.`);

• Line 2 holds two times recorded in the new page's entry.
• Line 4 prints The new page's first byte came at 30.1 ms.
• Line 5 prints The old page's unload started at 37.3 ms.

Notice the order. The old page's unload ran after the new page's first byte had arrived. The browser didn't throw the old page away the moment you clicked. It kept it on screen until the new page had started arriving, so you never stare at an empty window. It's like a TV that keeps showing the old channel until the new one has a picture.

One warning about unload. Chrome's team calls it "extremely unreliable". On phones it often doesn't run at all, because tabs are put in the background and then closed. The exercises ask what to use instead.

Following a redirect

A redirect is that sign. The browser asks for one address, and the server answers "it lives somewhere else now", with a status code like 301 and the new address. Then the browser asks again. Everything the first ask cost counts as the redirect: finding the server, connecting, asking, and reading the answer. Navigation Timing times it from redirectStart to redirectEnd.

Like unload, a redirect is only reported when it stayed on the same origin. If any step went through another origin, both times are 0. This site sends /web-performance/, with a slash at the end, to /web-performance, without one. The course timed it:

1// A visit to /web-performance/ (with a slash at the end).2// The server answered: "this page lives at /web-performance now".3const visit = { redirectStart: 0.3, redirectEnd: 274.9, requestStart: 276.5, responseStart: 300.1 };4 5const redirect = visit.redirectEnd - visit.redirectStart;6const realRequest = visit.responseStart - visit.requestStart;7console.log(`Following the redirect: ${redirect.toFixed(1)} ms`);8console.log(`The real request, once it left: ${realRequest.toFixed(1)} ms`);

• Lines 1 and 2 say what happened: the browser asked for the address with the slash, and was sent to the one without.
• Line 3 holds four recorded times.
• Line 5 subtracts the redirect's start from its end. Line 6 does the same for the real request: from the moment it left to its first byte.
• It prints Following the redirect: 274.6 ms and The real request, once it left: 23.6 ms.

The real request took about 24 ms. The detour took more than ten times as long. It was a whole trip of its own: finding the server, connecting, asking, and getting the sign back. This picture shows the two trips, one after the other:

Links that point straight at the final address never meet the sign, so they skip the detour.

Asking a service worker

A service worker is a small script a site can install in your browser. It sits between the page and the network. When the page asks for something, the service worker gets the first chance to answer, often from files it saved earlier. It's like a receptionist who answers some questions from their own notes, without phoning the office.

If a site has one, the browser has to start the service worker, or wake it up, before the request. workerStart marks that moment. On sites without a service worker, it's 0. The course timed a page on its own computer whose service worker answered it:

1// A page whose service worker answered it, on the course's own computer.2const visit = { workerStart: 1.1, fetchStart: 1.2, responseStart: 3.6 };3 4console.log(`The service worker started its work at ${visit.workerStart} ms.`);5console.log(`The fetch began at ${visit.fetchStart} ms.`);6console.log(`The first byte came at ${visit.responseStart} ms.`);

• Line 2 holds three recorded times.
• It prints The service worker started its work at 1.1 ms., The fetch began at 1.2 ms. and The first byte came at 3.6 ms.

The service worker started just before the fetch and answered in a few milliseconds, with no network at all. Starting a worker that isn't running yet takes time of its own, and that time also comes before the first byte.

Here are all four recorded visits side by side. Pick one to see which jobs it did, and which it skipped:

Cache lookup, DNS, connect, and TLS

Now the browser starts fetching for real. That moment is called fetchStart.

The first thing it does costs almost nothing. It looks in its own HTTP cache, a store of files it kept from earlier visits. If a fresh copy of the page is there, it can skip the network completely. The look ends at domainLookupStart.

If the page isn't in the cache, the browser has to reach the server. On a first visit, that takes three jobs. They're easier to picture as a phone call:

• DNS turns a name like completefrontend.com into an IP address, the number computers use to find each other. It runs from domainLookupStart to domainLookupEnd. DNS lookups covers it in depth.
• TCP opens a connection. The browser and the server greet each other before any page data flows. It runs from connectStart to secureConnectionStart. See TCP connections and slow start.
• TLS sets up encryption, so nobody in between can read the page. It runs from secureConnectionStart to connectEnd. See TLS without the wait.

Here is the first visit again, with the cache check and all three jobs:

1// The first visit to completefrontend.com. Nothing was open yet.2const visit = {3  fetchStart: 0.8,4  domainLookupStart: 1.3,5  domainLookupEnd: 26,6  connectStart: 26,7  secureConnectionStart: 45.6,8  connectEnd: 83.8,9};10 11console.log(`Checking the cache: ${(visit.domainLookupStart - visit.fetchStart).toFixed(1)} ms`);12console.log(`DNS, finding the address: ${(visit.domainLookupEnd - visit.domainLookupStart).toFixed(1)} ms`);13console.log(`TCP, opening the line: ${(visit.secureConnectionStart - visit.connectStart).toFixed(1)} ms`);14console.log(`TLS, agreeing on a secret code: ${(visit.connectEnd - visit.secureConnectionStart).toFixed(1)} ms`);

• Lines 2 to 9 hold six recorded times, in the order they happened.
• Each of lines 11 to 14 subtracts one start time from one end time.
• It prints Checking the cache: 0.5 ms, DNS, finding the address: 24.7 ms, TCP, opening the line: 19.6 ms and TLS, agreeing on a secret code: 38.2 ms.

Add them up, and 83 ms had passed before the browser could say a single word to the server. That's the answer to the first question of this lesson.

Now the good part. If you call the same shop again a minute later and the line is still open, you skip the lookup and the dialling. Browsers do the same. They keep connections open for a while and use them again. Here is the next page on the same site:

1// The next page on the same site, a moment later.2const visit = { fetchStart: 0.2, connectEnd: 0.2, requestStart: 0.6 };3 4console.log(`Setting up a connection: ${(visit.connectEnd - visit.fetchStart).toFixed(1)} ms`);5console.log(`The request left at ${visit.requestStart} ms.`);

• Line 2 holds three recorded times. fetchStart and connectEnd are the same: no time passed between them.
• It prints Setting up a connection: 0.0 ms and The request left at 0.6 ms.

When a connection is reused, every DNS and connection time equals fetchStart, so each job shows 0. The browser used the first page's connection again, which by then spoke HTTP/3, and sent the request almost at once.

Request, response, and the first byte

The line is open. At requestStart, the browser sends its request: "please send me this page". Then it waits while the server finds or builds the page. The moment the first byte of the answer arrives is responseStart. The moment the last byte arrives is responseEnd.

Time to First Byte, or TTFB, counts the same way. web.dev defines it as "the time between starting navigating to a page and when the first byte of a response begins to arrive." So it holds everything before the request too, not just the server. It says most sites "should strive to have a TTFB of 0.8 seconds or less." The supporting metrics introduced TTFB; here you can take it apart:

1// The first visit to completefrontend.com again.2const visit = { startTime: 0, requestStart: 83.9, responseStart: 104.5, responseEnd: 161.3 };3 4console.log(`TTFB: ${visit.responseStart - visit.startTime} ms`);5console.log(`The server's own part: ${(visit.responseStart - visit.requestStart).toFixed(1)} ms`);6console.log(`Downloading the rest of the HTML: ${(visit.responseEnd - visit.responseStart).toFixed(1)} ms`);

• Line 2 holds the first visit's request and response times.
• Line 4 is TTFB: the first byte, counted from the start. It prints TTFB: 104.5 ms.
• Line 5 is the server's own part, from the request leaving to the first byte. It prints The server's own part: 20.6 ms.
• Line 6 is the download of the rest. It prints Downloading the rest of the HTML: 56.8 ms.

The kitchen took about 20 ms. The other 84 ms of the TTFB went on getting to the counter: the cache check, DNS, TCP and TLS. So a slow TTFB doesn't always mean a slow server. Subtract first, and you'll know which part to fix.

Parsing to first paint

The HTML is arriving. The browser doesn't wait for all of it. It starts reading as soon as the first bytes come in. Reading the HTML and building the page's tree of elements, the DOM, is called parsing.

Three timestamps mark how far the document has got:

• domInteractive: the browser has finished reading the HTML.
• DOMContentLoaded: an event that fires next, once any deferred scripts have run. Its times are domContentLoadedEventStart and domContentLoadedEventEnd.
• load: an event that fires when images, styles and other files have arrived too. It ends at loadEventEnd.

Painting isn't on this list. The moment the first text or image appears on screen is the first contentful paint, and it comes from a different API, Paint Timing. Here are the first visit's milestones, in time order:

1// The first visit again: each milestone, and the time it happened.2const milestones = [3  { what: "the last byte of the HTML arrived", ms: 161.3 },4  { what: "the browser finished reading the HTML", ms: 258.7 },5  { what: "DOMContentLoaded finished", ms: 258.7 },6  { what: "the load event finished", ms: 309.8 },7  { what: "the first text or image was painted", ms: 332 },8];9 10for (const { what, ms } of milestones.sort((a, b) => a.ms - b.ms)) console.log(`${ms} ms: ${what}`);

• Lines 3 to 7 list five milestones with their recorded times. The first four come from the navigation entry, the last one from Paint Timing.
• Line 10 sorts them by time and prints one per line.
• It prints 161.3 ms: the last byte of the HTML arrived and 258.7 ms: the browser finished reading the HTML. Then 258.7 ms: DOMContentLoaded finished, 309.8 ms: the load event finished and 332 ms: the first text or image was painted.

On this small page, the first paint came just after the load event. On a page with big images, it would come long before, the way your friend sees the bookcase before the books are in. The two aren't tied together, so the course always measures paints separately from load.

The Navigation Timing diagram

You've now met every job. The Navigation Timing standard draws them all on one diagram, left to right, in the order they happen. Here it is, folded into the four stages:

Chrome's DevTools show the same jobs for any request. Open the Network panel, click the page's request, and open the Timing tab. The names are a little different. Read this table across: each row is one job, its Navigation Timing times, and its name in DevTools.

To read the times for any page, call performance.getEntriesByType("navigation"). An older object, performance.timing, still exists, but the standard lists it as obsolete. Try the new one on this very page:

1const [entry] = performance.getEntriesByType("navigation");2 3const phases = [4  ["DNS", entry.domainLookupStart, entry.domainLookupEnd],5  ["connection", entry.connectStart, entry.connectEnd],6  ["waiting", entry.requestStart, entry.responseStart],7  ["download", entry.responseStart, entry.responseEnd],8  ["to load", entry.responseEnd, entry.loadEventEnd],9];10for (const [name, start, end] of phases) console.log(name, start, end - start);

Lines 3 to 9 of the panel's code pick a start time and an end time for each job. The last line prints how long each took.

Which phase?

Each problem below slows down one stage of a visit. Sort it into the stage it slows:

Common mix-ups

• "TTFB is the server's time." No. It counts everything from the start of the visit to the first byte. On the first visit, the server's part was 20.6 of the 104.5 ms.
• "domInteractive means the user can use the page." No. It means the browser finished reading the HTML. Scripts may still be running, and nothing may be painted yet.
• "The load event is when the user sees the page." No. Painting has its own clock. It can come before load or after it.
• "A zero means the job was instant." No. It can also mean hidden (an unload or redirect on another origin), skipped (no service worker), or reused (a connection that was already open).
• "unload is a safe place to send analytics." No. On phones it often doesn't run at all.
• "performance.timing is the API to use." No. The standard lists it as obsolete. Use the navigation entry.

Practice exercises

Answer first, then use the hints.

// The first visit to completefrontend.com again.
const visit = { startTime: 0, requestStart: 83.9, responseStart: 504.5, responseEnd: 561.3 };

console.log(`TTFB: ${visit.responseStart - visit.startTime} ms`);
console.log(`The server's own part: ${(visit.responseStart - visit.requestStart).toFixed(1)} ms`);
console.log(`Downloading the rest of the HTML: ${(visit.responseEnd - visit.responseStart).toFixed(1)} ms`);

// The first visit again: each milestone, and the time it happened.
const milestones = [
  { what: "the last byte of the HTML arrived", ms: 161.3 },
  { what: "the browser finished reading the HTML", ms: 258.7 },
  { what: "DOMContentLoaded finished", ms: 258.7 },
  { what: "the load event finished", ms: 309.8 },
  { what: "the first text or image was painted", ms: 200 },
];

for (const { what, ms } of milestones.sort((a, b) => a.ms - b.ms)) console.log(`${ms} ms: ${what}`);

// A visit that a different site redirected here.
// The server answered: "this page lives at /web-performance now".
const visit = { redirectStart: 0, redirectEnd: 0, requestStart: 276.5, responseStart: 300.1 };

const redirect = visit.redirectEnd - visit.redirectStart;
const realRequest = visit.responseStart - visit.requestStart;
console.log(`Following the redirect: ${redirect.toFixed(1)} ms`);
console.log(`The real request, once it left: ${realRequest.toFixed(1)} ms`);

Check your understanding

For each question, ask yourself which job it's about, and which two times mark its start and end.

Key takeaways

• Loading a page is a chain of jobs: before the request, the connection, the request and response, then the document.
• Each job is the gap between two times in the navigation entry. Subtract them to find where the time went.
• A zero can mean instant, skipped, hidden, or reused. Unload and redirects on another origin are hidden.
• TTFB counts everything before the first byte, not just the server.
• Painting has its own clock, separate from DOMContentLoaded and load.

Sources

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

• Navigation Timing Level 2, W3C.
• Deprecating the unload event, Chrome for Developers.
• Time to First Byte (TTFB), web.dev.
• PerformanceNavigationTiming, MDN.
• PerformancePaintTiming, MDN.
• RequestTimingView.ts: the Network panel's Timing tab, Chrome DevTools source.

Coming next: HTML parsing and the preload scanner. While the browser reads the HTML, a second reader runs ahead to start fetching files early. You'll see what it finds, and what hides files from it.