What 5.7 million pageviews reveal about WordPress performance

This is our first performance report based on anonymized data from WordPress sites monitored by DebugHawk during Q4 2025 (October through December).

Our goal is to share insights that help the WordPress community understand real-world performance patterns and optimize their own sites.

Throughout this report, we use percentiles to summarize performance: the median (p50) represents typical experience, p75 shows what 75% of users experience or better, and p95 captures near-worst-case scenarios. Learn more about percentiles.

The big picture

Before diving into specifics, here's what stands out from Q4 2025:

• 86% of pageviews pass LCP: The majority of WordPress sites are delivering good Largest Contentful Paint scores, with a median of just 1.1 seconds.
• TTFB is the biggest opportunity: Only 65% pass the TTFB threshold, largely due to PHP execution time consuming most of the 800ms budget.
• Persistent object caching cuts PHP time by 67%: Sites with a persistent object cache had a median PHP execution time of 508ms versus 1,542ms without.
• Page caching delivers 7× faster TTFB: Cached pages had a median TTFB of 106ms versus 723ms for uncached pages.

Core Web Vitals

Google's Core Web Vitals (LCP, INP, and CLS) measure what visitors actually experience and can influence search rankings. We also include TTFB, which measures server response time and often reveals why LCP underperforms on WordPress sites.

LCP is the strongest indicator of perceived load speed. With 86% of pageviews under the 2.5-second threshold and a median of 1.1 seconds, WordPress sites are delivering fast initial experiences.

INP replaced First Input Delay in 2024 as a more comprehensive measure of interactivity. The strong results here suggest WordPress sites are handling user interactions efficiently, with minimal JavaScript blocking.

CLS measures how much the page shifts unexpectedly during loading. A median of zero means over half of pageviews have no layout shift at all, likely thanks to properly sized images and reserved space for dynamic content.

At 65%, TTFB is where WordPress sites show the most room for improvement. Server response time depends on hosting quality, caching, plugin and theme choices, and database efficiency. The sections below show just how much impact these factors have. Improving TTFB will likely have a knock-on effect and improve LCP even further.

Backend performance

While web vitals measure what visitors experience in the browser, backend metrics reveal what's happening on the server. These numbers help identify optimization opportunities that frontend performance tools such as GTmetrix miss entirely.

PHP execution time

This is the total time PHP spends generating a response, including database queries, hook processing, and template rendering.

A 483ms median means PHP execution alone consumes most of the 800ms TTFB budget before any network latency is added. This explains why only 65% of pageviews pass the TTFB threshold above. The 3.5x gap between public and admin pages reflects additional plugin hooks, outgoing external requests (typically update checks), and database work. These numbers show why caching matters: object caching reduces PHP execution time, while page caching bypasses PHP entirely for the fastest possible response.

PHP memory usage

How much RAM each request consumes while generating a response. This includes WordPress core, active plugins, theme code, and any data loaded from the database.

Public pages staying under 32MB means servers can handle more concurrent visitors without running out of memory. Admin operations are heavier, with 37% exceeding 32MB. The 565MB peak suggests some operations (bulk imports, page builder rendering) may need a higher WP_MAX_MEMORY_LIMIT than the default 256MB.

Database execution time

How long PHP waits for MySQL to execute queries and return results. Slow queries, missing indexes, large datasets, and N+1 query patterns can all increase this number. Object caching can dramatically reduce it by serving repeat queries from memory.

For public pages, the database accounts for just 10ms of the 483ms median PHP execution time, around 2%. The bulk of PHP time is spent elsewhere: hook processing, template rendering, and plugin logic. Admin pages spend more time in the database (149ms median), with P95 hitting 3.2 seconds on heavy operations like plugin updates or bulk edits.

Database query count

The number of SQL queries WordPress executes per request. High counts often indicate N+1 patterns, inefficient plugins, or missing object caching. While query count alone doesn't determine performance, it's a useful signal for optimization opportunities.

Public pages average under 0.2ms per query, so 55 queries add minimal overhead. The real concern is the admin P95 at 1,598 queries, which explains why some dashboard operations hit 3+ seconds of database time. These spikes typically come from plugins that loop through large datasets without batching.

Outgoing HTTP requests

HTTP requests made during PHP execution, typically for license checks, API integrations, or update pings. Most are blocking, meaning PHP waits for the remote server to respond before continuing. This makes them one of the biggest wildcards in WordPress performance, adding latency you can't control.

Most public pages avoid external calls entirely, which helps keep TTFB predictable. Admin pages make more calls (13%) due to update checks and license verification. If your public pages are in the remaining 6%, it's worth identifying which plugins are responsible.

Caching

The numbers above show why TTFB is the hardest metric to pass. For a dynamic CMS like WordPress, caching is the single most impactful optimization you can make. It reduces or eliminates the PHP execution, database queries, and external requests that slow down every uncached page load.

Persistent object cache

WordPress has a built-in object cache, but it only lasts for a single request. A persistent object cache stores data across requests in an in-memory datastore such as Redis, so repeated database queries can be served from memory instead.

For sites that can't rely on page caching, such as WooCommerce stores, membership sites, or pages with personalized content, a persistent object cache is one of the easiest wins available.

Page cache

While object caching speeds up PHP, page caching skips it entirely. When a visitor requests a cached page, the server returns a static HTML snapshot without touching WordPress at all.

A 7× improvement in TTFB is hard to ignore. If your site can use page caching, it should be at the top of your optimization list.

Key takeaways

1. Core Web Vitals are strong: INP (91%) and CLS (94%) show that WordPress sites handle interactivity and visual stability well. LCP at 86% is solid but has room to improve.

2. TTFB is the main opportunity: At 65%, server response time is where most sites fall short. PHP execution consumes most of the 800ms budget before network latency is added.

3. Caching is the fix: A persistent object cache cuts median PHP time by 67%. Page caching bypasses PHP entirely, delivering 7× faster TTFB. If your site isn't using either, start there.

Methodology

This report is based on anonymized, aggregated data from WordPress sites using DebugHawk during Q4 2025. The dataset includes 5.7 million pageviews. Individual site data is never shared or identified.

Web vitals are measured using real user data (RUM) from actual visitors, not synthetic tests. Backend metrics are captured server-side during WordPress execution, via the DebugHawk WordPress plugin.

---

Want to see how your site compares? Start your free trial and get real-time performance insights within minutes.