Scenario · Custom website · Architecture studio
A portfolio that lives up
to the work it shows.
A studio with high-quality projects and a website that has not changed in years: slow images, text that is hard to update, no English version. I turn it into an editorial portfolio that loads quickly and that the team manages on its own.
Website scenario — architecture practice
Great work,
poorly told.
The scenario: a practice with a solid track record — dozens of projects, some clients abroad, a few features in trade publications. Yet the website is stuck six or seven years ago: a template with compressed, grainy photos, static text and no way to update it in-house.
The problem isn't just how it looks. Every time a partner wants to update a project or add a photo, they have to call an outside webmaster and wait days. The site becomes a fixed cost instead of a business tool.
The typical brief is short: "We want something that looks like us, not a WordPress theme." That's where the conversation that shapes the whole project starts.
"We have international clients who look at the website before deciding. When they open it in a meeting, we want to look good, not apologise."
— The request I hear most from practicesArchitect online portfolio requirements
What was really
needed.
A first meeting with the partners and a look at the existing site (and its Analytics data) usually bring out six clear areas of work.
High-profile editorial presence
The site has to convey the quality of the work before the visitor reads a word. Minimal but bold design, strong typography, full-screen images — no compromises with templates.
Portfolio filtered by category
Three macro-categories (Residential, Commercial, Temporary installations) with smooth navigation. Each project: photo gallery, technical data, year, location, team involved.
Self-managed CMS, no webmaster
The partners need to add a project, edit text or upload new photos on their own — without depending on anyone, without code, without paid CMS subscriptions.
Bilingual Italian and English website
International clients and collaborators. A complete EN version was needed, easy to update, without duplicating the site or relying on machine-translation plugins that degrade the quality of the copy.
Cinematic scroll animations
The strongest practices in the field use animation to create a sense of "slow time" that suits the kind of work. The goal is the same perceived quality.
Top-level performance and technical SEO
Architecture photos are heavy. The site still has to load fast — green Lighthouse scores across the board — and be found in local and industry searches.
Technical challenges of an architecture portfolio
Where the real
problems hide.
Editorial sites with high-resolution galleries look simple on the surface. In reality they concentrate some of the most interesting challenges in front-end development. These are the five main ones.
Development process for an architecture practice
How I
organise the work.
Eight to ten weeks in four phases. Each phase has a concrete output and a sign-off call with the lead partners. No surprises at launch.
Review of the existing site, comparison with the best international practices, content map, sitemap and data structure for the CMS.
Design system: palette (e.g. white, black and one accent colour), font pairing (editorial serif + mono for technical data), asymmetric grid, typographic rules. An interactive wireframe shared in Figma.
Full build: semantic HTML, custom-property-based CSS, vanilla JavaScript for interactions and i18n. JSON-based CMS with step-by-step documentation. Image optimisation with a WebP pipeline + automatic srcset.
Testing on Chrome, Safari and Firefox, on real iOS and Android phones, CMS training for the team, DNS switch and go-live. Active monitoring for the following 7 days.
Solutions for a fast architecture portfolio
How I solve
each problem.
Automatic optimisation pipeline
Every image uploaded to the CMS goes through a Node.js script that automatically generates three WebP versions (320px, 768px, 1440px) and keeps the original JPEG as a fallback for legacy browsers. The <img srcset> tag serves the right format to the right device.
Native lazy loading (loading="lazy") combined with a server-generated blur placeholder (a 40×40px version inlined in base64) eliminates layout shift and keeps the page visually solid while loading.
Goal: 3–5 MB images brought down to about 80–180 KB with no visible loss of quality on screen, and a first render under one second.
JSON-driven: no database, zero dependencies
The answer is a CMS built on JSON files the partners edit directly, with a simple editor or a small panel. Each project is an object with all its data: title, description, category, year, location, list of images, IT/EN text.
A small script reads these files and builds the portfolio, project pages and filters. No backend, no database, cheap hosting. A site like this can run on static hosting for a few euros a month.
Native bilingual, no plugins
Each piece of text in the HTML has a data-i18n="key" attribute linked to a JSON dictionary per language. Switching IT/EN replaces the text in a few milliseconds without reloading the page, and the choice is remembered.
The partners review the translated text themselves — no machine translation, no plugins. For international clients, the quality of the English is a requirement, not a detail.
The same mechanism also handles the SEO metadata (<title>, <meta description>, hreflang) to ensure both language versions are indexed correctly.
IntersectionObserver + CSS: no library, perfect frame rate
A custom scroll-animation system built with IntersectionObserver and CSS transitions. Each element enters with a combined effect: fade, a 24px vertical move and a slight scale from 0.97 to 1, in 0.7s with cubic-bezier(0.22, 1, 0.36, 1) — a soft curve typical of Apple interfaces.
The image parallax uses only CSS transform: translateY(), with a CSS variable updated by a single requestAnimationFrame. No external library: a target of around 15 KB of JavaScript in total.
opacity: 0;
transform: translateY(24px) scale(0.97);
transition: all 0.7s cubic-bezier(.22,1,.36,1);
}
.reveal.in-view {
opacity: 1;
transform: none;
}
Tech stack for an architecture website
Technologies chosen, not imposed.
Zero frontend frameworks, zero runtime dependencies. Every technology choice has a precise reason — no over-engineering, no library "just in case".
Weight target: HTML, CSS and JS under 60 KB in total, compressed. No framework, no runtime, no dependency that could become a security or maintenance problem in two years.
Example goals — architecture website
What to expect
in the first months.
Example figures, not a client's results: these are realistic goals for a scenario like this, to be measured with Google Analytics 4 and Google Search Console, comparing the same period before and after launch.
"A client chose us after seeing the website, without needing a presentation." That's the result to aim for: a site that works like the first meeting.
— The business goal, more than any metricLessons for a professional portfolio
What I bring
to every project like this.
These are the points I always keep in mind when building an editorial portfolio.
There's no "right" CMS by default. For a practice like this, hand-editable JSON can be far better than WordPress: no vulnerabilities, no plugins to update, no hosting to manage. The question isn't "which CMS" but "how much autonomy does this client really need?"
Speed isn't negotiable in high-end sectors. A practice designing projects worth hundreds of thousands of euros can't afford a site that takes 4 seconds to load. Load time is a quality signal, even before design.
Good i18n requires planning before the first line of HTML. Adding a second language afterwards is a devastating refactor. The data structure must be designed multilingual from the start, even if at that moment only Italian is needed.
The CMS guide is part of the delivery. A step-by-step guide with screenshots for the partners is worth a day's work. Without it, even the simplest CMS in the world becomes useless after launch.
The most important metric often isn't in the brief. Hardly anyone asks to measure "new clients who came from the website", yet it's the one that wins over the most sceptical partner. Measure what matters to the business, not just what's easy to measure.
Have a similar project in mind?
Tell me about it: we start from goals and priorities, and the first call is free.