Image formats: AVIF and WebP.
AVIF and WebP are modern image formats that deliver the same visual quality in markedly smaller files than JPEG and PNG.
On most sites images take the largest share of total page weight, and most of that share is unnecessary. The format choice alone can halve the file size — without sacrificing visual quality and without requiring any design change.
Both formats enjoy wide browser support and both offer lossy compression. AVIF usually produces the smaller file but encodes more slowly; WebP is slightly larger but faster to produce and works in older browsers too.
Serving with fallbacks
The right approach is not picking a single format but offering the browser the options and letting it take the best. An image element can declare multiple sources, and the browser downloads the first format it supports; it never requests the ones it does not.
The order matters: the smallest and newest format on top, the most widely supported at the bottom. The modern browser takes the smallest file, the old browser takes a working file, and neither downloads anything needlessly.
On this site the showcase images are served exactly this way: three widths and two formats are produced for every project. The verification suite measures on every run that the three AVIF files at the largest width together stay under 200 kilobytes — the format choice is not a preference but a budget bound to a test.
Responsive sizes
The second decision, as important as the format, is size: sending the desktop image to a phone is the most common waste and burns mobile users’ bandwidth directly. An image element can declare different files for different widths, and the browser picks the appropriate one by screen size and pixel density.
For the pick to be right, the browser must be told the image’s size in the layout — because it cannot know that before downloading the CSS, and it wants to request the image early. Without that information the browser assumes the worst case and downloads a larger file than needed.
- How many widths to produce — usually three suffice: mobile, tablet, desktop.
- Which widths — derived from the layout’s real breakpoints, not from round numbers.
- Pixel density — extra widths for high-density screens; but not without limit.
- The size declaration — the browser must be told how many pixels the image will occupy in the layout.
- Width and height — independent of file selection, always written, for layout shift.
Compression quality
In lossy formats the quality setting works on a curve, and past a certain point of the curve the file grows but the visible quality does not. Finding that point is done by comparison, not by eye: the same image is produced at different quality settings, placed side by side, and the last point where the difference is visible is chosen.
Photographs and graphics behave differently. A photograph tolerates lossy compression well because it already carries continuous tonal transitions. Sharp-edged graphics and images containing text degrade visibly at low quality settings — for those, a lossless format or a vector should be preferred.
An image containing text is a wrong decision whatever its format — text must be written as text.
The rule in that last line reaches past performance: text baked into an image is read by no screen reader, indexed by no search engine, and cannot be enlarged by the user. The question to ask before any format debate is whether there is text in that image.
Production must be automated
Three widths and two formats mean six files per image. Producing that by hand is unsustainable: adding one image takes six steps, and when one step is forgotten the defect ships silently. The lasting fix is producing the derivatives with a tool.
On this site the showcase images come from a build script: the source image is placed once, the script produces three widths and two formats and reports the sizes. When a new project is added, the only thing to do is run the script.
Automation’s second benefit is measurement: the tool can weigh its own output and warn when the budget is exceeded. In manual production that check falls to human attention, and human attention scatters after the third image.
And a maintenance note: the source image must always be kept. Producing a derivative from a derivative accumulates quality loss; with the source in place, everything can be regenerated from scratch and losslessly when the format changes or a new width is needed.
Vectors and icons
For some images the right answer is no lossy format at all: logos, icons, diagrams and sharp-edged graphics should be served as vectors. Vector files are size-independent — the same file serves as a small icon and a large print — and they are usually smaller than a lossy counterpart.
The vector’s second advantage is being stylable: its color can change via CSS, it can adapt to a dark theme, and it can be animated. Serving an icon set as raster files means losing that flexibility from the start.
A warning: vector files coming out of design tools usually carry needless metadata and redundancy. A cleanup step lowers the file size markedly, and that step can be automated.
On this site the icon family and the monogram are built with this logic; favicon production is bound to a tool, and the real glyph is drawn on a browser canvas — so the glyph comes out identical on every machine. Design consistency is tied to a production decision.
And a maintenance reminder: format support widens over time. A format that needs a fallback today can become sufficient on its own within a few years, and at that point the fallback files become dead weight. If the production chain reads which formats to produce from a single place, that transition is a one-line change; fallback lists written by hand into every page have to be cleaned one by one.
One last measurement habit: after every image derivative is produced, its size should be reported and bound to a budget. On this site the showcase image budget is defined over the total of the three files at the largest width, and the verification suite measures it on every run. When an image is refreshed and accidentally arrives uncompressed, the defect shows at deployment time — not at the next audit.