惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
SegmentFault 最新的问题
Jina AI
Jina AI
罗磊的独立博客
V
Visual Studio Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
J
Java Code Geeks
U
Unit 42
Microsoft Azure Blog
Microsoft Azure Blog
B
Blog RSS Feed
爱范儿
爱范儿
酷 壳 – CoolShell
酷 壳 – CoolShell
Last Week in AI
Last Week in AI
T
The Blog of Author Tim Ferriss
腾讯CDC
Hugging Face - Blog
Hugging Face - Blog
T
Tailwind CSS Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
I
InfoQ
月光博客
月光博客
博客园_首页
Vercel News
Vercel News
P
Proofpoint News Feed
GbyAI
GbyAI
Y
Y Combinator Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Why I Built My Own Site with Astro, Not WordPress when I ...
Mathieu Mull · 2026-05-21 · via DEV Community

Mathieu Muller

The short version — WordPress is a brilliant tool — it's also the wrong tool for a site that's nothing but articles, calculators, and a sitemap. Tinkernotes has no logins, no comments, no checkout, and no database it can't live without. So it's an Astro site built as static HTML and served from Cloudflare Pages. The result is a site that costs £0/month to host, ships almost no JavaScript, and can't be hacked the ways WordPress sites get hacked. If you're a WP dev sitting on a content project, this is the build I'd push you towards.

I've spent eight years shipping WordPress and WooCommerce for a UK agency — custom plugins, themes, gateway integrations, the lot. WordPress pays my mortgage. So the most reasonable question about this site is: why isn't it WordPress? I've had that question from two developers I respect already. Here's the long answer.

The choice I was expected to make

If you'd asked me to build a content site any year from 2014 to about 2022, the answer was reflex: WordPress. Pick a host, install WP, drop in a block theme or build one, add Yoast for SEO, write. I could have had Tinkernotes live in an afternoon and never thought about it again. That's not a knock on WordPress — that is WordPress's superpower. It collapses "publish a website" into a solved problem.

But "I already know how" is a sunk cost, not a reason. So before defaulting, I wrote down what this site actually has to do:

  1. Render articles, reviews, and guides from text I write.
  2. Run two interactive calculators in the browser.
  3. Generate a sitemap, meta tags, and structured data.
  4. Be fast, and stay cheap.

That's the whole list. Notice what's not on it: no user accounts, no comments, no shopping cart, no form that writes to a database, no content edited by anyone but me. The moment I saw the list written out, WordPress stopped looking like the obvious answer and started looking like a lot of moving parts solving problems I don't have.

What WordPress would be carrying that I don't need

A standard WordPress install is a PHP application that boots on every request, talks to a MySQL database, runs the plugin and theme hook stack, and assembles HTML — then you bolt a caching plugin on top to avoid doing most of that. It's a dynamic system pretending to be a static one because, for a content site, static is what you actually want.

Everything dynamic about WordPress is also its attack surface and its maintenance bill:

  • The database. A dependency, a backup job, and a thing that can get out of sync.
  • PHP version drift. Hosts deprecate, plugins lag, you babysit the gap.
  • Plugin updates. Yoast, a cache plugin, a security plugin — each one a small recurring risk and another notification.
  • The login page. /wp-admin and /wp-login.php are probed by bots within minutes of going live. Every WP site I've ever run shows it in the logs.

None of that is hard for me — I do it for clients every week. But it's all labour, and it's labour in service of capabilities this site will never use. Zero of those moving parts make a single article load faster for a reader.

The framing

A blog is read far more often than it's written. WordPress optimises the writing moment — the dashboard — and pays for it on every read with a PHP and database round-trip. A static site inverts that: do the work once at build time, then serve plain files forever.

The stack I chose, and what each piece does

Nothing here is exotic. It's the boring, well-trodden static stack — which is exactly the point.

