Most websites are slower than they need to be. Not because the team behind them didn’t care, but because the default way of building — a server that assembles every page fresh on every request, plus a heavy layer of client-side JavaScript to make it interactive — does a lot of work that most pages simply don’t need. Static-first architecture starts from the opposite assumption: do the work once, at build time, and serve the result.
What “static-first” actually means
When we build static-first, most of your pages are rendered to plain HTML ahead of time — at the moment we deploy, not the moment a visitor arrives. Those pre-built files are pushed to a content delivery network (CDN), so a visitor in London and a visitor in Munich both receive a page from a server physically close to them, with no database query or server render standing between the click and the content.
That doesn’t mean the site is frozen. Content still comes from a CMS, forms still work, and interactive components — a filter, a booking widget, an AI assistant — still run in the browser. The difference is that interactivity is added deliberately, to the parts of the page that need it, instead of shipping a full application framework to render a page that is mostly text and images.
We build this way primarily on Astro, which was designed around exactly this idea: send zero JavaScript by default, and “hydrate” only the interactive islands. Next.js covers the cases where an application genuinely needs server rendering.
Why it matters for the numbers that matter
Speed isn’t a vanity metric. Google’s Core Web Vitals — loading speed, responsiveness and visual stability — are a ranking signal, and more importantly they track how a real person experiences your site. Static-first architecture moves almost every lever in the right direction at once:
- Largest Contentful Paint (LCP): a pre-built page served from a CDN typically renders its main content in under a second, because there’s no server work to wait for.
- Interaction to Next Paint (INP): shipping less JavaScript means the browser has less to parse and execute, so the page responds to taps and clicks faster.
- Cumulative Layout Shift (CLS): rendering the full layout up front, rather than assembling it piecemeal in the browser, keeps content from jumping around as it loads.
Across our builds this consistently lands a 95+ Lighthouse performance score on every page and a typical 0.9-second LCP at launch — not as a one-off on the homepage, but as the baseline everywhere.
When static-first is the right call — and when it isn’t
Static-first shines for the majority of the web: marketing sites, corporate sites, documentation, content-heavy publishing, most eCommerce catalogue and content pages. If a page looks broadly the same for every visitor, there’s rarely a good reason to rebuild it on every request.
It’s the wrong default when a page is genuinely per-user and real-time — a logged-in dashboard showing live account data, a complex web application where the “page” is really software. For those, server rendering or a client-side application is the right tool, and we reach for it deliberately. The point of static-first isn’t dogma; it’s starting from the fastest possible baseline and adding complexity only where it earns its place.
That discipline — the fastest default, complexity only where it pays — is the same one that runs through everything we build. If you’re weighing up a new build or a rebuild of a slow existing site, that’s the conversation we’d start with.