The landing page speed checklist: 21 checks before you buy traffic.

Almost every slow landing page is slow for the same reason.

It is the pictures. Not the framework, not the hosting, not the theme — the hero photograph somebody exported straight out of a design tool and dropped in at full size.

A browser will happily download a four-thousand-pixel image and then draw it into a box six hundred pixels wide. It pays for every one of those pixels first. Export at the size the image is displayed, convert to a modern format, and the single largest line item on most pages disappears in an afternoon. This is also the least glamorous work on the page and the reason it keeps not getting done.

The dimensions item is about a different failure. Without a width, a height or an aspect ratio, the browser does not know how much room to leave, so it leaves none — and when the file arrives, everything below it jumps. Visitors experience that as the page moving under their thumb at the exact moment they reached for the button. The fix costs two attributes.

One trap worth naming: lazy loading is an attribute on the image element, and a picture set as a CSS background does not have one. If the page is still heavy after you have been through every visible image, the weight is usually hiding in a stylesheet.

A font can hold your headline hostage.

Typefaces are small files that arrive at exactly the wrong moment: after the HTML, before the text is allowed to appear, on the connection you have the least control over.

Three settings do most of the work. Host the files yourself, so the page is not waiting on somebody else’s server to answer. Subset them to the characters you actually use, because a full family carries alphabets your landing page will never render. And set the display behaviour to swap, so the browser paints in a fallback immediately and replaces it when the real face lands. Swapping looks slightly untidy for a moment; a blank headline looks broken for longer.

Then there is the preload trap. Preloading tells the browser to fetch something with high priority, which is genuinely useful for the one font the first screen needs. Preload six files and you have not prioritised anything — you have just moved six downloads to the front of the queue where they compete with each other and with the image you were trying to speed up. One preload, on the one file, is the whole technique.

The headline should not need JavaScript to become visible.

Everything else in this group follows from that one sentence. The first screen is a promise the page makes before any script has run, and it either arrives in the HTML or it arrives late.

Load the page once with JavaScript switched off. Whatever remains readable is what your slowest visitor sees first — the person on a train, on a three-year-old phone, on a connection that drops one file in ten. If that test leaves you with an empty rectangle where the offer should be, no amount of image optimisation will fix the number the browser reports, because the browser is waiting on the script, not the bytes.

Third-party tags are the other half. Every tag is somebody else’s code running on your critical path, and they compound: an analytics tag, a chat widget, a heatmap, two ad pixels and an embedded video player is six separate opportunities for a page to stop responding. Keep the ones that earn their place, defer them, and load the heaviest after the first interaction rather than before the first paint.

Speed is not only what loads. It is what the visitor has to do next.

A page that renders instantly and then asks for a job title, a company size and a phone number has not saved anybody any time. The form is where a fast page most often stops being fast.

Cut the field count to what you will act on this week. Every field is a small decision taken before the conversion, and fields collected for a segmentation plan nobody has written yet are pure cost. If you genuinely need the extra data, ask for it on the page after the conversion, where the visitor has already committed and answering feels like finishing rather than qualifying.

Then let the browser help. Correct autocomplete hints turn a five-field form into one tap on a phone that already knows the answers; the right input type opens a number pad for a phone number rather than a full keyboard. And test the error state on a slow connection, because the classic mobile failure is not a rejected submission — it is a submission with no visible response, tapped three more times, producing three more records with the same email address.

A narrow browser window is not a phone.

Dragging the desktop window narrow tests the layout and nothing else. It does not test the network, the processor, the keyboard, or a thumb reaching across a screen that is now too tall for one hand.

Check the tap targets on the device. Buttons and links need enough area to hit at speed and enough space between them that the wrong one is not adjacent — a stack of small text links with tight line height is the most common offender, and it is usually the footer nobody looked at.

Horizontal scroll is the other one, and it is always an accident. Something on the page is wider than the screen: a fixed-width image, a table, a long unbroken URL, a negative margin that made sense at desktop width. The symptom is a page that drifts sideways while somebody is trying to scroll down it, which reads as broken rather than as a bug. Load the page at the narrowest common width and try to scroll right; if you can, something is oversized.

Lab data tells you what changed. Field data tells you whether it mattered.

They are different instruments and they disagree constantly, which is not a fault in either one. Knowing which question each answers is most of what people mean by knowing how to measure a page.

A lab run is a simulation: one device, one throttled connection, repeatable. That repeatability is the point — it is the only way to say that a specific change made a specific difference. Run it before you touch anything, keep the result, run it again after. A single lab score in isolation is almost meaningless; the same score either side of one change is evidence.

Field data is the opposite: real visitors, real devices, real networks, collected over time. It is slow, it is noisy, and it is the number that pays, because it describes people who were actually deciding whether to fill in your form. When the two disagree, field data wins and the lab run becomes the tool you use to find out why.

Keep one measurement per failure mode: something that tells you what paints last, something that tells you how much the layout moves after it paints, and something that tells you how long the page takes to answer a first tap. The published Core Web Vitals thresholds are a reasonable target because they are a standard rather than an estimate — check the current definitions rather than trusting a number quoted in an article, including this one.

What you noticed, and where to look for it.

Most speed work starts with a symptom rather than a metric — somebody said the page felt slow, or a report went amber. This table turns that into a place to start.

The last row is the one worth reading twice. A fast page that does not convert is not a performance problem, and no further optimisation will find the answer — the question has moved to what the page says and what it asks for.

A builder removes a class of mistakes. It does not remove your judgement.

This is the one place on the page where the tool you choose genuinely changes the work, so it is worth being precise about which half it changes.

Which means the honest version of the tool question is not “is this builder fast”. It is whether it lets you do the editorial half well: fewer fields because the data you wanted is already on the record, fewer scripts because the tracking is native rather than pasted, fewer embeds because the thing you were embedding lives on the same platform.

That is also the argument against stitching. Every extra product involved in a conversion tends to add a tag to the page — one to capture the lead, one to attribute it, one to sync it somewhere else. The page gets slower in direct proportion to the number of systems that need to be told what just happened.