An architecture photograph exists to be seen large. That is the point of it: the scale, the light crossing an opening, the meeting of two materials. Shrunk to a thumbnail, it stops saying what it had to say.
The file that comes out of the camera is not what the page serves
High-resolution originals serve the archive and print. For the website, check whether the platform creates and serves versions suited to each screen. Shrinking an image only in the stylesheet does not reduce the file the browser downloads.
Between the original and the page there is a preparation step, and it is not an implementation detail: it is the product. The original stays intact in the archive. What the page serves are derivatives, and each one answers three questions: at which widths will the image actually appear in the layout, how far can it be compressed before the difference shows at that width, and in which format does the browser read it best.
The opening image can determine the wait
LCP measures when the largest visible content element appears, which may be an image, text or video. The good threshold is 2.5 seconds or less at the 75th percentile of page loads, assessing phones and computers separately. An opening photograph may be that element; measuring the page confirms it. We explain all three metrics in your site on a client’s phone.
Images visible when the page opens should load without deferral. For images outside that initial area, loading="lazy" lets the browser defer the request until they approach the screen. For an important opening image, fetchpriority="high" suggests a higher priority. The browser decides how to organize requests; check the result on a phone.
Choose the format for the photograph
WebP and AVIF are options for reducing photograph file sizes compared with a JPEG of similar visual quality. The result depends on the image and compression settings. Compare versions at the size people will see: stone textures and facade details should not disappear just to reduce the file size.
MDN documents support for these formats in major browsers and recommends a fallback for AVIF. The picture element lets you offer AVIF while keeping another version for a browser that does not support it.
A phone does not have to receive a desktop image
Always sending the largest file can use data without improving the image someone sees. With srcset, the page lists the available versions; with sizes, it indicates the space the image will occupy. The browser can choose based on that space and the screen’s pixel density. A phone with a dense screen may need more pixels than its apparent width suggests.
Another decision is what MDN calls the art direction problem. It is not about serving the same
photograph smaller: it is about serving a different framing. A wide exterior, building in
the middle and the site around it, may work on a monitor and lose detail in a narrow column.
With the picture element and a width condition, the phone gets a tighter
crop, chosen by whoever chose the framing and not by the browser.
Declared dimensions, so the page does not jump
CLS measures visual instability caused by unexpected content shifts, and the good threshold is 0.1 or less. Images without reserved space are a common cause. Declaring width and height, or reserving the aspect ratio with CSS, helps the browser keep space for the image before it arrives.
In a project grid, reserving space for images helps keep links in place. Without that space, an arriving photograph can move the project someone was about to tap.
The archive is an editing problem before it is a technical one
With the mechanical part solved, what remains is the part no tool solves. A studio accumulates work, and it is good that it does. The page that shows it cannot accumulate at the same rate, or it stops being an argument and becomes an inventory. The distinction is this: the archive is the complete record of the work and it serves the studio; the page is a selection made for someone who has not yet decided whether to call. They can coexist. They cannot be the same object.
Ordering projects from newest to oldest is simple to maintain, but gives the latest work prominence. If the visitor is looking for a type of work, grouping by housing, refurbishment, interiors or public buildings may be more useful. The selection should help them find work relevant to what they need.
And then there is what stays out, which is the hard part because every piece cost somebody work:
- The photographs that need explaining before they are understood.
- The variations on the same angle, kept because none was clearly the best.
- The construction shots that say nothing to anyone who was not there.
- Competitions and studies, unless they are identified as such. Nothing appears described as built if it was not built: it is the one rule on this list that is not negotiable.
Remove images that repeat the same point. A chosen sequence should help someone understand the project without searching through variations of the same angle.
What makes a project page earn its length
A long project page is not a fault. It is a fault when it is long for no reason. It earns the length when every piece does something the others do not:
- One line, right at the top, saying what this is: programme, year, scale in words, and the location at the level of detail the client agreed to make public.
- A first image chosen to convey the project’s idea, even if the visitor does not continue through the gallery.
- A drawing: plan, section or site plan. It is what separates a studio’s page from a gallery of pretty photographs, and it is what an attentive client looks for when they want to understand the idea and not just the finish.
- One paragraph of intent, short, written for someone outside the profession.
- Credits: photography, engineering, construction. What the photography licence allows is confirmed with the photographer before publishing, not after.
- Alt text suited to the image’s purpose. For informative photographs, describe what matters; for purely decorative images, use
alt="". If an image acts as a link, its accessible name should make the destination understandable.
And what does not earn the length: the paragraph describing in words what the photograph beside it already shows.
Ask to see how the next project is added
Before choosing who builds the site, bring a representative project and ask for a demonstration: add a title, images and credits, prepare the English version, review it on a phone and publish. Confirm who handles each step and whether a change requires the agency’s involvement.
Also test the route to an enquiry: can the visitor identify the project they are asking about? Does the team receive that context and know which language to reply in? These are questions for the demonstration and proposal, not features to take for granted.
Give the work room, with a well-prepared page
Good preparation helps balance detail, file size and ease of browsing. Project selection, image versions and the way the archive is updated should be decided together. We describe that work on our page for architecture studios.
Bring a representative project and tell us how the studio publishes new work. We can start there to understand what the site needs to show and who will maintain it: book a 15 minute call.
Sources
- What LCP measures and the 2.5 second threshold: Largest Contentful Paint (LCP), web.dev.
- The three thresholds and the 75th percentile of real page loads: Web Vitals, web.dev.
- Not deferring the images visible at the start: Browser-level image lazy loading for the web, web.dev.
- Declared dimensions and reserving space against layout jump: Optimize Cumulative Layout Shift, web.dev.
- Image formats and browser support: Image file type and format guide, MDN.
- Resolution switching,
srcset,sizesand the art direction problem: Responsive images, MDN. - Values of
loadingandfetchpriority: <img>: The Image Embed element, MDN. - Text alternatives and image purpose: Images Tutorial, W3C.
Sources checked again on 10 September 2026. The selection and presentation recommendations are editorial criteria; they do not represent measured results for a studio.