Why hero images get special treatment

The largest image near the top of a page has an outsized effect on perceived speed.

That is why we do not treat every image on a site the same.

A gallery image six screens down can wait. A hero image that dominates the first viewport cannot.

The hero often becomes the LCP element

Largest Contentful Paint measures when the main visible content finishes rendering.

On visually rich marketing pages, the LCP element is often the hero image or the main heading block.

If the hero image is oversized, discovered late, or competing with unnecessary scripts, the page can feel slow even when the rest of the site is efficient.

That makes the hero a performance decision, not just a design asset.

Source dimensions matter before optimization

Framework image optimization is useful, but it should not be an excuse to keep absurdly large source files.

If the design never renders an image anywhere near its original camera resolution, reducing the source dimensions can lower repository weight, processing work, and the chance of accidentally delivering more pixels than the layout needs.

We still keep enough resolution for high-density screens and responsive crops.

The goal is not aggressive compression at any cost. The goal is an appropriate source.

Priority is a scarce resource

Next.js lets us prioritize critical images.

We use that deliberately.

Marking every image as priority defeats the point because the browser now has several assets competing for early bandwidth.

The first meaningful image may deserve priority. The cards below it usually do not.

On one service site, the navigation logo is also loaded early because it is part of the initial interface. That does not mean every decorative image in the page receives the same treatment.

Responsive sizes help the browser choose correctly

An image component can know the original dimensions without knowing how wide the image will appear on every viewport.

The sizes attribute gives the browser that missing layout information.

A hero that spans the viewport needs a different sizing rule from an image inside a narrow article column.

Without that information, a browser can choose a larger source than necessary.

Cropping and layout are part of performance

Sometimes the fastest image is not the same composition the designer originally exported.

A desktop hero may be wide and shallow. A mobile hero may need a different crop or a different focal point.

Trying to force one enormous image to solve every viewport can create both design and performance problems.

We prefer responsive presentation that respects the source material and the layout.

Reserve the space

An image should not arrive and shove the rest of the page downward.

Known dimensions or stable aspect-ratio containers let the browser reserve the correct amount of space before the asset finishes loading.

That reduces layout shift and makes the page feel more stable.

The visual system still matters

Performance work can become destructive if the answer to every problem is "remove the image."

We build marketing sites. Strong photography and visual identity can be part of the conversion value.

The engineering job is to deliver the image responsibly.

That means controlling dimensions, format, compression, loading behavior, responsive sizing, and placement so the visual asset earns its cost.

Below the fold gets a different strategy

Once the visitor has the main page, we can be more patient.

Portfolio galleries, article images, and secondary sections generally load lazily. That keeps the critical path focused on what the person can actually see.

This distinction is one reason our image strategy performs better than a blanket approach.

The page does not have "images."

It has critical images, supporting images, decorative images, and sometimes images that should not be there at all.

We optimize according to the role.