I tested ten Australian architecture studio websites on a mid-range Android phone over 4G a few weeks ago. The median Largest Contentful Paint was 5.4 seconds. The fastest was 2.1 seconds (a studio with a properly built custom site). The slowest was 11.3 seconds (a Squarespace template with full-resolution hero images and no responsive sizing).

For context: Google's Core Web Vitals threshold for "good" LCP is under 2.5 seconds. Above 4 seconds is "poor." Eight of the ten sites I tested fell into the poor band.

The studios building these sites would argue, reasonably, that their visitors are looking at architecture and that some loading time is acceptable for image quality. The argument doesn't survive contact with the data. Page bounce rates above 4-second LCP run substantially higher than under 2 seconds. For a studio whose website is part of how briefs are won, every bounce is a brief that might have arrived but didn't.

The opinion: the slow-architecture-website problem is solved technology. The studios still suffering from it are either on the wrong platform, working with the wrong supplier, or have made a conscious trade-off they probably shouldn't have made. This post is the math on what the slow website is costing, and the technical specifics of fixing it without compromising image quality.

The case for not optimising

Before the takedown.

Architecture is a slow medium. Buildings take years to design and build. Magazines that publish architecture are physical objects that reward dwelling. The pace of architectural appreciation is not the pace of mobile commerce.

There's a real argument that architecture websites should be allowed to take their time — to load deliberately, to reward patience, to refuse the optimised-for-impatience defaults of consumer web design. Some of the most respected studios internationally have sites that load slowly and feel correct for it.

There's also a real budget consideration. Image optimisation pipelines, modern CDNs, and proper responsive sizing are technical investments that template platforms don't deliver out of the box. The cost of a custom-built site with these features is materially higher than a Squarespace setup. For small studios with limited marketing budgets, the optimisation might genuinely not be the highest-priority spend.

Both arguments deserve a hearing. Neither holds up at the brief values most established studios are competing for. A studio bidding for a $400K residential brief or a $1M institutional fitout cannot afford to leave a meaningful fraction of qualified prospects bouncing because the homepage takes 7 seconds to load.

The Australian context

Some grounding numbers.

Mobile share of architecture website traffic. For most Australian studios we've audited, mobile sits between 55% and 70% of all traffic. This is in line with general web trends and is climbing year on year.

Mobile data and bandwidth. Australian 4G performance is broadly fine in metropolitan areas but inconsistent on regional connections and on the trains, in cafes, and in the situations where prospects actually browse. The performance budget for a mobile site needs to assume mid-range device + average network, not high-end phone + WiFi.

Bounce rate sensitivity. Google's research (cited widely in Core Web Vitals documentation) puts the bounce rate at 9% for pages under 2 seconds, 38% for pages over 5 seconds. The relationship is non-linear and the inflection point sits roughly where most architecture sites currently sit.

