Why we send smaller images to mobile screens

A photograph spanning a large monitor and the same photograph in a card on a phone should not be one and the same file. When they are, the phone downloads pixels it will never show and the visitor waits.

On 24 September 2026 we added image dimensions and a choice of sizes for the browser to media handling in CMS4. Visitors do not see this as a new menu item. They notice it the moment a page appears and nothing on it jumps. October brought further steps, described below.

Three facts the browser would otherwise guess

The browser picks a suitable file itself, based on the display and pixel density. To do that it needs:

• A choice of sizes (srcset). From an uploaded photograph, CMS4 prepares versions from 160 to 3,840 pixels wide, never wider than the original.

• The space on the page (sizes). How much room the image takes at a given window width. Only the component that renders the image knows this, so the component supplies it.

• Dimensions (width and height). These give the browser the aspect ratio before the file arrives.

They only work together. Several files are no help if the browser does not know how much space the image will really take.

Space reserved in advance

Width and height let the browser reserve space before the image loads, so text and buttons do not jump when the photograph arrives. In a gallery or a project list, that is a difference people feel during ordinary browsing.

On the P+P website in CMS4, the logos and icons carry exact dimensions in the same way – 302 images in total. As a result, every image on all 48 pages carries its dimensions, with no visible change to the design.

Crop, format and density

Cropping changes the maths

A landscape photograph placed in a tall card gets cropped, so the browser needs a larger file than the card’s width suggests. For a 3:2 image in a 4:5 tile it is about 1.875 times as wide. CMS4 components can therefore derive the size from the shape of the frame the image is drawn into. The focal point is not baked into the file; it only decides which part stays visible when cropped.

Format by browser, density with sense

The same width can arrive in different formats: AVIF, WebP, or JPEG or PNG for browsers that do not accept the modern formats. CMS4 searches for the compression quality of each image separately against a measure of visual similarity, rather than one fixed setting for everything. The delivered versions also carry no EXIF, XMP or ICC metadata, so whatever the camera wrote into the file does not travel with them.

Phones with very fine screens would otherwise download images for three times the pixel density. That is about 2.25 times the pixels needed at double density, and the eye cannot tell the difference. Published pages therefore cap density at roughly double.

What loads now and what can wait

The main image visible when the page opens must arrive on time; a gallery far below can wait until the visitor gets close. CMS4 distinguishes three cases: the page’s main image loads with priority, other images on the first screen load straight away, and everything else loads lazily.

Page preview in CMS4 keeps an eye on details like this. If a main image were set to both ‘load lazily’ and ‘load with priority’, the preview would report the contradiction to the author – just as it reports an image without dimensions or alternative text.

A well-prepared image keeps what matters in the photograph without making the visitor wait for nothing.

Check before publishing

Checks happen on the actual page at different widths, not by looking at file sizes. Before you publish, go through:

• Is the main image marked as the priority, and only that one?

• Does the crop keep what matters on a phone and on a wide monitor?

• Does every image have a description in every language of the website?

• Does the page preview report any image without dimensions?

• How does the page look and load at several window widths?

How CMS4 handles the media library and performance is summarised on the Media and performance page.