All postsA visitor on a phone does not need a 4096 pixel PNG. Until now Atlas sent it anyway: an upload was stored as it came, and the delivery API handed out that one file. Every brand site then had to build its own image pipeline, or serve the original and live with the cost. The Atlas Image Optimizer fixes that at the source.
What it does
When an image upload finishes, a background job writes a ladder of resized copies next to the original, in the brand's own storage: 480, 768, 1200 and 1920 pixels wide (only the widths smaller than the source), plus the source width itself, capped at 2560. Every width is written twice, as WebP and as AVIF.
The delivery API then adds two fields to the image: srcset, with the WebP candidates, and sources, with AVIF first. The block renderer turns them into a picture element, so the browser takes the format it understands and the width it needs. An image without copies is delivered exactly as before, so nothing breaks for a site that does not know the new fields.
What it saves
We ran the backfill on two brand libraries in production, 327 images in total. Take what a phone with a 390 pixel wide screen at 2x density would download if every image filled the screen. The larger library (300 images, 41.5 MB) shrinks by about 72 percent with WebP and 84 percent with AVIF. The smaller one (27 images) shrinks by more than 90 percent. These are estimates from the stored file sizes, not page measurements.
A concrete case: the product screenshot on the atlascms.id home page is a 4096 pixel PNG of 962 KB. The page now offers a 1200 pixel AVIF of about 20 KB for it, and in a real browser at 1440 pixels wide the picture element picked exactly that file.
Choices we measured
- AVIF against WebP. On four real images at 1200 pixels, AVIF at quality 50 came out 45 to 52 percent smaller than WebP at quality 80, and at 1:1 it looked close to the JPEG at quality 80, with a little less fine texture. We settled on quality 55.
- Encoder speed. AVIF speed 4 was 3 to 10 times slower for less than 5 percent gain. Speed 8 was faster but the files were 30 to 80 percent bigger. Speed 6 is the middle.
- No new infrastructure. The servers we already run can write both formats, so there is no extra service to operate and nothing new to install.
- Cost. An AVIF copy of 1200 to 1920 pixels takes roughly 0.1 to 0.5 seconds on one CPU. The backfill of 327 images finished in a few minutes.
Rules that keep it safe
- A copy is kept only when it is smaller than the original, and an AVIF only when it is smaller than the WebP of the same width. WebP can be larger than a tiny JPEG or PNG, so this matters.
- Photos are turned upright using their EXIF orientation, and no metadata (EXIF, GPS) is copied into a copy.
- Animated files, GIF, SVG and anything above 40 megapixels are delivered as uploaded. A decoded 8192 by 8192 bitmap needs about 256 MB of memory, so the job refuses anything above the cap before it decodes, and raises its own memory limit.
- File names carry a hash of the original and the objects are written with a one year immutable cache header. Replacing a file gives new URLs, and replacing or deleting removes the old copies.
- The job runs inside the brand's context and only touches that brand's storage.
Two things production taught us
Three indexed PNGs of 1920 pixels got no copies. The image library refuses to write a palette image as WebP or AVIF, and the widest rung used the decoded source directly. The original stayed the only delivery, which is safe, but the optimisation was lost for those images. We found it by checking the library after the backfill, not through a test. The fix converts a palette image to full colour first, skips a format that fails instead of failing the whole job, and there is a test for it now.
The second one is about caching. We write a one year header, yet browsers received four hours: the CDN in front of our storage rewrote it. After enabling this on your own stack, send a HEAD request for a real copy and read the header. On our side that is a CDN setting we still have to change.
What it does not do yet
Sizes outside the ladder, smart cropping and on the fly transforms are not part of this. The contract (named widths, stable URLs, a size cap) is built so they can be added later without changing how a site reads images. We have measured bytes and the file the browser chooses, not Core Web Vitals yet.
How to use it
There is nothing to switch on for new uploads. Images that were uploaded earlier get a one time backfill per brand, and a site on the latest Atlas site layer renders the picture element on its own.
If you try it on your own images, tell us what the numbers look like for you.
