Page cache served by nginx
When a visitor who is not logged in opens a page, Cache Enabler saves the finished HTML. The next visitors get that file directly from nginx, without starting PHP or touching the database. The cache is cleared when you publish or edit, so nobody sees a stale page for long.
Redis object caching, on the isolated tier
Logged-in users, carts and admin pages can't be cached as whole pages. On the isolated tier every site has its own Redis, which keeps the most requested database results in memory, so WordPress queries MariaDB less often. On the base tier the database sits on a shared server with a connection limit per site: the right choice as long as most visits are served from the page cache.
Replicas when traffic rises
nginx and PHP run as separate services, so each can grow on its own. When load goes up, new replicas start automatically, up to the maximum of your plan, and they stop when the peak is over.
- Lite and Plus: one PHP replica and one web server replica. Max: up to two PHP replicas.
- Start: one PHP replica and one web server replica, with guaranteed CPU.
- Pro: up to three PHP replicas and two web server replicas. Business: up to six PHP and three web server replicas.
Replicas run on the same server node as your site's storage. They absorb peaks within the plan's limits, and if your site sits at the maximum most of the time, the next plan is the honest answer.
Recent PHP, chosen for your WordPress version
Each WordPress branch runs on the PHP version that suits it best, with security support still active. OPcache is on. You decide when to move to a new branch, and the update rolls back on its own if the site does not respond afterwards.
Numbers in your dashboard
You do not have to take our word for it. Your dashboard shows uptime checked every two minutes, CPU and memory use, active replicas, traffic, disk space and the site's logs.