Optimizing WordPress Autoloaded Options for Faster TTFB

When optimizing WordPress performance, database indexing and frontend asset minification often receive the majority of attention. However, one of the most insidious and pervasive root causes of sluggish Time to First Byte (TTFB) and high PHP worker memory consumption is autoloaded options bloat inside the wp_options table.

Every time WordPress processes an incoming HTTP request—whether rendering a marketing homepage, handling a WooCommerce checkout submission, or servicing an authenticated REST API query—the core bootstrap routine invokes wp_load_alloptions(). This core function executes a single, massive SQL query:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' /* Or 'on' */

All retrieved rows are deserialized, parsed into PHP arrays or objects, and stored in the global memory variable $wp_alloptions. If this dataset is small (e.g., 300 KB to 700 KB), the overhead is negligible. But on production WooCommerce sites, membership portals, and high-traffic publisher platforms that have operated for several years through numerous plugin installations, upgrades, and uninstalls, the autoloaded options size frequently balloons to 5 MB, 10 MB, or even 30 MB+.

In this definitive architectural guide, we will analyze the internal mechanics of wp_load_alloptions(), explore the exact memory and TTFB penalties of oversized options tables, review automated SQL diagnostic scripts, build an enterprise PSR-4 Autoload Profiler & Cleanup Service, discuss transient garbage collection traps, and formulate persistent Redis object caching architectures.

The Internal Lifecycle of wp_load_alloptions()

To understand why autoloaded bloat impacts server concurrency, we must examine the WordPress initialization lifecycle inside wp-includes/option.php:

1. WordPress Core Bootstrap: In wp-settings.php, early bootstrap initializes the database connection ($wpdb) and loads essential runtime configurations.
2. Execution of wp_load_alloptions(): WordPress checks if the alloptions cache key exists in the persistent object cache (e.g., Redis or Memcached). If no persistent cache is active, it queries MySQL for all rows where autoload equals 'yes' or 'on' (and in WordPress 6.6+, options with autoload = 'auto' that qualify).
3. Memory Allocation & Deserialization: MySQL transmits the raw string data over the TCP socket/Unix domain socket. PHP allocates heap memory to receive the payload. PHP then iterates through every row and runs maybe_unserialize() on serialized strings, transforming complex nested configuration trees into live PHP memory objects.
4. Population of Global Cache: The resulting dictionary is assigned to the global memory runtime cache. Subsequent calls to get_option('siteurl') or get_option('blogname') resolve instantly from in-memory arrays without triggering individual SQL queries.

The Performance Paradox: Speed vs Memory Starvation

Autoloading was originally designed in WordPress 2.x as a performance optimization. By bundling hundreds of configuration calls into a single database roundtrip, WordPress avoided executing 150+ discrete SELECT queries during page initialization.

However, the optimization relies on a critical assumption: that only frequently accessed, lightweight configuration flags are marked as autoloaded. When third-party plugins store multi-megabyte log files, base64-encoded CSS/font strings, temporary cart sessions, or massive API response caches with autoload = 'yes', this optimization turns into a major bottleneck.

Benchmarking the Impact of Autoload Size on TTFB and Concurrency

The table below is a qualitative illustration of how a growing alloptions payload affects TTFB, memory and PHP-FPM capacity. It is not a measured benchmark; the trend follows from WordPress loading every autoloaded option on each request:

This pattern reflects three practical realities:

1. Non-Linear Memory Amplification: Storing 6 MB of serialized data in MySQL does not merely consume 6 MB in PHP. When PHP deserializes arrays containing thousands of elements, object pointers and memory fragmentation amplify the actual PHP heap memory consumption well beyond the serialized size.
2. Worker Pool Exhaustion: As individual PHP worker memory climbs from 14 MB to 148 MB, servers with 4 GB of RAM that could previously support 150 concurrent PHP-FPM workers are forced to reduce pm.max_children to 25 to prevent Linux Kernel Out-of-Memory (OOM) killer terminations.
3. Garbage Collection Latency: At the end of each HTTP request, the PHP Zend Engine must traverse and free thousands of nested array memory structures, adding CPU garbage collection time before the worker can accept the next incoming request.

