Learning on Web Dev Open is free for all.

Take It Apart > What the browser actually doesRead your own traffic
Phase 01What the browser actually does33 of 434

Read your own traffic

Open the Network panel on the site you shipped in Phase 00 and account for every single request. There will be more of them than you expect, and at least one you cannot explain.

Build25 minAI off

Open your deployed site in a new tab. Open DevTools, go to the Network panel, tick "Disable cache", and reload. What you are looking at is every byte a stranger downloads to see your page.

Before you read anything: write down your guess. How many requests do you think there are? How many kilobytes in total? Many people under-guesses both, usually by a factor of two or three, and that gap gives you a much better sense of what the page is really loading.

Now work through it. Sort by size and note the largest resource. Sort by time and note the slowest. They are usually different files, and understanding why, a large file on a fast connection versus a small file behind a slow third-party server, is most of what waterfall reading is.

Then go hunting. Look for a request you cannot account for: a font weight you do not use, an analytics script you forgot you added, a favicon variant, a source map shipped to production, a Google Fonts stylesheet pulling in four families when your page uses one. Every site has at least one. Find yours.

Finally, click the largest request and read its Headers tab in full. Find Content-Encoding, is it compressed? Find Cache-Control, what did your host decide on your behalf? You read about these in the last chapter; this is where they stop being trivia.

Write the results in a file called network-audit.md in your project repo. It is the first artifact of this phase and you will refer back to it when you rebuild the page by hand in lesson seven.

Done when

  • A written prediction, made before opening the panel, of request count and total transfer
  • The actual numbers next to it
  • The largest resource and the slowest resource both named, with a sentence on why they differ
  • At least one request identified that the page does not need, with a note on where it came from
  • The Cache-Control and Content-Encoding values your host set, quoted exactly

Nobody marks this for you. It goes into your phase checkpoint, where a person does.

Build this in your own editor

This one runs on your machine rather than in the browser workbench. Work to the outcomes below, then come back and mark it complete.

Worth reading

You should now be able to

  • Account for every request a page makes
  • Find the largest resource and the slowest one, and know they are rarely the same
  • Identify a request nothing on the page needs
  • Read a waterfall well enough to say what is blocking what
Ask the community

Loading…