Astro is the framework. I write content as MDX — Markdown with frontmatter, plus the ability to drop components into the prose. Astro renders every page to plain HTML at build time and ships zero JavaScript by default. The interactive bits — the 3-year cost calculator and the hosting cost calculator — are Svelte "islands": JS loads only for that component, only on the pages that use it. The article you're reading ships no framework JavaScript at all.

Cloudflare Pages hosts it. I push to main on GitHub, Cloudflare builds the site and serves the static output from its edge network. There's no origin server to keep patched, because there's no origin server. The free tier covers unlimited bandwidth and 500 builds a month — comfortably more than a one-person site needs.

Git is the CMS. Content lives in the repo as .mdx files. Every edit is a commit; every commit is a diff, a history, and a one-line rollback. I get drafts via branches and review via pull requests — the workflow I already use for code, now also for prose.

For a developer this is a feature, not a compromise. For a non-technical client it would be a non-starter, and that distinction matters — I'll come back to it.

What I gave up coming from WordPress

I want to be honest about the trade, because "just use a static site" advice usually isn't.

What I gained

  • No server to patch, no PHP version to chase, no database to back up
  • Hosting cost is £0/month on Cloudflare Pages — and stays £0 under traffic spikes
  • No /wp-admin to be brute-forced; the attack surface is basically static files
  • Pages render as pre-built HTML — fast without a caching plugin bolted on
  • Content is versioned in Git: real diffs, real history, instant rollback

What it cost me

  • No dashboard — publishing means a commit and a build, not a "Publish" button
  • No mobile editing, no "fix a typo from my phone in the pub" moment
  • A content rebuild runs on every change; fine at this size, slower at thousands of pages
  • The plugin ecosystem is gone — anything WP gives you free, you wire up yourself
  • It is a developer workflow: hand this stack to a non-dev client and it falls over

The last one is the real boundary. WordPress's enduring genius is that it hands a non-technical person a usable website and the means to run it. The day-to-day editor isn't meant to touch code. Astro-on-Git assumes the editor is the developer. For Tinkernotes — a personal site I both build and write — that assumption holds perfectly. For most of my agency clients it would be indefensible.

What changed once it was live

Three things, concretely.

Performance came for free. No caching plugin, no CDN to configure, no image optimisation stack to tune. The pages are already static HTML with hashed assets, served from the edge. I set a Lighthouse budget of 95+ and hitting it has mostly been about not breaking it, rather than chasing it.

The security worry just... left. There's no admin login to harden, no plugin CVE feed to watch, no "is this theme still maintained" question. A static file can't run a SQL injection. That's not nothing — a meaningful share of agency emergency work is cleaning up compromised WordPress installs.

Cost went to zero and stayed there. No managed WordPress host, no renewal-rate surprise twelve months in. If a post ever does numbers, Cloudflare's edge absorbs it on the same free tier — a static file under load is still just a static file. (Renewal-rate games are exactly the trap I dig into in the Kinsta UK review and Hostinger UK review — worth a read if you are hosting WordPress.)

When I'd still reach for WordPress — and I would

This isn't a conversion story. WordPress is still the right call when the site needs the things WordPress is for:

  • A non-technical person has to publish and manage content independently.
  • The site is genuinely dynamic — accounts, comments, gated content, member areas.
  • It's a shop. WooCommerce on WordPress is still where I'd start most UK ecommerce builds — the whole Shopify vs WooCommerce comparison exists because that decision is rarely obvious.
  • You need to move fast with a known team and a deep plugin ecosystem behind you.

The mistake isn't choosing WordPress. The mistake is choosing it by reflex — defaulting to a dynamic CMS for a job that's pure content, then spending the project budget caching and securing your way back to the static site you could have built directly.

The takeaway

Match the tool to the workload, not to your CV. Tinkernotes is content and calculators with one developer-author, so it's static HTML on the edge. Your next build might point straight back at WordPress — and that's fine, as long as you actually looked.

If you want the longer version of who's writing this and why, the about page covers it. The short version: I still write WordPress for a living. I just stopped assuming it was the answer before I'd heard the question.


More from Tinkernotes: