Half the web runs on WordPress. Most of it is slow. That is not a coincidence, and it is not because the owners are doing anything wrong. WordPress is slow by architecture — the way it works fundamentally pushes sites toward poor performance unless a lot of expensive work fights against it.

I have audited and migrated a number of WordPress sites. Here is why they struggle, and what moving to a custom stack actually fixes.

How WordPress actually serves a page

When someone visits your WordPress homepage, here is what happens:

  1. The web server (usually Apache or Nginx) receives the request.
  2. It hands the request to PHP.
  3. PHP bootstraps the entire WordPress codebase — core, theme, every active plugin.
  4. PHP queries the MySQL database, often 30–100+ times to assemble a single page.
  5. The active theme renders HTML by stitching together templates.
  6. Every active plugin gets a chance to inject scripts, styles, and markup.
  7. The final HTML is sent back to the browser.
  8. The browser starts downloading the stylesheets and scripts — often 20+ separate files.
  9. jQuery loads (yes, still, in 2026). Then the theme's JS. Then each plugin's JS.
  10. Finally the page becomes interactive.

Every step above is slower than it needs to be. Typical result: a WordPress homepage takes 2–6 seconds to become usable on a mobile connection, with a page weight of 3–5 MB and a Lighthouse mobile score in the 40s.

Compare to a modern static site: the first byte arrives in under 100 ms from a global edge network, the entire page is ~200 KB, JavaScript is optional, and Lighthouse scores hit 95–100 consistently.

The specific things that make WordPress slow

Plugins stack up

The average WordPress site uses 15–25 plugins. Each one loads its own CSS and JS on every page, whether that page uses the plugin or not. A contact form plugin adds its assets to your homepage. An analytics plugin adds a third analytics layer. A "speed optimization" plugin adds another layer on top.

Plugin authors cannot know which pages their code is needed on, so they load everywhere. The result is dozens of files fighting for bandwidth on every request.

Themes are generalists

A WordPress theme has to work for bloggers, shops, restaurants, portfolios, and agencies. To do that it ships code for all of those use cases. Your brochure site loads the e-commerce CSS it will never use. Your shop loads the portfolio layout code.

Custom builds load only what the current page needs. I wrote more about this trade-off in Why I Build Custom Websites Instead of Using Templates.

PHP on every request

Unless you install caching (which many sites do not), every page view runs the entire PHP bootstrap. Even with caching, anything personalized — logged-in users, carts, form submissions — hits the full pipeline.

Modern stacks serve most pages as pre-rendered static HTML from a CDN. No PHP on the critical path.

The database is the bottleneck

WordPress's database schema is designed for flexibility, not speed. A single page load typically runs dozens of queries to assemble the content, meta fields, options, menus, and widgets. Add a few popular plugins and you are at 100+ queries per page. Each query is fast, but fast × 100 is slow.

Shared hosting

Most WordPress sites live on cheap shared hosting. That means your site shares CPU, memory, and disk I/O with hundreds of others. When a neighbor gets traffic, your site slows down. When they get hacked, you might too.

What "fixing it" actually costs

The honest answer: a serious WordPress performance rescue is expensive and often hits a ceiling. You can pay a specialist €1,000–€2,000 to:

  • Audit and remove unnecessary plugins.
  • Install a caching layer (WP Rocket, LiteSpeed Cache).
  • Move to better hosting (Kinsta, WP Engine — €30–€50/month).
  • Lazy-load images and defer scripts.
  • Minify and combine assets.

Best case, you go from a 45 Lighthouse mobile score to 75. Still not good enough for the top rankings. Still 3x the page weight of a clean custom build. And you are now paying €50/month for hosting on top of the one-time fix cost.

A custom rebuild on a modern stack (Next.js + Supabase, or a static Astro site for simpler cases) delivers a 95+ Lighthouse score out of the box, costs €5–€20/month to host, and does not need the plugin audit cycle.

When WordPress still makes sense

To be fair: WordPress is not always the wrong answer. It still wins when:

  • The site owner needs to edit everything themselves with zero developer involvement.
  • There is a specific WordPress-only plugin the business genuinely depends on.
  • The budget is below €1,500 and the alternative is nothing.
  • The team already knows WordPress and has no appetite to learn anything new.

For everything else — business sites that have to rank on Google, e-commerce, custom apps, anything where performance matters — custom builds on modern stacks are simply better. I explain my default stack choice in How I Use Next.js to Build Fast Business Websites.

Migration is easier than people think

If you already have a WordPress site and are considering a custom rebuild, the migration is usually straightforward:

  1. Export all content (posts, pages, media) via the WordPress REST API or a WXR export.
  2. Transform it into Markdown or a modern CMS structure.
  3. Build the new site with the real content.
  4. Set up redirects from old URLs to new ones so you do not lose SEO.
  5. Launch, monitor, and keep the old site alive for a few days as a safety net.

For a typical small business site this is 4–6 weeks of work. Clients who move from WordPress consistently report: faster loads, higher rankings, lower monthly costs, fewer random plugin update failures, and content updates that actually take seconds instead of minutes.

Work with me

If your WordPress site is dragging and you are considering either a performance rescue or a full rebuild, I run free audits and give honest recommendations — sometimes that means "fix your current site", sometimes "rebuild from scratch". Email info@tonibarisic.com or hit the contact form.