Why does a few seconds matter so much?
People decide quickly whether a page is worth waiting for. When the bakery’s photo takes ten seconds to appear on a phone, many visitors have already pressed back and tried the supermarket instead. They never see the opening hours or the order button, however good the bread is.
Speed also shapes how a site feels once people stay. A page that shows something useful within a second or two feels calm and trustworthy. A page that stays blank, then lurches as pieces arrive, feels broken even when everything eventually works.
There is a practical side too. Search engines use real-visitor speed as one of many signals when ranking pages, and on a phone every kilobyte costs battery and, for some people, money. A faster page is kinder to everyone, and it is usually simpler as well.
What is actually slow on this page?
Open the Waterfall view. Each row is one file the phone downloads: the HTML page itself, the stylesheet, and the photo. The bars show when each request started and finished, on a shared timeline across the top.
The photo’s bar runs for about nine seconds. The file is 1,800 KB, a 3,000 by 2,000 pixel image straight from a camera. On a phone, this spot is only about 328 CSS pixels wide, which is 656 real pixels on a sharp 2x screen. More than four out of every five pixels in that file are thrown away after the phone has paid to download them.
Everything else is small. The HTML is half a kilobyte and the CSS is 12 KB, and both arrive within about one second. That is the usual pattern on real sites: one or two heavy files cause most of the waiting, and finding them is the first job.
What does the pretend phone measure?
The page loads on a simulated phone with a 4G connection: each trip to the server and back takes 150 milliseconds, and downloads share about 200 KB per second. Those are realistic numbers for a phone on an average mobile network, and they make problems visible that a fast office connection would hide.
Three numbers matter most, and the Vitals view shows them. Largest Contentful Paint (LCP) is when the biggest thing on the first screen appeared, here the photo. Cumulative Layout Shift (CLS) adds up how much visible content jumped around while loading. First Contentful Paint (FCP) is when anything at all first showed up; it is a useful clue, though not one of Google's Core Web Vitals. Later lessons add the third vital, Interaction to Next Paint (INP), for how quickly the page responds to a tap.
The simulator is deterministic: the same files always give the same numbers, so you can see exactly what each change did. A real phone varies from visit to visit, and real measurement tools take that into account. The ideas carry over directly.
Why does the text jump when the photo arrives?
Open the Filmstrip. In the early frames the heading and the opening hours sit near the top of the screen. When the photo finally arrives, they are pushed about 230 pixels down in one go. Someone reading the hours, or about to tap Order bread, suddenly finds it has moved.
That happens because the browser doesn’t know how tall the image will be until the file starts arriving. With no size information, it gives the image zero height and lays out the rest of the page. When the real size becomes known, everything below has to move.
The fix costs nothing: put width and height on the <img>. The browser divides one by the other to get the shape, works out the height at the column’s width, and keeps that space empty from the very first paint. The CSS rule img{max-width:100%;height:auto} still lets the image shrink to fit the phone.
<img src="/img/hero-800.jpg" alt="Loaves cooling on a rack"
width="800" height="533">How much smaller can a photo get without looking worse?
Much smaller than most people expect. The 800 pixel copy is 95 KB, about one nineteenth of the original, and on a phone screen it looks the same. Fewer pixels to store is the biggest saving; better compression and modern formats like WebP and AVIF, which a later lesson covers, cut it further.
A good rule of thumb is to size a photo for the largest space it will ever fill, times two for sharp screens. A photo that spans a phone needs roughly 700 to 800 pixels across. A photo that spans a wide desktop layout might need 1,600 to 2,000. Later lessons show how to offer several sizes and let each device pick.
The bakery’s server already has the smaller file. On your own site you would make it once, with an image editor or an export setting, and upload it next to the original.
Where should you look first on any slow page?
Start with the waterfall and ask two questions: which bars are longest, and what is waiting for them? A long bar for a large file means too many bytes. A row tagged “blocks paint” or “blocks parser” means the screen can’t show anything until that file is done, which slows the page even when the file is small.
Then look at the first screen as a visitor would. What is the largest thing there, and how soon does it appear? That one element decides LCP, so speeding it up helps more than shaving bytes from something further down the page.
Finally, watch the Filmstrip for jumps. Layout shift is often the easiest problem to fix and the most annoying one to leave in, because it makes people tap the wrong thing.
What do real tools show compared with this one?
In Chrome, open DevTools with F12 and the Network panel shows the same kind of waterfall for any real site. Its throttling menu can pretend to be a slower phone. The Lighthouse panel runs a lab test with scores and suggestions, and PageSpeed Insights does the same online, adding real visitor data from the Chrome UX Report when a site has enough traffic.
Those tools measure an actual browser, so their numbers wobble a little between runs and include things this simulator leaves out, such as image decoding time and the work of the browser itself. What they share with this page is the method: find the longest wait on the path to the main content, remove it, and measure again.
What does AI often get wrong about page speed?
Ask an AI assistant to make a page faster and you will often get a long list of generic tips: minify everything, add a CDN, switch frameworks. Some help a little, some not at all, and few are aimed at the actual problem on your page. Here, none of them would fix the 1.8 MB photo.
AI-written pages also commonly leave out width and height on images, use the largest image they were given, and add scripts to the head without defer. Treat its speed advice as ideas to test. Measure before and after each change, keep the ones that move the numbers, and drop the rest.
Field notes
- Visitors leave a page that takes many seconds to show its main content.
- The waterfall shows which file is slow and what is waiting for it.
- A photo sized for the screen can be a small fraction of the original file.
- Giving an image
widthandheightstops the text jumping when it loads.
Easy to get wrong
Shrinking a large image with CSS only changes how it is drawn. The phone still downloads all 1,800 KB. Serve a file that is close to the size it will be shown at.
A smaller file arrives sooner, but without width and height the text still jumps when it does. Give every image its real dimensions so its space is kept from the start.
A fast connection hides exactly the problems your visitors feel. The bakery page looks fine on fibre and takes ten seconds on 4G.
Questions people ask
Do I need to install anything for this course?
No. Every lesson loads its page on a simulated phone inside this page, with nothing sent over the network. On your own sites you would use Chrome DevTools, Lighthouse and PageSpeed Insights, which work the same way.
Is the simulator exactly like a real phone?
No simulator is. It models the network, the order files are found and downloaded, blocking, fonts, layout and the main thread, which are the parts that cause most real slowness. It leaves out decoding, the browser’s own overhead and network wobble, and it lays every page out as a single phone column. The numbers are realistic, and they always move in the same direction a real browser’s would.
What counts as a good score?
Google’s Core Web Vitals call Largest Contentful Paint good at 2.5 seconds or less, layout shift good at 0.1 or less, and Interaction to Next Paint good at 200 milliseconds or less. Real-world scores use the 75th percentile of actual visits, so most visitors need a good experience, including those on slower phones.
Does page speed really affect search rankings?
It is one signal among many. Good content is far more important, but when pages are otherwise similar, a fast one has an edge, and visitors are more likely to stay and use it.