The problem, and the short answer
If you've ever built or maintained a site for an architecture firm, you've probably run into this: gorgeous, professionally shot project photography, and a page that still feels underwhelming. Usually it's not a design problem in the visual sense. It's a build problem: unoptimized images tanking load time, a gallery component with no real page-level structure underneath it, and project "pages" that are really just image dumps with no title, description, or alt text worth indexing.
Short version: better project presentation for architecture sites is mostly a front-end and content-structure problem, not a purely visual one. Fix the technical layer and the design work you already have starts doing its job.
What's actually going on, technically
Two things determine whether a project page works: how the images are delivered, and how the page is structured around them.
On the image side, this is standard performance territory: responsive images (srcset/sizes or a modern <picture> setup), modern formats like WebP or AVIF with fallbacks, native lazy loading for anything below the fold, and a CDN or image pipeline that serves appropriately sized assets instead of a single huge source file to every device. Architecture sites are some of the most image-heavy builds out there, so skipping this step shows up immediately in load time and Core Web Vitals.
On the structure side, each project deserves to be a real, individually addressable page: a proper <title>, a meta description, heading hierarchy, and a short block of written content (the brief, constraints, response, outcome) alongside the images. A single-page gallery component that swaps images via JS without changing the URL or the document metadata is invisible to search crawlers, no matter how good the photography is. Structured data (CreativeWork or similar schema via JSON-LD) can help here too, giving search engines an explicit signal about what each project actually is.
Why this matters beyond the codebase
For a lot of these projects, the client is non-technical and evaluating "is this worth it" mostly on how the finished product looks and performs, not on the implementation. But the business case is concrete: a slow, image-heavy site loses visitors before they see anything, and a site with no indexable project pages means the firm's actual portfolio, its best marketing asset, never shows up in search for the exact queries prospective clients are typing. Both of those are directly attributable to build decisions, which puts them squarely in front-end territory rather than "design taste."
Key implementation points worth getting right
A few things consistently matter more than the rest. Image optimization and responsive delivery, since photography is the core content type here. A real URL and metadata per project, not just a modal or a client-side gallery state. Lazy loading and sensible bundle size, since heavy JS on top of heavy images compounds load time fast. A predictable, reusable template for project pages so content editors (often non-technical) can add new work without breaking layout or SEO fields. And mobile performance specifically, since a large share of traffic to these sites arrives from phones, often from social referrals.
If the site is running on a static site generator or a headless CMS setup (common, reasonable choices for this kind of content-heavy, low-interactivity site), most of this becomes a build-time or edge-caching problem rather than a runtime one, which is generally the easier problem to have.
## https://softwin.io/'s practical perspective
The pattern we run into repeatedly on these builds: the visual design is rarely the weak point, the client already has strong photography and usually a clear aesthetic direction. The gap is almost always in the technical layer underneath it, unoptimized assets, missing per-project SEO fields, inconsistent page templates, that never got scoped as part of the "design" work in the first place. Treating image pipeline, page structure, and metadata as part of the same deliverable as the visual design, rather than a follow-up task, is usually what separates a portfolio that looks good in a design review from one that also performs well in production and in search.
Common mistakes
Shipping full-resolution source images straight from the photographer without a compression or resizing pipeline is the most common one, and it's an easy one to catch with a quick Lighthouse pass. Building the whole portfolio as a single-page component with client-side routing or modals, so individual projects never get their own crawlable URL, is a close second. Inconsistent page templates across projects make both maintenance and SEO harder over time. And skipping alt text and meta descriptions because "the images speak for themselves" removes exactly the information search engines rely on, since they can't evaluate photography directly.
FAQ
Does responsive image delivery actually matter for a portfolio this visual?
Yes, arguably more than for a typical content site. Architecture portfolios are unusually image-heavy, so unoptimized assets have an outsized effect on load time and Core Web Vitals compared to a typical text-driven page.
Is a static site generator a good fit for this kind of site?
Often, yes. Project content tends to be relatively static and update infrequently, which plays well with static generation or ISR-style approaches, and it simplifies the performance side considerably.
Do single-page, JS-driven galleries hurt SEO?
They can, specifically when individual projects don't get their own URL and metadata. A crawler needs an addressable page with real content to index; a modal or client-side state change alone usually won't provide that.
How much written content does a project page actually need?
Not much, a few sentences on brief, constraints, and response is typically enough. It's there to give both users and search engines context that images alone can't carry.
What's a fast way to audit an existing architecture site?
A Lighthouse or PageSpeed Insights run will surface image and performance issues quickly, and a quick crawl (or just checking whether each project has a unique, indexable URL) will surface most of the structural issues.
Wrapping up
Most of the gap between an architecture firm's actual work and how it comes across online is fixable at the build level: image pipeline, per-project page structure, and metadata. None of it requires compromising the visual design the client already has.
https://softwin.io/ works on this kind of build regularly, performance, page structure, and SEO for content-heavy, visually driven sites. Happy to compare notes in the comments if you've run into similar issues on architecture, real estate, or portfolio-style builds.
Top comments (0)