When we introduced this support, we deliberately chose: sizes="100vw" as the default strategy.

The reasoning was simple:

• it worked reliably
• it was predictable
• it avoided forcing developers to manually configure responsive image rules
• it provided a good baseline experience across different layouts

Even back then, the ambition was to make the sizes attribute configurable and adaptable to different layouts and content areas. The problem was that this quickly became extremely complicated in real-world systems.

A responsive image may appear:

• in a full-width hero
• inside a narrow content column
• in a card grid
• in a sidebar
• inside nested layouts
• in editor-controlled content areas

Each case potentially requires different sizes rules.

In theory, developers could manually configure these values. In practice, this creates several challenges:

• layouts evolve over time
• editors move content between contexts
• breakpoints become difficult to maintain
• configuration becomes fragile
• the solution often requires tooling support to remain manageable

Over the years, we explored ways to expose sizes customization both for developers and editors, but never found an approach that felt robust, maintainable, and flexible enough across all layout scenarios.

As a result, sizes="100vw" remained the practical default.

While functional, it also meant browsers often downloaded larger images than necessary because viewport width rarely matches the image’s actual rendered size.

That tradeoff made sense in 2015, but modern browsers now allow us to do significantly better.

The Problem with Responsive Images

Responsive images using srcset have always depended on the sizes attribute to tell the browser how large an image will appear in the layout.

A typical example might look like this:

The challenge is that the browser must choose which image to download before the layout is fully calculated. That forces developers to manually describe expected image widths across breakpoints.

In practice, this becomes difficult to maintain:

• Layouts change over time
• Different sections require different sizes
• Complex grid systems are hard to describe accurately
• Most developers fall back to overly simplified values

Historically, Sitevision has used sizes="100vw" as a safe baseline. While functional, this is often inaccurate. The browser assumes the image spans the full viewport width, even when the image actually appears in a much narrower column. That can lead to dramatically oversized image downloads.

A large image rendered inside a narrow content area may cause the browser to fetch image variants several megabytes larger than necessary.

The New Approach: sizes="auto"

Modern rendering engines now support a newer approach:

sizes="auto"

When combined with:

loading="lazy"

the browser can postpone image requests until layout information is available.

This changes everything.

Instead of developers manually predicting image sizes, the browser can determine the actual rendered size itself and choose the most appropriate image from the srcset. This enables responsive images to become largely self-optimizing.

Why Lazy Loading Matters

sizes="auto" only works for lazy-loaded images because the browser needs layout information before it can determine the correct image size.

Without lazy loading, the browser must choose an image before layout information is fully available. With lazy loading enabled, image requests happen later, after layout calculations are complete, allowing the browser to make far more accurate image selections.

That means:

• Smaller image downloads
• Reduced bandwidth usage
• Faster rendering for non-critical content
• Better automatic optimization without custom configuration

For most images on a page, this is a clear win.

Important Exception: Above-the-Fold Images

There is one important tradeoff.

Images that contribute to LCP (Largest Contentful Paint) should generally not use lazy loading. Lazy-loading hero images or other above-the-fold content can delay rendering and negatively impact Core Web Vitals.

As a template developer, you should therefore avoid lazy loading for critical images that are immediately visible when the page loads. In those cases, loading="eager" is usually the better choice.

Why width and height matter

To support sizes="auto" correctly, images must include explicit width and height attributes.

Sitevision has already emitted these attributes for image modules during recent years because they provide important layout benefits.

Modern browsers use these values to calculate an intrinsic aspect ratio before the image has loaded. This prevents layout shifts and improves visual stability.

Without width and height information:

• pages may “jump” during image loading
• CLS (Cumulative Layout Shift) becomes worse
• browsers cannot reserve the correct space in advance

This is especially important with sizes="auto" because browsers otherwise fall back to a default intrinsic placeholder size.

For a deeper explanation of why sizes="auto" effectively requires intrinsic dimensions, Eric Portis has written an excellent article on the topic External link..

Changes Introduced in Sitevision 2026.07.1

The following changes are now being introduced.

sizes="auto" is automatically added

When an image uses both srcset and loading="lazy", Sitevision will now automatically include sizes="auto".

This applies to the Image module, ImageRenderer, the News module and the Picture marketplace app.

Lazy loading becomes default

Image sizes under Website Settings / Images will now have srcset and loading="lazy" selected by default for newly created image sizes.

Existing configurations are not modified.

The Image module will also enable srcset and loading="lazy" by default for newly created modules.

Existing modules remain unchanged.

ImageRenderer now has setLazyLoad(true) enabled by default.

Only renderers explicitly configured with setLazyLoad(false) will render eagerly.

The News module will now automatically apply srcset and loading="lazy" to all article images.

The Picture marketplace app will now use loading="lazy" by default.

A new setting allows images to be loaded eagerly for special cases.

ImageRenderer now outputs width and height

All rendered images will now include explicit dimensions.

This improves:

• layout stability
• aspect-ratio handling
• browser rendering behavior

Best Practices for Developers

Use lazy loading for most images

This should be your default choice.

Ideal candidates include:

• article images
• gallery images
• cards
• teasers
• content blocks below the fold

Avoid lazy loading for critical hero images

For large images above-the-fold, loading="eager" is often preferable. This helps protect LCP performance.

Always use responsive CSS correctly

The pattern we use for the Image module is this:

This ensures aspect ratios remain intact even when explicit width and height attributes are present.

Potential Compatibility Considerations

In most cases, adding explicit width and height attributes improves layout stability and works well with existing responsive CSS.

Some older custom layouts or scripts reacting to image load events may behave slightly differently now that browsers can determine image dimensions earlier in the rendering process.