The web presence for Rigelian and my other applications has been based on Wordpress for a number of years, but I was never truly satisfied with it.
It felt bloated and slow, unlike the software it’s representing, which aims to be simple, straightforward and fast. Time for a change.
Limitations of the WordPress Setup
WordPress is a mature and capable system, particularly well-suited for content-heavy or highly dynamic platforms. However, for a small product site consisting primarily of static marketing pages and occasional blog posts, the operational model became disproportionate to the requirements.
Runtime overhead
WordPress generates pages dynamically per request:
- PHP execution on every request
- Database queries for content, configuration, and plugins
- Plugin and theme asset loading
Even with caching layers enabled, the baseline stack remains heavier than a purely static delivery model. For largely immutable content, this introduces unnecessary moving parts.
Operational maintenance
The system required continuous attention:
- Core updates
- Theme updates
- Plugin updates
- Security patches
Each update cycle carries compatibility risk and verification overhead. For a solo developer, this maintenance effort competes directly with product development time.
Theming abstraction
Themes provide rapid setup but enforce structural and stylistic assumptions. Customizing layout, spacing systems, or typographic hierarchy often required overriding theme defaults. This introduced CSS layering complexity and reduced design precision.
For use cases involving dynamic content management or editorial workflows, these trade-offs are justified. For a focused product site, they represented avoidable complexity.
Migration to Astro
Astro follows a build-time rendering model.
Pages are compiled into static HTML during the build process. The deployed artifact consists of static assets that can be served directly by a CDN or basic hosting provider without a server-side runtime.
Deterministic output
- No PHP execution at request time
- No database dependency
- No server-side templating
- No runtime plugin execution
The result is deterministic output: each request returns a pre-generated HTML file with no computation required. And because it’s all static html that can be served up without any server-side processing, it performs really well.
I thought my website was slow because of my cheap hosting program, but it was related to the use of Wordpress. With the move to astro all pages now appear with minimal delay.
Reduced client-side JavaScript
Astro’s “islands architecture” allows JavaScript to be shipped only where interactivity is explicitly required. Static sections remain zero-JS by default. This reduces bundle size and improves initial render performance.
Build-time asset optimization
Images are processed during the build:
- Multiple resolutions generated automatically
- Format optimization (e.g. modern formats when appropriate)
- Responsive image markup generated at compile time
This shifts computational work from the client and server runtime to the build step, where it is predictable and controlled.
Lower operational surface area
The deployment artifact is static:
- No admin interface exposed publicly
- No plugin ecosystem
- No server-side runtime dependencies
Security exposure and update cadence are therefore significantly reduced.
Content workflow
Content is written in Markdown or regular html and compiled into static pages. The model remains flexible: interactive components can be introduced selectively without converting the entire site into a client-rendered application.
Use with AI
By dropping the source folder into Codex, AI assisted updates are very easy to achieve. It understand the astro setup and can change the layout and styling based on prompts, allowing to focus on just the content.
CI/CD: automatic uploads via github actions
When the sources are hosted in github, a github action can automatically build and upload the website to a provider. I’m using Strato, which supports only sftp for uploads. The action definition below (kept in .github/workflows) takes care of the entire process, using lftp.
name: Build and Deploy Astro (SFTP)
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- name: Install dependencies
run: npm ci
- name: Build Astro site
run: npm run build
- name: Install lftp
run: sudo apt-get update && sudo apt-get install -y lftp
- name: Add SFTP host key
run: |
mkdir -p ~/.ssh
ssh-keyscan -H ${{ secrets.SFTP_HOST }} >> ~/.ssh/known_hosts
- name: Deploy via SFTP
run: |
lftp -u "${{ secrets.SFTP_USER }},${{ secrets.SFTP_PASSWORD }}" sftp://${{ secrets.SFTP_HOST }} <<EOF
mirror -R --delete --verbose dist/ /dist/
quit
EOF