WordPress Page Speed: The Three Caching Layers That Separate Fast Sites From Slow Ones

Twenty years running hosting infrastructure in Ireland teaches you to look at websites differently. Not the design — the response time. Not the colour scheme — the TTFB. Not whether it looks polished on a large screen, but whether it loads before the customer on a mobile phone gives up and goes to a competitor.

March 2026 brought a concrete change to how Google measures that. The "good" Largest Contentful Paint threshold tightened from 2.5 seconds to 2.0 seconds, a consequence of the March 2026 core update. Sites that passed Google's performance benchmark on Wednesday morning technically failed it by Thursday. Nothing changed on those sites. The goalposts moved.

This is not a niche technical matter. It is a business problem for any organisation that relies on its website to bring in customers. This article covers what page speed actually measures, the three server-side caching layers that determine whether a WordPress site is fast or slow, and what the numbers mean in terms that translate to customers and revenue.

What Google's Core Web Vitals Actually Measure

Google assesses website performance using three Core Web Vitals metrics. Each has a "good," "needs improvement," and "poor" threshold. Google's Search Central documentation is unambiguous that all three are used as ranking signals, though they function more as tie-breakers than primary ranking drivers — content relevance and authority still dominate. When two pages compete for the same position and one passes Core Web Vitals while the other does not, the faster page has a measurable advantage.

Largest Contentful Paint (LCP) is the time it takes for the main visible content to appear on screen: typically a hero image or headline. The 2026 "good" threshold is 2.0 seconds on mobile. Above 4.0 seconds is "poor."

Interaction to Next Paint (INP) measures responsiveness: how quickly a page reacts after someone taps a button or menu item. Under 200 milliseconds is good. Above 500 milliseconds, users notice the delay. Slow INP is particularly damaging on mobile booking forms and WooCommerce checkouts, where hesitation costs you the transaction.

Cumulative Layout Shift (CLS) measures visual stability — whether elements jump around as images and fonts load. This catches business owners off guard: a site that looks stable on a desktop may have a CLS problem on mobile where slower connections cause content to pop in asynchronously, shifting the layout under the reader's thumb just as they are about to tap.

Together, these three metrics measure whether your page loads fast, responds quickly, and holds together visually as it loads. All three affect whether customers stay long enough to become customers.

The Three Caching Layers

A "cache" is a stored copy of something expensive to produce. WordPress generates pages by querying a database and running PHP code to assemble the result. That process takes time. Caching shortcuts it — by serving a pre-built copy, retrieving data from memory rather than disk, or skipping code compilation entirely.

There are three distinct caching layers on a well-configured WordPress server, each operating at a different level of the stack.

Layer 1: Nginx FastCGI Page Cache

Full-page caching at the web server level. When a visitor first loads your homepage, Nginx assembles the page through PHP and MySQL, then stores the resulting HTML on disk. Every subsequent request for that page gets the stored HTML file served directly, without touching PHP or the database at all.

The practical effect is significant. Cached pages served via FastCGI typically respond in 35 to 60 milliseconds. The same page without page caching can take 800 milliseconds to 1.2 seconds just to respond, before the browser has rendered anything. That is the gap between a site that feels instant and one that makes people wonder if it is broken.

What happens without this layer: picture a business whose homepage gets shared in a popular local Facebook group. One hundred and fifty people click the link within thirty minutes. Each triggers a full PHP process and database query. On shared hosting with limited resources, those processes queue. Pages stall. Visitors wait, assume something is wrong, and leave. By the time the site recovers, the moment has passed.

With FastCGI page caching in place, the first visitor builds the page. Visitors two through several thousand get it from disk in under 100 milliseconds.

Layer 2: Redis Object Cache

FastCGI handles static, full-page caching for logged-out visitors. Dynamic content is a different problem. WooCommerce product pages, logged-in member areas, pages that vary based on session data — these cannot be served from a pre-built static copy. Every visit requires a database query.

Redis is an in-memory data store that sits between WordPress and the database. It holds the results of common database queries in RAM, so WordPress retrieves the data it needs without reading from disk each time. Memory access is several orders of magnitude faster than reading from a storage drive.

