Why we chose Astro for our marketing websites

Problems with our existing stack

My team at Nord Security is responsible for building and maintaining websites for the fastest VPN in the world. We have multiple marketing sites built by different people at different times. Some were made with Gatsby, others with WordPress, and still more with a home-grown React-based SSG (static-site generator).

Those websites served us well. However, rapid scaling has caused issues with website performance, which has a direct impact on sales and marketing. It’s a proven fact that a reduction in website performance (for example, slower load times) decreases sales. This has been demonstrated in studies from WPO Stats.

As the business scaled, my team had the challenging task of researching and proposing a tech stack to rebuild our websites and achieve optimal marketing potential.

A challenge

There was a lot of work to be done. We had more than 20 locales, 10 currencies, and thousands of pages. Personalization had to be considered and A/B testing implemented. Supporting an ever-expanding list of requirements while still achieving optimal performance felt like an impossible goal.

We tried different frameworks — Next.js, Preact, SvelteKit, and Elder.js — and even tried building server-side rendering and island architecture with Svelte. We had to find the best systems to satisfy the needs of content editors, data analysts, and engineers.

Of course, it’s not every day that a team gets a chance to rebuild their websites from scratch. We knew we could create something great, so we wanted to make the most of this opportunity.

Enter: Astro

As our research continued, it became clear that Astro, an all-in-one web framework, ticked all our boxes. We had initially ruled out Astro because it didn’t offer server-side rendering, but when this feature was added in 2022, we knew that we’d found our framework.

Astro is not a mainstream framework, of course, and when we were considering it, the framework was still in beta. Going down this route was a risk, but it was one we were willing to take. Why? Because not only did it fulfill almost all of our requirements, but it already had a vibrant and active community and a responsive developer team. New features are planned, implemented, and delivered several times a week.

Along with server-side rendering, Astro’s developers had added Node.js support and edge deployment. These factors facilitate streamlined continuous deployment and enhance the power of a globally deployed content delivery network, allowing for unmatched performance. Edge deployment with Cloudflare, Vercel, and Netlify involves only a few simple steps, but the impact is huge.

With just a few lines of code, we now had server-side rendering enabled on our desired deployment server.

Benefits of Astro

During the research phase, we noted that Svelte syntax, being a superset of HTML, was much easier to work with than React syntax. The same went for Astro. We have hundreds of different components to implement, most of which require little to no JavaScript, so being able to convert them to the HTML-style syntax of Astro made those components more readable.

The complex components that required client-side JavaScript and reactivity were another story. Our main requirement of reaching optimal website performance pushed us to try something new: SolidJS.

SolidJs is performant-reactive and simple for building user interfaces. It uses JSX syntax, works well for server-side rendering, and offers outstanding performance. It does all this with a fraction of the size of other libraries that usually come shipped with a browser.

Furthermore, both Astro and SolidJS share the concept of so-called vanishing components. Components exist to organize your code and not much else. What is shipped to the client is pure HTML and CSS.

Client-side JavaScript is an opt-in feature in Astro. Unless you specifically use one of the client directives, the component is shipped with 0kb of JavaScript. Of course, you also have the option to bundle global or local script straight from the component code.

SolidJS and other framework components are inserted into Astro files using the “islands architecture” pattern. The pattern was proposed by frontend architect Katie Sylor-Miller in 2019 and is expanded on in this post by Preact creator Jason Miller.

Here are the possible client directives for making “islands” interactive:

• client:load — Loads JavaScript and hydrates the component on page load.
• client:idle — Loads JavaScript and hydrates the component after page load once the main thread is idle.
• client:visible — Embraces the power of Intersection Observer API and loads JavaScript only if the component becomes visible.
• client:media — Useful in cases where certain components should be visible and interactive only on certain screen sizes.
• client:only — Skips server-side rendering and runs the code on the client. Be careful with this one because it can push down your SEO scores.

Some parts of the page can be fully static, without any JavaScript needed, while other parts, or islands, may require a JavaScript. The process of resolving the component state is called hydration.

Though the JavaScript community is still split over whether hydration is the right approach compared to resumability, it solves our current problems nicely.

With Astro, islands come with another benefit: various component framework support. It offers flexibility when choosing a UI framework, and has integrations to work with React, Svelte, SolidJS, and Vue. Of course, you won’t typically mix those, but it gives you flexibility and room to maneuver.

The results

To see how well it worked, check out the Lighthouse scores for one of our new websites, nordvpn.org:

The other projects integrated well with our Cloudflare Pages, and more will be built soon!

The pace of releases, weekly community calls, RFCs, the involvement of the core team, and its vibrant community all serve to confirm that we made the right choice with Astro.