Synthetic testing measures website performance by loading a page in a controlled test environment.

Instead of waiting for real visitors, a synthetic test simulates a page visit from a defined location, device type, browser, or network condition. The test then records performance metrics such as loading speed, rendering behavior, page weight, requests, and Core Web Vitals.

Use synthetic testing to compare performance over time, detect regressions, and understand how important pages behave under repeatable test conditions.

What synthetic testing does

Synthetic testing gives you a controlled way to test a page.

A synthetic test can show:

  • How long a page takes to load
  • How quickly important content appears
  • How stable the page layout is while loading
  • How much JavaScript, CSS, images, and other assets the page loads
  • Whether render-blocking resources slow the page down
  • Whether third-party scripts affect performance
  • Whether a page becomes slower after a change
  • How results compare before and after optimization work

Synthetic tests are useful because they make performance testing repeatable. You can test the same URL again later and compare results under similar conditions.

Synthetic testing vs real-user data

Synthetic testing and real-user data answer different questions.

Synthetic testing answers: “how does this page perform under controlled test conditions?”

Real-user data answers: “what did actual visitors experience?”

Synthetic testing is based on simulated visits. Real-user data is based on actual visitor sessions.

Synthetic test results may differ from real-user experience because visitors can use different:

  • Devices
  • Browsers
  • Locations
  • Network speeds
  • Screen sizes
  • Cookies
  • Login states
  • Browser cache states
  • Extensions or privacy tools

A synthetic test is useful for comparison and troubleshooting, but it does not represent every visitor.

When to use synthetic testing

Use synthetic testing when you need a consistent way to check performance.

Common use cases include:

  • Running a performance audit for a specific URL
  • Comparing performance before and after optimization work
  • Checking whether a plugin or theme update affected performance
  • Testing important landing pages
  • Monitoring product, pricing, or campaign pages
  • Detecting performance regressions over time
  • Reviewing Core Web Vitals in a controlled environment
  • Checking whether page weight, scripts, or images increased
  • Verifying whether a performance issue affects one URL or multiple URLs

Synthetic testing is especially useful when you need a stable baseline.

When not to rely only on synthetic testing

Do not rely only on synthetic testing when you need to understand live visitor behavior.

Synthetic testing may not fully explain:

  • Issues that affect only logged-in users
  • Problems that happen only during traffic spikes
  • Short outages between tests
  • Region-specific visitor problems not covered by the test location
  • Browser-specific issues
  • User-specific checkout, cart, account, LMS, or membership behavior
  • Problems caused by a visitor’s device, network, or browser extensions
  • Security events or blocked requests
  • Cache behavior across all live traffic

For these cases, combine audit results with traffic analytics, cache analytics, logs, security events, and support details from affected users.

What synthetic tests can measure

Depending on the audit tool and configuration, synthetic tests may measure:

  • Page load timing
  • Time to first byte
  • Largest Contentful Paint
  • Cumulative Layout Shift
  • Interaction-related metrics
  • Total page size
  • Number of requests
  • JavaScript execution impact
  • CSS and render-blocking resources
  • Image optimization opportunities
  • Third-party script impact
  • Main thread activity
  • Waterfall timing
  • Cache behavior indicators

These metrics help you understand why a page feels fast or slow under test conditions.

Why results can vary

Synthetic test results can vary between runs.

Common reasons include:

  • Network variation
  • Third-party script delays
  • External fonts, ads, embeds, or analytics
  • Different cache state
  • Recent content changes
  • Plugin or theme updates
  • Image or asset changes
  • Server or origin response variation
  • Background tasks on the site
  • Redirect changes
  • Test location or device differences

A small difference between two tests is normal.

Look for repeated patterns, large changes, or drops that happen after a known site change.

How to read synthetic test results

Review synthetic test results as part of a trend.

Do not treat one result as the full performance story.

When reviewing results, ask:

  • Did the same URL become slower over multiple tests?
  • Did the change happen after a plugin, theme, content, or rule update?
  • Did page size increase?
  • Did the number of requests increase?
  • Did JavaScript or CSS become heavier?
  • Did third-party scripts delay rendering?
  • Did important images become larger?
  • Did cache behavior change?
  • Does the issue affect only one page type?

If one result looks unusual, run another audit and compare it with previous results.

Common synthetic testing use cases

Before and after optimization

Run a test before making changes, then run another test after the changes are live.