Diagnosing Autoload Bloat with SQL Queries

Before writing code, database administrators can quickly audit and quantify their wp_options table using raw SQL. Run these diagnostic queries via MySQL CLI, phpMyAdmin, or Adminer:

Query 1: Calculate Total Autoloaded Options Size

SELECT 
    COUNT(*) AS total_autoload_keys,
    ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_size_mb,
    ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_size_kb
FROM wp_options 
WHERE autoload IN ('yes', 'on', 'auto');

Query 2: Identify the Top 20 Largest Autoloaded Options

SELECT 
    option_id,
    option_name,
    LENGTH(option_value) AS size_bytes,
    ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,
    autoload
FROM wp_options 
WHERE autoload IN ('yes', 'on', 'auto')
ORDER BY LENGTH(option_value) DESC 
LIMIT 20;

Query 3: Find Expired and Orphaned Transients

Transients in WordPress are stored as options with the prefix _transient_ and _transient_timeout_. If transients are created without explicit expiration handling or if cron cleanup jobs fail, thousands of expired transients remain trapped in wp_options:

SELECT 
    COUNT(*) AS expired_transients_count,
    ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS expired_transients_kb
FROM wp_options 
WHERE option_name LIKE '_transient_timeout_%' 
  AND option_value < UNIX_TIMESTAMP();

The Four Primary Causes of Autoload Bloat

1. Orphaned Options from Uninstalled Plugins

When administrators delete plugins from the WordPress dashboard, WordPress executes the plugin's uninstall.php file. Unfortunately, a vast percentage of commercial and free plugins either fail to provide an uninstaller or leave their database options intact "in case the user reinstalls." Over 5 years of site evolution, hundreds of abandoned plugin options remain permanently loaded into memory on every page request.

2. Runaway Autoloaded Transients

When calling set_transient($transient, $value, $expiration), developers frequently fail to realize that if $expiration is omitted or set to 0, WordPress treats the transient as permanent and assigns autoload = 'yes'. Even when an expiration timestamp is provided, older WordPress versions defaulted to autoloading transient values under certain fallback conditions, causing API cache responses to accumulate indefinitely.

3. Monolithic Theme and Page Builder Settings

Complex page builders and multi-purpose themes often serialize massive JSON configurations—including entire font libraries, historical revision snapshots, and global styling maps—into a single option key (e.g., elementor_active_kit or fusion_options) marked as autoloaded, injecting 1.5 MB+ into every page request.

4. Session Data and Shopping Carts

Flawed custom checkout or cart plugins that store customer session states, abandoned cart tracking tables, or raw webhook transaction logs directly in wp_options instead of dedicated custom tables or transients with autoload = 'no' can corrupt memory performance rapidly during high-volume sales campaigns.

Building an Enterprise PSR-4 Autoload Profiler Service

To maintain visibility into database health and automate alerting when options bloat exceeds acceptable thresholds, we will construct a production-ready PSR-4 service: AutoloadProfilerService. This service inspects memory allocations, calculates size distributions, pinpoints the top offending keys, and provides safe remediation APIs.

<?php

declare(strict_types=1);

namespace WPStack\Database;

use wpdb;
use WP_Error;

/**
 * Enterprise Autoloaded Options Profiler & Diagnostic Service.
 */
final class AutoloadProfilerService {
    private wpdb $db;
    private const CRITICAL_THRESHOLD_BYTES = 800000; // 800 KB Alert Threshold
    private const WARNING_THRESHOLD_BYTES  = 500000; // 500 KB Warning Threshold

    public function __construct(wpdb $db) {
        $this->db = $db;
    }

