Aller au contenu

Why Edge Caching

Ce contenu n’est pas encore disponible dans votre langue.

WordPress builds every page dynamically: each request runs PHP and queries the database, even when the page is identical for every visitor. That design is flexible, but it creates a set of recurring operational problems. Edge Caching addresses them at the edge, without changes to your WordPress installation.

A typical WordPress page takes hundreds of milliseconds of PHP and MySQL work to render. Most of that work is repeated for every anonymous visitor.

Edge Caching serves cacheable pages directly from Varnish’s memory, so the time to first byte for a hit is measured in milliseconds and the origin handles only misses and personalized traffic. A site with a high hit rate typically needs a fraction of the origin capacity it needed before.

A newsletter, a social media mention or a marketing campaign can multiply traffic within minutes. Without a cache, every additional visitor becomes additional PHP workers and database connections, and the origin eventually saturates.

With Edge Caching, a popular page is fetched from the origin once and then served from memory to every subsequent visitor. Origin load follows the number of distinct pages, not the number of visitors.

The same protection covers a classic self-inflicted outage: purging a WordPress cache plugin such as LiteSpeed Cache on a busy site. Without Edge Caching, every visitor suddenly reaches PHP at once. With it, visitors keep being served from the edge and the purge causes no surge at all. See How the cache is refreshed.

Hosting incidents, database failures, PHP fatal errors after an update, or a plugin left in maintenance mode all take a site offline.

With Always Online, Edge Caching keeps expired copies of each page for a configurable period (up to 48 hours) and serves them whenever the origin fails to respond or returns a server error. Visitors keep browsing while you fix the problem.

WordPress is the most targeted CMS on the web. Login brute forcing, XML-RPC abuse, vulnerability scanners and automated exploitation of plugin CVEs reach every exposed site, and each malicious request still costs a PHP worker.

Edge Caching inspects traffic before it reaches the origin:

  • CrowdSec blocks IPs known for attacking other sites (the community blocklist) and bans clients whose behavior matches attack scenarios, such as login brute forcing or path scanning.
  • Virtual patching blocks exploitation attempts against known vulnerabilities, including many in popular WordPress plugins, even while the vulnerable version is still installed.
  • Per-site rules cover WordPress-specific hardening: blocking XML-RPC, author enumeration, PHP execution in uploads and access to sensitive files, plus geo blocking and user agent filtering.

Issuing, installing and renewing TLS certificates across many sites is repetitive work, and an expired certificate is an outage.

Edge Caching terminates TLS at the edge and manages Let’s Encrypt certificates automatically, including renewal. Certificates are only requested once DNS actually points to the platform, which avoids failed validations and Let’s Encrypt rate limits. Sites that need a specific certificate, such as a wildcard for a Multisite network, can use their own.

Caching is easy; knowing when to invalidate is the hard part. Purging the whole cache on every change throws away most of the benefit, while not purging serves stale content.

The Edge Caching WordPress plugin invalidates precisely: when a post changes, it purges that post, the front page, the posts page and the post’s category archives. Site-wide events such as a theme switch or a menu change purge everything. When LiteSpeed Cache, WP Rocket or Hummingbird are installed, their caches are cleared at the same time, so the layers never disagree. How the cache is refreshed explains in depth how expiration, purges and flushes behave.

Edge Caching accelerates content that is the same for many visitors. Sites where nearly every page is personalized, such as a membership site where all visitors are logged in, benefit mostly from the security features rather than from caching. The platform is built and tuned for WordPress; other applications can work behind it, but the default rules assume WordPress conventions.