Use this to compare:

  • Image optimization changes
  • CSS or JavaScript changes
  • Plugin removals
  • Theme changes
  • Cache changes
  • Web Rules changes
  • Third-party script changes

Performance regression checks

Use scheduled or repeated tests to detect when a page becomes slower.

This is useful after:

  • Plugin updates
  • Theme updates
  • New tracking scripts
  • New ads or embeds
  • Content redesigns
  • WooCommerce changes
  • Landing page changes

Campaign page monitoring

Use synthetic testing for campaign pages before and during a launch.

Check:

  • Page speed
  • Page weight
  • Important images
  • Third-party scripts
  • Tracking tags
  • Form behavior
  • Cacheability

WooCommerce page testing

Use synthetic testing for public WooCommerce pages, such as:

  • Product pages
  • Product category pages
  • Shop archive pages
  • Campaign landing pages

Avoid using synthetic audits as the only test for:

  • Cart
  • Checkout
  • My Account
  • Payment steps
  • Order confirmation pages
  • Customer-specific pages

Those flows need functional testing as well.

Best practices

Follow these practices when using synthetic testing:

  • Test the same URL consistently.
  • Use stable public URLs.
  • Run tests before and after major changes.
  • Compare trends instead of reacting to one result.
  • Avoid private, logged-in, cart, checkout, or account URLs.
  • Document major changes so results have context.
  • Check page weight and request count when scores drop.
  • Review third-party scripts if results become unstable.
  • Combine synthetic results with analytics and logs when troubleshooting.
  • Use scheduled audits for important pages you want to track over time.

Common issues and solutions

Symptom: Results are different between two test runs

Likely causes:

  • Normal network variation
  • Different cache state
  • Third-party scripts loaded more slowly
  • External resources changed
  • The page changed between tests

Resolution steps:

  1. Run another test for the same URL.
  2. Compare the result with previous audits.
  3. Check whether the page content changed.
  4. Review third-party scripts and external resources.
  5. Look for repeated patterns instead of one isolated result.

Symptom: The synthetic test looks worse than real user reports

Likely causes:

  • The test uses a slower simulated device or network.
  • The test location differs from your main audience.
  • Real users may have cached assets.
  • Real users may use faster devices or networks.
  • The synthetic test loads the page as a first-time visitor.

Resolution steps:

  1. Review the test conditions.
  2. Compare results with real traffic or analytics data.
  3. Check whether repeat visits perform better.
  4. Review cache behavior for the tested URL.
  5. Use the result as a controlled benchmark, not the only source of truth.

Symptom: Real users report issues, but synthetic tests look fine

Likely causes:

  • The issue affects only specific locations.
  • The issue affects logged-in users.
  • The issue happens during traffic spikes.
  • The issue depends on a specific device or browser.
  • The issue occurs between scheduled test runs.
  • The issue involves checkout, account, LMS, or membership behavior.

Resolution steps:

  1. Collect affected URL, device, browser, location, and timestamp.
  2. Check traffic analytics and logs around the reported time.
  3. Review cache and security events.
  4. Test the user flow manually if it involves login, checkout, or private content.
  5. Contact Support if the issue cannot be reproduced.

Symptom: The tested URL redirects

Likely causes:

  • The URL is not the canonical version.
  • HTTP to HTTPS behavior changed.
  • www or non-www behavior changed.
  • A redirect rule affects the URL.
  • The page was moved or unpublished.

Resolution steps:

  1. Open the URL in a browser.
  2. Confirm the final destination URL.
  3. Test the final canonical URL.
  4. Review redirect rules if the redirect is unexpected.
  5. Update scheduled audits if the monitored URL changed.

Need help?

Contact Support if:

  • Synthetic tests fail for a valid public URL
  • Results drop repeatedly and the cause is unclear
  • A page appears blocked during testing
  • Audit results changed after DNS, cache, plugin, theme, or Web Rules changes
  • You need help deciding whether a page should be tested synthetically
  • You cannot connect audit results with live traffic behavior

Include:

  • Affected domain
  • Tested URL
  • Audit date and time
  • Timezone
  • Expected result
  • Actual result
  • Screenshots of the audit result
  • Recent plugin, theme, content, DNS, cache, or Web Rules changes
  • Whether the issue affects one page or multiple pages
  • Any related user reports, locations, devices, or timestamps

Where to go next