The master image is not the web image.
An architect may need a high-resolution file for print, presentations and future crops. A visitor looking at a project on a phone needs a file sized for that display and connection. These are different deliverables. Keep the master untouched, then produce derivatives for specific uses on the website.
Start by separating visual quality from pixel count. A sharp 8K render can look worse after aggressive compression, but sending all 8K pixels to a narrow browser window does not recover detail the screen cannot display. The right export depends on rendered width, display density, image texture and the amount of acceptable compression.
Ask the designer or developer: “Where will this image appear, how wide can it become, and can someone open a larger version?” The answers determine the export variants. “Please make everything 2000 pixels wide” is not an image strategy.
If the studio is still choosing projects and collecting rights or credits, start with the project-content preparation guide. This article begins after the selection is made and addresses the technical delivery of those approved images.
Give every image a job before choosing its size.
A homepage hero, project index thumbnail and detailed plan serve different purposes. Reusing the same oversized file for all three creates needless transfers; forcing them all into the same crop can damage the architectural story.
| Image role | What to optimise for | Implementation decision |
|---|---|---|
| Opening project image | Composition, immediate visibility and legible focal point | Responsive sources; treat as a likely priority image |
| Project index card | Fast scanning and a consistent visual rhythm | Small variants; deliberate crop and descriptive link text |
| Full-width gallery frame | Material detail and the intended proportions | Several width variants; defer frames well below the fold |
| Floor plan or section | Readable labels, linework and spatial information | Clean export plus an accessible enlarged view and text |
| Panorama or 360° view | Usable interaction without blocking navigation | Poster image first; load the interactive experience on demand |
Not every image needs every size. A small card and a full-screen photograph have different upper bounds. Record the real maximum displayed width in the design before making a derivative list. A project page with varied image ratios can still use one shared responsive-image component, provided it does not force every asset into the same aspect ratio.
Let the browser choose a suitable image, not the master.
The HTML srcset attribute offers files at several widths. The sizes attribute describes how much horizontal space the image occupies at different viewport widths. Together they let the browser choose a source using the layout and the device's pixel density. A responsive image is more than a single large file styled with width:100%.
For a hypothetical full-width architectural image, the markup might look like this. The filenames and dimensions below are fictional implementation examples, not files on this website or assets from a client project. Each candidate must really exist and have the declared pixel width before the example is used in production.
The width and height describe the image's aspect ratio; CSS can still display it fluidly. The example's three files share that ratio. The sizes rule is only correct if it matches the actual layout. A narrow content column might require a different value.
What about AVIF, WebP and JPEG?
Choose formats by tested visual quality and compatibility rather than by a blanket rule. AVIF and WebP can reduce transfer size for many photographs and renders; JPEG remains a useful fallback. A <picture> element can offer alternative formats with an <img> fallback. Verify that the image pipeline produces the right variants and that the fallback actually loads.
Inspect fine brickwork, vegetation, glazing reflections and gradients after export. They reveal different compression problems. A smaller file is not automatically a better file if facade joints smear or a smooth sky breaks into visible bands. Compare exports at their actual on-screen size, not only at 100% zoom in an editing application.
Do not sacrifice the architecture to a thumbnail grid.
Architecture images often rely on precise relationships between a building, its surroundings and the edge of the frame. Cropping a wide elevation into a portrait card may remove the entrance, cut a roofline or imply a different relationship to the site. Decide which views tolerate a crop and which should remain intact.
Use object-fit:cover deliberately for index cards, with an individually reviewed focal position. Use object-fit:contain or natural proportions when the complete drawing or composition matters. A mobile crop may need a separate, approved export rather than an automatic centre crop.
Imagine a wide visualisation of a small public library. The entrance is near the left edge and a mature tree explains the approach from the street. A centred portrait crop removes both. For the index card, choose a different camera view or a consciously framed mobile crop; on the detail page, retain the original wide composition. This library is a fictional example, not an Atmosferi commission.
If the mobile version uses a different crop, test the transition around the breakpoint. The crop must not silently change the building's apparent form or hide a key architectural feature. An alternative crop also needs an accurate text description where the visible content changes meaningfully.
Load the first meaningful image first.
On image-led architecture sites, the opening photograph or rendering is often a candidate for Largest Contentful Paint (LCP), a loading metric. The browser should discover this important asset early. Avoid putting the main image behind a JavaScript-only loader or marking it loading="lazy". For a genuinely critical hero image, fetchpriority="high" can help the browser prioritise its request.
Reserve lazy loading for images that are off screen, such as later gallery frames. Do not give every image high priority: a portfolio with ten competing “important” images has no meaningful priority order. If the hero is a CSS background, consider whether a responsive HTML image would make discovery, alternative text and sizing easier; any preload must match the actual chosen asset rather than accidentally causing a second download.
Initial view: project name, introduction and first image render without waiting for a carousel script. Scrolling: later photographs load near the viewport. Optional interaction: a 360° viewer or large zoomable drawing loads when the visitor asks for it, with an accessible static fallback.
The guidance on image priority is explained further in Chrome's image-priority documentation. Treat it as a starting point and verify the outcome on the actual page.
Preserve layout and meaning while images load.
Missing image dimensions can make text and controls jump as the image arrives. Declare intrinsic width and height, or reserve the correct aspect ratio in the layout. If responsive variants share a crop, their aspect ratios should match. When different mobile and desktop crops have different ratios, test that the layout reserves the appropriate space at each breakpoint.
Alternative text is not a place to stuff search keywords. Describe the architectural information the image contributes. “North-facing brick facade with a recessed entrance” is more useful than “architecture portfolio building design”. If a nearby caption already provides the same information, keep the alt text concise. Purely decorative images may use empty alt text.
Drawings need more than an image description.
A detailed floor plan can contain room names, dimensions, orientation and circulation. No single short alt attribute can replace all of that. Offer a readable larger view, retain essential information in adjacent HTML text and do not trap zoom or panning behind gestures that exclude keyboard users. Check whether downloadable drawings contain information the studio is permitted to publish.
For technical background, see web.dev's explanation of image dimensions and layout shift and MDN's responsive-image guide.
Make image delivery repeatable for the next project.
The image system should work when the studio uploads its next commission, not only when a developer hand-tunes the launch portfolio. Agree on who supplies masters, who approves crops, who generates variants and who checks the published result. If a CMS handles derivatives automatically, test what it does to a portrait photograph, a panoramic rendering and a fine-line drawing before relying on it.
Record the approved source and crop revision. If a design changes, replace the correct derivative set rather than re-compressing an old web file. Keep photographer and collaborator credits attached to the asset record and confirm publication rights for the website, not merely possession of the files.
A content-management system should expose the fields editors actually need. The architecture portfolio CMS guide
Test the delivered page, not just the export folder.
Open the page on a narrow phone, a normal laptop and a large high-density screen. Then use browser developer tools to inspect which image variant was actually requested. A correctly configured srcset is useful only if the browser receives an appropriately sized file. Check with an uncached reload and a slower connection profile, not only on a fast office network.
Inspect LCP and layout shifts using browser performance tools or PageSpeed Insights, but avoid declaring success from a single synthetic score. A real visitor's device and network may behave differently. Also check whether a CDN, cache or CMS has served an outdated crop after an image revision.
- At phone width, the first image is visible promptly and its main subject remains in frame.
- The hero is not lazy-loaded; lower gallery images are not all competing with it immediately.
- Requested image widths roughly match the actual layout and device density, rather than always selecting the largest file.
- Every image reserves space before loading; headings and buttons do not jump when photographs arrive.
- Brick, glass, foliage and gradients look acceptable at the size visitors will actually see.
- Plans remain legible when enlarged, and essential information is available without reading microscopic labels.
- Captions, alt text, credits and any visualisation-status labels match the published image.
- Responsive crops have been approved by the studio, including portrait and panoramic assets.
- A 360° viewer does not trap scrolling or block access to the static project information.
- The production page loads the same variants, captions and image rights information that were approved in preview.
The goal is not to shrink every image until a performance tool turns green. It is to deliver the architectural image at the quality its role requires, without asking each visitor to carry the weight of an archive master.