    /**
     * Generate an exhaustive diagnostic profile of the wp_options table.
     *
     * @return array{
     *     total_size_bytes: int,
     *     total_size_formatted: string,
     *     total_keys_count: int,
     *     status: string,
     *     top_offenders: array<int, array{option_name: string, size_bytes: int, size_kb: float, autoload: string}>,
     *     transients_summary: array{total_count: int, expired_count: int, size_bytes: int}
     * }
     */
    public function profile_autoload_health(): array {
        $table = $this->db->options;

        // 1. Calculate Aggregate Size
        $aggregate = $this->db->get_row(
            "SELECT 
                COUNT(*) AS total_count,
                COALESCE(SUM(LENGTH(option_value)), 0) AS total_bytes
             FROM {$table}
             WHERE autoload IN ('yes', 'on', 'auto')",
            ARRAY_A
        );

        $total_bytes = (int) ($aggregate['total_bytes'] ?? 0);
        $total_count = (int) ($aggregate['total_count'] ?? 0);

        // Determine Status Tier
        $status = 'HEALTHY';
        if ($total_bytes >= self::CRITICAL_THRESHOLD_BYTES) {
            $status = 'CRITICAL';
        } elseif ($total_bytes >= self::WARNING_THRESHOLD_BYTES) {
            $status = 'WARNING';
        }

        // 2. Fetch Top 25 Largest Autoloaded Keys
        $raw_offenders = $this->db->get_results(
            "SELECT 
                option_name,
                LENGTH(option_value) AS size_bytes,
                autoload
             FROM {$table}
             WHERE autoload IN ('yes', 'on', 'auto')
             ORDER BY LENGTH(option_value) DESC
             LIMIT 25",
            ARRAY_A
        );

        $top_offenders = [];
        foreach ($raw_offenders as $row) {
            $bytes = (int) $row['size_bytes'];
            $top_offenders[] = [
                'option_name' => (string) $row['option_name'],
                'size_bytes'  => $bytes,
                'size_kb'     => round($bytes / 1024, 2),
                'autoload'    => (string) $row['autoload'],
            ];
        }

        // 3. Analyze Transient Garbage
        $transient_stats = $this->analyze_transients();

        return [
            'total_size_bytes'     => $total_bytes,
            'total_size_formatted' => $this->format_bytes($total_bytes),
            'total_keys_count'     => $total_count,
            'status'               => $status,
            'top_offenders'        => $top_offenders,
            'transients_summary'   => $transient_stats,
        ];
    }

    /**
     * Safely toggle the autoload flag for a specific option key.
     *
     * @param string $option_name Option to modify.
     * @param bool $should_autoload True for 'yes', False for 'no'.
     * @return bool|WP_Error
     */
    public function update_autoload_flag(string $option_name, bool $should_autoload): bool|WP_Error {
        $table = $this->db->options;
        $autoload_value = $should_autoload ? 'yes' : 'no';

        $exists = $this->db->get_var(
            $this->db->prepare("SELECT COUNT(*) FROM {$table} WHERE option_name = %s", $option_name)
        );

        if (!$exists) {
            return new WP_Error('option_not_found', "Option '{$option_name}' does not exist in {$table}.");
        }

        $updated = $this->db->update(
            $table,
            ['autoload' => $autoload_value],
            ['option_name' => $option_name],
            ['%s'],
            ['%s']
        );

        if ($updated === false) {
            return new WP_Error('db_update_failed', "Failed to update autoload flag for '{$option_name}'.");
        }

        // Invalidate in-memory and persistent alloptions cache
        wp_cache_delete('alloptions', 'options');
        wp_cache_delete($option_name, 'options');

        return true;
    }

