Performance

Image performance standard

Images often account for the largest share of transferred bytes on a marketing site, so image handling deserves its own standard.

Images often account for the largest share of transferred bytes on a marketing site, so image handling deserves its own standard.

Start with the right source size

A 5000 pixel image should not be the default source for a card that never displays wider than 600 pixels. We resize images to practical dimensions before relying on browser optimization.

Prefer efficient formats

WebP and AVIF can reduce file size substantially for photographic assets. We choose formats based on browser support, quality, and the specific asset.

Use responsive sizing

The browser should know how wide an image is expected to render at different viewport sizes. That helps Next.js and the browser choose an appropriate source instead of downloading more pixels than necessary.

Prioritize only the critical image

The image that controls the first meaningful view may need eager loading. Images below the fold generally should not. Overusing priority loading can make performance worse by forcing too many resources to compete at once.

Prevent layout shift

Known width and height values, or a stable aspect ratio, reserve space before the image arrives. That keeps surrounding content from jumping.

Compression is part of publishing

An image is not finished just because it looks good in Photoshop or Canva. It is finished when it also has an appropriate file size, dimensions, alt text, and loading behavior for the page where it lives.

We configure the image pipeline around the kinds of images the site actually uses

One of our image-heavy Next.js projects explicitly enables AVIF and WebP output, defines responsive device breakpoints, limits generated quality levels, and gives optimized images a long cache lifetime. Those settings are not copied blindly into every repo. They exist because that project has a large visual catalog and benefits from a more deliberate image policy.

Other projects lean more heavily on static imports. A local image imported through Next.js carries intrinsic dimensions through the build, which makes layout stability easier to protect. Content-driven sites may use an image registry or resolver so the MDX file can refer to an approved image without knowing how the bundler imports it.

The common rule is that image behavior should be controlled somewhere obvious.

Source dimensions still matter even with an optimizer

An image optimizer is not permission to upload anything. A massive source file still has to be processed, stored, and transformed. We prefer source assets that are already within a sensible range for their intended use. A full-width project gallery may need a larger source than a service-card thumbnail. Treating both assets identically wastes bytes and processing.

The sizes attribute is part of the performance contract

Responsive image components work best when the browser knows how large an image is expected to render. A card that occupies one-third of a desktop grid and nearly the full width of a phone should declare that behavior instead of implying it will always be viewport-wide.

Good sizes values help the browser choose a smaller candidate before download. That is one of the few image optimizations that can prevent unnecessary transfer rather than merely compressing it afterward.

Priority loading is deliberately scarce

We reserve eager or priority loading for images that materially affect the first useful viewport. If every gallery image, logo, and card is marked important, they compete with the actual hero and with each other. This is why image policy belongs with critical-path loading. Performance is not only about making assets smaller. It is about deciding which asset deserves the network first.

The visual result still wins

We are not interested in compression artifacts that make project photography look cheap. The goal is to find the smallest practical representation that preserves the visual standard. That often means different quality choices for a small card, a large portfolio image, and a social share asset.

A technically fast site that damages the proof it is supposed to show has optimized the wrong thing.

From explanation to proof

Where this connects to the work

The performance library explains why our technical scores tend to be unusually strong without treating the score itself as the product.