--- title: "Why I Rebuilt My Website on Svelte Instead of WordPress" url: "https://kevinyoung.net/writing/why-i-rebuilt-my-website-on-svelte-instead-of-wordpress/" description: "I rebuilt kevinyoung.net as a static SvelteKit site for fewer moving parts and full control, and it scores 92 percent on a 172-topic web quality checklist. WordPress is still the right tool for most business sites." --- 1. [Home](https://kevinyoung.net/index.md) 2. [Writing](https://kevinyoung.net/writing.md) 3. Why I Rebuilt My Website on Svelte Instead of WordPress [Writing](https://kevinyoung.net/writing.md) kevinyoung.net # Why I Rebuilt My Website on Svelte Instead of WordPress Kevin Young September 30, 2026 \[Image: A hand lifting the orange Svelte logo out of a browser window, with the WordPress logo on a tile beside it\] _Last verified: September 30, 2026_ I rebuilt kevinyoung.net as a static site on SvelteKit and SveltePress instead of WordPress, the tool I use for most client work. I wanted fewer moving parts, control over every line the browser receives, and a public scorecard to hold myself to. Against a 172-topic web quality checklist, the site scores 92 percent by its own audit, failures included. WordPress is still the right tool for most business sites, and RdyToGo still builds them. This is one personal project: what I chose, what the sources say, and where my opinion takes over. ## How does a web designer end up with a stale website? The same way a mechanic ends up with a noisy car. I built sites for clients for years while mine sat frozen in 2023, with an About page describing a business that no longer looked like that. It bothered me more than I admitted. My first website was the one a classmate and I built in high school, around 1997. We taught ourselves HTML in Notepad, and our computer teacher turned our new hobby into a class project: the whole class built the school's first website. Every page was a plain file on a server. Nothing to update, nothing to patch. It just loaded. Twenty-nine years later, the most modern thing I could build for myself turned out to be plain files again. With a lot more care under the hood. ## What checklist did I measure it against? I used [specification.website](https://specification.website/), a free, open checklist of what a good website does. It covers 172 topics in ten categories: Foundations (20), SEO (14), Accessibility (30), Security (20), Well-Known URIs (13), Agent Readiness (21), Performance (26), Privacy (7), Resilience (8), and Internationalisation (13). Every topic links to the standard behind it, from W3C to WCAG, and the site says the spec applies whether you ship WordPress, Next.js, or plain HTML. One small irony made me smile. The checklist was written by Joost de Valk, who founded Yoast SEO, one of the best-known WordPress plugins. So the ruler I held my non-WordPress site up to came from one of WordPress's own. Good standards don't care what you build with. I asked Claude to audit the live site against every item, and I [published the results](https://kevinyoung.net/website-audit.md), misses included. As of this writing: 92.0 percent, 268.5 of 292 applicable points. SEO scored 27 of 27. Accessibility scored 60 of 63. Security is the weakest category at 80 percent. The score was lower when I started writing this post, because I kept fixing things. That is a self-assessment by an AI, not a certification, and I have not re-checked every row by hand. The audit page says so at the top. ## Why not just build it in WordPress? Because WordPress is the right tool for a different job. It runs about 40 percent of all websites and nearly 60 percent of sites with a known CMS, according to W3Techs. It's open source, its plugin directory covers almost anything, and non-technical people can edit it. I co-organize the Myrtle Beach WordPress Meetup, and RdyToGo builds WordPress sites every week. This is not a breakup post. WordPress does come with a maintenance job. In September 2026, version 7.1.1 shipped on the 17th with a batch of security fixes. Version 7.1.2 followed on the 22nd to close a critical flaw, rated 9.2 out of 10, that could let an attacker with no login run code on some servers. Both came with the same advice: update immediately. Core security updates usually install themselves. Themes and plugins are where a person still has to click, test, and sometimes clean up after an update that breaks something. That's not a scandal. It's the cost of being the software 40 percent of the web runs on, because attackers aim where the crowd is. I spent years on that treadmill for clients, which is why I started Firebolt, which turns a WordPress site into a pre-built static copy. Could I have hit the checklist with WordPress? Probably, with enough plugins or enough custom code working against the platform's assumptions. For my own site, I wanted fewer moving parts. ## What did I build it with? Seven tools, each chosen for one job, served through Netlify and Cloudflare. I didn't type every line myself. I built the site in conversation with Claude and Claude Code, Anthropic's AI coding tools. I decided what to build, looked at the results, and asked for changes until they were right. My [AI policy page](https://kevinyoung.net/ai-policy.md) spells out who did what. **Node** is the engine everything runs on. It's one more thing to keep updated, but a quiet one. **pnpm** installs the site's building blocks. Instead of copying every package into every project the way npm does, it keeps one copy on disk and links to it. It also won't run a new package's install scripts until I approve them, which blocks a favorite trick of supply-chain attacks. pnpm's own benchmark page shows it beating npm in all six test scenarios; a fresh install of its "alotta-files" test project took 4.42 seconds against npm's 48.4. That's pnpm's own lab, on one machine. Take the direction, not the decimals. **TypeScript** is spell-check for code. It flags mistakes while I type, before anything runs. The cost is a learning curve and a stricter build, and it only catches the kinds of mistakes a type system can describe. **Svelte** builds the parts people see and click. It does its work when the site is built, turning components into small JavaScript files, where React does more of its work in the visitor's browser. More on speed below. **SvelteKit** is the framework around Svelte, and I picked it for how seriously it takes static sites. By default, its static adapter fails the build if any page didn't prerender, so I can't ship a half-static site by accident. One setting pre-compresses every file with Brotli and gzip. Its docs even warn that single-page-app mode hurts performance and SEO. **SveltePress** turns Markdown into pages. Out of the box it offers search and an llms.txt file for AI tools, but I skipped its themes and built a custom one, so every page looks and behaves the way I wanted. The tradeoff is community. WordPress has a meetup in my town; I help run it. SveltePress has a GitHub repository. When something breaks at 11 p.m., that difference matters. **UnoCSS** writes the styles. It generates only the styles I actually use, and it lets me define my own design rules instead of adopting someone else's. I'm not claiming smaller files than Tailwind. I'm claiming a better fit for how I work. **Netlify and Cloudflare** serve the site. HTTPS, security headers, and DNS protections live there, not in the framework. A static site hands a lot of its safety to its host, so choose the host carefully. ## Is Svelte really faster than React? On the one public benchmark I trust, yes. In the js-framework-benchmark's Chrome 152 run, Svelte 5 scored 1.17 and React 19 (hooks) scored 1.58 on the keyed CPU average, where lower is better. By my arithmetic, React's score is about 35 percent higher. That benchmark times components updating a big table on one machine. It says nothing about whole websites, and nothing about SvelteKit versus Next.js. And honestly, on a personal site that's mostly words, visitors will never feel that gap. What they feel is how much a page sends them, and a prerendered page sends very little. ## What about Next.js? I found no public benchmark comparing SvelteKit to Next.js, so I'm not claiming either is faster. Both can build a fully static site. Next.js lists what its static export gives up: rewrites, redirects, custom headers, incremental regeneration, default image optimization, draft mode, and more. To be fair, SvelteKit's static output can't do those things itself either. My redirects and headers live in Netlify and Cloudflare. The difference I care about is defaults: SvelteKit refuses to publish a half-static site unless I tell it to. That's my preference, not a measurement. ## Which projects should still use WordPress? Most of them. In 1999, I taught a computer class for adults through my township's Parks and Recreation department. My oldest student, an 82-year-old cake maker, lifted the mouse off the desk on the first night and pointed it at the screen. A few months later, she was running her business from a computer. [Her story is here](https://kevinyoung.net/writing/never-old-learn.md). People like her deserve a dashboard, a preview button, and a big Publish button. That's WordPress. If your staff edits content, if a team publishes together, or if you need ecommerce, booking, or memberships, use WordPress. The same goes if you want to hire help easily in any city. The static stack fits a different kind of project: a personal site, a marketing site, documentation, or a blog where a developer publishes and quality control is the point. Most RdyToGo clients belong in the first group, and that's fine. The second group now has an option that wasn't on our menu before. Picking the right tool for each project is the whole job. ## What did I get wrong along the way? Plenty, and the audit page keeps the receipts. - My first attempt at a vector favicon weighed 827 KB, traced from a photo with 1,481 paths. A simpler trace and some cleanup got it to 27 KB. - A keyboard-only test found that the Display settings panel opened but left focus behind, so pressing Tab skipped right past it. Fixed. - Turning JavaScript off revealed a row of dead buttons: menu, search, theme toggle. They now stay hidden until scripts run, and a plain row of links replaces the menu. - On a simulated slow phone, the main image still takes 4.6 seconds to appear. Google's "good" line is 2.5 seconds. That one's still open. - The Spanish and Portuguese pages started as machine translations. Friends who speak those languages natively are reviewing them. I'd rather show you that list than a perfect score. ## What is the evidence behind these claims? This section is for readers who want to check my work. I opened each source below on September 30, 2026. **Svelte vs React.** js-framework-benchmark, Chrome 152 official results. Keyed implementations, CPU, weighted geometric mean of slowdown compared with the fastest implementation. Svelte 5.42.1 scored 1.17; React Hooks 19.2.0 scored 1.58. The "about 35 percent" is my arithmetic: (1.58 − 1.17) ÷ 1.17. The page shows no run date, so I cite it by Chrome version. It measures UI frameworks, not SvelteKit against Next.js. **pnpm.** pnpm's benchmark page, alotta-files project, npm 12.1.0 against pnpm 12.7.0, fastest of three runs, over an emulated 50 ms, 200 Mbps connection. Clean install: 48.4 s vs 4.42 s. Nothing changed: 1.24 s vs 18 ms. It's vendor-run on one machine, three of nine scenarios are left out, and the page rebuilds with new numbers on every deploy. **WordPress.** Usage: W3Techs, September 21, 2026. Releases: WordPress 7.1.1 (September 17) and 7.1.2 (September 22), which fixed CVE-2026-87902. **The audit.** [kevinyoung.net/website-audit](https://kevinyoung.net/website-audit.md): 268.5 of 292 applicable points, weighted by each item's tier (3 points for Required, 2 for Recommended, 1 for Optional). Audited by Claude, not independently certified. **Also checked:** the specification.website checklist, the SvelteKit adapter-static docs, the Next.js static exports docs, and the SveltePress README. ## Frequently asked questions ### Should I move my WordPress site to SveltePress? **Probably not.** If your staff edits content, a team publishes together, or plugins run your store, bookings, or memberships, WordPress is the better fit. Moving means rebuilding how your people publish, not just the pages. A static stack suits sites where a developer publishes and quality control matters most. RdyToGo builds both and will tell you which one your project needs. ### Can my staff edit a SveltePress site without a developer? **Not the way they edit WordPress.** Content lives in Markdown files, and changes go live through a build step. There's no dashboard, no preview button, and no plugin to install for a new feature. Someone comfortable with a text editor can learn it in an afternoon. If your team edits daily and would rather not see code, choose WordPress. ### Is Svelte faster than React? **On the js-framework-benchmark's Chrome 152 run, yes:** Svelte 5 scored 1.17 and React 19 scored 1.58, where lower is better. That's about 35 percent apart by my arithmetic. It measures how fast components update on one machine, not how fast whole websites load, and it doesn't compare SvelteKit with Next.js. ### Does this stack cost less to maintain? **It has fewer things that can break.** There's no plugin update treadmill, no database to patch, and the output is plain files. But fewer developers know Svelte than know WordPress or React, so finding help is harder. Maintenance gets cheaper and hiring gets harder. Budget for both with open eyes. ### What does the 92 percent audit score mean? **It means the site earned 268.5 of 292 possible points** on specification.website's checklist, with more weight on required items than optional ones. Claude ran the audit, not an independent auditor, and I published every result, including the failures. It covers SEO, accessibility, security, performance, privacy, and more. The number changes as I fix things. ### Is RdyToGo dropping WordPress? **No.** RdyToGo still builds WordPress sites and will keep building them, because WordPress is the right tool for sites that clients edit themselves. The static stack is a second option for projects that want the control and quality bar of a hand-tuned site. Two tools, chosen per project. ## Want a website built to this standard? If you want a site held to the same bar as mine, on WordPress or on this static stack, [contact RdyToGo](https://rdytogo.com). You'll talk to me directly. [← All writing](https://kevinyoung.net/writing.md)