From Angular to Astro: Why I Rebuilt My Website
Why I rebuilt my own website from Angular to Astro: almost no JavaScript, easier upkeep, clearer texts. With real measurements.
Until autumn 2026 this website ran on Angular. Today it runs on Astro. That was not a switch for fashion’s sake, but a correction: I had chosen a tool built for applications for a website full of text.
This article covers why I rebuilt it, what changed and what it brought. I measured the numbers on both versions on the same day.
Why I chose Angular first
Angular is the framework I know best. I wanted to see what speed I could get from an enterprise framework. That is the name for frameworks built for large company applications.
In the PageSpeed test, which I ran during development, the site scored 84 out of 100 on mobile and 100 on desktop. PageSpeed is a free test from Google that rates how fast a page loads. That was good enough. After that I switched to Astro, a lighter framework that mostly ships CSS and HTML and only small amounts of JavaScript.
The starting point
The old website ran on Angular with server-side rendering. That means a server assembles each page before it goes to the browser. It was hosted on Railway, with Cloudflare in front. For Google that was fine, because search engines got finished pages to read.
The problem lay elsewhere. Angular is made for web applications: programs in the browser with logins, forms and lots of clicks. My website, though, consists mainly of text: services, prices, projects and articles. For a site like that, the setup was too heavy.
What the old setup cost
- A server of its own, just so the pages could be created.
- 476 KB of JavaScript on the home page, spread over 15 files. The browser has to load and run all of it.
Why Astro
When I publish, Astro turns every page into a finished HTML file. Cloudflare delivers these files directly, with no server of its own behind them. JavaScript only goes where it is really needed: on the home page, it is one small script for the menu on phones.
The articles are now simple text files in Markdown, with a few characters for headings and links. German and English sit side by side, and every page has its English version at the same address with /en/ in front.
Only the contact form still needs a small piece of code on a server. It receives the inquiry and passes it on to my server at Railway. That server now does only two things: contact inquiries and the AI chat.
A check also runs every time I publish. It checks whether all old addresses still work, whether any code sits directly in a page, and whether every page carries its structured data in full. Structured data are the details in the code from which Google reads, for example, services, prices and address.
What it brought
Measured on the home page, both versions on 30 September 2026, counting only files from the site’s own domain:
- JavaScript: before 476 KB in 15 files, now under 1 KB in one file.
- HTML: before 107 KB, now 57 KB.
- CSS: before 23 KB, now 59 KB. The new design draws more, so the CSS has grown. Unlike JavaScript, though, the browser does not have to run it first.
- Readability of the German text (Flesch-Amstad score): before 38, now 60. Scores under 50 count as hard to read, scores around 60 as easy to follow.
Readability has nothing to do with the technology. I did not notice it at first. Then someone from my circle of friends opened the old website and did not understand it. An online test confirmed it: the texts were too technical. So I rewrote every page during the rebuild.
In the PageSpeed test, the mobile score rose from 84 to 94. On desktop it dropped from 100 to 96. The CSS is large because every drawing on this website is code. For that amount, the result is good. I would not dwell on these numbers: the test runs on old phone models and a slow 4G connection. If your page loads in under 2.5 seconds, that is fine.
How fast the site loads for real visitors will only show in Google’s data after a few weeks. I will add those figures here as soon as they are available.
The AI chat stayed as it was
The chat is a small program of its own, built with Preact, a lean alternative to React. It runs in a sealed-off frame (a sandboxed iframe) at its own address, separate from the rest of the page. In the background, a RAG system first looks up matching content before the language model Gemini answers. So the answers are based on real content.
Because the chat did not depend on Angular, I could take it over unchanged in the rebuild. That is exactly what the separation was for: it can go on any website, whatever it is built with.
What I take away
- The tool follows the content. Angular is the tool I know best. For a website full of text, it was not the best choice.
- For real applications, a framework stays right. For logins, a customer area or lots of input, Angular is still a good tool.
- No address was lost. All 60 old addresses still lead to the right page, either directly or through a permanent redirect.
- Rebuilding early is cheaper. The younger a website is, the less depends on it.
Which technology suits which website is explained in the article WordPress or a custom website. For most businesses, a lean business website is enough.