Abstract background with soft green and blue geometric shapes overlaying a light gradient, creating a translucent and modern design.

How we made Storyblok and Astro deployments almost 11 times faster

Andrew Wagley LinkedIn

Head of Development

When you're running a large website built with Storyblok and Astro, build times can become a challenge as the website grows. More content, more languages and more pages all mean more work needs to happen before changes can go live.

We've recently tackled exactly this problem for Amtico, reducing production deployment times on Netlify from nearly 11 minutes to just over one minute. That's almost 11 times faster.

And we've achieved this as part of a major technical upgrade, without rebuilding the website, migrating content or requiring any downtime.

It's a good example of how much Storyblok and Astro have developed over the past few years, and how an existing website can continue benefiting from those improvements long after launch.

Three years of growth on Storyblok and Astro

Back in 2023, we launched Amtico's new website. It was our first project combining Storyblok and Astro, and marked the beginning of what has since become a core part of how we build websites at Anything.

Screenshot of a website displaying Amtico flooring options with a modern interior design setup, featuring a desk and staircase.

Website speed and performance had been a particular challenge for Amtico, so we chose Astro specifically for its ability to prerender pages into fast, static HTML. Rather than generating every page dynamically when someone visited, much of the website could be generated ahead of time and served efficiently.

Storyblok provided the other half of the solution, giving Amtico's content team the flexibility to create and manage content without relying on developers for every change.

And the approach has worked really well.

Since launch, Amtico has expanded into new markets, introduced more languages and continued creating content. Storyblok has allowed the website to grow alongside the business, while Astro has continued delivering the fast page-loading experience we originally set out to achieve.

There was, however, a consequence of that growth.

As the amount of content increased, so did the work required during each production build. More pages needed generating, more content needed retrieving from Storyblok and deployments were taking increasingly longer.

While the live website continued benefiting from Astro's performance, production deployments were approaching 11 minutes.

At the same time, Storyblok and Astro had both developed considerably since our original implementation, and we'd gained a huge amount of experience working with the two technologies.

We decided it was time to revisit the build process and take advantage of those improvements.

Why were our Storyblok and Astro builds taking so long?

Amtico's website uses a combination of static site generation (SSG) and server-side rendering (SSR), with eight distinct language and audience structures.

Marketing and content pages are largely prerendered during deployment, while areas such as product and retailer pages remain dynamically rendered. This gives us the performance advantages of static HTML alongside the flexibility needed for more dynamic functionality and Storyblok's Visual Editor.

The trade-off with prerendering is that some of the work happens during the build rather than when a visitor requests a page.

Every deployment requires Astro to identify which pages exist, retrieve their content from Storyblok, fetch related stories and reusable components, and generate the finished HTML.

When we investigated the build process, we found that a significant amount of time wasn't actually being spent compiling code. It was being spent waiting for Storyblok API requests to complete.

We needed to reduce that unnecessary work without compromising the performance benefits of the original architecture.

Making Storyblok API requests more efficient

One of the most effective improvements was changing how we retrieved content from Storyblok.

Previously, when Astro needed to discover which pages to generate, we were requesting complete Storyblok stories just to retrieve their URLs. That meant downloading entire content structures when all we actually needed was a list of paths.

We switched to using Storyblok's Links API, which returns lightweight information about the available pages without retrieving their full content.

Across eight language and audience structures, that's a considerable amount of unnecessary data we no longer need to fetch.

We also improved how individual pages retrieve related content. Pages containing articles, global components or references to other stories could previously trigger multiple separate API requests, sometimes fetching information we'd already retrieved elsewhere.

By batching requests, reusing content already available during the build and excluding fields we didn't need, we significantly reduced the amount of data being transferred and the number of requests required.

As part of the wider optimisation work, we also reduced one product-related Storyblok API response from 387 KB to just 42 KB, almost 90% less data.

This benefits both static page generation and dynamically rendered pages, reducing the amount of data transferred during builds and when handling live requests.

These changes highlight something worth considering when optimising Storyblok websites: it's not always about making API requests faster, but about making fewer requests and retrieving only the information you actually need.

Taking advantage of improvements to Astro and Storyblok

Alongside the API optimisations, we carried out a major upgrade of the underlying technology.

We moved from Astro 4 to Astro 7, upgraded Storyblok's Astro integration from version 4 to version 10, and updated Tailwind CSS, Svelte, Vite and Node.js. We also switched from npm to pnpm for more efficient dependency management.

Astro has come a long way, and the newer tooling gave us opportunities to simplify parts of the implementation.

One significant change involved CSS. Previously, much of the website's styling relied on Tailwind utilities within Astro components, with CSS processed alongside JavaScript and component compilation.

We've now moved the majority of this styling into dedicated native CSS files and separated CSS compilation from Astro's main build process.

While we've upgraded to Tailwind 4, its role is now much smaller, handling some remaining legacy utilities for spacing, alignment and colours rather than acting as the website's main styling system.

This simplifies the build process, makes component styling easier to maintain and lays the groundwork for eventually removing Tailwind altogether.

We also enabled Astro's experimental parallel prerendering, allowing multiple static pages to be generated concurrently rather than sequentially.

Combined with the improvements to Storyblok data fetching, these changes made the overall build process considerably more efficient.

Storyblok's Visual Editor has improved too

One of the things we've particularly enjoyed seeing over the past three years is how Storyblok has continued to improve its platform and its integration with Astro.

When we first launched Amtico, Storyblok already provided a flexible visual editing experience. Since then, the integration has matured considerably, particularly around live preview and how content updates are handled.