    /**
     * Purge all expired transients from wp_options table safely in chunks.
     *
     * @param int $batch_size Maximum rows to delete per transaction.
     * @return int Total number of purged expired transient records.
     */
    public function purge_expired_transients(int $batch_size = 500): int {
        $table = $this->db->options;
        $now   = time();
        $total_deleted = 0;

        do {
            // Find batch of expired transient timeout keys
            $timeout_keys = $this->db->get_col(
                $this->db->prepare(
                    "SELECT option_name 
                     FROM {$table} 
                     WHERE option_name LIKE '_transient_timeout_%' 
                       AND option_value < %d 
                     LIMIT %d",
                    $now,
                    $batch_size
                )
            );

            if (empty($timeout_keys)) {
                break;
            }

            $keys_to_delete = [];
            foreach ($timeout_keys as $timeout_key) {
                $keys_to_delete[] = $timeout_key;
                // Corresponding data key: replace '_transient_timeout_' with '_transient_'
                $keys_to_delete[] = str_replace('_transient_timeout_', '_transient_', $timeout_key);
            }

            // Create parameterized placeholders for IN clause
            $placeholders = implode(',', array_fill(0, count($keys_to_delete), '%s'));
            $sql = "DELETE FROM {$table} WHERE option_name IN ({$placeholders})";
            
            $deleted = $this->db->query(
                $this->db->prepare($sql, ...$keys_to_delete)
            );

            if ($deleted && $deleted > 0) {
                $total_deleted += $deleted;
            }

        } while (count($timeout_keys) === $batch_size);

        // Clean persistent cache
        wp_cache_delete('alloptions', 'options');

        return $total_deleted;
    }

    /**
     * Analyze transient health and quantify expired records.
     *
     * @return array{total_count: int, expired_count: int, size_bytes: int}
     */
    private function analyze_transients(): array {
        $table = $this->db->options;
        $now   = time();

        $stats = $this->db->get_row(
            $this->db->prepare(
                "SELECT 
                    COUNT(*) AS total_transients,
                    SUM(CASE WHEN option_value < %d THEN 1 ELSE 0 END) AS expired_transients,
                    COALESCE(SUM(LENGTH(option_value)), 0) AS total_bytes
                 FROM {$table}
                 WHERE option_name LIKE '_transient_timeout_%'",
                $now
            ),
            ARRAY_A
        );

        return [
            'total_count'   => (int) ($stats['total_transients'] ?? 0),
            'expired_count' => (int) ($stats['expired_transients'] ?? 0),
            'size_bytes'    => (int) ($stats['total_bytes'] ?? 0),
        ];
    }

    private function format_bytes(int $bytes): string {
        if ($bytes >= 1048576) {
            return number_format($bytes / 1048576, 2) . ' MB';
        }
        if ($bytes >= 1024) {
            return number_format($bytes / 1024, 2) . ' KB';
        }
        return $bytes . ' Bytes';
    }
}

The "N+1 Single Option Query Trap": Why You Cannot Blindly Set All Options to autoload = 'no'

When database administrators discover that their alloptions table is 4 MB in size, a common knee-jerk reaction is executing a bulk SQL query to mark everything as autoload = 'no':

/* DANGEROUS: DO NOT EXECUTE IN PRODUCTION WITHOUT PROFILING */
UPDATE wp_options SET autoload = 'no' WHERE LENGTH(option_value) > 5000;

While this dramatically decreases the initial size of wp_load_alloptions(), it introduces a severe secondary performance hazard: The N+1 Single Option Query Problem.

If a plugin or active theme accesses 40 distinct option keys during every page execution (e.g., checking license status, layout configurations, color codes, or breadcrumb toggles), and those keys are marked as autoload = 'no', WordPress cannot resolve them from memory. Instead, WordPress is forced to execute 40 separate SQL queries against MySQL:

SELECT option_value FROM wp_options WHERE option_name = 'my_plugin_setting_1' LIMIT 1;
SELECT option_value FROM wp_options WHERE option_name = 'my_plugin_setting_2' LIMIT 1;
/* ... repeated 38 more times per page request ... */

Under high traffic, executing 40 discrete database queries per request creates massive connection pool contention, elevates MySQL CPU usage, and eliminates any performance gains achieved from reducing the initial alloptions payload.

