Making WordPress fast
WordPress on a dedicated server is capable of a great deal. Most slow installations are slow for the same four reasons.
1. No page cache
Every anonymous visitor runs PHP and hits the database for a page that is identical for all of them. A page cache turns that into a static file.
Options, in order of speed: nginx fastcgi_cache at the web server
level, or a plugin such as WP Super Cache or W3 Total Cache. The nginx route never
wakes PHP at all, which is why it is faster by an order of magnitude.
Exclude the admin area, logged-in users and the cart from caching, or you will serve one customer's basket to another.
2. No object cache
WordPress caches internally per request, then throws it away. A persistent object cache in Redis keeps it between requests, which helps exactly the pages a page cache cannot help: the admin, the checkout, anything for a logged-in user.
Install Redis, bind it to localhost with a password, and use a Redis object cache plugin. See Redis and caching.
3. PHP-FPM left at defaults
Opcache off, or on with too little memory, costs you a recompile on every request. Pool sizing left at the shared-hosting default wastes the machine you just bought. See tuning PHP-FPM — opcache alone is usually the single biggest win on a WordPress box.
4. The database has never been cleaned
Post revisions, expired transients, orphaned metadata and spam comments accumulate
for years. On an old site the wp_options table with autoloaded data is
frequently the slowest thing in the installation:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';
Anything much over a megabyte is loaded on every single request. Find the worst offenders, and remove the plugins that left them behind. Then see database basics for the buffer pool.
The plugins that cost most
- Anything doing work on every page load that could be scheduled — related posts, popularity counters, broken-link checkers
- Statistics plugins that write to the database on every hit. Use a proper analytics tool instead.
- Security plugins doing in-PHP what a firewall and fail2ban do better and cheaper
- Page builders that load megabytes of CSS and JavaScript on every page
Measure rather than guess: Query Monitor shows you which plugin is responsible for which queries and how long they took.
The usual order of work
- Opcache and PHP-FPM sizing
- Page cache for anonymous traffic
- Object cache in Redis
- Database cleanup and indexes
- Images: resize properly, serve WebP, lazy-load
- Only then, more hardware
And keep it updated. WordPress and its plugins are the most attacked software on the web; an out-of-date installation becomes someone else's spam relay. See securing a new server and a compromised server.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base