Good design travels light.

A page can download a large image, several font files, analytics or chat scripts, and code for features a visitor never uses. These assets consume bandwidth and can compete for CPU, connections, and attention. But byte count alone does not reveal the sequence in which the browser discovers, downloads, decodes, and renders each asset. A large image displayed immediately may matter more to LCP than a larger file far below the fold.

Images are a strong first candidate because source dimensions and display size often diverge. Google’s web.dev responsive-image guidance notes that serving desktop-sized files to mobile screens can use 2–4 times more data than needed. That range describes its example guidance, not a universal savings estimate for every site. Use srcset and sizes to offer candidates, compress images at acceptable visual quality, and choose formats appropriate to the content.

The hero or product image may be the LCP element. Make it discoverable in the initial HTML, provide a suitable mobile-size candidate, and avoid lazy-loading it if it appears immediately. Conversely, images below the fold are often candidates for native lazy loading. Set width and height or an aspect ratio so space is reserved before an image arrives; this can prevent layout shifts. Use captions and alt text where they help users understand the image, not as a performance trick.

List third-party tags and ask what each is for, who uses its output, and whether it must run on every page. Remove unused integrations and load noncritical features only when needed. Inspect unused CSS and JavaScript, but don’t delete code solely because it was idle in one initial-load test: it may support a later menu, checkout, or accessibility behavior. Fonts can also add requests and bytes; limit families and weights to those the design uses. Caching repeatable assets can reduce repeated downloads, but set freshness rules so updated files arrive correctly.

Bare Audit’s page-weight panel estimates observed resources from a single mobile Lighthouse run and distinguishes resource types. Its HTML source checks are bounded and do not execute JavaScript. This makes the report useful for identifying candidates, not a complete inventory of every runtime request or every interaction state.

Saving bytes does not guarantee a proportional speed or conversion gain. Network conditions, caching, CPU, image decoding, layout, and other resources all affect the result.