Vehicle photographs are the heaviest thing on a dealership website.

Fewer photographs are the wrong lever and usually cost more than they save. Shoppers want more images of a used vehicle, not fewer. Loading only the images a shopper has reached achieves the same result on the first view while keeping every photograph available to anyone who scrolls.

Whatever size the slot on the screen actually uses, which is not one number. A thumbnail rail, a gallery viewer and a full-screen view are three different sizes, and delivering the same full-resolution file to all three means the browser downloads pixels it immediately discards.

Every image except the first one a shopper sees. The photograph visible without scrolling should load with the page, because it is usually the element the Largest Contentful Paint measurement is timing. Marking that one lazy delays the exact thing the page is judged on.

Images cause layout shift whenever their dimensions are not declared. The browser cannot reserve space for a photograph whose size it does not know, so the page reflows as each one arrives, and a shopper reaching for a price or a lead button finds it has moved.

A used-inventory search results page, then a vehicle detail page. The search results page repeats a thumbnail for every vehicle in stock and is the easiest page to forget, because most testing starts on the homepage where there is one hero image and nothing else.

Usually the platform, working from photography the dealership or its vendor uploaded. The dealership sees the result instead of the mechanism, which makes this a question to put in writing instead of a setting to change: what sizes are generated, which format is served, and what is deferred.

A current format for browsers that support it, with an older format available for anything that does not. The point is not the specific name. It is that the same visible quality arrives in a smaller file, which is the one improvement that costs the shopper nothing.

A content delivery network shortens the distance the file travels and does nothing about its size. A full-resolution photograph delivered quickly is still a full-resolution photograph in a thumbnail slot. Delivery distance and file sizing are separate problems and both are worth fixing.

Read which resources delayed the largest visible element and how much time went to script execution. If the largest element is a photograph and the main thread is mostly idle, it is an image problem; if the photograph arrives quickly and the page still feels slow, it is a script problem.

Fixing images fixes the part of the problem images cause, which on a photograph-heavy page is often the largest single part. It does nothing about chat, trade, retailing and tag scripts competing for the browser, and most dealership sites have both problems at once.

Switching formats can, WebP and AVIF typically produce smaller files at the same visible quality, but the format matters less than whether images are sized correctly for where they display and loaded in the right order.

Where possible, yes: the closer the uploaded image is to its display size, the less work the browser and the platform have to do to shrink it on every page load.

A spin viewer usually adds the most weight of any single VDP feature, since it loads many images or a video stream. Loading it only when a shopper interacts with it, instead of immediately, is the usual fix.