![Advanced Speed Up WordPress: 7 Errors [Solved]](/images/blog/advanced-speed-up-wordpress-7-errors-solved.jpg)
You've installed a caching plugin, compressed your images, and ticked every optimization checkbox—yet your WordPress site still crawls. The problem isn't that you skipped a tutorial step. It's that the real bottlenecks hide behind symptoms that look identical on the surface: a slow admin dashboard, a five-second Time to First Byte, or a frustrated user closing the tab before your hero image loads.
In support tickets I handled, the usual culprit wasn't a missing plugin. It was a bloated transient table, an unclosed database connection, or a theme pulling in forty separate CSS files. Below are seven errors that kill WordPress performance in production—each with the symptom you'll see in the browser or logs, the root cause underneath, and the exact fix.
Error 1: Slow queries from wp_options autoload bloat
Symptom
Your homepage takes three to five seconds to load the first byte, even with an empty cache. The admin dashboard is sluggish when you open any settings page. A query monitor plugin shows wp_options taking hundreds of milliseconds per request.
Root cause
WordPress loads every row in the wp_options table where autoload='yes' on every single page load. Plugins and themes add their settings there, but many never clean up when you deactivate them. Over time that table grows to several megabytes. I've seen wp_options autoload data hit 8 MB on a two-year-old WooCommerce install.
The fix
Check your autoload size first:
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options
WHERE autoload='yes';
Anything above 1 MB deserves cleanup. Identify the offenders:
SELECT option_name, LENGTH(option_value) / 1024 AS size_kb
FROM wp_options
WHERE autoload='yes'
ORDER BY size_kb DESC
LIMIT 20;
You'll see transients, old plugin settings, and serialized arrays. For transients that should have expired, delete them:
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND autoload='yes';
For orphaned plugin data, change autoload to no instead of deleting—it won't load automatically anymore but the plugin can still retrieve it if reactivated:
UPDATE wp_options
SET autoload='no'
WHERE option_name='old_plugin_settings';
Flush your object cache afterward if you're using Redis or Memcached.
Error 2: Unindexed postmeta queries
Symptom
Archive pages or custom post type listings load slowly. Query Monitor or the slow query log shows SELECT statements against wp_postmeta taking a second or more. CPU spikes when users browse product categories or filter results.
Root cause
WooCommerce, custom fields, and ACF all store data in wp_postmeta. Every query filters by meta_key and sometimes meta_value, but the default index only covers post_id and meta_key. A table scan happens when you filter by value—especially on text columns.
The fix
Add a composite index that covers the columns your queries actually use. For WooCommerce price filters, this speeds up most product archive queries:
ALTER TABLE wp_postmeta
ADD INDEX meta_key_value (meta_key, meta_value(20));
The (20) prefix length keeps the index size reasonable for long text fields. Check your slow query log for the exact meta_key values you're filtering on and create targeted indexes:
ALTER TABLE wp_postmeta
ADD INDEX _price_index (meta_key, meta_value(10))
WHERE meta_key='_price';
MySQL versions 8.0.13 and later support partial indexes with WHERE, which saves space. Test the query before and after with EXPLAIN to confirm the index is used.
Error 3: Render-blocking CSS and JavaScript
So what if the backend is fast but the browser still paints slowly?
Symptom
Lighthouse or PageSpeed Insights flags render-blocking resources. Your First Contentful Paint sits above two seconds. Users on mobile see a blank screen, then everything pops in at once.
Root cause
WordPress core, your theme, and every active plugin enqueue their own CSS and JavaScript files. By default these block rendering—the browser downloads and parses each one before painting anything. A typical install loads a dozen separate stylesheets in the <head>.
The fix
Combine and minify your assets first. Use a plugin like Autoptimize or WP Rocket to concatenate CSS and JS into single files. Then defer non-critical scripts:
function defer_non_critical_scripts($tag, $handle) {
$defer_scripts = ['jquery-migrate', 'contact-form-7'];
if (in_array($handle, $defer_scripts)) {
return str_replace(' src', ' defer src', $tag);
}
return $tag;
}
add_filter('script_loader_tag', 'defer_non_critical_scripts', 10, 2);
For CSS, inline critical styles directly in the <head> and lazy-load the rest. Autoptimize has a built-in feature for this. Check that your above-the-fold content renders without waiting for full stylesheets—run a test with throttled 3G in Chrome DevTools.
Error 4: Image optimization skipped for user uploads
Symptom
Your homepage loads a 4 MB JPEG hero image at full resolution, even though the CSS renders it at 1200px wide. Lighthouse flags "serve images in next-gen formats." Mobile users burn through data allowances.
Root cause
WordPress generates thumbnails when you upload an image, but it doesn't compress the originals or convert them to WebP. Editors upload straight from their phone camera without resizing. A single uncompressed image can be larger than your entire HTML, CSS, and JavaScript bundle combined.
The fix
Install an image optimization plugin that processes uploads automatically—Smush, EWWW, or ShortPixel all work. Configure them to create WebP versions and serve them via <picture> tags or content negotiation.
For existing images, run a bulk optimization:
wp media regenerate --yes
wp smush optimize --all
If you're on a VPS and want more control, use ImageMagick directly:
find wp-content/uploads -type f -name '*.jpg' -exec mogrify -strip -quality 82 {} \;
That strips EXIF data and recompresses to 82% quality, which is visually lossless for web use. Pair it with cwebp for WebP generation:
find wp-content/uploads -type f -name '*.jpg' -exec sh -c 'cwebp -q 82 "$1" -o "${1%.jpg}.webp"' _ {} \;
Update your .htaccess or Nginx config to serve WebP when the browser supports it.
Error 5: No persistent object cache
Symptom
Your site feels fast after you load a page, but the first request after clearing cache is slow. Database queries repeat on every page load even though the content hasn't changed. CPU usage spikes during traffic surges.
Root cause
WordPress core includes an object cache, but it's non-persistent—it only lasts for a single request. Every page load queries the database for the same options, post data, and taxonomy terms. On a high-traffic site that's thousands of redundant queries per minute.
The fix
Install Redis or Memcached and configure WordPress to use it. On Ubuntu with Redis:
sudo apt install redis-server php-redis
sudo systemctl enable redis-server
Copy the object cache drop-in to your wp-content directory:
cd /var/www/html
wget https://raw.githubusercontent.com/rhubarbgroup/redis-cache/master/includes/object-cache.php
mv object-cache.php wp-content/
Define the Redis host in wp-config.php:
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
Flush the cache and test:
wp cache flush
redis-cli MONITOR
You should see cache keys being set and retrieved. Check your query count before and after—most sites drop from a hundred queries per page to under twenty.
Error 6: External HTTP requests blocking page load
Symptom
Your site hangs for several seconds on certain pages, then loads instantly on refresh. The browser's network tab shows a long wait time for the HTML document itself. Query Monitor reports external HTTP requests timing out.
Root cause
Plugins make outbound HTTP requests during page rendering—checking license keys, fetching social share counts, or validating API tokens. If the remote server is slow or down, WordPress waits for the request to time out before continuing. That blocks the entire page.
The fix
Identify which plugins are making external requests. Install Query Monitor and check the "HTTP API Calls" panel. You'll see the URL, response time, and the plugin responsible.
For requests that don't need to be synchronous, move them to a cron job:
function fetch_remote_data() {
$response = wp_remote_get('https://api.example.com/data');
if (!is_wp_error($response)) {
update_option('cached_api_data', wp_remote_retrieve_body($response));
}
}
add_action('my_hourly_cron', 'fetch_remote_data');
Then read from the cached option during page load instead of making the request. For license checks and other blocking calls, add a short timeout:
$response = wp_remote_get('https://licensing.example.com/validate', [
'timeout' => 2,
]);
Two seconds is enough to fail fast without hanging the page.
Error 7: Excessive revisions and trashed posts
Symptom
Your database backup file is multiple gigabytes even though you only have a few hundred published posts. Queries against wp_posts are slower than expected. Searching in the admin takes several seconds.
Root cause
WordPress saves every revision when you edit a post—draft saves, autosaves, and manual saves all create new rows in wp_posts. A single post can have fifty revisions. Multiply that by hundreds of posts and your wp_posts table balloons. Trashed posts and orphaned postmeta rows add to the bloat.
The fix
Limit revisions going forward by adding this to wp-config.php:
define('WP_POST_REVISIONS', 5);
That keeps the five most recent revisions per post. For existing revisions, clean them up with WP-CLI:
wp post delete $(wp post list --post_type='revision' --format=ids) --force
Empty the trash:
wp post delete $(wp post list --post_status=trash --format=ids) --force
Optimize the table afterward:
OPTIMIZE TABLE wp_posts;
Check for orphaned postmeta rows—metadata without a corresponding post:
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
Back up your database before running that. I've seen it reclaim gigabytes on old WooCommerce installs.
What to check first
Start with your wp_options autoload size and your database indexes. Those two fixes alone resolve the majority of WordPress performance issues I see in production. Install Query Monitor and Redis before you add another caching layer—object cache has a bigger impact than page cache for logged-in users and dynamic content.
Check your slow query log regularly. MySQL writes queries that take longer than a threshold you define, usually two seconds. That log tells you exactly where to optimize:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
Restart MySQL and let it run for a day, then review the log. The queries at the top are your priorities.
Questions
How do I know if my site needs Redis or Memcached?
If you're using a shared hosting plan, you probably can't install either. On a VPS or dedicated server, install Redis if your object cache hit rate is below 90% or you're seeing repeated database queries for the same data.
Can I just increase PHP memory instead of cleaning up wp_options?
Increasing memory_limit doesn't fix the problem—it just delays the crash. WordPress still loads the entire autoload array on every request, which wastes CPU and database connections even if you have RAM to spare.
Should I delete all post revisions?
Keep a few recent revisions in case you need to roll back an edit. Deleting everything makes recovery harder if an editor accidentally overwrites a post.
Why is my site still slow after adding a CDN?
A CDN serves static assets faster, but it doesn't help with Time to First Byte or database bottlenecks. Fix your backend performance first, then add a CDN to speed up asset delivery.
How often should I optimize my database tables?
Once a month is enough for most sites. Run OPTIMIZE TABLE during off-peak hours—it locks the table briefly.
Fix the root cause
Performance issues compound. A slow query makes the object cache less effective, which increases load, which makes the next query slower. Start with the errors that have the biggest measurable impact—autoload bloat and missing indexes—then work through the rest. Monitor your changes with actual metrics: Time to First Byte, query count, and cache hit rate. Those numbers tell you whether a fix worked better than any subjective assessment.