You own a large site with thousands of existing JPEG and PNG assets. How do you decide whether converting them to modern formats is worth doing, and how do you keep that decision from becoming a permanent maintenance tax?

## Size the prize before you spend anything The failure mode of format migrations is that they are undertaken because they are obviously good, not because anyone measured what they would return. Before committing engineering time, answer three questions with data: 1. **What fraction of real page weight is imagery?** If your heaviest pages are dominated by scripts, a 40% cut to image bytes moves very little. 2. **Which images, on which pages?** Weight concentrates: a handful of templates and a handful of asset classes usually account for most of the bytes actually shipped. A whole-library sweep is expensive and mostly touches assets nobody requests. 3. **What is the realistic saving on your own content?** Encode a representative sample across your asset classes and measure. Published averages are derived from someone else's images. ## Rank by traffic times bytes The correct priority metric is bytes shipped over a real window — request count multiplied by transferred size — not size on disk and not asset count. This routinely reverses intuition: the enormous press-kit image that three people a month download is worth far less than the moderately sized category thumbnail served on every listing page. Access logs or CDN analytics give you this directly, and it also tells you the long tail that is not worth converting at all. ## Put the honest costs on the other side A new format is not free simply because the encode happens once: - **Encode CPU and wall time**, particularly for the more expensive modern codecs, multiplied by every responsive variant. - **Storage**, again multiplied across variants and formats. One extra format across five widths is five more objects per image. - **Cache fragmentation.** Every additional derivative splits requests across more cache keys, so each one is requested less often and is more likely to be evicted or cold. Beyond some variant count you are trading a smaller file for a colder cache, and the second effect can win. - **The fallback surface.** Someone must keep the legacy path working and must think about it whenever the delivery path changes. That is an ongoing cognitive cost, not a one-off task. - **Review and debugging load.** More formats means more "why does this image look different on that device" investigations. When the saving on an asset class is small, these costs dominate and the correct decision is to leave it alone. Deciding *not* to convert is a legitimate, defensible outcome and worth saying out loud in an interview. ## Decide what you deliberately exclude Write the exclusions down, because they are what keeps the policy from being "everything, forever": - Assets already below a few kilobytes, where fixed format overhead can make the modern encode larger. - Icons and simple marks that should be vector artwork instead. - Screenshots and text-bearing images, unless you have tuned settings specifically for them. - Rarely requested archives, where lifetime bytes saved will never repay the encode. ## Make it a policy, not a migration The maintenance tax comes from treating this as a project with an end date. Instead: - **One place decides format tiers.** Whatever produces or serves images applies the policy; individual teams do not each pick formats for their own pictures, or you get five inconsistent answers and no way to change any of them. - **New assets cannot arrive in the wrong shape.** Enforce at upload or build time. A migration that leaves the intake unguarded refills the library within a year. - **Keep the originals.** All derivatives must be regenerable from source, so a future format is another pass, not another migration. This is the single highest-leverage decision here. - **Encode settings live in one versioned place**, so changing a quality target or adopting a new codec is a config change plus a regeneration, not an archaeology exercise. ## Verify in the field, then decide what is next Lab numbers confirm the encoder worked; only real-user data confirms users benefited. Watch image byte weight and the loading metrics for the affected templates before and after, on real devices and networks. Expect the improvement to be smaller than the byte saving implies — the network is not the only constraint, and a page can be bound by something else entirely. Finally, plan the exit. A legacy fallback should not live forever by default. Decide in advance what evidence would justify dropping it — the share of your own real requests still negotiating it, measured in your own logs rather than global support tables — what the saving would be in storage and complexity, and how quickly you could put it back. A format policy with no retirement criterion is how sites end up serving four encodings of every image a decade later.