How to reduce page weight and optimize images for faster loading?

resource-optimization-needed page

The issue

A heavy page loads acceptably on a fast connection and slowly on a slow one, and visitors on the slow one wait for every byte before the page is usable. Images are usually the largest part of that weight. An oversized hero image alone can hold back LCP however fast the server is.

The cause is resources sent in a larger form than the page needs: images in older formats or larger than they are displayed, images below the first screen loaded straight away, and responses sent without compression. Each one adds weight to every visit.

Scope

Each page has its own weight, made up of everything it loads, including third-party scripts and fonts. Templates share assets, so one oversized image or uncompressed script in a template adds weight to every page built from it.

How to check you have it

• In probeo: each page lists its total bytes and resources, by content type and by host, and the images to fix: any over 200 KB, and any in an older format (JPEG, PNG, GIF, BMP or TIFF). The site view sorts pages into weight bands and lists the 20 heaviest.
• By hand: in Chrome DevTools, reload with the Network panel open, sort by size, and filter to images. The footer shows the total transferred.
• With a tool: PageSpeed Insights lists oversized and legacy-format images in its Lighthouse audits.

Weight by connection

The same weight takes very different times to transfer depending on the connection. Using the bandwidth of probeo’s four network profiles, transfer alone, before any round trips, parsing or rendering, takes:

The right budget depends on who visits. A page read mostly on phones over mobile networks should be judged by the slow rows.

FAQ

How does page weight relate to Core Web Vitals scores?

Page weight affects Core Web Vitals indirectly through resource delivery time. LCP measures when the largest visible element renders. If that element is an unoptimized image, the image transfer time directly delays LCP. CLS can be affected when images load without dimension attributes and shift layout. FCP depends on the critical rendering path, which heavy stylesheets and blocking scripts extend. Reducing page weight does not guarantee better CWV scores, but excessive page weight makes good scores impossible on slower connections.

Should all images use WebP or AVIF?

Format selection depends on content type and browser support. WebP is supported by all current major browsers and is a reasonable default for photographs. AVIF usually compresses further, but takes longer to encode. SVG remains better for icons, logos, and simple graphics. PNG remains necessary for images requiring transparency without lossy compression. The goal is to use the most efficient format that the target browsers support and the content allows.

What is the performance difference between lazy loading and eager loading?

Eager loading requests all images immediately when the HTML is parsed. Lazy loading defers image requests until the browser estimates the image is approaching the viewport. For a page with 20 images where 4 are above the fold, eager loading requests all 20 simultaneously. Lazy loading requests 4 immediately and defers the remaining 16. This reduces initial page weight by the total size of deferred images and frees bandwidth for critical resources. The tradeoff is that aggressively lazy-loaded images near the fold may appear briefly blank during fast scrolling.

Does page weight affect search engine crawling?

For most sites, no. Google describes crawl budget as a concern mainly for very large sites or sites whose pages change very often. On those sites, how quickly the server responds affects how much Google crawls, so slow, heavy responses can mean fewer pages crawled.

How do third-party scripts affect page weight?

Third-party scripts, including analytics, tag managers, chat widgets, and ad platforms, contribute to total page weight but are not directly controlled by the site owner. A tag manager can load several more scripts after it runs, and these often load additional resources after execution, increasing total page weight beyond what the initial transfer reveals. Auditing third-party contribution requires measuring total transfer size including all dynamically loaded resources, not just the initial HTML payload.

Is there a universal page weight budget?

There is no single correct page weight. The appropriate threshold depends on the page’s audience connection profile, content requirements, and performance targets. A documentation page should aim for under 500 KB. A media-rich product page may reasonably reach 2 MB. A data dashboard serving enterprise desktops on corporate networks can tolerate more. The budget should be set based on the slowest connection in the target audience, not the fastest. Performance budgets are useful when they are specific, measured continuously, and enforced during development rather than treated as aspirational targets.