An image performance budget is a project limit you define and measure, not a universal maximum size for every photograph. Choose a representative page and device, decide which images matter at initial load, and allocate bytes to those roles. Track the delivered requests so a new hero or product grid cannot silently exceed the agreed target.
Define exactly what the budget counts
Specify whether you count initial image requests, all images after scrolling, transferred bytes or original resource sizes. Record viewport, cache state and network conditions. Otherwise two measurements can disagree while both are correct. Separate third-party images and intentional high-resolution zoom assets when the team needs different rules for them.
Allocate before compressing
Illustrative budget: a team might allow 500 KB for a page image set, with 200 KB reserved for the main image and 300 KB shared by six secondary images. These are planning numbers, not Google thresholds. If one role cannot retain essential detail within its allocation, adjust the design or explicitly reconsider the budget instead of hiding the exception.
Measure the actual variants
Use the browser Network panel to record the candidate delivered to each target layout. A source file in the repository is not necessarily the one selected by srcset or an image CDN. Compare pixel dimensions, content type and transfer size, then optimize the largest overspend through dimensions, format or quality.
Track usability alongside the total
A page can meet its byte budget and still discover the hero too late. It can also load quickly while showing unreadable labels. Track LCP and visual checks separately; the web.dev LCP guide explains why download time is only one part of that metric. Keep a small review log with baseline, change and reason, and remeasure when the template or image pipeline changes.