Performance testing helps you understand how fast your WordPress site feels to visitors, how efficiently it responds under load, and which parts of the experience need attention.

Use this guide to understand why performance testing matters before and after enabling Pressidium EDGE, changing cache settings, optimizing images, or updating your WordPress site.

Pressidium’s performance testing guidance emphasizes that speed measurement can be misleading if you only look at one score or one test result. Different tools measure different parts of the experience, so you need a consistent baseline, repeated tests, and the right metrics for the problem you are investigating.

What performance testing helps you prove

Performance testing helps you move from assumptions to evidence.

It can show whether:

  • EDGE is reducing response times
  • More requests are being served from cache
  • A page is slow because of origin response time
  • A page is slow because of front-end assets
  • Image optimization improved page weight
  • CSS or JavaScript optimization improved rendering
  • A traffic spike affected performance
  • A change improved or harmed Core Web Vitals

Without testing, it is difficult to know whether a performance issue comes from hosting, caching, images, JavaScript, third-party scripts, traffic spikes, or the browser experience.

Why a baseline matters

A baseline is a saved record of how a page performed before you made changes.

Create a baseline before:

  • Enabling EDGE
  • Changing DNS
  • Changing cache settings
  • Purging or adjusting cache rules
  • Enabling image optimization
  • Enabling CSS or JavaScript minification
  • Updating plugins or themes
  • Launching a campaign or high-traffic page

A baseline gives you something to compare against after the change.

Pressidium’s speed testing checklist recommends recording key metrics before optimization, then re-running tests afterward to compare results against the baseline.

What to measure

Do not rely on one score alone.

A useful performance test should look at several areas:

  • Time to First Byte (TTFB) – how quickly the first response comes back from the server or edge layer
  • Largest Contentful Paint (LCP) – how quickly the main visible content appears
  • Interaction to Next Paint (INP) – how responsive the page feels during interaction
  • Cumulative Layout Shift (CLS) – how stable the page layout is while loading
  • Total page weight – how much data the page transfers
  • Number of requests – how many files the browser needs to load
  • Cache HIT, MISS, and BYPASS behavior – whether EDGE serves content from cache
  • Waterfall timing – which requests delay the page

PageSpeed Insights, GTmetrix, WebPageTest, browser developer tools, and EDGE dashboard screens each show different parts of the performance picture. Pressidium’s PageSpeed Insights article explains that PSI reports both field data and lab-style diagnostics, and highlights metrics such as FCP, LCP, CLS, Speed Index, and Total Blocking Time.

Synthetic tests and real-user data

There are two common ways to review performance.

Synthetic tests simulate a page visit under controlled conditions. Tools such as PageSpeed Insights, GTmetrix, and WebPageTest help you compare pages, identify bottlenecks, and test before-and-after changes.

Real-user data comes from actual visitors. It helps you understand how the site performs across real devices, networks, and locations.

Use both where possible.

Synthetic tests are useful for diagnosis and comparison. Real-user data is useful for understanding what visitors actually experience over time.

For more detail, see Synthetic testing explained.

Why one test is not enough

One test result can be affected by many factors, including:

  • Test location
  • Device profile
  • Network speed
  • Browser cache
  • Cold or warm cache state
  • Third-party scripts
  • Background tasks
  • Traffic levels
  • Recent cache purges
  • Plugin or theme changes

Run tests more than once and keep the setup consistent.

For example, if you test a page before enabling EDGE from one location, test it again from the same location after enabling EDGE. If you test mobile before optimization, test mobile again after optimization.

Pressidium’s TTFB guidance also notes that a single PageSpeed Insights test is only one measurement, and repeated tests give more reliable results.

How EDGE changes what you measure

Pressidium EDGE sits in front of your origin and processes requests before they reach your server.

This means performance testing should look at both:

  • EDGE behavior, such as cache HIT rate, BYPASS rate, and response timing
  • Page behavior, such as LCP, image weight, JavaScript execution, and layout stability

A page can have strong EDGE caching but still perform poorly if it loads large images, heavy JavaScript, render-blocking CSS, or slow third-party scripts.

A page can also have good front-end assets but still feel slow if requests bypass cache and the origin takes too long to respond.

Use the EDGE Dashboard and page audit tools together.

Where to test performance in EDGE

Use these related dashboard screens and docs depending on what you need to investigate.

Performance Overview

Use Performance Overview when you want a high-level view of a site’s performance state.

Go to Performance Overview.

Cache Analytics

Use Cache Analytics to check how often requests are served from cache.

This helps you understand HIT, MISS, and BYPASS behavior.

Go to Cache Analytics.

Traffic Analytics

Use Traffic Analytics when you need to compare performance with request volume, bandwidth, or traffic spikes.

Go to Traffic Analytics.

Site Audit

