WordPress Performance FAQ


Mike

Is the idea of improving performance by preventing unnecessary work specific to WordPress, or is it a broader performance principle?

For example, WordPress often loads a large runtime before deciding what a request actually needs. But do other systems also improve performance by avoiding unnecessary execution, reducing runtime participation, classifying requests early, or using smaller execution paths where possible?

Sam

It's a much broader performance principle. In fact, one of the most fundamental ideas in computer science and systems engineering is:

The fastest work is the work you never do.

What you're observing in WordPress—trying to avoid bootstrapping the entire runtime when a request only needs a small subset of functionality—is just one manifestation of that principle.

The general pattern

Many systems improve performance by:

  1. Classifying requests as early as possible
  2. Avoiding loading components that won't be needed
  3. Using the smallest execution path that satisfies the request
  4. Short-circuiting expensive processing
  5. Moving work out of the request path entirely

These ideas appear everywhere.

Web servers

A classic example is serving static files.

Less efficient

Request
  ↓
Full application runtime
  ↓
Framework
  ↓
Routing
  ↓
Controller
  ↓
Return image.css

More efficient

Request
  ↓
Web server detects static file
  ↓
Serve file directly

This is why servers like Nginx and Apache HTTP Server are often configured to serve assets directly rather than involving application runtimes.

Operating systems

Operating systems constantly avoid unnecessary work.

Examples:

  • Lazy loading of libraries
  • Demand paging
  • Copy-on-write memory
  • Deferred disk writes
  • Interrupt-driven processing

Instead of loading everything immediately, the OS waits until something is actually needed.

Databases

Databases are essentially machines for avoiding work.

Consider an indexed lookup.

Without an index:

Scan 10 million rows

With an index:

Jump directly to matching rows

The database is classifying the request and narrowing the execution path before touching most of the data.

Query planners go even further:

  • Predicate pushdown
  • Partition pruning
  • Join elimination
  • Covering indexes

All of these are mechanisms for preventing unnecessary execution.

Modern web frameworks

Many modern frameworks explicitly focus on minimizing runtime participation.

Examples include:

  • Next.js static generation
  • Astro islands architecture
  • SvelteKit prerendering
  • Edge functions and edge caching

The common theme is:

Don't invoke the full application runtime if the answer is already known.

CPU architecture

Even processors themselves do this.

Examples:

  • Branch prediction
  • Speculative execution
  • Cache hierarchies
  • Instruction pipelines

The CPU spends enormous effort determining what work can be skipped, reordered, or avoided.

Networking and CDNs

A CDN is almost entirely an "avoid work" technology.

Without a cache:

Request
  ↓
Origin server
  ↓
Application
  ↓
Database

With a cache hit:

Request
  ↓
CDN
  ↓
Response

The entire backend stack is bypassed.

Systems like Cloudflare and Fastly exist largely to eliminate unnecessary origin processing.

High-performance application design

Many high-scale systems are built around request classification.

For example:

Is this static?
Is this cached?
Is authentication required?
Does this endpoint need database access?
Can this be served from memory?

Each "yes" allows the system to avoid loading more machinery.

A common architecture is:

Layer 1: CDN
Layer 2: Reverse proxy
Layer 3: Cache
Layer 4: Application
Layer 5: Database

The goal is for most requests to be answered at Layer 1 or 2 and never reach Layers 4 and 5.

Where WordPress fits

WordPress is often discussed in this context because historically many requests trigger a substantial bootstrap sequence:

  • Core initialization
  • Plugin loading
  • Theme loading
  • Hook registration
  • Query setup

Only after much of this work does WordPress fully understand what the request requires.

Performance optimizations in WordPress frequently try to:

  • Identify requests earlier
  • Skip plugin execution
  • Serve cached pages
  • Use specialized endpoints
  • Bypass the full bootstrap when possible

But that's not a WordPress-specific philosophy.

It's the same principle that appears in databases, operating systems, CPUs, web servers, CDNs, compilers, and distributed systems:

Determine what is actually needed as early as possible, and avoid executing everything else.

Mike

Performance by Prevention is not limited to WordPress. It is a broader performance principle: the fastest work is the work that never has to happen.

Databases use indexes to avoid scanning unnecessary rows. CDNs avoid origin requests. Web servers serve static files without invoking an application runtime. Operating systems use lazy loading and demand paging. Modern frameworks use route-aware loading, prerendering, edge functions, and smaller execution paths where possible.

LiteCache Rush applies this general principle to a specific WordPress problem.

WordPress traditionally treats the full runtime as the default path: core bootstrap, active plugins, theme code, hooks, database queries, and plugin logic often enter the request before it is clear how much of that runtime is actually needed.

Rush targets that early server-side layer. It classifies the request before unnecessary runtime participation begins and, where safe, selects a known-safe execution profile. If the request requires the full WordPress stack, Rush allows it. If classification is uncertain, Rush falls back to the full runtime.

So Performance by Prevention is a general systems principle. LiteCache Rush is its WordPress-specific implementation for reducing unnecessary PHP and plugin participation per request.