For a business running a WooCommerce shop, even a modest one with 50 to 100 products, Redis object caching reduces load time on product listing pages, checkout flows, and cart calculations. Without Redis, each of those interactions triggers fresh database reads. With Redis, repeated queries are served from memory.

Layer 3: PHP OPcache

PHP is an interpreted language: PHP source files get compiled to machine-readable bytecode before they execute. Without OPcache, that compilation happens on every single request. Every page load, every time.

OPcache stores the compiled bytecode in memory, so the compilation step only runs once. Subsequent requests use the cached bytecode directly. The result is a measurable reduction in server response time for every PHP-powered page on the site.

This is the most invisible layer for a business owner, but it contributes meaningfully to TTFB. On a plugin-heavy WordPress install with 30 or 40 plugins — each adding its own PHP files — OPcache removes compilation overhead that compounds across every request.

The three layers are complementary. FastCGI handles full-page delivery for anonymous visitors. Redis accelerates database access for dynamic requests. OPcache eliminates PHP compilation overhead at the application layer. Running all three on a properly configured stack pushes TTFB for cached traffic below 100 milliseconds consistently, with spikes under 60 milliseconds on a warm cache.

Why Most WordPress Sites Miss All Three

The default WordPress experience on generic shared hosting delivers none of these layers as standard. PHP runs on every request. The database is read on every page load. PHP compiles from source each time.

This is not a WordPress problem. WordPress powers roughly 43% of websites on the internet, as tracked by W3Techs. The platform scales to very high traffic when the hosting layer is properly configured. The problem is how most WordPress installations are hosted, not the CMS itself.

Generic shared hosting places hundreds of sites on a single server. There is no per-site PHP worker allocation. FastCGI caching is either absent or inconsistently configured. Redis requires additional server-side setup that most shared hosts do not provision. OPcache may be present but configured at defaults designed for simpler PHP applications, not a plugin-heavy WordPress install.

Plugin overload compounds the problem. According to data gathered by HTTP Archive's annual Web Almanac — which analyses millions of websites across the internet — the average WordPress site runs somewhere between 20 and 35 active plugins. Each adds database queries, often on every page request regardless of whether the specific page needs the data. Each may load JavaScript and CSS files sitewide. The cumulative effect is a site that starts sluggish and gets slower as it adds functionality over time.

I made this error myself. Working with an early WordOps deployment, I recommended a popular drag-and-drop page builder to a business in Clare that needed a quick redesign. Their Google PageSpeed mobile score dropped from the mid-70s to the high 30s within a week of the new design going live. It took us three weeks to isolate the cause and another two to rebuild the affected templates without the builder. I would not make that call again.

One genuine exception worth naming: if you are running a large-scale WooCommerce operation with significant concurrent logged-in user traffic, multiple stores, or complex server-side personalisation requirements, enterprise managed hosts have infrastructure built for those specific workloads. Kinsta's enterprise tier or WP Engine's enterprise plans run dedicated Redis instances, custom Nginx configurations, and dedicated PHP worker pools at scale. For a business genuinely operating at that level, those platforms are a legitimate fit. The cost is significant — typically EUR100 to EUR600 per month — but justified at that scale. The businesses that need this know who they are. It is not most WordPress sites in Ireland.

Images: The Bottleneck Most Business Owners Do Not See

If I had to name the single most common performance problem across Irish business WordPress sites, it is not misconfigured caching. It is unoptimised images.

Most sites upload photographs directly from a camera or phone, typically JPEG files between 2MB and 6MB, displayed at whatever dimensions the theme dictates. The browser downloads the full file regardless of display size. A 5MB image rendered at 400 pixels wide transfers 5MB of data for a visual that would be indistinguishable at 80KB in WebP format.

WebP, developed by Google and supported natively in WordPress since version 5.8, compresses photographs to roughly 25 to 34% smaller than equivalent JPEGs at comparable visual quality, based on multiple independent benchmarking studies — though results vary considerably by image type and original file characteristics. For pages where the hero image is the Largest Contentful Paint element, converting to WebP has been shown to reduce LCP by somewhere between 0.8 and 1.6 seconds in testing by NitroPack and Luminos Agency, though I would treat those as directional estimates rather than guarantees given they are both companies with a stake in demonstrating optimisation value.

