Why we chose Astro
Recipe for fast performing marketing websites
We are living in fascinating times of Web development. Engineers have never had so many choices with various UI libraries, bundlers, build tools, and most importantly, website-building frameworks.
For sure, the diversity and competition of those frameworks have a positive impact on the industry. Reactivity, island architecture, “resumability”, lazy loading, are all different great techniques to solve the modern website building pain points. But when we talk about pain points, who are we actually referring to? A user suffering due to pure website performance, an engineer who does not wish to sacrifice a developer experience due to performance, scalability, ecosystem choice? The answer is, it depends.
The reality is that most of the frameworks are meant for specific use cases; even if it is great in one case, it might not suit the other one. Just like you can’t treat everything as a nail when you have a hammer.
I highly recommend Fred Schott’s article about web framework performance based on the Chrome User Experience Report (CrUX).
When existing stack is a concern
My team at Nord Security is responsible for building and maintaining websites for the fastest VPN in the world, NordVPN. We have multiple marketing sites built by different people at different times. Some were made with Gatsby, and others with WordPress and a home-grown React-based SSG (static-site generator).
Those websites served us well. However, the rapid scale caused issues with the performance. Marketing needs became even more challenging to implement. It’s a proven fact that performance decrease causes a drop in sales, WPO Stats provides great case studies about that.
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 had to be 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.
We had many questions to solve:
- Which component framework do we use?
- Which website building framework do we use?
- What about organizing CSS?
- Which headless CMS system will satisfy the needs of the content editors, analysts, and engineers?
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.
Several proof-of-concepts and performance measurements were conducted. We wanted to increase confidence that the choice we make would not only cover the current needs but is also a future-proof. Many decisions to be made, which caused a danger of slowing down by postponing decisions.
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 on a regular basis.
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:
export default defineConfig({
output: ‘server’,
adapter: node(), // cloudflare(), vercel() ...
});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 was what pushed us to try something new: SolidJS.
Simple and performant reactivity for building user interfaces.
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 scripts 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 Katie Sylor-Miller in 2019 and is expanded 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 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. More information about the hydration topic can be found in this great article.
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.
Furthermore, it is so versatile that as Alan Kay said:
Makes simple things simple, complex things possible.
You need static side generation today? Possible. Scalability and continues deployment is a concern? Use existing SSR adapter and easily deploy your website to Cloudflare, Netlify or Vercel. It can even be wild as hybrid rendering mode, when despite default SSR toggle, some pages can be pre-rendered. The reverse is also planned into a roadmap.
The results
To see how well it worked, check out the Lighthouse scores for one of our reworked 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.
In a constantly evolving web development landscape, Astro’s all-in-one framework and island architecture prove to be a versatile and forward-thinking choice for building performant and flexible websites.
Thank you for reading!
PS. Stay tuned for my next article on the journey of switching to SSR with Astro and achieving a fully-fledged cloud-native deployment.