Conversion impact. A typical architecture studio website's conversion rate from visit to enquiry sits at 1–3% for a portfolio-led site. Halving the bounce rate doesn't always double conversions (some bounced visitors weren't going to enquire anyway), but in our experience the lift is roughly 40–80% when you take a site from 6 seconds to 2 seconds. On a studio site getting 3,000 visits a month, that's the difference between 30 enquiries a month and 50.

Why the slow problem is so common in architecture

Five reasons specifically affecting the sector.

1. The image source files are huge

Architecture photography is shot on full-frame DSLRs and medium format. RAW files run 60–120MB. Even processed JPEGs at high quality are 8–25MB at full resolution. Studios upload these to the website with the (correct) instinct that the image quality matters, and the template platform either keeps them at full size (slow) or downsamples them (compromising quality).

2. The platforms used most often don't handle this well

Squarespace, Cargo, and most Webflow templates were built for general portfolio use, not for the specific case of an architecture studio where image weight is extreme and image quality matters disproportionately. The defaults aren't right for this use case.

3. The "let the work speak" convention rewards large images

The dominant aesthetic convention — full-bleed hero images, large-format project galleries, generous whitespace, slow scroll experiences — was designed when broadband was the dominant connection and mobile was a secondary consideration. The aesthetic is good. The implementation on mobile is often disastrous.

4. Studios rarely test on the devices their prospects use

Most architects build and review their websites on 27-inch monitors over fibre internet. The site looks great in that environment. It's a different site at 5 inches over 4G in regional Victoria.

5. The build budget is usually allocated to design, not engineering

A typical $15K architecture studio website spends $12K on the design and $3K on the implementation. A site that performs well requires the reverse — or at minimum a split closer to 50/50. The disinvestment in engineering shows up as performance problems.

The math on what slow is costing

Let me work through a realistic example.

Studio: mid-sized Melbourne practice. 8 architects. Pipeline includes mid-range residential ($300K–$1.5M briefs), small commercial, and the occasional institutional project. Average brief value $750K. Studio fee at industry-typical 8–12% = $60K–$90K per brief. Conversion rate from enquiry to signed brief: ~25%.

Website traffic: ~4,000 visits a month, 60% mobile, primarily from organic search, Instagram, and referrals.

Current performance: mobile LCP 5.8 seconds, mobile bounce rate 42%, monthly enquiries averaging 8.

Conversion math: 4,000 visits × 58% non-bounced (i.e., 1 - 42% bounce) × 0.35% conversion = 8 enquiries/month. At 25% close rate, 2 briefs/month. At $75K average fee, $1.8M annual fee revenue from website-attributed pipeline.

Same studio with mobile LCP fixed to 2.2 seconds, mobile bounce rate drops to 18%: 4,000 visits × 82% non-bounced × 0.40% conversion (slight conversion lift from better UX) = ~13 enquiries/month. At same 25% close rate, ~3.25 briefs/month. At same $75K fee, $2.9M annual fee revenue.

Marginal annual fee revenue from the speed fix: roughly $1.1M. Against a one-time cost of $15K–$30K to rebuild the site properly.

The numbers vary enormously by studio. A studio with smaller briefs and lower conversion rates sees a smaller absolute lift but proportionally similar improvement. A studio with bigger briefs sees more.

The order of magnitude is consistent: the slow site is taxing the pipeline by 30–60% of its potential, and the cost of removing the tax is one-time and relatively small.

What the technical fix actually looks like

Six specific changes, in roughly the order of impact.

1. Build the image pipeline properly

The single highest-impact change. Source images stay at source quality and resolution. Build-time processing generates multiple variants:

AVIF for modern browsers (smallest file at same quality)
WebP as fallback for slightly older browsers
JPEG as last-resort fallback

Each variant is generated at multiple sizes — typically 400px, 800px, 1200px, 1600px, 2400px wide — so the browser can request the right size for the viewport.

The <picture> element with proper srcset and sizes attributes routes the browser to the right variant.

Studios using Next.js can get most of this from the built-in <Image> component. Studios on custom builds use sharp at build time. Either way, this is solved technology.

2. Preload the LCP image

The Largest Contentful Paint image is almost always the hero. Preloading it — telling the browser to start downloading it before the HTML is fully parsed — typically shaves 500–1,200ms off the LCP measurement.

The technique is a <link rel="preload" as="image" href="..."> tag in the HTML head. Standard, well-supported, easy to get wrong if the preload doesn't match what the browser actually requests at runtime.

3. Defer everything below the fold

Images, scripts, and stylesheets that aren't needed for the first viewport should not block the initial render. Lazy-loading for below-fold images. Async or defer for non-critical scripts. Critical CSS inlined, full CSS loaded async.

Template platforms generally don't do this aggressively because the templates have to work for every possible use case. A custom-built site can be ruthless about what's critical and what isn't.

4. Use a fast CDN for image delivery

A studio in Melbourne with prospects across Australia and occasionally Asia needs images served from edge locations close to the prospect, not from a single origin. Cloudflare, Vercel's edge network, Bunny CDN, or Cloudflare Images for image-specific delivery all work.

The latency difference from origin-only to CDN-served is typically 100–300ms per image. On image-heavy pages with parallel image loads, this compounds.

5. Optimise font loading

A common cause of layout shift and slow text rendering on architecture sites is custom font loading. Studios often use multiple weights of a custom serif or sans-serif, loaded via @font-face with default font-display behaviour, which blocks text rendering while the font downloads.

The fix: font-display: swap to render with system fonts while custom fonts load. Preload critical font files. Use variable fonts where possible to consolidate weight loading into a single file.

6. Audit and remove unused JavaScript

Most studio sites are running 200–800KB of JavaScript that isn't doing anything useful — old Google Tag Manager configurations, abandoned third-party widgets, analytics tools the studio doesn't use anymore. Each one of these blocks main-thread execution and hurts both LCP and INP (Interaction to Next Paint, another Core Web Vital).

A clean audit and removal can shave 30–60% off the total JavaScript payload on a typical studio site. The performance impact is significant and the work takes a few hours.

The non-negotiables for any new build

For any architecture studio commissioning a new website in 2026, the performance specification should include:

Mobile LCP under 2.5 seconds on a 4G connection (test with WebPageTest or PageSpeed Insights at a 4G profile)
AVIF + WebP image variants with proper responsive sizing
Preloaded hero images on key pages
Critical CSS inlining
A CDN that serves images from edge locations
Lighthouse performance score above 90 on mobile, not just desktop

If the supplier you're commissioning won't commit to these in the spec, find a different supplier. These are not specialist requirements anymore; they're the baseline for a 2026 website.

What's worth keeping slow

A small concession. Not every interaction on an architecture website needs to be fast.

The deliberate slowness of an animated page transition, the careful timing of a parallax effect, the considered pace of a project gallery scroll — these are aesthetic choices that can legitimately add a few hundred milliseconds to a perceived experience without hurting the underlying performance metrics.

The distinction is between deliberate slowness (a design choice) and accidental slowness (a technical failure). The former is sometimes correct. The latter is always a problem.

The honest bottom line

Slow architecture websites are a solved problem with a known cost. The studios still running on 6-second LCPs are losing a measurable fraction of their potential briefs to performance issues that are fixable for a one-time investment of $15K–$30K AUD.

The fix doesn't require compromising image quality. The technical pipeline can preserve full source quality while delivering exactly the right size and format to every viewport. The "we have to be slow because architecture needs big images" argument is no longer technically true.

The studios that fix this in 2026 outperform their peers on the only metric that matters: briefs won per dollar of marketing spend.

If you want a free performance read on your current site — including a specific LCP measurement, an image format audit, and an estimate of the bounce-rate impact — run it through our audit. The report tells you what's costing you the most and what would shift the numbers fastest.

Slow Architecture Sites: The 5.4s Lost-Brief Tax (2026)