How WordPress Can Be Intercepted Before It Even Boots

Most developers think WordPress starts with plugins and themes.

That’s not true.

There is a hidden entry point—advanced-cache.php—that allows you to intercept requests before WordPress even initializes.

This layer is where high-performance caching systems operate, often reducing response times from hundreds of milliseconds to single digits.

The Trigger: WP_CACHE Constant

Everything begins in wp-config.php:

<?php
define('WP_CACHE', true);

This single line tells WordPress:

“Load the advanced cache layer before anything else.”

Once enabled, WordPress attempts to load:

wp-content/advanced-cache.php

Where advanced-cache.php Sits in the Boot Process

index.php
└── wp-blog-header.php
    └── wp-load.php
        └── wp-config.php
            ├── advanced-cache.php  ← YOU ARE HERE
            └── wp-settings.php
                ├── mu-plugins
                ├── plugins
                └── theme

This is before plugins, themes, and most of core.

You are operating in a nearly raw PHP environment with minimal WordPress loaded.

Why This Layer Is So Powerful

• Runs before any plugin overhead
• No database queries required (if cached)
• Full control over request lifecycle
• Can short-circuit WordPress entirely

This is how major caching plugins achieve sub-10ms response times.

Basic Example: Intercepting a Request

<?php
// wp-content/advanced-cache.php

if ( $_SERVER['REQUEST_URI'] === '/health-check' ) {
    header( 'Content-Type: application/json' );
    echo json_encode( ['status' => 'ok'] );
    exit;
}

This endpoint runs without booting WordPress at all.

Full-Page Caching Internals

The most common use of advanced-cache.php is full-page caching.

How It Works

1. Generate a cache key (URL, cookies, device)
2. Check if cached HTML exists
3. If yes → serve and exit
4. If no → let WordPress render and save output

Minimal Full-Page Cache Example

<?php

$cache_key = md5( $_SERVER['REQUEST_URI'] );
$cache_file = __DIR__ . "/cache/{$cache_key}.html";

if ( file_exists( $cache_file ) ) {
    header('X-Cache: HIT');
    readfile($cache_file);
    exit;
}

// buffer output for later caching
ob_start( function( $html ) use ( $cache_file ) {
    file_put_contents( $cache_file, $html );
    return $html;
});

This is a simplified version of what major caching plugins do internally.

How Caching Plugins Hook Into This Layer

Popular caching plugins don’t rely only on hooks—they hook into the boot process itself.

Typical Setup

• Define WP_CACHE
• Create advanced-cache.php
• Implement custom cache engine

What They Add

• Device detection (mobile/desktop cache)
• Logged-in user bypass
• Cache invalidation logic
• Compression (gzip/brotli)
• Edge/CDN integration

Example: Logged-in User Bypass

<?php

if ( isset( $_COOKIE['wordpress_logged_in'] ) ) {
    return; // skip cache, continue WordPress boot
}

This ensures personalized content isn’t cached incorrectly.

Advanced Techniques (Rarely Documented)

1. Smart Cache Segmentation

$device = strpos( $_SERVER['HTTP_USER_AGENT'], 'Mobile') !== false ? 'mobile' : 'desktop';
$cache_key = md5( $_SERVER['REQUEST_URI'] . $device );

2. Edge-Like Behavior

You can mimic CDN logic locally:

if ( $_SERVER['REQUEST_METHOD'] !== 'GET' ) {
    return; // bypass cache for POST/PUT
}

3. Early Security Filtering

if ( false !== strpos( $_SERVER['REQUEST_URI'], 'wp-login.php' ) ) {
    // apply rate limiting or block
}

Performance Impact (SEO Critical)

Page speed is a ranking factor.

Using advanced-cache.php:

• TTFB can drop to under 10ms
• Server load is drastically reduced
• Crawl efficiency improves
• Core Web Vitals benefit

This is why high-performance WordPress sites rely heavily on this layer.

Limitations & Caveats

• No WordPress APIs available
• No database abstraction (unless manually loaded)
• Must handle everything in raw PHP
• Debugging can be harder

This layer requires discipline and careful design.

Key Insight Most Developers Miss

advanced-cache.php is not a feature—it’s an interception point.

You are not extending WordPress.

You are deciding whether WordPress should run at all.

That’s a completely different level of control.

FAQ