Common Performance Issues

Dobsie finds the same handful of issues on most WordPress sites. Here’s what they are, why they happen, and what to do about them.

—

Too Many Database Queries

What Dobsie shows: High query count in the toast (200+), or a plugin dominating the Deep Scan bar chart.

Why it happens: Some plugins run a separate database query for every item they display. A product grid showing 20 products might run 100+ queries: one for the product, one for the price, one for the image, one for the stock status, and so on.

What to do:

• Check if the plugin has a caching option in its settings
• Install a page caching plugin (WP Super Cache, W3 Total Cache, or similar). This serves cached pages to most visitors, skipping the queries entirely
• If the plugin is consistently the top consumer and you don’t really need it, consider alternatives

—

Slow Individual Queries

What Dobsie shows: Queries flagged as slow (>10ms in Deep Scan, >20ms in the toast).

Why it happens: Usually one of these:

• Unindexed meta queries: searching wp_postmeta or wp_usermeta without an index
• Large tables: tables with millions of rows take longer to search
• Complex JOINs: queries that combine multiple tables

What to do:

• Note which plugin generates the slow query. The fix usually needs to come from them
• If it’s a wp_postmeta query, check if the plugin offers a way to reduce its meta usage
• Consider adding a database index if you’re comfortable with SQL (or ask your host)
• An object cache (Redis or Memcached) can eliminate repeated slow queries by caching the result

—

Oversized Autoloaded Options

What Dobsie shows: Large entries in the Autoloaded Options table on the Overview tab.

Why it happens: WordPress loads all autoloaded options into memory on every single page load. Some plugins store large data blobs (serialized arrays, cached settings, logs) as autoloaded options. Even after you deactivate the plugin, this data stays in the database.

What to do:

• If the option belongs to a plugin you’ve already deactivated, it’s safe to delete it (use a database cleanup plugin or phpMyAdmin)
• If the option belongs to an active plugin, check if the plugin has a “clean up” or “optimize” option in its settings
• For options over 100KB, consider whether the plugin really needs that data autoloaded. Some plugins autoload data that should be loaded on demand

—

Expired Transients

What Dobsie shows: High count of expired transients in the Database Cleanup Stats.

Why it happens: Transients are temporary cached data with an expiry time. WordPress doesn’t always clean them up when they expire, so they can pile up, especially on sites without an object cache.

What to do:

• Install a database cleanup plugin that handles transient cleanup (many caching plugins do this)
• If you have an object cache (Redis/Memcached), transients are stored in memory and expire automatically, so this problem goes away entirely

—

Overdue Cron Jobs

What Dobsie shows: Multiple overdue events in the Cron Health section of Server Health.

Why it happens: WordPress cron runs when someone visits your site. On low-traffic sites (or sites with aggressive page caching), visits might not trigger cron often enough.

What to do:

• Set up a real cron job on your server to call wp-cron.php every few minutes. Your hosting provider can usually help with this
• Add define( 'DISABLE_WP_CRON', true ); to wp-config.php after setting up the real cron job
• Some managed WordPress hosts (like Kinsta, WP Engine) handle this automatically

—

No Object Cache

What Dobsie shows: “No object cache detected” in Server Health.

Why it happens: WordPress doesn’t include an object cache by default. Without one, every database query runs fresh on every page load.

What to do:

• Check if your host offers Redis or Memcached (many managed hosts include it)
• Install a Redis plugin (like Redis Object Cache) to connect WordPress to the cache
• This is one of the single biggest performance improvements you can make, especially on sites with lots of dynamic content

—

OPcache Not Enabled

What Dobsie shows: OPcache status showing as disabled in Server Health.

Why it happens: OPcache is PHP’s built-in bytecode cache. It stores compiled PHP files in memory so they don’t need to be recompiled on every request. Some hosting environments don’t enable it by default.

What to do:

• Contact your hosting provider and ask them to enable OPcache
• On most modern hosts, it’s already on. If Dobsie says it’s off, it’s worth a quick check

—

Problem Files in Web Root

What Dobsie shows: Error logs, debug files, or other problem files detected in Server Health.

Why it happens: PHP error logs, debug output files, or temporary files end up in your web root where they’re publicly accessible. This is a security concern, because error logs can reveal file paths, database credentials, and plugin versions.

What to do:

• Move log files outside your web root, or configure your web server to block access to .log files
• Delete any debug output files (like debug.log in wp-content/)
• Check your wp-config.php. If WP_DEBUG_LOG is set to true, logs go to wp-content/debug.log by default

—

High Memory Usage

What Dobsie shows: Memory usage approaching your PHP memory limit in the Overview metrics.

Why it happens: Too many plugins loaded, plugins loading large libraries, or plugins processing large datasets in memory.

What to do:

• Check the Deep Scan for plugins with high query counts. They’re often the same ones using the most memory
• Increase your PHP memory limit if you have headroom (in wp-config.php: define( 'WP_MEMORY_LIMIT', '256M' );)
• Deactivate plugins you’re not actively using. Every active plugin consumes memory even if it’s not doing anything visible