The Architectural Decision Framework: Autoload = 'yes' vs 'no'

Automating Inspections and Cleanup with Custom WP-CLI Commands

To integrate options health checks into automated CI/CD deployment pipelines, Ansible playbooks, or scheduled cron maintenance routines, we wrap our profiler service into a custom WP-CLI command suite:

<?php

declare(strict_types=1);

namespace WPStack\CLI;

use WP_CLI;
use WPStack\Database\AutoloadProfilerService;

final class AutoloadProfilerCommand {
    /**
     * Inspect and profile autoloaded options database health.
     *
     * ## OPTIONS
     *
     * [--format=<format>]
     * : Output format (table, json, yaml).
     * ---
     * default: table
     * options:
     *   - table
     *   - json
     *   - yaml
     * ---
     *
     * ## EXAMPLES
     *
     *     wp wpstack autoload profile
     *     wp wpstack autoload profile --format=json
     *
     * @param array<string> $args
     * @param array<string, string> $assoc_args
     */
    public function profile(array $args, array $assoc_args): void {
        global $wpdb;
        $service = new AutoloadProfilerService($wpdb);
        $profile = $service->profile_autoload_health();

        WP_CLI::line(WP_CLI::colorize("%B=== WPStack Autoload Health Profile ===%n"));
        WP_CLI::line("Total Autoload Keys: " . $profile['total_keys_count']);
        WP_CLI::line("Total Autoload Size: " . $profile['total_size_formatted']);

        if ($profile['status'] === 'CRITICAL') {
            WP_CLI::warning("Autoloaded options size exceeds 800 KB! Optimization strongly recommended.");
        } elseif ($profile['status'] === 'HEALTHY') {
            WP_CLI::success("Autoloaded options size is within healthy performance thresholds (< 500 KB).");
        }

        WP_CLI::line("\n" . WP_CLI::colorize("%YTop 10 Largest Autoloaded Options:%n"));
        $top_table = array_slice($profile['top_offenders'], 0, 10);
        WP_CLIUtilsformat_items($assoc_args['format'] ?? 'table', $top_table, ['option_name', 'size_kb', 'autoload']);

        WP_CLI::line("\n" . WP_CLI::colorize("%YTransients Health:%n"));
        WP_CLI::line("Total Transients: " . $profile['transients_summary']['total_count']);
        WP_CLI::line("Expired Transients: " . $profile['transients_summary']['expired_count']);
    }

    /**
     * Purge all expired transients from wp_options table.
     *
     * ## EXAMPLES
     *
     *     wp wpstack autoload purge-transients
     */
    public function purge_transients(array $args, array $assoc_args): void {
        global $wpdb;
        $service = new AutoloadProfilerService($wpdb);

        WP_CLI::log("Scanning and purging expired transients in batches...");
        $purged = $service->purge_expired_transients(500);

        WP_CLI::success("Successfully purged {$purged} expired transient option records.");
    }
}

if (defined('WP_CLI') && WP_CLI) {
    WP_CLI::add_command('wpstack autoload', AutoloadProfilerCommand::class);
}

Persistent Redis Object Caching: Eliminating MySQL alloptions Execution

For high-traffic enterprise applications, the ultimate defense against autoloaded options database bottlenecks is deploying a persistent in-memory cache—specifically Redis Object Cache via the phpredis C extension and a drop-in object-cache.php.

When persistent object caching is enabled:

1. On initial startup, WordPress queries Redis for the key {prefix}:options:alloptions.
2. If the cache hits, Redis returns the pre-serialized dictionary in under 0.8 milliseconds, completely bypassing MySQL.
3. MySQL executes zero SQL queries against the wp_options table during standard page generation.
4. When an administrator updates an option via update_option(), WordPress automatically invalidates the Redis key, ensuring immediate data consistency across all web cluster nodes.

Preventing Redis alloptions Invalidation Storms