We've updated Amtico to take advantage of Storyblok's newer getPayload functionality, which allows us to reuse story data already supplied by the Visual Editor rather than making unnecessary additional API requests.

Comparison of webpage structure: left shows all sections reloading, right shows only content reloading for faster updates.We've also improved click-to-edit functionality across content blocks, making it easier for editors to select elements directly within the page preview and jump to the corresponding content in Storyblok.

For a growing multilingual website with complex layouts and lots of reusable content, these improvements make managing content more straightforward.

Importantly, the preview environment continues to use server-side rendering, meaning editors retain the flexibility of Storyblok's Visual Editor while production benefits from prerendered pages.

It's another example of how an existing website can benefit from improvements to Storyblok without needing to rebuild the entire platform.

A major technical upgrade without a major website project

Perhaps one of the most important aspects of this work is what we haven't had to do.

Anyone who's managed websites on traditional CMS platforms will be familiar with the challenges of major version upgrades. In our experience with platforms such as Umbraco, these could become substantial projects, involving significant redevelopment, client involvement and carefully planned migrations.

With Amtico, we've been able to modernise almost every part of the technology stack without rebuilding the website or migrating any content.

One of the biggest advantages was that we could run the original website and the upgraded version alongside each other, both using the same content from Storyblok.

This made development and testing much easier. We could compare the two implementations directly, identify any differences and thoroughly test the upgraded platform without interrupting the existing website.

Meanwhile, Amtico's content team could carry on creating, editing and publishing content in Storyblok as normal. There was no need to maintain two separate sets of content or freeze publishing while the upgrade was underway.

Once everything was tested and ready, we could switch over to the upgraded version without a content migration or planned downtime.

For Amtico, this hasn't meant another website project. The technical work has been handled by our development team, without requiring the client to get involved in a major migration, retrain editors or start again.

Of course, upgrades of this scale still require careful development and testing. But there's a big difference between improving an existing implementation and having to rebuild a website simply to move onto newer technology.

It's one of the long-term advantages of combining a headless CMS like Storyblok with a modern frontend framework like Astro. The content platform and the frontend can evolve independently, making it easier to keep the website up to date as technology changes.

The results from the upgrade have been significant

Comparison of deployment times: Before is 10m 52s, After is 1m 01s, demonstrating an 11x faster improvement.We've made Amtico's production deployments approximately 10.7 times faster, bringing the time required to publish a new deployment down from nearly 11 minutes to just over one.

The original figure is based on two production publishes measured on 21 October 2026, while the upgraded figure comes from our technical upgrade testing. We'll continue monitoring deployment times following the rollout.

For our developers, that means shorter feedback loops and less time waiting for changes to deploy. For Amtico, it means content updates can reach the live website sooner, alongside an improved editing and preview experience.

And perhaps most importantly, the original decision to use Storyblok and Astro continues to deliver exactly what we wanted: a fast, flexible website that can grow with the business.

What's next? Continuing to simplify the frontend

While this upgrade has delivered a significant improvement, we're not finished yet.

Our approach to frontend development has evolved considerably since we first built Amtico in 2023. On newer Anything projects, we've moved away from libraries such as Tailwind and Alpine.js, favouring native CSS and JavaScript wherever possible.

This gives us greater control over the code, reduces dependencies and makes websites lighter and easier to maintain.

Amtico still uses some Tailwind utilities and Alpine.js components, but we've already made significant progress towards simplifying the frontend. Our next goal is to remove these remaining dependencies and bring the implementation in line with how we build websites today.

AI is an established part of our development process at Anything. We use Cursor daily, with shared team knowledge, project-specific context and coding standards that help our developers work consistently across projects.

This is particularly valuable when modernising an established website like Amtico. Rather than manually refactoring hundreds of components, we can use AI-assisted development to accelerate repetitive changes, with our developers reviewing, refining and testing the results.

The combination of AI tools, shared knowledge and experienced developers allows us to move faster without compromising code quality or consistency.

We'll share more about how we're using this approach to migrate Amtico's remaining Tailwind components to native CSS, including the process, challenges and results, in a future article.

When we launched Amtico in 2023, it was our first Storyblok and Astro project. Three years later, both technologies have improved considerably, and so has the way we build with them.

Building a fast website is important. Being able to keep it fast, improve it and evolve the technology as the business grows is just as valuable.

Frequently asked questions about Storyblok and Astro performance

How can I speed up Storyblok and Astro build times?

Start by reducing unnecessary API requests. Use Storyblok's Links API for URL discovery, batch related content requests and reuse data already fetched. Optimising CSS compilation and enabling Astro's parallel prerendering can also significantly improve build performance.

Why do Astro builds get slower as a website grows?

When using static site generation (SSG), Astro generates HTML for each prerendered page during the build. As more pages, languages and content are added, builds can take longer, particularly when pages make multiple requests to Storyblok.

Is SSR better than prerendering for Storyblok websites?

Both approaches have benefits. Prerendering produces fast static pages, while SSR combined with CDN caching can deliver similarly fast responses without rebuilding the website when content changes.

For our newer Storyblok and Astro projects, we've moved towards SSR with CDN caching and Storyblok publishing webhooks to invalidate cached content when changes are published. Astro's newer Route Caching API makes this approach even more powerful, allowing us to combine fast page delivery with more immediate content updates.

Does a headless CMS make website upgrades easier?

Yes. A headless architecture separates content management from the frontend, allowing each to be upgraded independently. For Amtico, we upgraded Astro from version 4 to 7 without migrating content or interrupting the live website. We ran both versions alongside each other using the same Storyblok content, making testing and switching over straightforward.