Web Image Evolution: from GIF to AVIF and the Optimal Stack

Images have always been the heaviest element on a web page — and they still are. The difference is that once their weight was an acceptable cost of aesthetics, while today it is one of the main signals by which Google and users judge site quality.

1990s: GIF, JPEG and the dial-up era

The first web pages operated under very tight constraints. GIF, with its 256-colour palette, was the only sensible choice for flat graphics and animations — lossless compression worked well only with a small number of colours. For photographs, JPEG was used, introducing lossy compression and for the first time letting developers consciously trade off quality vs file size.

Responsiveness was not a concept — an image had fixed pixel dimensions, and the only "performance budget" was a user's patience waiting for a page to load over a 56k modem.

PNG and transparency

PNG appeared as an answer to GIF's weaknesses — deeper colour palette, alpha channel, lossless compression. It was a genuine quality leap for UI graphics (icons, buttons, shadows), but higher quality came at the cost of larger files than JPEG. Developers learned their first important lesson: the format must be matched to the content type, not applied universally.

Broadband and CSS sprites (2005–2010)

As DSL and cable internet spread, visual expectations grew — pages became more graphically rich. A new problem appeared: the number of HTTP requests. Every additional image meant another connection, and browsers limited the number of parallel requests per domain. The answer was CSS sprites — combining dozens of small graphics (icons, UI elements) into one file and cutting fragments out via background-position. This was the first serious performance trick unrelated to image quality itself.

Mobile revolution: when one image stopped being enough (2010–2015)

Smartphones and Retina displays turned everything upside down. Suddenly different versions of the same image had to be served depending on pixel density and viewport width. This gave rise to srcset and sizes — letting the browser choose the best file from a set of variants — and the picture element, giving full control over art direction: different image cropping depending on the device, not just scaling.

This was a philosophical shift: we stopped thinking about an image as a single file and began thinking about it as a set of variants chosen contextually.

New compression formats: WebP (2015–2020)

Google introduced WebP in 2010 (based on VP8 video codec technology), offering significantly better compression than JPEG and PNG at comparable quality — for both photos and graphics with transparency, in a single format. WebP became a mainstream topic around 2015–2020 as browser adoption grew: Firefox added support in 2018, and Safari finally followed in 2020. Initially, compatibility was a real problem requiring fallbacks. Today that is largely a non-issue — WebP is widely supported, and its successor has already arrived.

Format comparison

Performance as an SEO factor: Core Web Vitals

The turning point for the whole industry was Google introducing Core Web Vitals as a ranking signal. Images directly affect two of the key metrics:

• LCP (Largest Contentful Paint) — in most cases it is the image that is the largest element rendered on screen, so its loading time determines the score.
• CLS (Cumulative Layout Shift) — lacking defined width and height attributes causes layout "jumping" as the image loads in.

From that moment, image optimisation stopped being an aesthetic question and became part of technical SEO. Native loading="lazy" and automatic image optimisation by CDNs (Cloudinary, Imgix, Cloudflare Images) — which convert and scale images on the fly depending on the client's device — entered the standard.

Where we are today: the optimal stack (2023–2026)

The current recommended standard is not a single format — it is a strategy. Using the picture element, you serve AVIF to browsers that support it, fall back to WebP for broad coverage, and finally to JPEG or PNG for any remaining legacy browsers. Key elements of this approach:

• AVIF as first choice — the best compression of widely available formats, especially for highly complex photos.
• WebP as fallback — wide support, good quality-to-size trade-off where AVIF falls short (e.g. slower server-side encoding).
• JPEG/PNG as the last resort — for browsers that support neither of the modern formats.
• srcset + sizes combined with modern formats — full responsiveness independent of format choice.
• width and height always defined — no longer optional; a requirement for good CLS.
• loading="lazy" for images below the fold — natively supported by browsers without any JavaScript.
• Framework automation — components like next/image or astro:assets generate the whole boilerplate automatically, including the right format and size based on the client's viewport.
• Accessibility — the alt attribute remains mandatory regardless of how advanced the technical stack is.

Practical checklist

• Photos → AVIF/WebP with JPEG fallback
• Flat graphics / icons with transparency → WebP or SVG (if vector)
• Always define width and height on every img element
• Lazy loading for everything below the first screen
• Automatic optimisation via CDN or framework instead of manual export from image editors
• Regular audits via Lighthouse / PageSpeed Insights

Summary

The journey from GIF to AVIF is in practice the journey from "how should it look" to "how should it work while looking good". Each subsequent stage was a response to a specific constraint — bandwidth, screens, ranking algorithms. Today's standard is not a single format, but a flexible strategy for matching format, size and load timing to the user's context. This is a departure from static thinking about images towards a fully adaptive approach — and the next stage of this evolution will likely move towards even greater automation, probably supported by AI on the build-tooling side.