While Redis solves database read contention, high-write environments can suffer from Cache Stampedes. Every time any autoloaded option is modified (such as an analytics tracker updating an impression count), WordPress purges the entire alloptions Redis key.

If 200 concurrent requests hit the server during the 50ms window when the cache key is missing, all 200 requests will simultaneously execute SELECT * FROM wp_options WHERE autoload = 'yes' against MySQL. To prevent this storm:

// wp-config.php - Prevent volatile transient writes from invalidating alloptions
define('WP_REDIS_IGNORED_GROUPS', [
    'counts',
    'plugins',
    'themes',
]);

// Set dedicated Redis database index and timeout
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1.0);
define('WP_REDIS_READ_TIMEOUT', 1.0);

WordPress 6.6+ Dynamic Autoloading Mechanics (large_options)

Starting in WordPress 6.6, core introduced significant enhancements to mitigate autoload bloat out-of-the-box. When an option is added without explicitly defining the autoload argument (or when passing 'auto'), WordPress evaluates the payload size before persisting it to MySQL.

Core enforces a default soft threshold defined in wp_max_autoload_value_size() (default: 150,000 bytes / ~146 KB). If an option value exceeds 150 KB, WordPress automatically overrides the autoload flag to 'no', preventing individual monolithic settings from choking wp_load_alloptions().

Developers can fine-tune or customize this threshold using the wp_max_autoload_value_size filter to enforce stricter engineering standards across enterprise multisite networks:

<?php

declare(strict_types=1);

namespace WPStack\Database;

final class AutoloadThresholdConfig {
    /**
     * Enforce strict 64 KB autoload size limit for all newly created options.
     */
    public static function register(): void {
        add_filter('wp_max_autoload_value_size', static function (int $max_size): int {
            // Restrict maximum autoloaded option size to 64 KB (65,536 bytes)
            return 65536;
        });

        // Filter default autoload behavior for third-party plugins
        add_filter('default_option_autoload_value', static function (string $autoload, string $option_name, mixed $value): string {
            // Force autoload 'no' for transient-like caches and telemetry payloads
            if (str_starts_with($option_name, 'wpstack_cache_') || str_ends_with($option_name, '_log')) {
                return 'no';
            }
            return $autoload;
        }, 10, 3);
    }
}

Exporting Autoload Metrics to Prometheus & Grafana

In modern cloud Kubernetes and VPS production environments, options table bloat should be monitored proactively via automated telemetry rather than discovered during an outage. We expose an authenticated Prometheus metrics endpoint that exports real-time gauge values for total autoloaded bytes, key counts, and expired transient queues:

<?php

declare(strict_types=1);

namespace WPStack\Telemetry;

use WP_REST_Request;
use WP_REST_Response;
use WPStack\Database\AutoloadProfilerService;

final class DatabaseMetricsController {
    public const ROUTE_NAMESPACE = 'wpstack/v1';
    public const ROUTE_RESOURCE  = '/telemetry/db-metrics';

    public static function register_routes(): void {
        register_rest_route(
            self::ROUTE_NAMESPACE,
            self::ROUTE_RESOURCE,
            [
                'methods'             => 'GET',
                'callback'            => [self::class, 'get_prometheus_metrics'],
                'permission_callback' => [self::class, 'verify_metrics_token'],
            ]
        );
    }

    public static function verify_metrics_token(WP_REST_Request $request): bool {
        $token = $request->get_header('x-telemetry-token');
        $expected = defined('WPSTACK_TELEMETRY_SECRET') ? WPSTACK_TELEMETRY_SECRET : '';
        return !empty($expected) && hash_equals($expected, (string) $token);
    }

