You usually sense that a landing page is slow before you can prove it. The difficulty comes next: ask a developer to “improve the speed” and their first job is deciding what to look at — and a surprising amount of that job you can do for them.
The four checks below need nothing but a browser and your eyes. No code, no server access. When you are done, the request stops being “make it faster” and becomes a list of filenames and domains.
Setup — the network tab is the whole toolkit
Open your browser’s developer tools and go to the Network tab. Reload the page with the cache disabled and every file needed to draw it appears as a list. Two things to do there: sort by size to see the heaviest items, and scan the domain column to separate your own assets from everyone else’s. The total transferred and the request count shown at the bottom are worth writing down — recorded before and after, those two numbers are already a report.
Do this on a mobile profile. Switch on device emulation and apply network throttling, and you are looking at conditions much closer to your actual visitors.
1. Images — find originals larger than they are displayed
This is the most common finding and the easiest to fix. Sort by size and the top of the list is almost always images. For each one, the thing to establish is the gap between the original dimensions and the displayed dimensions. An image shown at 400px wide but stored at 3,000px means visitors are downloading pixels they will never see.
Checking is quick: open the image in a new tab and the browser reports its true pixel size, then hover over the same element in the inspector and it reports the rendered size. Compare the two.
Look at the format while you are there. Photographs saved as PNG are usually heavier than they need to be. For the handover, simply write down filename, original size, displayed size.
2. Third-party scripts — count the domains
Pick out everything in the network list that is not on your own domain: analytics, advertising pixels, chat widgets, font services, testing tools, social buttons. There is a pattern to how that list grows — most of it was added by marketing, one item at a time — which is exactly why marketing is best placed to prune it.
Ask three questions of each entry. Is it still in use? Does anyone actually look at the data? Would anything break without it? Two or three items usually answer no to all three: a pixel left behind after a campaign ended, a heatmap tool used twice, a tag installed by a previous agency.
3. Fonts — count the weights and the files
Count the files ending in .woff2. Fonts covering large character sets are far heavier than Latin-only ones, so every extra weight costs real bytes. It is common to find six weights loading on a page whose design genuinely uses two or three.
What you are checking here is not a technical matter but a design decision. Count the weights the page actually uses, hand the number over, and trimming the rest is something engineering can do from there.
4. Is the hero image lazy-loaded?
This one gets its own section for a reason. Lazy loading is a good technique for images further down the page, but applied to the largest image on the first screen it delays exactly the thing people are waiting for — that image usually determines when the page feels loaded.
To check: inspect the hero image and look for loading="lazy" on the img tag. If it is there, that single attribute is an improvement item. Plenty of plugins and themes apply lazy loading to every image indiscriminately, so this turns up more often than you would expect.
Hand it over as a list
With those four done, the request changes shape. Instead of “the page is slow”, it reads: “the hero background is a 3,000px original displayed at 1,200px; three of our nine third-party domains are tags from finished campaigns; six font weights load and the design uses three; the hero image carries a lazy attribute.” Same request, except the other side can start immediately.
Building a measure-fix-measure loop is covered in the speed and conversion series, and the underlying mechanics live in the performance archive. To get a full reading of a site in one go, try the site diagnostic in our free tools; if the server and caching layers need work as well, that is what the optimization program covers.