The visible page may be a short service description, while the HTML behind it contains a huge menu, repeated data and large inline assets. Customers see the result of that complexity as waiting or unstable rendering. Search crawlers have their own limits too. A lean document is useful for both, without turning a technical threshold into a design target.

Look at the response, not just the screenshot

Google’s March 31 explanation of its crawling infrastructure describes a current Googlebot fetch limit of 2MB per URL, excluding PDFs. It warns that very large inline payloads can push important information beyond the fetched portion. Most ordinary pages should never need to approach that size in HTML.

The interesting question is what occupies the response. A company page with a few hundred words should not require megabytes of unrelated embedded data. Inspect the delivered document and identify which parts support the page’s actual purpose.

Keep content at the centre of the document

A sensible HTML structure makes the main heading, explanation and important links easy to locate. Metadata and relevant structured information should also have deliberate places. This is a clearer foundation than treating the document as a container for an arbitrary amount of application state.

Imagine a retailer repeating the full category tree and product information inside every response. A customer reading a returns page does not need that entire catalogue embedded before the policy. Separate the genuinely shared navigation from data that belongs to another task.

What occupies the page response?: Document metadata; Navigation and main content; Relevant structured information; Heavy resources loaded separately
Keep the document centred on content instead of letting large inline payloads dominate the response.

External resources still need a budget

Moving large scripts or styles into separate files can reduce document size and support reuse. It does not make their cost disappear. The browser still has to retrieve and process the resources needed for the page, so inspect their purpose and loading behaviour too.

Avoid replacing one oversized document with a chain of unnecessary dependencies. A lightweight page should deliver the content and interactions it needs with as little redundant work as practical. The goal is a better experience, not merely passing under a crawler limit.

Give reusable sections the same scrutiny as individual pages. A small duplication in a header or footer can be repeated across the whole site. Removing an unnecessary shared payload can simplify many routes without changing the information customers actually need.

Put size review into ordinary maintenance

Check representative routes when a theme, plugin or navigation structure changes. Record unexpectedly large responses and trace them to their source. This can reveal duplication that a visual review misses, especially when the page still looks simple.

Lean HTML is a useful engineering discipline because it forces a concrete conversation about what belongs on a page. The result should be easier to deliver, inspect and maintain. Customers benefit when the website spends its effort on the information and actions they actually came to use.