How a Page Loads

After this lesson you can

• Explain the order in which the browser reads a page and fetches its files
• Measure a page's requests and total size in the Network panel, on a slow connection
• Run a Lighthouse performance report and explain what its score means

Key takeaways

• The browser reads a page's HTML from top to bottom, and asks the server for each file the HTML names when it reaches it.
• Some files are found late. A font is named inside a stylesheet, so the browser can ask for it only after the stylesheet arrives.
• The Network panel lists every request, and its bottom line says how many there were and how much was transferred.
• Throttling to Slow 4G on a phone-sized screen shows a page the way many visitors really get it.
• A Lighthouse score is a lab test on one simulated phone. Read its suggestions, and compare your own page before and after a change.

You finish a page, it looks great on your laptop, and then a friend opens your link on the bus and stares at a white screen for six seconds. Many visitors don't wait that long: they go back and pick another link. Sooner or later someone asks you "why is this page slow?", a client, a boss, or the person grading your project, and this lesson is how you find out. You'll watch a browser load a page file by file, weigh it, slow it down to a phone's connection, and get a second opinion from a tool called Lighthouse.

The page in this chapter belongs to the Movie Night Club, a neighborhood club that shows free films on the wall of a community center every Friday. Its page has a poster for each film, a countdown to showtime, a stylesheet and a font from another site: the same kinds of files almost every page on the web has.

A recipe card, read from the top

Think about cooking from a recipe card you've never seen before. You read it from the top, one line at a time. When a line names something you don't have, such as "2 eggs", you send someone to the store for it and keep reading.

A browser reads a page the same way. The part of the browser that reads the HTML is the HTML parser (to parse is to read something and work out its parts). It reads from the first line to the last and builds the page as it goes. Every time a line names another file, the browser sends a request for it: a message to the server that says "please send me this file". The server's answer, with the file inside, is the response.

Here is a small version of the Movie Night Club page:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Movie Night Club</title>
  <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Bebas+Neue&display=swap">
  <link rel="stylesheet" href="style.css">
  <script src="countdown.js"></script>
</head>
<body>
  <h1>Movie Night Club</h1>
  <p id="countdown">Counting down to Friday...</p>
  <img src="posters/robots-on-roller-skates.jpg" alt="Poster for Robots on Roller Skates">
  <img src="posters/pancake-planet.jpg" alt="Poster for Pancake Planet">
</body>
</html>

Reading it from the top, the browser asks for:

1. The page itself, index.html. Nothing else can start until it arrives, because the browser doesn't know what else the page needs.
2. The font's stylesheet, from fonts.googleapis.com.
3. The club's stylesheet, style.css.
4. The script, countdown.js.
5. The two posters, in the order they appear.

Modern browsers also skim ahead while the parser works, so several downloads run at the same time and finish in a different order from the one they started in. The rule to remember is the recipe card's: a file can't be fetched before something names it.

Some files are found late

One file isn't on that list yet: the font itself. The HTML never names it. It names a stylesheet, and the stylesheet names the font. Here is part of what the font's stylesheet holds:

/* latin */
@font-face {
  font-family: 'Bebas Neue';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/bebasneue/v16/JTUSjIg69CK48gW7PXoo9Wlhyw.woff2) format('woff2');
}

The src line is the font file, and it lives on a different site again, fonts.gstatic.com. It's like a recipe that says "make the sauce from card 12": you only find out the sauce needs basil once you have card 12 in your hand. So the font is one of the last files to arrive, which is why headings sometimes change their look a moment after a page appears. Icons, Stylesheets and Resource Hints, later in this chapter, shows how to warn the browser early.

There's one more request you didn't write. When a page names no icon for its browser tab, the browser asks for /favicon.ico on its own, and if there's no such file the server answers 404, "not found". The same lesson fixes that too.

Watch it in the Network panel

The browser's developer tools show every request as it happens. Open them with F12 (Cmd+Option+I on a Mac) and choose the Network panel. It records only while it's open, so reload the page once it is.

Each row is one request:

• Name: the file.
• Status: the server's answer. 200 means "here it is", 404 means "not found".
• Type: document, stylesheet, script, font, or an image type such as jpeg.
• Size and Time: how big the file was and how long it took.
• Waterfall: a bar for each file showing when it started and finished. Bars that sit side by side downloaded at the same time; a bar that starts late was found late.

