Most hosting providers list WordPress requirements that barely keep the site alive. You need specs that match real traffic patterns, not just the install script.
I've migrated hundreds of WordPress sites between hosting environments. The gap between "it runs" and "it runs well" comes down to four resource categories: PHP configuration, memory allocation, disk performance, and database tuning. Let's break down what each traffic tier actually demands.
PHP version and configuration
WordPress will install on PHP 7.0, but you shouldn't run it there. The core team recommends PHP 7.4 or newer, and for good reason—each major version brings performance gains of twenty to forty percent.
PHP 8.0 and newer offer the best speed, but check your plugins first. A compatibility scan saves you from a white screen after the upgrade. Run this in your WordPress root:
wp plugin list --field=name | xargs -I {} wp plugin verify-checksums {}
Beyond the version number, three php.ini directives make or break performance:
memory_limitcontrols how much RAM a single request can consumemax_execution_timesets the wall-clock limit for scriptsupload_max_filesizegates media library additions
Default shared hosting often sets memory_limit to 128M. That works for a basic blog. Add WooCommerce or a page builder and you'll hit that ceiling during product imports or theme customization. I typically see support tickets when users try to upload a large media file or run a plugin update—both operations that spike memory use briefly.
Memory limits by site type
A content blog with ten plugins runs fine on 128M. Double that for WooCommerce stores. Membership sites with user-generated content need 512M to 1G, especially if you're processing video uploads or running background jobs.
You can check your current limit from the WordPress admin. Tools like Site Health (under Tools → Site Health) report the active memory_limit. If it's below 256M and you're running an online store, expect slowdowns during checkout or inventory sync.
Disk I/O matters more than disk space
Most hosts advertise storage capacity—50GB, 100GB, unlimited. That number rarely matters for WordPress. A typical site with a few thousand posts and images uses under 5GB.
What kills performance is slow disk I/O. WordPress writes to disk constantly: caching pages, logging errors, storing sessions, updating the database journal. An SSD with decent IOPS (input/output operations per second) makes admin actions feel instant. A spinning disk on a shared NFS mount makes every page save feel like pulling teeth.
I've seen identical WordPress installs where one loads the admin dashboard in under a second and the other takes eight. Same code, same database size—the difference was the hosting provider's storage backend.
How to test disk speed
SSH into your server and run a quick write test:
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct
That writes a 1GB file and reports throughput. Anything below 100 MB/s suggests slow storage. NVMe SSDs hit 500+ MB/s easily. Shared hosting on mechanical disks might show 30-50 MB/s, which explains why auto-saves lag and media uploads stall.
Delete the test file when you're done:
rm testfile
Database performance baseline
WordPress leans hard on MySQL or MariaDB. Every page view triggers dozens of queries—fetching post content, checking user permissions, loading theme options, retrieving widget data. A slow database turns a fast PHP script into a timeout.
Three configuration variables control how MySQL handles WordPress load:
innodb_buffer_pool_size = 256M
max_connections = 150
query_cache_size = 0
The buffer pool size should match your database size for best performance. A 200MB WordPress database fits comfortably in a 256M buffer pool, keeping hot data in RAM. Shared hosting rarely lets you tune this—another reason VPS and dedicated servers outperform budget shared plans.
Query cache sounds helpful but causes contention on busy sites. MySQL deprecated it in version 5.7 and removed it in 8.0. If you're still on an older version, set query_cache_size to zero and rely on object caching instead.
When the database becomes the bottleneck
WordPress installations grow in two dimensions: post count and plugin activity. A blog with ten thousand posts but simple queries runs smoothly. A store with five hundred products but complex inventory plugins hammers the database with joins and subqueries.
You'll notice database strain when:
- Admin pages take longer to load than the front end
- The wp-admin dashboard times out during traffic spikes
- Slow query logs fill up with SELECT statements against wp_options
The wp_options table is usually the culprit. Autoloaded options—data WordPress pulls on every page load—bloat over time as plugins add settings. Check the size:
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
Anything over 1MB slows page generation. Clean up orphaned options from deleted plugins or switch heavy options to non-autoload.
Object caching closes the gap
Out of the box, WordPress doesn't cache database queries between requests. Install Redis or Memcached and you cut database load by sixty to eighty percent.
Redis is easier to set up on most hosting environments. Install the Redis server, then drop in the WordPress object cache plugin. On Ubuntu or Debian:
sudo apt install redis-server
sudo systemctl enable redis-server
Then install the Redis Object Cache plugin from the WordPress repository. Activate it and click "Enable Object Cache" in Settings → Redis. The plugin writes a file to wp-content/object-cache.php that intercepts database calls.
Check if it's working:
redis-cli INFO stats | grep keyspace_hits
A healthy hit rate is above seventy percent. If it's lower, your cache size might be too small or the TTL (time to live) too short.
Traffic tiers and resource scaling
Let's talk real numbers. These are estimates based on typical WordPress configurations—your mileage will vary depending on page complexity and plugin load.
Small site: up to 1,000 daily visits
- 1 CPU core
- 2GB RAM
- PHP memory_limit: 256M
- Shared MySQL instance
- No object cache required
This tier covers personal blogs, small business sites, and portfolio pages. Shared hosting works fine here if the host isn't overselling. Look for providers that cap accounts per server and use SSD storage.
Medium site: 1,000 to 10,000 daily visits
- 2 CPU cores
- 4GB RAM
- PHP memory_limit: 512M
- Dedicated MySQL instance or managed database
- Redis or Memcached strongly recommended
Most business sites land here. You'll want a VPS or a quality managed WordPress host. The step up from shared hosting makes a visible difference in admin responsiveness and peak-hour performance.
Large site: 10,000+ daily visits
- 4+ CPU cores
- 8GB+ RAM
- PHP memory_limit: 512M to 1G
- Dedicated database server or cluster
- Redis or Memcached required
- CDN for static assets
At this scale you're looking at dedicated servers or cloud infrastructure. Load balancing and database replication become worth the complexity. A single server can handle more traffic than most people expect if you tune it properly, but redundancy matters when downtime costs revenue.
What about concurrent users?
Daily visit counts hide the traffic shape. A site with steady traffic all day has different needs than one with a morning spike when the email newsletter hits.
PHP-FPM workers determine how many requests your server handles simultaneously. Each worker consumes memory according to your memory_limit setting. Simple math: if you have 4GB RAM and set memory_limit to 256M, you can run about twelve workers before you're swapping to disk.
Check your current worker count:
ps aux | grep php-fpm | wc -l
Compare that to your FPM pool configuration in /etc/php/7.4/fpm/pool.d/www.conf (path varies by distro). Look for the pm.max_children directive. If that number is higher than your RAM can support, you'll see intermittent slowdowns when traffic peaks.
Start with your current metrics
Don't guess at requirements. Check what you're using now. Install Query Monitor or enable server-side monitoring to see real resource consumption. That tells you if you need more RAM, faster disks, or better database tuning.
Most performance problems trace back to plugins—specifically, poorly coded ones that run heavy queries on every page load. Audit your plugin list before you buy a bigger server. Sometimes deleting two plugins solves what looked like a hardware problem.
The specs I've outlined give you a baseline. Your actual needs depend on how you've built the site, which plugins you've installed, and whether you've set up caching properly. Start small, monitor closely, and scale when you see sustained resource pressure—not when a blog post tells you to.