How to Analyze WordPress Performance: From TTFB to Core Web Vitals

"The site feels slow" is not a diagnosis. Before you install another caching plugin or upgrade the hosting plan, you need to know where the time is actually going — because a slow TTFB and a slow-loading image are completely different problems with completely different fixes. This guide is a practical WordPress performance analysis: the metrics that matter, how to read them, and how to turn "it feels slow" into a specific list of things to fix.

Start with the two halves of "slow"

Every page load has two distinct phases, and almost every performance problem lives in one of them:

• Server response time (TTFB — Time To First Byte). How long the server takes to build the page and send the first byte back. This is PHP, the database, the host, and whether anything is cached. A high TTFB means the problem is on the server.
• Front-end rendering. Once the HTML arrives, how long the browser takes to download and render everything — images, CSS, JavaScript, fonts. A fast TTFB but a slow-feeling page means the problem is in what you're shipping to the browser.

Measure TTFB first. If it's high (anything consistently over ~600ms), no amount of image optimization will save you — you're fixing the wrong half.

The metrics worth tracking

TTFB and server response

A healthy WordPress TTFB is under ~300ms for a cached page. If yours is high, the usual causes, in rough order of frequency:

• No page caching. Without a page cache, WordPress rebuilds the entire page from PHP and the database on every single request. Caching turns that into serving a static file. This is the single biggest TTFB win available and should be the first thing you check.
• A bloated or unoptimized database. Years of post revisions, expired transients and orphaned metadata make every query slower. Scheduled database optimization keeps it lean.
• A slow or overloaded host, or a PHP version several releases behind (PHP 8.x is dramatically faster than 7.x).
• A plugin doing expensive work on every load — a poorly built related-posts query, an external API call with no caching.

Core Web Vitals (the front-end half Google actually ranks on)

Google measures real-user experience through Core Web Vitals, and they're a confirmed ranking signal. Three numbers:

• LCP (Largest Contentful Paint) — how long until the biggest thing on screen (usually the hero image) is visible. Target under 2.5s. Almost always an image problem: an unoptimized, uncompressed, non-lazy-loaded hero.
• INP (Interaction to Next Paint) — how quickly the page responds when a user taps or clicks. Target under 200ms. Almost always a JavaScript problem: too much script blocking the main thread.
• CLS (Cumulative Layout Shift) — how much the layout jumps around as it loads. Target under 0.1. Usually images or ads without reserved dimensions, or a late-loading font.

Page weight and requests

The total kilobytes a page ships and the number of HTTP requests it makes. A 4MB page full of uncompressed images will feel slow on any connection that isn't fibre. This is the metric most directly under your control.

How to actually run the analysis

There's a difference between a one-off test and ongoing monitoring, and you want both.

For a point-in-time audit, a single page tested from one location tells you what's heavy on that page: which images are oversized, which scripts are blocking, what the TTFB is right now. This is how you diagnose a specific complaint.

For performance monitoring over time, you want the same metrics sampled regularly so you can see trends — TTFB creeping up after a plugin was added, page weight ballooning after a redesign, Core Web Vitals degrading before Google notices. A number measured once is an anecdote; the same number tracked weekly is a signal.

At the portfolio level this matters even more: you don't want to test fifty sites by hand. Platform-level performance analysis pulls the metrics from each site through a connector plugin on a schedule, so a site whose TTFB doubled shows up in a list instead of waiting for a client to complain.

From measurement to fixes

Analysis is only worth anything if it ends in actions. The usual high-impact fixes, roughly in order of return on effort:

1. Turn on page caching. Biggest TTFB win, lowest effort.
2. Compress and right-size images, serve them as WebP/AVIF, and lazy-load anything below the fold. This is almost always the biggest LCP and page-weight win.
3. Add object caching (an object cache like Redis) so repeated database queries are served from memory. Meaningful on dynamic sites and WooCommerce.
4. Defer or remove render-blocking JavaScript. The biggest INP lever, and often the hardest — audit what each script is for and whether it's needed on first paint.
5. Optimize the database on a schedule so it doesn't slowly re-bloat.
6. Upgrade PHP if you're behind. Often a free, dramatic TTFB improvement.

After each change, re-measure. Performance work without before-and-after numbers is guesswork, and it's easy to "optimize" something that wasn't the bottleneck.

Why this belongs in routine maintenance

Performance isn't a one-time project — sites get slower on their own. Every new plugin, every content addition, every design tweak adds weight, and databases bloat continuously. Left alone, a fast site becomes a slow one over a year without anyone making a single obviously-bad decision. That's why performance analysis belongs in the same routine as security scanning, backups and uptime monitoring: measured regularly, trended over time, and acted on before a client is the one who tells you the site got slow.

---

WP MegaManager includes performance analysis for every connected site — TTFB, page weight, the heaviest images and scripts, database size and Core Web Vitals, sampled on a schedule and surfaced in one dashboard, with an AI Copilot that reads the numbers and tells you what to fix first. Start with the free beta and stop guessing why a site is slow.