AVIF compresses smaller still — around 20 to 30% smaller than WebP at similar quality — and WordPress supports it natively since version 6.5 where the required image library (Imagick or libavif) is available on the server.

Neither format improvement requires a developer. Both require a hosting environment that supports WebP and AVIF conversion, which has been table stakes on a properly managed WordPress platform for several years.

Where Your Server Lives Matters for Irish Visitors

There is a metric called TTFB (Time to First Byte) that measures how long a visitor's browser waits before receiving the first data from the server. It is a direct function of two things: network latency and server processing time.

Network latency is physics. Data travels at a finite speed through undersea cables and routing equipment. A visitor in Sligo hitting a server in Virginia is making a round trip of roughly 80 to 100 milliseconds in network latency alone, before any server processing begins. The same visitor hitting a server in a Dublin data centre covers the same network trip in under 5 milliseconds.

That gap compounds. Every resource the browser requests — the HTML page, stylesheets, fonts, scripts, images — makes a separate round trip. On a page with 20 to 30 resources, the accumulated latency difference between US-hosted and Ireland-hosted infrastructure is not negligible.

For businesses handling personal data through their website — contact forms, booking requests, customer records — server location also carries GDPR implications. Data that touches a server in the United States is subject to US legal jurisdiction regardless of what a privacy policy says. Irish sovereign cloud infrastructure keeps that data under Irish and EU legal frameworks. That is not a compliance checkbox. It is an infrastructure decision.

What the Numbers Mean for a Business

Google's own research on mobile user behaviour — published in the "Need for Mobile Speed" report, based on analysis of real mobile sessions — found that roughly 53% of mobile visitors abandon a page that takes more than three seconds to load. Not occasional visitors. Not frustrated ones. A majority, regardless of intent or interest.

For conversion rates, e-commerce benchmarking consistently shows a drop-off as load time increases. Sites loading in under two seconds typically see conversion rates in the range of 2.5 to 3%. At three seconds, that tends to drop to around 1.5 to 2%. At four seconds or above, it typically falls below 1% in most benchmarks. These figures vary by industry, device, and audience mix, and I would treat any single-source benchmark with appropriate caution — but the directional relationship is consistent across every dataset I have reviewed: faster pages convert better.

For rankings, analysis of the HTTP Archive dataset across millions of URLs shows that pages in position 1 pass Core Web Vitals at rates somewhere in the range of 8 to 12 percentage points higher than pages in position 9. The causality runs in both directions — sites with stronger content and authority tend to invest more in technical quality — but the correlation is real. When two pages are genuinely competitive on content relevance and backlinks, page speed is a meaningful differentiator.

Consider a pattern we see regularly with seasonal businesses: an outdoor activity operator builds a beautiful gallery-heavy site to attract bookings. Traffic picks up. They add a second photo gallery from a new camera, uploading high-resolution images directly. Mobile load time on their booking page doubles. Enquiry rates drop. They assume it is a slow season. It is a slow page. Slow pages are invisible to the business owner because they do not announce themselves.

For a broader view of what a well-optimised WordPress performance setup looks like beyond caching, the complete WordPress performance guide for business owners covers the full picture of what separates a fast site from a slow one at every layer.

One Limitation Worth Knowing

Server-side page caching works by serving the same pre-built HTML to all anonymous visitors. This works perfectly for product pages, blog posts, and most business website pages. It cannot serve personalised or session-specific content from the full-page cache.

WordPress and WooCommerce handle this by bypassing the FastCGI cache for logged-in users and active cart sessions — which is the correct behaviour, not a flaw. But it means a WooCommerce store where most visitors are logged-in customers sees a smaller proportion of its traffic served from the fastest caching tier.

Redis object caching still helps significantly in those scenarios, because database queries are still accelerated. But the headline TTFB improvements from FastCGI caching apply primarily to anonymous visitor traffic. A shop with a large authenticated customer base may need custom cache configuration to optimise those specific flows. Know this before setting expectations about what any caching layer will deliver for a specific site.

For more on how WordPress responsiveness metrics — specifically INP — affect logged-in user experiences, our breakdown of the INP Core Web Vital covers what this metric measures and where most WordPress sites are falling short.

What a Well-Configured Stack Looks Like

