Test key performance signals (LCP, CLS, TTFB and more), then get a plain-English rundown plus a shareable results card. Use it to spot what’s slowing your site down and what to fix first.

Tip: run the test twice. First pass is a baseline. Second pass helps confirm whether caching, DNS, and connection reuse are affecting results.

---

What this tool checks

This analyser focuses on practical speed signals that tend to map to real user experience. The exact numbers vary by device and network, but the categories below are a reliable way to decide what to work on.

TTFB (Time to First Byte)

TTFB is how long the server takes to start responding. High TTFB usually points to origin performance (slow hosting, heavy WordPress stacks, uncached HTML, database bottlenecks) or edge configuration issues (no HTML caching, bypassed cache rules, long redirects).

LCP (Largest Contentful Paint)

LCP measures how quickly the main “hero” content appears. Poor LCP is often caused by oversized images, render-blocking CSS/JS, slow fonts, or late-loading above-the-fold elements.

CLS (Cumulative Layout Shift)

CLS is visual stability. If elements jump around while the page loads, users notice. Common causes are images without explicit dimensions, ads/embeds that resize, late font swaps, and UI injected after initial render.

Other checks you’ll commonly see

• Redirect chains: extra hops waste time before the real page loads.
• Compression: missing Brotli/Gzip increases transfer size.
• Caching signals: whether repeat visits get faster or stay slow.
• Payload size: large JS bundles and heavy images can dominate load time.

What “good” looks like (quick benchmarks)

These ranges are intentionally simple. Your goal is not perfection; it’s removing the biggest bottleneck first. Performance benchmarks (rule-of-thumb)

Metric	Great	OK	Needs work	Usually caused by
TTFB	< 0.8s	0.8–1.8s	> 1.8s	Slow origin, uncached HTML, heavy plugins, slow DB, too many redirects
LCP	< 2.5s	2.5–4.0s	> 4.0s	Large hero image, render-blocking assets, slow fonts, heavy JS
CLS	< 0.10	0.10–0.25	> 0.25	Missing image dimensions, late embeds, layout injected after load, font swaps

If only one metric is bad, start there. If everything is bad, start with TTFB (origin/edge) before chasing front-end tweaks.

How to use your results

1. Run the test on your homepage (it’s usually the heaviest page).
2. Run it on one content page (blog/article) and compare. If articles are fast but the homepage is slow, the issue is usually theme/widgets.
3. Check for consistency: if results swing wildly test-to-test, suspect caching, third-party scripts, or an overloaded origin.
4. Fix in this order: TTFB → LCP → CLS. It’s the most reliable path to noticeable improvements.

Example report (what a typical result means)

Here’s a simplified example of the kind of interpretation you want. Your exact numbers will differ. Sample interpretation

Finding	Why it matters	What to do first
TTFB above 2.0s	The origin is slow to respond, so everything else starts late. Front-end optimisations won’t fully help until this improves.	Enable HTML/edge caching where possible, reduce heavy server work (plugins, DB), and remove redirect chains.
LCP above 4.0s	Users wait too long to see the main content. This is often the “feels slow” complaint.	Optimise the hero image (size/format), preload key assets, and reduce render-blocking CSS/JS.
CLS above 0.25	Layout shifting is distracting and reduces trust, especially on mobile.	Add explicit width/height to images, reserve space for embeds/ads, and avoid injecting UI after initial paint.

Common fixes that move the needle

• Kill redirect chains: make one clean hop to the final URL (especially www/non-www and trailing slash).
• Get HTML caching right: for WordPress, cached HTML often reduces TTFB more than any other single change.
• Optimise your hero image: correct dimensions, modern formats, and avoid shipping massive images to mobile.
• Trim third-party scripts: tag managers, widgets, and chat scripts can dominate load and interaction.
• Stabilise layout: define image sizes and reserve space for embeds to reduce CLS.

If you want an immediate “what next” plan, use the tool output to pick one metric to improve, make one change, then retest. Small controlled changes beat random plugin stacking.

Limitations (so you interpret results correctly)

• One test is a snapshot: networks, caching state, and third-party scripts can change results.
• Lab vs real users: a page can look fine in a controlled test but still feel slow on older phones or busy networks.
• Tool output depends on what your page serves: if your site detects bots and serves different HTML, results can mislead.

FAQ

Why does my score change between runs?

Caching state, connection reuse, and third-party scripts can change timing. Run at least two tests and focus on repeated patterns.

My TTFB is high. Should I optimise images first?

Usually no. High TTFB means the server is slow to start responding. Fix origin/edge/caching first, then optimise front-end assets.

What’s the fastest way to improve LCP?

Start with the largest above-the-fold element (often the hero image). Reduce its size, serve modern formats, and avoid render-blocking assets.

What causes CLS most often?

Images without dimensions, embeds that resize, and late UI injection. Reserve space and define sizes so layout doesn’t shift mid-load.

Can I share the results card publicly?

Yes, but treat it as a summary. For debugging, keep the full breakdown (especially TTFB and the largest resources) so you can reproduce changes.

---

Next steps

If you want a structured workflow, run the analyser, pick the worst metric, apply one fix, and retest. Repeat until you’ve brought TTFB, then LCP, then CLS into a reasonable range.

Related articles:

• How to reduce TTFB