Why static-first architecture matters more than schema in a post-search world

Everyone is asking the same question right now: how do you stay discoverable in a search landscape that is no longer just search? Llms, AI overviews, agentic browsing and traditional engines are all reading content through different paths, and the answers on offer are everywhere, schema markup, brand mentions in training data, citation strategy, topical authority, generative engine optimisation.

Most of that conversation focuses on content. Far less of it focuses on the architecture the content sits on, and that is where I think a significant advantage is hiding. The architecture decides whether the content can be read at all.

For full disclosure, paulthinks.com is built on Astro for exactly this reason. IMO it is the single best architecture for discovery-optimised content right now, and the rest of this piece is the working that got me there.

The architecture point most people skip

The dominant pattern in modern web development is to send minimal HTML to the browser and let JavaScript construct the actual page on arrival. That works for a human on a fast device, less well for everything else trying to read the page (crawlers, llms, agentic systems), because every additional step between the request and the readable content is a place where retrieval fails or gets deprioritised.

Single Grain’s analysis of JavaScript-heavy sites in llm retrieval is direct: rendering strategy is the single biggest technical lever for how content performs in both search rankings and llm retrieval. The 2025 Web Almanac shows 52% of mobile websites fail at least one Core Web Vital in real-world field data, regardless of how well they score in lab tests (source).

Static-first architectures invert the default. Content is pre-rendered to finished HTML at build time, so what ships to the browser, the crawler or the llm is the page itself rather than a set of instructions for assembling the page. Astro is the framework leading this shift for content-driven sites, using a pattern it calls “islands architecture”: static HTML by default, with small isolated interactive components only where interactivity is genuinely needed.

Astro sites routinely score 95-100 on Lighthouse without manual optimisation, and Single Grain’s rendering strategy comparison is explicit on the llm side: client-side rendering produces a high chance of empty or low-text snapshots for llm crawlers, while static-site generation produces stable, complete snapshots. Core Web Vitals are a confirmed Google ranking signal, so the search visibility translation is direct. For llms and agentic crawlers, pre-rendered HTML is immediately readable with no JavaScript runtime to wait on and no risk of content being invisible because a script failed.

Why the edge changes the calculation

Static generation alone is a known quantity. The shift worth paying attention to is what happens when you combine it with edge deployment, which is what the Cloudflare acquisition of Astro in January 2026 is engineered for.

Edge deployment puts content on servers distributed around the world rather than in a single data centre. A request gets served from the closest node, dropping time to first byte and latency regardless of where the request comes from.

The implication for llms is the more interesting one. Pre-rendered content served from the edge is computationally cheaper to crawl: no server-side rendering to trigger, no database to query, no JavaScript runtime to spin up. As crawler traffic from llms continues to grow, and the energy/compute cost of llm operations becomes a real industry conversation, static + edge becomes a meaningful efficiency story at scale. Cloudflare buying Astro is the proof point that this matters at infrastructure scale; their edge network and Astro’s static-first architecture are the same bet expressed two different ways.

Two responses to the same problem

The website builder industry has been working on the same performance problem for years, and the response has split into two camps making opposite architectural bets.

The first camp engineers around the heavy stack. Duda has led website-builder Core Web Vitals pass rates since 2021, claiming 82% of Duda sites pass all three CWV metrics through critical CSS inlining, lazy loading, bfcache support and ETag header optimisation (marking their own homework, but the methodology is published). The lab results are real. The underlying stack is fundamentally JavaScript-heavy, and field performance degrades fast once clients use the platform as intended. PageSpeed Matters’ analysis of real Duda sites reports that the average Duda site takes over 3 seconds to load on mobile, and that most have multiple header/footer script injections (analytics, chat widgets, CRM integrations, review platforms, marketing pixels) which combine with heavy widgets to create 1-3MB of JavaScript blocking the main thread. The pattern repeats across the AI builder category. AdwaitX tested 30+ AI website builders over eight weeks and 23 failed basic quality checks, shipping with over 300KB of unused CSS, lacking export options or scoring below 70 on Google PageSpeed Insights.

The second camp removes the cause. Static-first architectures do not need critical CSS inlining or bfcache optimisation because they are not shipping the JavaScript that creates the problem in the first place. Same outcome on a synthetic Lighthouse test, very different exposure when real-world content, widgets and scripts get layered on top.

There is a contradiction worth pulling out of this. AI is accelerating publication volume across the website-builder category at exactly the moment infrastructure is moving the other way (static + edge + minimal JavaScript). More content, generated faster, deployed onto the heaviest stacks, while the architectural frontier is going somewhere else. My read is that the engineering-around approach has a ceiling, and the architectural-rethink approach is where the discoverability advantage compounds.

Cloudflare’s own press release notes Webflow and Wix run on Astro infrastructure via Cloudflare. The heavy-stack builders are quietly betting on the architectural-rethink camp themselves.

Who is making this bet

The Astro showcase is the cleanest way to see the scale, but a few names are worth pulling out for what they signal.

Cloudflare’s developer documentation runs on Astro. Self-evident given the acquisition, but worth noting that the company’s primary developer-facing surface is built on the framework they have just bought. Firebase Studio and the Firebase blog run on Astro, which is a credibility marker because Google is not going to publish on a stack that hurts their own indexing. Microsoft’s Fluent 2 Design System follows the same logic.

Beyond the platform vendors: Visa’s Product Design System, Unilever Global, IKEA Global, Porsche, The Guardian Engineering, NordVPN, Marie Curie, Michelin, Proton and Jamie Oliver are all live on the framework. Content-led surfaces, where being found matters and the cost of running a heavier stack is no longer justifiable.

OpenAI is named as an Astro adopter in coverage of the Cloudflare acquisition, though the specific surface is not detailed publicly.

Where the architectural answer is the wrong answer

This is not a universal position. Astro is built for content, not transactions. Real-time inventory, personalised pricing, complex authenticated flows, heavy back-end logic on every request, wrong framework. Next.js with server-side rendering or hybrid approaches still wins for application-layer work.

The clean line: if the primary purpose of the site is publishing and being found, the architectural argument applies. Most marketing sites, documentation, blogs, news publications and content portfolios sit cleanly in that bucket. Hybrids are also viable; Astro 6 includes Server Islands that allow real-time data to stream into otherwise static pages, so even sites with some dynamic requirements can stay on the architecture without falling back to a fully dynamic stack.

So what

Schema markup, citation strategy, brand mentions, generative engine optimisation, none of it does the work it is meant to do if the content sits on an architecture that makes it expensive to read. The content-led discoverability conversation is not wrong, it is incomplete.

Static-first architecture treats every reader the same, whether human, search crawler, llm or agentic system. Same finished HTML, served from the closest edge node, no rendering tax. That is a different design philosophy to the one the JavaScript-heavy web has been operating on for the last decade, and it is the one Cloudflare has just placed a very large bet on. Discoverability is now an architectural question as much as a content one, and the half of the conversation that does not get the airtime is the half that decides whether the rest of the work compounds.