Choosing Image Formats a Small Studio Site Can Keep Fast

A photo-led studio site should serve its images as WebP, with a JPEG copy offered as a fallback, because WebP keeps a visibly sharp picture at a smaller file size and every current browser can read it. The format is only half the job: the file still has to be sized to the space it fills, and the largest image on the first screen still has to load before a visitor loses patience.

Why does the file format matter at all?

A picture that looks identical on screen can weigh very differently depending on how it is encoded. JPEG compresses photographs well but has sat still as a format for decades. WebP and the newer AVIF format use more modern compression and can hold the same visible detail in a smaller file, which is exactly what a studio site needs when every page opens on a portfolio image.

The practical choice for a small site is WebP with a JPEG fallback. According to MDN's reference on image formats, WebP is supported by all major current browsers, and serving it alongside a JPEG costs nothing beyond generating the second file once, at build time, not on every visit.

Does the format replace good sizing?

No, and this is the mistake that undoes the saving. A correctly formatted image that is still twice the pixel width it needs to be loads slowly regardless of format. The format cuts the weight of a given pixel count; sizing cuts the pixel count itself. Both have to happen.

The rule that holds for a studio site: generate a small number of fixed widths for each photograph (a thumbnail width, a card width, a full-bleed width) and let the browser choose the smallest one that fills the space, rather than shipping one large master image everywhere and letting the browser scale it down in the window.

What does a visitor actually wait for?

Google's Core Web Vitals name the moment that matters: Largest Contentful Paint, the render time of the largest image, text block or video visible in the viewport, measured from when the visitor started loading the page. Web.dev's guidance sets the target at 2.5 seconds or less, and a photo-led homepage is exactly the kind of page where the largest element is a picture, not text.

Three things change how quickly that picture appears:

1. File size. A smaller WebP file of the same crop reaches the screen sooner over a mobile connection.
2. Loading priority. The hero image above the fold should load immediately; every other image on the page can wait until the visitor scrolls near it.
3. Server distance. An image served from a CDN edge close to the visitor arrives faster than one fetched from a single distant server, regardless of its format.

What should a studio actually check before publishing a page?

A short, repeatable check, done in a real browser rather than guessed at:

• Open the page on a throttled mobile connection and watch which image paints last.
• Confirm the hero image is not also being lazy-loaded; a picture the visitor sees immediately should load immediately too.
• Compare the WebP file size to the JPEG it replaces. Google's own measurements put lossy WebP at 25 to 34 per cent smaller than a comparable JPEG; a saving well below that range suggests the JPEG was already well compressed and the swap is not doing much work.
• Resize the browser window to a phone width and check that a smaller derivative is served, not the same large file scaled down by CSS.

None of this requires new equipment or a paid tool. It requires generating the derivatives once, serving the right width for the right screen, and letting the browser pick the format it understands.

Does this change the brief a studio writes for a client site?

It adds one line to it. A brief that already asks for a sitemap, a tone of voice and a set of approved photographs should also state which widths each image needs and whether AVIF is worth adding alongside WebP for the sites that can support it. A studio that settles this once, in the brief, never has to relitigate it per page.

The short version

Serve WebP with a JPEG fallback. Generate a small, fixed set of widths for every photograph instead of one oversized master. Load the hero image immediately and let every other image wait. Check the result on a throttled connection before calling the page finished, because the only honest measure of "fast enough" is what a visitor's own device shows them.