On a phone, a visitor should be able to read a building project's description without first downloading a full-resolution rendering. Large images are part of an architecture website, but serving them at the wrong size can hold up the information people came for. The aim is a page that becomes readable quickly, responds to taps and stays steady as it loads—not just one with a smaller file size.
That distinction matters to property owners, developers and design practices. A prospective client might be checking a firm's healthcare experience; a resident might need a consultation document. A polished page on an office monitor is little help if either task is difficult on a phone.
Measure the experience before changing the site
Start with pages people use: the home page, a representative project page, a service page, and any contact or document-download page. Test on a mobile device or a realistic mobile connection as well as on desktop. A fast desktop result can mask oversized images, heavy scripts or a menu that responds poorly on a less powerful phone.
Three Core Web Vitals help identify different problems. Largest Contentful Paint (LCP) measures when the largest visible content element finishes rendering; a good field-data target is 2.5 seconds or less. Interaction to Next Paint (INP) measures responsiveness across user interactions, with 200 milliseconds or less considered good. Cumulative Layout Shift (CLS) measures unexpected movement of visible elements; the good threshold is 0.1 or less. These thresholds are assessed at the 75th percentile of visits. One fast test does not show that most visitors have a good experience.
Lab tests can help locate a cause; data from real visits shows what people encounter across devices and connections. Record the metric alongside the page condition. A project page led by a large image may have a different bottleneck from a text-heavy planning update. Compare page types and mobile versus desktop results instead of reducing the whole site to one reassuring score.
Make large images useful without making them expensive
Architecture and real-estate sites rely on renderings, site photographs, plans and material details. Keep the quality those images need, but serve files suited to their display size. A 4,000-pixel-wide photograph in a narrow mobile column makes visitors download detail their screens cannot show. Prepare responsive versions and let the browser choose an appropriate width. Keep a higher-resolution option where people need to inspect detail.
Use modern image formats when browser support and the publishing workflow allow, and inspect the compressed result at its intended display size. Fine linework and labels on a floor plan may need different settings from a façade photograph. Check that drawing text remains legible rather than applying the same aggressive compression to every asset. Set image dimensions or an aspect ratio so nearby text does not jump when the image loads.
Prioritize what appears first
The main image at the top of a page is often its LCP element. Give it an appropriately sized source and let it load promptly. Images farther down a long project page can usually wait until the visitor approaches them. Lazy-loading every image, including the hero, can delay the one people see first.
An embedded video walkthrough can be costly if its player loads immediately. A still preview with a clearly labeled play control can defer the player until someone chooses to watch. Readers looking only for the building area or completion date need not load it.
Reduce work before the first useful screen
Smaller images will not fix a page whose browser must process extensive code before displaying a heading. Review fonts, stylesheets and scripts against what the first screen needs. The navigation menu should work immediately; an animation near the bottom of a case study need not. Remove unused code where possible, and defer nonessential scripts rather than just hiding their visible components.
Third-party additions deserve scrutiny. Analytics, maps, chat widgets, social feeds and consent tools may each have a purpose, but together they can compete with page content for download and processing time. Inventory them, identify who owns each one and test the page with each disabled. A map used only on the contact page has little reason to load on every project page. A static location graphic or address can provide useful information before an interactive map is requested.
Fonts affect both speed and stability. Limit the families, weights and character sets downloaded. Specify a readable fallback so text can appear while a custom font loads, then check whether the swap moves headings, buttons or navigation items. If the brand font is essential, use it deliberately; a service description should not have to wait for several decorative variants.
Fix server and delivery delays
Even a compact page can feel slow if the server is late to respond. Check for slow database queries, excessive redirects, overloaded hosting and pages rebuilt unnecessarily on every visit. Public pages that rarely change, such as completed-project descriptions, are often suitable for caching. Forms, personalized content and recently updated notices need more careful rules to avoid serving stale or incorrect information.
A content delivery network can serve static assets from locations closer to visitors, but it cannot fix inefficient page code or an oversized image. Compression and appropriate browser caching reduce repeat downloads; versioned asset filenames help visitors get updated files after a site change. Check cache behavior when publishing: a revised project description should not sit behind a long-lived cached HTML page.
Protect usability while removing delays
A page that appears faster is not necessarily more useful. Removing contact-form validation may reduce script size but lead to failed enquiries. Loading a PDF preview late may improve an initial timing result while leaving someone waiting for a planning drawing they selected. Judge speed changes against the task on each page.
- Project portfolio: Check that images remain sharp enough to explain design decisions and that captions stay with the correct views.
- Contact page: Test keyboard access, form errors and confirmation messages after changing scripts or caching.
- Public consultation page: Keep key dates and document links available as text, even if a map or interactive model loads later.
- Mobile navigation: Confirm that menu controls respond promptly and do not shift while fonts or banners load.
Unexpected movement matters beyond the CLS number. A consent banner, late-loading advertisement or image without reserved space can push a button just as someone tries to tap it. Reserve space for known components, avoid inserting material above the current reading position and watch the page load rather than judging only the finished screenshot. Hiding useful content from the initial page is not a sound way to improve a metric.
Prioritize changes by user impact
Performance work is easier to budget when a proposed change addresses a specific bottleneck and has a measurable outcome. These symptoms suggest useful first checks, not guaranteed fixes.
| Visitor experience | Likely first check | Practical change to test |
|---|---|---|
| Project image appears late | Image dimensions, file size and loading priority | Serve a responsive hero image and do not lazy-load it |
| Page appears but taps feel delayed | Long-running scripts and third-party widgets | Remove unused code or defer nonessential work |
| Text and buttons move during loading | Missing dimensions, font swaps and inserted banners | Reserve space and adjust font loading |
| Every page begins loading slowly | Server response, redirects and cache rules | Investigate hosting and cache suitable public pages |
Where feasible, make one meaningful change at a time and retest the same pages and devices. Keep the prior result, the change and any visual or functional side effects on record. Field data takes time to reflect a release; lab tests provide quicker feedback. A better synthetic score is not enough if a drawing download breaks or a contact button becomes hard to find.
For a first pass, take the most-visited mobile project page and identify its LCP element. If it is a 3 MB hero rendering displayed at 700 pixels wide, make a suitably sized version and keep a separate detailed view if needed. Then retest with the caption, menu and enquiry control in place.