Why I Moved My Site from WordPress to SvelteKit

I recently moved my website from WordPress to SvelteKit. Strictly speaking, WordPress and SvelteKit are not the same kind of tool. WordPress is a content management system, while SvelteKit is an application framework. But for my use case, they were solving the same practical problem: building and managing a website.

I now use SvelteKit for the frontend and Sanity as the CMS, so this was not a move away from content management entirely. It was a move away from WordPress as the center of the stack. WordPress is still excellent. It powers a huge part of the web for a reason. It is mature, flexible, well documented, and supported by a massive ecosystem. For many sites, especially content-heavy sites, small business sites, and projects where non-technical users need familiar editing tools, WordPress remains a very strong choice.

More control

The biggest reason I switched was control. With WordPress, I often felt like I was working around the system. Themes came with assumptions, plugins added their own patterns, and even simple changes could involve undoing defaults or bending the site around decisions made by tools I did not fully control. That is not necessarily a flaw in WordPress. It is part of what makes it useful to so many different people. WordPress has to support a huge range of sites, users, plugins, themes, and workflows. But I wanted something more direct.

With SvelteKit, I feel closer to the actual structure of the site. The routing, components, data loading, styling, and build process all feel more intentional. I am not starting from a large set of defaults and then trying to remove the parts I do not need. I am building up from a cleaner foundation.

Better control over performance

Performance was another major reason. WordPress can be very fast when it is set up well. A carefully built WordPress site with good hosting, caching, optimized themes, and minimal plugin usage can perform extremely well. The problem is that WordPress sites often accumulate layers over time. Plugins, page builders, analytics tools, theme features, embeds, forms, sliders, and other conveniences can all add weight. Individually, each one might be reasonable. Together, they can make the site harder to reason about.

With SvelteKit, I have more direct control over what ships to the browser. I can keep the frontend lean, decide how data is loaded, and avoid sending unnecessary code when a page does not need it. That does not automatically make every SvelteKit site fast. You can build a slow site with any framework. But SvelteKit makes it easier for me to understand what is happening and keep the site closer to the performance profile I want.

Fewer maintenance concerns

Maintenance was part of the decision too. WordPress maintenance was not a huge problem for me, but it was still something I had to think about. Core updates, plugin updates, theme updates, security patches, compatibility issues, and occasional plugin conflicts are all part of running a WordPress site. None of that is unusual, and much of it can be managed well. But it still adds background noise.

I wanted fewer moving parts. With SvelteKit and Sanity, the maintenance model feels simpler for my needs. There are still dependencies, updates, and things that can break. But the overall stack feels easier for me to understand and maintain because there is less hidden behavior coming from plugins or theme systems.

The JavaScript ecosystem fits how I work

Another reason is that I enjoy working in the modern JavaScript ecosystem. SvelteKit gives me access to a workflow I like: component-based development, modern build tools, TypeScript support, flexible rendering options, and easy integration with other frontend tools. PHP and WordPress are not bad. They are proven and widely used. But the part of web development I enjoy most right now is happening in the JavaScript ecosystem, especially around modern frontend frameworks, content APIs, server-side rendering, and static generation.

SvelteKit fits naturally into that world.

AI-assisted development has improved

One thing that used to make newer frameworks harder to adopt was tooling support, including AI support. Older, more established stacks usually had more examples, more documentation, and more training data behind them. That meant AI tools were often better at helping with WordPress, PHP, React, or other larger ecosystems than they were with newer or less common frameworks. That has changed a lot.

Recent models are much better with Svelte and SvelteKit, including Svelte 5. That makes a real difference. I can move faster, debug issues more easily, and get useful help without constantly correcting outdated syntax or patterns. AI is not a replacement for understanding the framework, but it does make working in newer stacks feel smoother than it did a few years ago.

Sanity covers the CMS side

The main thing WordPress gives you, beyond the website itself, is the editing experience. I still need that. I do not want every content update to require editing code. That is where Sanity comes in.

Sanity gives me structured content, a customizable editing environment, and an API-first approach that works well with SvelteKit. I can model content the way I want and keep the frontend separate from the CMS. It has its own tradeoffs. It is not WordPress, and it does not try to be. But for my site, it gives me the content workflow I need without tying the frontend to a traditional WordPress theme or plugin ecosystem.

WordPress is not the problem

I do not think everyone should leave WordPress. For many people, WordPress is still the right tool. If you need a familiar admin interface, a large plugin ecosystem, easy publishing workflows, lots of available themes, or a site that non-developers can manage without touching code, WordPress is hard to beat. The issue is not that WordPress is bad. The issue is that it is built to serve a very broad range of needs.

That breadth comes with baggage. WordPress has to maintain backward compatibility. It has to support a huge plugin and theme ecosystem. It has to work for beginners, agencies, publishers, businesses, developers, and non-technical users. That flexibility is powerful, but I no longer need all of it.

Why SvelteKit works better for me

SvelteKit feels cleaner for the way I like to build. I prefer working with components, routes, structured content, and a frontend that I fully control. I like being able to decide exactly how the site is assembled and what gets sent to the browser. I like having the CMS separate from the presentation layer. A setup that feels more direct.

WordPress is still excellent. But for my own site, SvelteKit with Sanity feels lighter, more flexible, and better aligned with how I want to work.