WordPress Performance: Stripping Down To Production Essentials

WordPress sites accumulate features over years. Plugins get installed for specific needs and then forgotten. Settings get enabled to test something and never reverted. The cumulative weight grows even as the site's actual functionality doesn't.

The strip-down audit identifies what's actually needed and removes what isn't. The audit takes a few hours and produces meaningful performance and security improvements.

The categories of cruft

Plugins that are no longer used. Installed for a project that ended, kept around because removing seems risky, never actively maintained.

Plugins that are still used but for trivial features. The 200KB plugin that exists to add a small visual effect that could be done in 5 lines of CSS.

Settings enabled for testing that weren't reverted. WP_DEBUG left on; query logging left enabled; verbose logging that's not being used.

Stale custom code in functions.php or a custom plugin. Code added years ago for a problem that no longer exists.

Unused themes. WordPress includes Twenty-X themes by default; old themes from previous redesigns are usually still installed.

Stale data: old post revisions, expired transients, abandoned drafts, deleted but not purged posts.

The audit step 1: plugin review

Open the Plugins page in WordPress admin. For each active plugin, ask:

1. What does this plugin do?

2. Is that functionality currently used on the site?

3. Could the same functionality be achieved with less weight (different plugin, custom code, removal of the underlying need)?

If you can't immediately answer #1, the plugin is a candidate for removal (you don't know what it does, which probably means it's not load-bearing).

If the answer to #2 is no, the plugin is a candidate for removal.

If the answer to #3 suggests lighter alternatives, the plugin is a candidate for replacement.

For each candidate plugin, test removal on staging. Verify nothing breaks. If clean, remove from production.

The audit step 2: theme cleanup

Open the Themes page in WordPress admin. The active theme stays. Old themes can usually be removed:

Twenty Twenty-Three, Twenty Twenty-Two, Twenty Twenty-One: keep one as a fallback for diagnostic purposes (you might activate Twenty Twenty-Three temporarily to isolate whether a problem is theme-related). Remove the rest.

Old previously-active themes: usually safe to remove. Keep them only if you have a specific reason (planning to revert, A/B testing).

Child themes for unused parent themes: remove with the parent.

The cleanup reduces disk usage and reduces the attack surface (unused themes can have vulnerabilities).

The audit step 3: settings review

Walk through Settings > all submenus and check each setting. Common cruft:

WP_DEBUG = true. Should be false on production.

WP_DEBUG_LOG = true. Should be false on production unless you're actively debugging.

SCRIPT_DEBUG = true. Same.

Search engines blocked checkbox under Settings > Reading. Should be unchecked on production. Sometimes gets left checked after staging tests.

Comments allowed setting that doesn't match your actual comment policy.

Permalink structure that doesn't match what you want.

Default category or default post type that doesn't match your actual usage.

Each setting takes 30 seconds to verify. The cumulative review catches the ones that are wrong.

The audit step 4: custom code review

If you have a child theme functions.php or a site-specific plugin with custom code, read through it. For each function or block of code, ask:

1. What does this code do?

2. Is it still needed?

3. Does it work correctly in the current WordPress version?

Custom code added years ago for specific problems often persists past the problem's relevance. Remove what's no longer needed.

Custom code that's still needed should have a comment explaining what it does and why. If the comment isn't there, add one before moving on.

The audit step 5: database cleanup

Run database cleanup operations:

1. Limit post revisions going forward (define WP_POST_REVISIONS in wp-config.php to a reasonable number like 10).

2. Delete old post revisions beyond the limit.

3. Delete expired transients.

4. Delete spam and trash comments older than 30 days.

5. Delete unused options from uninstalled plugins.

6. Optimize tables (for older MySQL versions).

WP-CLI, WP-Optimize, or Advanced Database Cleaner can handle these operations efficiently.

The audit step 6: media library cleanup

The media library accumulates uploaded files that aren't used anywhere. Identifying them takes specialized tooling: plugins like Media Cleaner or Image Cleanup scan for unused media.

The risk: false positives can delete files that are actually used (in custom code, in admin areas, in URL references). Test thoroughly before bulk deletion.

The reward: significant disk space recovery on sites with years of media accumulation.

The audit step 7: scheduled task review

Install WP Crontrol (free) and review what's in the cron queue. Tasks from uninstalled plugins sometimes remain in the queue, running periodically without doing anything useful.

Tasks that aren't associated with active plugins are candidates for removal. WP Crontrol can delete them.

For tasks that are still relevant, verify they're scheduled at reasonable times. Tasks scheduled hourly that could run daily are wasting resources.

The verification after cleanup

After the audit, verify the site still works correctly. Walk through:

1. Homepage and major content pages render correctly.

2. Forms submit correctly.

3. E-commerce flows work (if applicable).

4. User registration and login work.

5. Search works.

6. Comments work (if applicable).

7. Admin functions work.

The verification takes 30 minutes. It catches problems that the cleanup introduced before they affect users.

The measurement of improvement

Measure performance before and after the audit:

PageSpeed Insights scores on representative pages.

Database size.

Page weight on representative pages.

Admin dashboard load time.

The improvements vary by site, but typical results:

Page weight: 10-30% reduction.

Database size: 20-50% reduction (depending on how much cruft had accumulated).

Admin dashboard load time: 20-40% faster.

PageSpeed scores: 5-15 point improvement on mobile.

The discipline going forward

After the initial audit, prevent re-accumulation:

When uninstalling a plugin, verify it cleaned up its data. If not, manually remove orphaned options and tables.

When testing temporary settings, document them so they can be reverted later.

When adding custom code, comment why it's there. Future you (or future maintainers) needs context.

Quarterly mini-audits to catch new accumulation. Full audits annually.

The discipline is small ongoing cost; the audits are larger periodic investments. Both pay off in operational simplicity.

The honest framing

Most WordPress sites have accumulated cruft. The accumulation is invisible but real. The audit makes it visible and removable.

The investment is a few hours of focused work. The result is a faster, leaner, more maintainable site. The pattern is repeatable; the audit can be done periodically.

For sites where performance matters, the strip-down audit is high-ROI work. The cumulative effect of many small reductions adds up to meaningful improvement.

For sites that have never been audited, the first audit usually reveals more cruft than expected. The discipline of regular audits prevents the buildup that the first audit had to address.