A Fast Page

A page that takes five seconds to appear loses a large share of its visitors before they read a word, and the ones who stay are already a little annoyed. Speed is not a finishing touch. It decides whether anyone sees the rest of your work.

The good news for a small site is that most of its speed comes down to three things you already know how to control: images, scripts and fonts. Think of packing for a trip. A suitcase is slow to carry because of a few heavy things, the boots and the hair dryer, not because of the socks. Find the heavy items first and the rest barely matters. After that the comparison runs out, because on the web you can also shrink the boots.

Where Does the Time Go?

Chapter 1 showed that a page is not one download but many: the HTML first, then every stylesheet, script, image and font it mentions, each a separate request. The Network panel in DevTools lists them all. Open it, reload the page, and each request appears as a row with its size and a bar showing when it started and how long it took. That chart of bars is called a waterfall, because each bar starts a little lower and further along than the last.

Two numbers at the bottom of the panel sum it up: how many requests the page made, and how many bytes travelled. For one page of the finished site the list is short: the HTML, one stylesheet, two or three scripts, perhaps the data file, a font and whatever images you added. On a small site like this, one photo can outweigh everything else put together.

Your own computer hides all of this, because it has a fast connection and the files sit on the same machine. To see what a visitor on a phone sees, use the throttling menu at the top of the Network panel to pick a slower network, and tick Disable cache so every file is downloaded again. The waterfall then stretches out, and the heavy rows become obvious.

Why Are Images the Biggest Cost?

A photo straight from a phone camera is about 4000 pixels wide and often weighs several megabytes. On the site it is shown perhaps 800 pixels wide. As Chapter 5 said, making it smaller with CSS changes only how it is drawn: the browser still downloads every one of those pixels.

<!-- About 3 MB: the phone's original file -->
<img src="images/photo.jpg" alt="Your Name at a desk with a laptop"
     width="4000" height="3000">

<!-- About 60 KB and 150 KB: two sizes, in a modern format -->
<img src="images/photo-800.webp"
     srcset="images/photo-800.webp 800w, images/photo-1600.webp 1600w"
     sizes="(min-width: 900px) 800px, 100vw"
     alt="Your Name at a desk with a laptop"
     width="800" height="600">

The first version sends the camera's original file to every visitor. The second offers two copies, 800 and 1600 pixels wide, saved as WebP, the modern image format from Chapter 2, and lets the browser pick the smaller one that is sharp enough for the screen, as Chapter 5 explained. On screen the two look the same. In the Network panel the photo's row drops from megabytes to around a hundred kilobytes, and the long bar in the waterfall shrinks to a short one. The exact sizes depend on the photo; a drop of more than ninety percent is normal.

One more habit from Chapter 5 finishes the job. Images further down the page get loading="lazy", so they download only when the visitor scrolls near them. The first large image, the one visible at once, never does, because making it wait makes the page feel slower.

Do Scripts Slow the Page Down?

They can. An ordinary script in the head stops the browser from reading the rest of the HTML until the script has downloaded and run, so the visitor stares at a blank page. That is why the site's scripts have loaded with defer since Chapter 6, and as modules since Chapter 7: both download in the background while the HTML is read, and run only once the page's structure is complete.

The one exception on the site is js/theme.js, which Chapter 9 put in the head without defer on purpose. It is a few lines long, and running it early is what stops the page flashing the wrong theme. A short blocking script is a fair price for that; a long one never is.

The second rule is plainer: less JavaScript is faster JavaScript. Every script has to be downloaded, read and run on the visitor's device, and a cheap phone does that far more slowly than your laptop. The site's scripts are a few kilobytes in total. Many commercial sites send hundreds of kilobytes before showing a single word.

What Do Fonts Cost?

Each web font is one more file to download, and each weight and style, regular, bold, italic, is usually a separate file. While a font is on its way, most browsers hide the text that uses it for a while, up to three seconds in Chrome and Firefox, rather than show it in another font. On a slow connection the page appears with its words missing.

@font-face {
  font-family: "Inter";
  src: url("../fonts/inter.woff2") format("woff2");
  font-display: swap;
}

This rule declares a web font and adds font-display: swap. The browser now shows the text at once in the next font in your list, then swaps in the web font when it arrives. The visitor can start reading immediately; the only cost is a small change in the look of the text a moment later.

The cheapest font is the one already on the device. The site's --font-body token already relies on such fonts, through the system font stack from Chapter 3. Its first entry, system-ui, is the operating system's own interface font: no download, no delay, and it looks at home on every device.

How Do You Measure Speed?

Lighthouse, the testing tool in Chrome DevTools that Chapter 12 used for accessibility, measures speed too. In its panel, tick the Performance category, press Analyze page load, and it loads your page on a simulated slow phone and connection, then reports a score out of 100, a handful of timings and a list of suggestions, each with the time it would save.

Google also defines three measurements of what visitors actually experience, called the Core Web Vitals. Largest Contentful Paint is how long the biggest piece of content, usually the main image or heading, takes to appear; 2.5 seconds or less counts as good. Interaction to Next Paint is how quickly the page responds visibly after a click, a tap or a key press; 200 milliseconds or less is good. Cumulative Layout Shift measures how much visible content moves unexpectedly, most often while the page loads; 0.1 or less is good.

Layout shift is where Chapter 2 pays off. An image without width and height takes no space until it arrives, then pushes everything below it down, often at the moment the visitor goes to tap a link. With both attributes set, the browser reserves the right box from the start and nothing moves.

Run Lighthouse on a page that still has the phone's original photo and Largest Contentful Paint is the timing in red, with the photo named as the element it waited for. Swap in the resized version, run it again, and that timing drops sharply, usually into the green. Of everything on this page, that one change tends to move the score the most. Lighthouse loads the page without touching it, so it cannot time a real click; it reports a related number called Total Blocking Time instead.