Every site on Web60 runs on the WordOps stack: Nginx with FastCGI full-page caching, Redis object caching, and PHP OPcache. All three layers are the default configuration — not an upgrade option, not an add-on tier. The baseline.

The infrastructure runs on SmartHost's sovereign Irish cloud, which means network latency for Irish visitors is measured in single-digit milliseconds. SSL certificates are provisioned and renewed automatically. Nightly backups run without intervention. Server-level security hardening is in place by default.

Web60's enterprise-grade Irish infrastructure details the full stack configuration, including how each hosting layer is set up for WordPress performance. If you want to see where your current site stands before any decisions, Google's PageSpeed Insights tool at search.google.com/speed/pagespeed/insights gives you a breakdown by mobile and desktop, with LCP, INP, and CLS scores plus specific recommendations. It uses real Chrome user experience data rather than a synthetic test. Run it against your most important pages, not just your homepage, and pay attention to the mobile score.

Conclusion

Page speed is not a technical nicety that ranks below design and content. It is the point where your hosting infrastructure either supports or undermines everything else you have put into your website — the design, the copy, the SEO work, the social traffic you have built. All of it lands on a page that loads in under one second or crawls past three. Those two seconds determine whether that visitor stays long enough to become a customer.

The three caching layers — FastCGI, Redis, OPcache — are not exotic configurations. They are the baseline for a serious WordPress hosting environment. The fact that many hosting providers do not run them by default reflects a hosting cost model, not a technical constraint. The cost of that choice falls on the business owner in the form of slower pages, lower rankings, and lost customers.

Run PageSpeed Insights. Check your mobile LCP. If it is above 2.5 seconds, the fix is almost certainly at the hosting layer, not the design layer.

Frequently Asked Questions

How do I check my WordPress site's page speed?

Use Google PageSpeed Insights, available at search.google.com/speed/pagespeed/insights. Enter your URL and run the test on both mobile and desktop. The report shows your Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift scores, with specific improvement recommendations. Run it against your homepage and at least one key product or service page — different pages can have significantly different scores depending on their content and plugin dependencies.

What is a good LCP score for a WordPress site in 2026?

Google's threshold for "good" Largest Contentful Paint tightened after the March 2026 core update to 2.0 seconds. A score between 2.0 and 4.0 seconds falls in the "needs improvement" range. Above 4.0 seconds is "poor." The threshold applies to the mobile score specifically — that is the version Google uses as its primary index for most websites. If your mobile LCP is above 2.5 seconds, your site is likely losing both rankings and conversions compared to faster competitors.

Do I need a caching plugin to improve WordPress page speed?

On a properly configured managed WordPress host, server-side caching is handled at the infrastructure level. You should not need a separate page caching plugin, and adding one on top of server-level FastCGI caching can create conflicts that result in stale or incorrect content being served. On generic shared hosting without server-side caching, a plugin can help, but it is a workaround for the underlying hosting limitation rather than a substitute for infrastructure-level caching.

Does server location affect my WordPress site's speed for Irish visitors?

Yes, directly. A visitor in Ireland hitting a server in the United States faces 80 to 100 milliseconds of network latency on every request before any server processing begins. A visitor hitting a server in Ireland or the UK sees under 5 to 10 milliseconds of latency. This directly affects Time to First Byte, which contributes to Largest Contentful Paint. For Irish visitors, Irish or UK-hosted infrastructure delivers measurably better TTFB than US-based alternatives, everything else being equal.

How does Web60 handle WordPress page speed?

Every Web60 site runs on the WordOps stack with Nginx FastCGI full-page caching, Redis object caching, and PHP OPcache active as the default configuration for every plan. The infrastructure runs on SmartHost's sovereign Irish cloud, keeping network latency low for Irish visitors and keeping data under Irish and EU jurisdiction. WebP image conversion is supported natively through WordPress's built-in image handling. All of this is included in the €60/year all-inclusive plan with no performance add-ons or tiered caching options.

Sources

• Understanding Core Web Vitals and Google search results — Google Search Central
• Understanding Google Page Experience — Google Search Central
• Mobile site load time statistics — Think with Google
• Performance — HTTP Archive Web Almanac 2025
• WebP vs AVIF on WordPress: image speed in 2025 — Luminos Agency