Performance Architecture

Caching Layers

Layer	Mechanism	Scope	TTL
Static files	Disk (`ABSPATH`)	14 discovery files	Permanent (until next sync)
Discovery transients	`get_transient()`	Knowledge Graph, LLMS-TLDR, AI sitemap, feed	15 min – 24 hr
Sitemap transients	`get_transient()`	Orchestrator XML output	12 hr
Provider caches	Instance properties	Exclusion SQL, settings	Request lifetime
Priority cache	Static array	Archetype defaults	Request lifetime
Bot identification	Static hash map	CrawlerRegistry UA lookup	Request lifetime
HTML card gridper	`get_transient()`	Discovery architecture	24 hr
YAML sitemap block	`get_transient()`	LLMS YAML sitemap section	12 hr

Why No Plugin-Level Option Cache

WordPress’s get_option() already caches autoloaded options via wp_cache_get()/wp_cache_set(). When update_option() is called, WordPress calls wp_cache_delete() to invalidate. A plugin-level static cache would:

Miss this invalidation
Return stale settings after a settings save in the same request
Add complexity with no measurable performance gain

The 25+ get_option('cybermaps_settings') calls per request are 1 DB query + 24 in-memory array lookups from WordPress’s object cache.

Transient Invlidation Policy

Named delete_transient() calls, not blanket LIKE '%_transient_cybermaps_%' queries. This ensures:

Object cache backends (memcached, Redis) are properly cleaned
Only the specific caches that need invalidation are touched
Compliance with WordPress Transients API best practices

Exclusion SQL Caching

The BaseProvider::get_exclusion_sql() method builds a complex WHERE clause involving post IDs, categories, tags, and search exclusions. This is computed once per provider instance and cached:

private ?string $cached_exclusion_sql = null;

protected function get_exclusion_sql(): string {
    if (null !== $this->cached_exclusion_sql) {
        return $this->cached_exclusion_sql;
    }
    // ... 73 lines of SQL construction ...
    $this->cached_exclusion_sql = $result;
    return $result;
}

Query Optimization

Health stats: Uses STRAIGHT_JOIN to force MySQL to start from wp_posts and join outward (more efficient for the post-meta pattern).
Log KPIs: Consolidated from 6 queries to 4. Request volumes use windowed COUNT() with CASE instead of separate queries.
Bot identification: Hash-map lookup, O(1) after first access.