The line at the bottom of the panel sums it up. For the full Movie Night Club page, with all six posters, it reads:

12 requests   1.1 MB transferred   1.1 MB resources

• requests: how many files the page asked for.
• transferred: how much came over the network. This is the page's weight, and it's the number a visitor's phone plan pays for.
• resources: the size of the files once unpacked. Servers often compress text files on the way, so this can be bigger than transferred.

Tick Disable cache at the top of the panel, too. The browser keeps copies of files it has already downloaded (its cache) to make a second visit faster, so without the tick you measure a second visit, not a first one.

Firefox's developer tools have the same Network panel. In Safari, first turn on Safari > Settings > Advanced > Show features for web developers, then open Develop > Show Web Inspector.

Slow it down to a phone

Your laptop on home Wi-Fi is not how most people see your page. Many visitors are on a phone, on a connection that's slower than yours. The developer tools can pretend to be one:

• Throttling: the menu near the top of the Network panel that says No throttling. Choose Slow 4G or 3G, and every download slows to match.
• The device toolbar: Ctrl+Shift+M (Cmd+Shift+M on a Mac) shows the page at a phone's size.

Reload, and watch the waterfall stretch out. On the Movie Night Club page you can see where the weight is: the HTML is about 3 kB, and each of the six posters is about 175 kB. Together the posters are almost all of the 1.1 MB. That's typical: pictures are usually the heaviest part of a page, so they're the first place to look when a page is slow.

Try it. Open a news site or a shop you use every week. Open the Network panel, tick Disable cache, choose Slow 4G, and reload. How many requests does it make, and how much does it transfer? Many big sites make more than a hundred requests and weigh several megabytes. Then try your own page and compare.

A Lighthouse report

Lighthouse is a tool built into the developer tools of Chrome and Edge. It loads your page the way a mid-range phone on a slow connection would, times it, and gives it a performance score from 0 to 100.

1. Open the page in a private window (Ctrl+Shift+N in Chrome and Edge, Cmd+Shift+N on a Mac), so browser extensions don't slow it down.
2. Open the developer tools and choose the Lighthouse panel (it may be behind the >> button).
3. Pick Navigation, Mobile and the Performance category, then click Analyze page load.

The full Movie Night Club page, run through Lighthouse 13, came back with:

Performance 77
First Contentful Paint    1.5 s
Largest Contentful Paint  6.2 s
Total Blocking Time       0 ms
Cumulative Layout Shift   0.066
Speed Index               1.5 s

The score's color tells you its band: 90 to 100 is green (good), 50 to 89 orange (needs improvement), and 0 to 49 red (poor). The five measurements under it say what the score is made of. Two to know first: First Contentful Paint is when the first text or picture appears, and Largest Contentful Paint is when the biggest thing on the first screen appears (here, the first poster). Below them is a list of suggestions, each with what it would save. For this page they included Render-blocking requests, Improve image delivery, and image elements without a width and height.

What the score means

The score is a lab test: one simulated phone, on one simulated connection, loading the page once. It isn't a grade, and chasing 100 isn't the goal. Run it twice and it can move a few points with nothing changed. A 100 doesn't promise every visitor a fast page, and a 77 doesn't mean the page is broken.

Use it the way a mechanic uses a diagnostic check: read the suggestions, fix the ones that matter for your page, and run it again. Your own before and after is the comparison that counts, not someone else's score. For a page that's already online, the same report runs at pagespeed.web.dev (PageSpeed Insights), in any browser, including Firefox and Safari, which don't have Lighthouse built in.

Try it. Run Lighthouse on your own page from earlier in the course. Write down its score and the first two suggestions. You'll fix pages like that one in this chapter's exercise.

Check yourself

2 questions to try on the lesson page.

So what

Every slow page you'll ever fix starts the same way: open the Network panel, see what the browser asked for and when, and measure before you change a line. The rest of this chapter is the HTML that changes what you see there.

Key terms

• HTML parser
• Request
• Developer Tools
• Lighthouse

Cheat sheets

• How a Page Loads

Related

• How a Browser Shows a Page
• Developer Tools: Inspecting a Page