What 3 Production Astro Sites Taught Us About Content Architecture at Scale

Three real production projects. Three different architectures. One clear conclusion: there's no one-size-fits-all template for content at scale.

Since Cloudflare acquired Astro in January and Astro 6 shipped in March, we've seen a wave of agencies and brands migrating content sites to the framework. The promise is tempting: zero JavaScript by default, lightning-fast build times, and the flexibility to choose between static, dynamic, or hybrid rendering with Server Islands.

But the reality of a production content site — with hundreds or thousands of pages, multiple languages, heavy images, video, and editorial teams publishing daily content — rarely matches the five-page demo.

Over the last six months, we launched three production sites on Astro 6 for different clients. Each one forced us to rethink a different aspect of content architecture. Here's what we learned.

Site 1: Multi-language Editorial Portal — 2,500+ pages, 3 languages, daily updates

The challenge: An editorial client with content in Spanish, English, and Portuguese needed to migrate 2,500+ articles from WordPress. The editorial team publishes 10-15 articles daily. The previous site loaded in 8 seconds on mobile.

The architecture we chose: Astro 6 with static Content Collections for 95% of pages, Live Collections for the homepage and featured sections (which need updates without a full rebuild), and deployment on Cloudflare Pages with the native adapter.

What worked:

• Content Collections with Zod 4: We typed every article with strict schemas, including metadata for images, author, categories, and related content. Zod 4 forced us to clean up legacy WordPress data that had null or inconsistent fields. It hurt during migration, but we haven't had a single content error in production since.
• Incremental builds with the experimental Rust compiler: The full build (2,500+ pages) takes 4 minutes 12 seconds. But for daily changes (10-15 articles), incremental builds run between 8 and 15 seconds. The editorial team can't tell the difference between publishing in WordPress and seeing the change go live.
• Automated image pipeline: We integrated @astrojs/image with an external CDN to generate 5 variants per image (AVIF, WebP, JPEG in 2 sizes). The client uploads a 5MB photo; the site serves 40KB in AVIF. Median LCP on mobile dropped from 4.2s to 1.8s.

What didn't work:

• We underestimated the WordPress data migration. Gutenberg blocks converted to flat JSON fine, but custom embeds (YouTube videos with specific parameters, complex tables) required manual transformations. We budgeted 3 days; it took 8.
• Live Collections on the homepage: It works perfectly, but when the site got a traffic spike (50,000 visits in one hour during a live event), every Live Collection request hit the content server. The fix was adding Redis as an intermediate cache with a 60-second TTL. Additional cost: ~$15/month.

Key metric: Median TTFB dropped from 680ms (WordPress + server in Miami) to 98ms (Astro 6 + Cloudflare CDN with edge in Panama). Lighthouse score went from 38 to 97 on mobile.

Site 2: E-commerce Catalog + Blog — mixed content, frequent inventory updates

The challenge: A retail brand with 800 products and a weekly content blog. They needed product pages with real-time availability but static blog pages. The marketing team uses Shopify for inventory and a headless CMS (Storyblok) for editorial content.

The architecture: Hybrid Astro 6 — Static Collections for the blog and content pages, Live Collections for products (connected to Shopify via the Storefront API), Server Islands for availability and price widgets inside static pages.

What worked:

• Multiple content sources weren't a problem. Astro handles different loaders naturally. We defined defineCollection for Storyblok and defineLiveCollection for Shopify. The framework resolves the right source every time.
• Server Islands for the availability widget: Category pages are fully static (200+ products listed). Each product card has a Server Island that queries current stock. The user sees the page instantly, and stock widgets appear 200-400ms later. The click-through rate on "out of stock" items dropped 34% because users no longer land on product pages to discover there's no stock.
• The product image pipeline is still the biggest bottleneck. Not because of Astro — because of inconsistent photo quality from the client. Lesson learned: the technical pipeline solves format and size, but it can't fix bad product photography. We now include a photography guide in the delivery documentation.

What we learned:

• The full build with Live Collections is slower (~6 minutes vs 2 minutes without them), but incremental builds mitigate this for daily changes.
• Shopify as a live content source requires rate limiting. On Shopify Plus it's fine, but on basic plans, frequent Storefront API queries can generate additional costs.

Key metric: First Contentful Paint on category pages: 0.6s. JavaScript bundle size: 3KB (vs 85KB on the previous Next.js site).

Site 3: Heavy Media Brand Portal — video, animations, and 4K galleries

The challenge: A luxury brand wanted a portal combining high-resolution image galleries, background video, entrance animations, and an immersive visual experience — without sacrificing Core Web Vitals or accessibility.

The architecture: Astro 6 with Server Islands for lazy video loading, @astrojs/image with AVIF pipeline for galleries, and animation components with client:load only where the user actually interacts. Everything served from Cloudflare with long cache durations.

What worked:

• Server Islands were the star here. The homepage background video (a 30-second 4K loop) lives in a Server Island that doesn't load until the user scrolls or interacts. The main page loads with a 12KB poster image instead of an 8MB video. LCP improvement was dramatic: from 6.2s (with preloaded video) to 1.2s (with poster + lazy loading).
• Animations stayed server-side. We used Astro's View Transitions for page transitions (zero additional JavaScript) and native CSS for scroll animations. Only truly interactive components (mobile menu, gallery zoom) use client-side JavaScript, and that's with client:visible so they don't load until the user can actually see them.
• AVIF as the default format: With the image pipeline, all galleries converted to AVIF (with WebP and JPEG fallbacks). 4K images dropped from 3-5MB to 120-250KB with no visible quality loss.

What didn't work:

• Overengineering Server Islands. In the first version, we Server Island-ed almost everything: the menu, footer, social widgets. Technically correct, but unnecessarily complex. Lesson: only use Server Islands when the component's load time justifies the overhead of an additional async request. Static menu and footer render in 50ms. They don't need to be islands.
• Complex animations required JavaScript. For a parallax scroll-tracking animation, native CSS wasn't enough. We ended up using an 8KB library (Lenis) for smooth scrolling, loaded with client:visible. It was the exception, not the rule.

Key metric: Lighthouse Performance Score: 99 (with video), 100 (without video). INP: 98ms. Cumulative Layout Shift: 0.02.

The Decision Framework We Now Use

After these three projects, we crystallized a simple framework for deciding content architecture on each new project:

The rule: start with the simplest architecture that works, and only scale when metrics prove you need more complexity.

What We'd Do Differently

Looking back, three things stand out:

1. Invest more time in content modeling before writing code. Across all three projects, we underestimated how long it would take to map existing data to Zod 4 schemas. For the next project, we'll dedicate a full week to modeling before writing the first line of code.

2. Don't start with Server Islands by default. Astro's modularity invites you to think "everything can be an island." The reality is that most components don't need to be. Server Islands add an additional network request — use them only when a component clearly benefits from deferred loading.

3. Set a performance budget from day one. On the editorial site, we didn't establish a JavaScript limit until the editorial team started adding third-party widgets. Now we have a CI workflow that fails if total JS exceeds 50KB or if any single page's bundle exceeds 15KB.

Astro 6, in production and at scale, delivers on its promises — as long as you respect its assumptions. Content-driven, server-first, zero JavaScript by default. The more your project aligns with those principles, the more Astro gives you: speed, simplicity, and green metrics. The more you deviate, the more you'll need to complement it with other tools.

At Mintec, we build on Astro, Next.js, and other frameworks depending on the use case. Contact us if you want a no-obligation assessment of which architecture fits your next project.