In this guide (8)
- 1How to measure slowness correctly
- 2The real causes of WordPress slowness
- 3Why caching doesn't solve everything
- 4The plugin problem and the hidden weight
- 5The WordPress database that slows down over time
- 6Hosting: when it's the problem and when it isn't
- 7What to do in practice
- 8When to stop optimizing and switch platform
Your WordPress site is slow. You've installed WP Rocket, optimized the images, switched hosting. It's still slow.
It's not your fault. It's the architecture's fault. WordPress has a structural performance problem that caching plugins partially solve — but not at the root. This guide explains the real causes of WordPress slowness, what works and what doesn't, and when it makes sense to stop optimizing and change approach.
How to measure slowness correctly
Before optimizing anything, you need to know what you're measuring. Perceived user speed and the PageSpeed score are two different things — and they're often confused.
The metric that matters for business is the Time to First Byte (TTFB) — the time the server takes to respond to the first request. If the TTFB exceeds 600ms, the problem is structural: it's in the server or the PHP code, not in the images or CSS. No caching plugin permanently fixes a high TTFB.
The metrics that matter for Google are the Core Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and Total Blocking Time (TBT). Google uses these metrics as a ranking factor — a slow site is penalized in organic search compared to faster competitors, even if the content is equivalent.
To measure correctly, use PageSpeed Insights on a normal connection — not locally, not with a VPN. The mobile score is what counts: Google evaluates the mobile version to determine ranking. A score below 50 on mobile indicates structural problems. Between 50 and 70 indicates possible but not urgent optimizations. Above 80, you're in a competitive position.
The real causes of WordPress slowness
WordPress is slow for specific reasons, not random ones. Knowing them is the first step to understanding what can be fixed and what can't.
PHP compiling everything on every request
WordPress is a dynamic PHP application. For every page visited, the server executes hundreds of lines of PHP — including files, initializing classes, loading plugins, querying the database — and then generates the HTML to send to the browser. This process happens from scratch for every request, even if the page hasn't changed in weeks.
OPcache reduces this cost by caching the compiled PHP bytecode — but every additional plugin adds code to execute, and OPcache doesn't eliminate database queries.
Database queries that multiply
A standard WordPress page generates 30-80 queries to the MySQL database. With additional plugins this number rises quickly — WooCommerce adds dozens of queries for every product page, SEO plugins add queries for metadata, security plugins add queries for logs and checks.
On a well-configured server, each query takes 1-5ms. With 80 queries, that's already 400ms of TTFB just for the queries — before even calculating PHP and network time. With unoptimized databases or poorly written queries, some individual queries can take 100-500ms.
The WordPress loop
WordPress loads the entire system — all active plugins, all their dependencies, all their hooks — even to serve a single static page. There's no native selectivity: if you have 30 active plugins, they're all initialized for every request, even those not needed for that specific page.
Why caching doesn't solve everything
Caching is the most common solution to WordPress slowness — and the most misunderstood. Plugins like WP Rocket, W3 Total Cache and LiteSpeed Cache are useful tools, but they only solve part of the problem and introduce additional complexity.
What caching solves
Page caching saves the HTML generated by WordPress and serves it directly without executing PHP or database queries. For static pages — homepage, text pages, blog posts — this drastically reduces TTFB for visits after the first one.
Object caching (Redis, Memcached) saves MySQL query results in memory. It reduces the number of actual database queries for repeated requests.
What caching doesn't solve
Caching doesn't work for dynamic pages — e-commerce carts, account pages, search results, pages with content personalized for a logged-in user. These pages must be generated from scratch for every request.
Caching doesn't solve the TTFB of the first request after a content change — every time you publish an article or update a page, the cache is invalidated and the next visit pays the full generation cost.
Caching doesn't solve undersized hosting problems. If the server doesn't have enough RAM or CPU to handle traffic spikes, caching mitigates but doesn't eliminate the slowdowns.
Caching doesn't solve the structural problem of slow queries. A query that takes 300ms is skipped by the cache — but when the cache expires, that 300ms query slows down the site again.
The caching paradox
The more caching plugins you add, the more complexity you introduce. Each caching plugin has its own invalidation rules, its own conflicts with other plugins, its own updates that sometimes break the configuration. Many slow WordPress sites have 3-4 optimization plugins installed that contradict each other — the result is often worse than a configuration without caching.
The plugin problem and the hidden weight
Every plugin installed on WordPress has a cost — in memory, in PHP execution time, in database queries, in loaded CSS and JavaScript files. This cost isn't always visible, but it adds up.
A form plugin like Gravity Forms adds 200-400KB of JavaScript on every page, even those without forms. An SEO plugin like Yoast adds 30-50 queries per page to read metadata. A security plugin like Wordfence adds a layer of control on every HTTP request that can add 50-150ms to the TTFB.
Most business WordPress sites have 20-40 active plugins. The aggregate cost of these plugins — even well-written ones — is real and hard to eliminate without removing the features they provide.
The correct way to check the impact of plugins is to disable them one by one and measure TTFB before and after with PageSpeed Insights. Often you'll discover that 2-3 specific plugins cause 70% of the slowdown — and that lighter alternatives or native solutions exist that don't require plugins.
The WordPress database that slows down over time
The WordPress database grows over time in ways that aren't always visible. The tables that grow the most and slow down queries are the less obvious ones.
The wp_options table is the most problematic. Any plugin can write data to the options table — configurations, temporary cache, logs. Over time this table can grow to contain thousands of rows, many of which are stale data from uninstalled plugins. WordPress loads the entire "autoload" portion of this table on every request — if it contains too much data, it adds hundreds of ms to the TTFB.
The wp_postmeta and wp_usermeta tables grow with post revisions, plugin metadata and session data. A site with years of history can have hundreds of thousands of rows in these tables — unindexed queries on these tables are among the most common causes of high TTFB.
Periodic database cleanup — removing excessive revisions, cleaning up wp_options, optimizing tables — is necessary but temporary. The structural problem is that WordPress doesn't handle database growth natively.
Hosting: when it's the problem and when it isn't
Hosting is often cited as the main cause of WordPress slowness — and sometimes it's true, but it's often used as a scapegoat for problems that exist independently of the server.
When hosting is the problem
Cheap shared hosting has limited resources shared with hundreds of other sites. If the TTFB from the server itself (measured with curl directly on the server) exceeds 300ms, the hosting is probably undersized. The solution is to move to a VPS with properly configured PHP-FPM and dedicated resources.
When hosting isn't the problem
If the TTFB from the server is under 200ms but the site is still slow, the problem is in the code — heavy plugins, slow queries, JavaScript that blocks rendering. Changing hosting won't solve anything in this case.
A simple test: measure the TTFB with curl directly from the server:
```bash curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://www.tuosito.it/ ```
If the result is under 200ms the server is adequate. If it exceeds 500ms the problem is in the hardware or in the PHP configuration.
What to do in practice
Before any optimization, measure the TTFB from the server with curl. This tells you immediately whether the problem is in the code/database or in the hardware.
Free Audit
Find out how much you're wasting with your current site.
Our technicians analyze your current stack — hosting, plugins, maintenance — and show you the real cost over 3 years. Free, no obligation.
Find out how much you're wasting →
If the TTFB from the server is high (over 300ms)
Enable MySQL's slow query log and identify queries that take more than 500ms. These are almost always queries on unindexed tables or queries from poorly optimized plugins. The solution is to add indexes to the columns used in the most frequent WHERE clauses or replace the responsible plugins.
Check the PHP-FPM configuration. With pm = ondemand every request creates a new PHP process from scratch — switch to pm = dynamic with start_servers suited to the available RAM. This alone can reduce TTFB by 30-50% on sites with intermittent traffic.
Check the wp_options table for autoload rows. A query showing more than 1MB of data in autoload is a problem:
```sql SELECT SUM(LENGTH(option_value)) as total_bytes FROM wp_options WHERE autoload = 'yes'; ```
If the TTFB from the server is low but the site is slow
The problem is on the frontend — JavaScript blocking rendering, unoptimized CSS, uncompressed images, fonts loaded in a blocking way. In this case frontend optimization plugins (WP Rocket, correct settings) are the right path.
Check which plugins contribute most to the slowdown by temporarily disabling them and measuring TTFB before and after. Often 2-3 specific plugins cause 70% of the problem.
When to stop optimizing and switch platform
Optimizing WordPress makes sense up to a point. Beyond that point, every additional optimization becomes more expensive and less effective — and the structural problem remains.
The signs that indicate it's time to consider a platform switch are specific:
You've already optimized hosting, PHP-FPM, database and plugins, and the TTFB remains above 400ms. You have more than 3 caching or optimization plugins installed that conflict with each other. Every WordPress update breaks something and requires technical intervention. Annual maintenance costs exceed the initial cost of building the site. The marketing team can't update content on its own without risking breaking something.
In these cases, the time and money spent on further optimizations yield diminishing returns. The same amount invested in migrating to a CMS with a more solid architecture produces structural — not temporary — results.
A managed proprietary CMS eliminates WordPress's structural problems at the root: no third-party plugins to update, PHP architecture optimized for speed, a database designed for the specific site's queries. The typical TTFB of a site on KeideaCMS is under 100ms from the server — with no caching plugins, no post-launch optimizations.
Detailed comparison
Want to see the full technical comparison between KeideaCMS and WordPress, feature by feature?
If your WordPress site is slow and you want to understand whether the problem can be optimized or is structural, you can request a free audit. We analyze TTFB, slow queries, PHP configuration and plugin weight — and we'll tell you honestly whether it's better to optimize or migrate.
KeideaCMS
Are you still paying for hosting, plugins and maintenance separately?
KeideaCMS includes everything in a fixed annual fee: dedicated hosting, maintenance, direct support in Italian and setup. Starting from €49/month, no surprises.
