Image loading optimisation for mobile traffic: WebP, AVIF and lazy load
Images are typically two thirds of page weight. On unstable mobile connections that is the difference between a page view and a bounce back to the SERP.
Formats: what to choose in 2026
WebP is supported by every current browser and cuts roughly a quarter to a third of JPEG weight at comparable quality. It is the safe default for photography and graphics.
AVIF compresses further, especially on photographs, but encoding is noticeably slower and support in older browsers and some embedded webviews is weaker. The optimal scheme serves AVIF where supported with WebP and JPEG fallbacks.
Implement it with a picture element and multiple sources: AVIF first, then WebP, then a plain img with JPEG. The browser picks the first supported option; no JavaScript is required.
Dimensions and responsive delivery
The most common mistake is serving one 2000-pixel-wide image to every device. A phone renders it at 360 CSS pixels while the user pays for the full download.
The fix is srcset with several width variants plus sizes describing how wide the image renders in the layout. Three or four variants — say 400, 800, 1200 and 1600 pixels — cover almost every case.
Always set width and height attributes. Without them the browser cannot know the aspect ratio before loading and reserves no space, so content jumps — directly harming visual stability metrics.
Lazy load: where it belongs and where it does not
The loading="lazy" attribute on img defers images outside the viewport. It is a native browser feature; a separate library is unnecessary and usually counterproductive.
The critical exception: never lazy-load the hero image above the fold. It is almost always the LCP element, and deferring it directly damages that metric. Give it fetchpriority="high" instead.
For catalogues the rule is simple: the first visible cards load normally, everything below loads lazily. On Uzbek mobile traffic that meaningfully cuts data for the first screen.
What to optimise beyond format
Strip EXIF metadata from photographs: geolocation, camera model and embedded previews add tens of kilobytes per file and serve no purpose on a website.
Tune compression quality by image type. For product photography 75–85 is usually indistinguishable from the original; interface screenshots need lighter compression or PNG with palette quantisation.
Convert icons and simple graphics to SVG. Vector weighs less than a raster equivalent, scales losslessly and needs no per-density variants.
Images and search traffic
The alt attribute describes image content for screen reader users and for image search. Write descriptively in the language of the current page version, not as a keyword list.
Give files meaningful Latin hyphenated names such as wool-coat-grey.webp. Filenames like IMG_20260814_112233.jpg carry no information for search or for the team.
For product imagery populate the image field in schema.org/Product markup — it raises the chance of a rich result. Large catalogues also benefit from a dedicated image sitemap.
Testing under real conditions
Open DevTools, the Network tab, enable a throttled connection profile and watch total weight and hero image load time. That is far closer to Uzbek mobile reality than office Wi-Fi.
In PageSpeed Insights read the modern formats, properly sized images and offscreen images items — each lists the potential saving per file in kilobytes.
After optimising, compare against field data in the Core Web Vitals report in Search Console two to four weeks later. Lab tests confirm the change; only field data confirms the outcome.