Skip to main content
Performance & Caching

fast isn't a feature.it's the floor.

Every WordPress site ships with a five-layer cache stack, NVMe storage, PHP 8.4, and Cloudflare edge delivery in front of it. No plugins, no tuning checklist, no hidden upgrade path for speed.

0.9sFCP
1.7sLCP
0msTBT
0CLS
5msTTFB

The five-layer cache stack

Most hosts stop at "we have caching." Yovale runs five layers in sequence so the easiest requests stop early and the hardest requests still land on tuned infrastructure.

01

Cloudflare edge

300+ global PoPs

Static assets, HTML, and markdown variants are cached at the nearest edge location so most requests never touch origin.

hit rate
85-95%
ttfb
5-20ms
02

Nginx FastCGI cache

origin HTML microcache

Nginx serves fully rendered HTML from disk in microseconds, so PHP and WordPress never wake up for cacheable traffic.

hit rate
~95%
ttfb
~30ms
03

Redis 7 object cache

dedicated per site

Every DB query, option, and transient is cached in memory with no shared pool and no noisy-neighbor eviction.

hit rate
sub-ms
ttfb
<1ms
04

PHP 8.4 OPcache

pre-compiled bytecode

WordPress runs from memory instead of reparsing files on every request, with runtime settings tuned per plan tier.

hit rate
100%
ttfb
~8ms
05

MariaDB 11 on NVMe

fast fallback layer

When a request makes it all the way to the database, it lands on MariaDB 11 with NVMe-backed storage instead of vague "SSD" marketing.

hit rate
fallback
ttfb
~15ms

vs most WordPress hosts

What other hosts upsell as add-ons or "premium tiers" is built into the platform on day one.

LayerMost hostsYovale
Edge CDNExtra monthly add-onCloudflare edge included
Origin HTML cachePlugin or manual setupNative Nginx FastCGI
Object cacheShared Redis or noneDedicated Redis 7 per site
PHP version8.1 or 8.2PHP 8.4
StorageSATA SSD or vague SSDNVMe across the fleet
DatabaseMySQL 5.7 or 8.0MariaDB 11
Worker isolationShared PHP-FPM poolDedicated container per site
UTM handlingCache fragmentationStripped before lookup

Traffic headroom

Sustained daily pageviews per plan. Burst traffic can climb higher before the stack starts sweating.

PlanContentWooCommerce
Starter50k/day12k/day
Growth150k/day40k/day
Business400k/day100k/day
The philosophy

Speed should not be a plugin, a support ticket, or a premium checkbox. It should be the default shape of the hosting itself.

5msTTFB at edge
5cache layers
0plugins required
see plans
compare it against your current stack
Under the hood

how a request actually flows.

The fastest path ends at the edge. The longer path still stays inside a stack tuned for WooCommerce and plugin-heavy WordPress sites.

Request pipeline
live
Fast path

85-95% of requests end at step 02, which means the origin server is never contacted and the request stays in the 5-20ms range.

what we don't do

and why that's the point
WP Rocket

no caching plugins

Caching plugins exist to patch over slow hosting. Yovale handles caching at the infrastructure layer so your app does less work.

Shared Redis

no shared object cache

Your cache is not competing with another customer on the same server. Each site gets its own Redis boundary.

Pooled PHP

no shared PHP workers

Requests are not queued behind another site going viral. Each site keeps its own isolated runtime.

Premium CDN

no faster tier upsell

Starter gets the same Cloudflare edge footprint as Business. There is no paid speed unlock hiding behind the pricing table.

Questions

Performance FAQ

Do I need to install a caching plugin on Yovale?

No. Edge caching, FastCGI page caching, Redis object caching, and PHP OPcache are already part of the stack.

Does this help WooCommerce too?

Yes. Anonymous traffic is handled early by edge and page caching, while dynamic WooCommerce work benefits from Redis, tuned PHP, and isolated resources.

Is Redis shared across accounts?

No. Every WordPress site gets its own Redis boundary, which keeps cache behavior predictable under load.

Can I still use my own performance plugins?

You can, but the platform is designed so you do not need them for the core caching and delivery layers.

See the stack in a real plan.

The performance page should make the pricing page easier to trust, not separate from it. Everything here is part of the platform, not a bolt-on.