    public static function get_prometheus_metrics(WP_REST_Request $request): WP_REST_Response {
        global $wpdb;
        $service = new AutoloadProfilerService($wpdb);
        $profile = $service->profile_autoload_health();

        $output  = "# HELP wp_autoload_bytes Total size of autoloaded options in bytes\n";
        $output .= "# TYPE wp_autoload_bytes gauge\n";
        $output .= sprintf("wp_autoload_bytes %d\n", $profile['total_size_bytes']);

        $output .= "# HELP wp_autoload_keys_total Total count of autoloaded option rows\n";
        $output .= "# TYPE wp_autoload_keys_total gauge\n";
        $output .= sprintf("wp_autoload_keys_total %d\n", $profile['total_keys_count']);

        $output .= "# HELP wp_expired_transients_total Total count of orphaned expired transients\n";
        $output .= "# TYPE wp_expired_transients_total gauge\n";
        $output .= sprintf("wp_expired_transients_total %d\n", $profile['transients_summary']['expired_count']);

        return new WP_REST_Response($output, 200, ['Content-Type' => 'text/plain; version=0.0.4']);
    }
}

Production Troubleshooting and Incident Runbook

Writing Automated Database Profiler Tests in PHPUnit

To guarantee that custom plugin updates never inadvertently introduce large autoloaded options or fail to clean up transients, include these automated tests in your CI/CD test suite:

namespace WPStack\Tests;

use WP_UnitTestCase;
use WPStack\Database\AutoloadProfilerService;

final class AutoloadProfilerTest extends WP_UnitTestCase {
    private AutoloadProfilerService $service;

    public function set_up(): void {
        parent::set_up();
        global $wpdb;
        $this->service = new AutoloadProfilerService($wpdb);
    }

    public function test_profiler_accurately_detects_autoload_size(): void {
        // Create controlled 100 KB option
        $dummy_data = str_repeat('A', 102400);
        update_option('wpstack_test_large_option', $dummy_data, 'yes');

        $profile = $this->service->profile_autoload_health();

        $this->assertGreaterThanOrEqual(102400, $profile['total_size_bytes']);
        $this->assertNotEmpty($profile['top_offenders']);
        $this->assertEquals('wpstack_test_large_option', $profile['top_offenders'][0]['option_name']);

        // Clean up
        delete_option('wpstack_test_large_option');
    }

    public function test_updating_autoload_flag_modifies_database(): void {
        update_option('wpstack_test_flag', 'some_value', 'yes');

        $result = $this->service->update_autoload_flag('wpstack_test_flag', false);
        $this->assertTrue($result);

        global $wpdb;
        $autoload = $wpdb->get_var(
            $wpdb->prepare("SELECT autoload FROM {$wpdb->options} WHERE option_name = %s", 'wpstack_test_flag')
        );

        $this->assertEquals('no', $autoload);
        delete_option('wpstack_test_flag');
    }

    public function test_purging_expired_transients_deletes_database_rows(): void {
        global $wpdb;

        // Manually inject expired transient timeout and value
        $wpdb->insert($wpdb->options, [
            'option_name'  => '_transient_timeout_wpstack_expired_key',
            'option_value' => time() - 3600,
            'autoload'     => 'no',
        ]);
        $wpdb->insert($wpdb->options, [
            'option_name'  => '_transient_wpstack_expired_key',
            'option_value' => 'expired_payload_data',
            'autoload'     => 'no',
        ]);

        $deleted_count = $this->service->purge_expired_transients(100);
        $this->assertGreaterThanOrEqual(2, $deleted_count);

        $remaining = $wpdb->get_var(
            "SELECT COUNT(*) FROM {$wpdb->options} WHERE option_name LIKE '%wpstack_expired_key%'"
        );
        $this->assertEquals(0, (int) $remaining);
    }
}

Next Steps for Faster Database Responses

Keeping database response times low on complex WordPress and WooCommerce builds depends on visibility into query execution, memory allocation and caching layers. MoxSEO's web development team builds and audits custom WordPress plugins and integrations, including profiling slow queries and removing autoload bloat.

If you are preparing for a high-traffic launch or cleaning up an older plugin, see our WordPress development services.

Frequently asked questions