Use Site Audit to test a specific URL and review page-level performance.

Go to Site Audit.

Site Audit Details

Use Site Audit Details to review a completed audit and understand the reported metrics and recommendations.

Go to Site Audit Details.

Use this workflow before and after major performance changes.

  1. Choose the URLs you want to test.
  2. Record the current state of each URL.
  3. Run a performance audit.
  4. Check cache behavior in Cache Analytics.
  5. Review traffic patterns in Traffic Analytics.
  6. Make one change at a time.
  7. Purge cache only when needed.
  8. Re-run the same test.
  9. Compare the new result with your baseline.
  10. Record what changed.

Test important pages such as:

  • Homepage
  • Landing pages
  • Product pages
  • Checkout pages
  • Account pages
  • Blog posts
  • Campaign pages
  • High-traffic URLs

Important: Test logged-out and logged-in behavior separately when needed. Logged-in traffic often bypasses cache because it may include private or user-specific content.

Testing before enabling EDGE

Before enabling EDGE, test your current site performance.

Record:

  • TTFB
  • LCP
  • INP
  • CLS
  • Total page weight
  • Number of requests
  • Key waterfall delays
  • Current load time from important regions

This gives you a baseline for comparing the impact of EDGE after traffic starts passing through the edge layer.

For setup steps, see Adding your first WordPress site.

Testing after enabling EDGE

After EDGE is active, test the same URLs again.

Check:

  • Whether TTFB improved
  • Whether public pages show cache HITs after warmup
  • Whether important dynamic pages bypass cache correctly
  • Whether traffic to origin is reduced
  • Whether Core Web Vitals improved
  • Whether any page shows stale or unexpected content

For cache behavior, see How EDGE caching works and Review cache analytics.

Testing after optimization changes

Run tests after changing:

  • Image compression settings
  • WebP or AVIF output
  • CSS minification
  • JavaScript minification
  • Concatenation
  • Cache rules
  • Browser caching
  • Plugin or theme versions
  • Third-party scripts

Change one thing at a time where possible.

If several changes are made together, it becomes harder to know which change caused the improvement or issue.

For image-related changes, see Image compression settings and Image format optimization: WebP and AVIF.

For CSS and JavaScript changes, see CSS and JavaScript optimization with the Performance Plugin.

Common questions

Is performance testing only for developers?

No. Developers may use deeper tools, but site owners and admins can still run useful tests.

Start with EDGE dashboard screens, PageSpeed Insights, and a simple before-and-after log.

Should I test only the homepage?

No. The homepage is important, but it may not represent the whole site.

Test important templates and business-critical pages, such as product pages, checkout pages, landing pages, and high-traffic posts.

Why do different tools show different results?

Different tools use different devices, locations, network conditions, and scoring methods.

Use the same tool and same test setup when comparing before-and-after results.

Can caching improve every performance metric?

No. Caching can improve response times and reduce origin load, but front-end issues may still affect Core Web Vitals.

Large images, heavy JavaScript, render-blocking CSS, and third-party scripts may still need attention.

Should I test immediately after purging cache?

You can, but remember that the first request after a purge may be a MISS.

For cache testing, run the request again after the cache has warmed.

Common issues and solutions

Test results change every time

Run multiple tests and compare the pattern, not just one result.

Use the same location, device type, and tool where possible.

PageSpeed score improved, but the site still feels slow

Review the waterfall, third-party scripts, and real-user data.

A single score may not explain every user experience issue.

Cache looks healthy, but Core Web Vitals are poor

The issue may be front-end related.

Review images, CSS, JavaScript, fonts, layout shifts, and third-party scripts.

TTFB is high on uncached pages

The origin may be taking longer to generate the response.

Check whether the URL can be cached, whether cache exclusions are too broad, or whether WordPress/backend performance needs attention.

Logged-in users see slower performance

This can be expected.

Logged-in sessions often bypass cache because they may include private or personalized content.

Best practices

  • Create a baseline before making changes.
  • Test the same URLs before and after optimization.
  • Run more than one test.
  • Use the same tool and location when comparing results.
  • Test mobile and desktop separately.
  • Test important page types, not only the homepage.
  • Check cache behavior alongside Core Web Vitals.
  • Record changes so you can connect results to actions.
  • Test after plugin, theme, cache, and image optimization changes.
  • Use Site Audit and Site Audit Details for page-level testing.

Need help?

If performance results are unclear or a site remains slow after optimization, contact Support and include:

  • Site URL
  • Tested URL
  • Time of the test
  • Tool used for testing
  • Screenshot or link to test results
  • Whether the test was mobile or desktop
  • Whether the request was logged-in or logged-out
  • Relevant Cache Analytics or Traffic Analytics screenshots
  • X-Cache header value, if available
  • Recent changes to plugins, themes, cache rules, images, or DNS

Where to go next