When someone says a website weighs eight megabytes, part of the sentence is missing: which page, on which visit and after doing what? The total may include an opening photograph, videos, a map or images that appear only after scrolling. Eight megabytes is a diagnostic example here, not a measurement from a client.
The first job is to turn that total into a list of choices. Which files help someone understand the business? Which are needed to make contact? Which are being loaded without a clear purpose?
Ask for a list, not just a score
The Network panel in Chrome's developer tools lets you inspect a page's requests, their types, sizes and timings. The Chrome documentation also explains how to empty the cache and reload to observe a first visit.
To compare two versions, keep conditions consistent: the same page, viewport, test network and sequence of actions. Record the opening and, separately, what happens when scrolling or opening a map. A capture without those actions does not describe the whole journey.
Ask the technical owner for a list of the largest requests and what each does. This inspection aims to understand transferred files. It does not replace a complete assessment of loading speed or response to taps, which also depend on work performed by the browser.
For photographs, check the delivered dimensions
A photograph can be well chosen and poorly prepared for the page. Keep the original in your working archive; the published version should suit its display space and required quality. Before lowering quality, check whether unnecessarily large dimensions are being sent.
The documentation on responsive images explains how to offer multiple sizes to the browser. This lets it choose between versions according to display conditions. Confirm those versions in the file the browser actually receives, not just an option selected in the editor.
Compare the result on a phone and a larger screen. Check text inside images, edges, crops and relevant details of the work shown. A smaller file that makes the photograph unsuitable for its purpose does not finish the job.
For video and external services, decide when they are needed
A video introduction, map and online booking serve different purposes. Review each with one question: must this download before someone chooses it? In some cases, a starting image with a button lets you postpone that work until there is interest.
That decision needs a usability check. A deferred map still needs a readable address. A booking needs a clear route and an alternative if the service fails. Reducing requests should not remove what the visitor came to do.
Do not delete code based on its filename
A code or font request may serve several pages and interactions. Identify what depends on it before removing it. Ask for the change to be made in a review copy, with a way to recover the previous version.
Then work through the controls that matter: navigation, language, forms, bookings and contact links. Open an inner page too. The homepage may look intact while a feature on another page stops working.
Close the change with two kinds of evidence
The first is a comparison of requests under the same conditions: what no longer loads, what became smaller and what remains necessary. The second is the visitor's route: reading, choosing and making contact without a new failure.
Do not automatically turn a reduction into sales percentages or Google positions. This work verifies a technical change and whether it functions. For the first-visit experience, also read your website on a customer's phone. If you need to identify what weighs yours down, talk to us.
Documentation checked on 20 September 2026. No client performance measurements were made for this article.