Migrations
Accounts
Features
Contact & Support
Terms & Privacy
Twitter
Facebook
LinkedinBuilt WithAround The
Copyright © 2016 - 2025 SiteDistrict, All Rights ReservedYou were probably sent to this page because you ran a synthetic performance testing tool on a website, and someone wants to show you a better way.
This page is meant as a starting point to making a huge leap forward in terms of understanding, speaking about, and actually improving real-world website performance.
Synthetic website performance testing tools are tools that measure metrics about a website's performance, using a very specific and fabricated - or "synthetic" - set of conditions.
They typically test a single page, though some can also test multiple pages. They test performance using a specific browser, network connection & speed, geographical location, browser state (cache, memory), and so on.
All synthetic test scenarios are essentially are "made up", and do not actually reflect the reality of your website as experienced by real world visitors.
There are a number of popular synthetic website performance testing tools. In the vast majority of cases, people are using them completely wrong. Some of the popular ones include:
There are other synthetic testing tools out there as well, and they all suffer the same shortcomings.
As hinted above, the main problem with synthetic testing tools is exactly as described by the name: they are synthetic.
Real-world website performance is far more complex and variable. It's often unpredictable. It's impossible to "measure" it with a synthetic tool.
Instead, real website professionals rely on real-user metrics, also known as "field data" (in some Google documentation). These metrics must be collected directly from actual website visitors.
There are a few reasons why this problem exists in the first place. Here are a few of reasons:
The situation is slowly changing for the better. Posts like this are a step in the right direction, even if some will find these truths hard to accept.
In order to properly understand the website performance of your actual visitors, especially the collective experience of multiple visitors over many different page views, you must view metrics and data that is collected for their actual browsing activity.
Thankfully, this is easier than it sounds, and is automatic in many cases.
The Chrome User Experience (UX) Report, also known as the CrUX, is a huge database maintained by Google that holds performance and user-experience metrics from users of Chromium-based browsers that have opted in to have their data collected and reported back to Google.
This huge database is available to the general public, and various public tools (some listed below) pull data from this database, to help you understand how your website is performing for actual users.
Website performance metrics can also be recorded by JavaScript code that is embedded directly into the website pages. Google provides a web-vitals library on GitHub, New Relic has a Browser Monitoring product, and there are other options as well. These options either send the browser performance metrics back to their own database or service, or let you decide which service should consume and hold the data.
SITEDISTRICT automatically embeds browser monitoring code into all website pages that we serve, and the data is collected by our platform and can be reviewed and visualized using our dashboard.
For properly understand real-word website performance, the "better" tools are all tools that let you visual data from actual website visitors, whether it is the data collected in Google CrUX database, or that sent to a separate third-party database.
See our Measuring Website Performance page for a list of alternatives.
SiteDistrict also uses its own analytics code to collect browser performance data, and you can see near real-time performance data and metrics from our dashboard. Our performance data and analytics are generally far more detailed and advanced than the other options listed above, but truly proficient use does involve some investment in learning.
On SiteDistrict, the synthetic testing tools above may be blocked, and a simple HTMl page saying "You're Doing It Wrong", with a link to this page, may be shown.
The sections below explain why these tools are blocked.
The main reason we started blocking these tools can be told quickly with a story. Here’s the common scenario:
We’ve actually lost count of the times this has happened. By the time we even know it’s happening, everyone has wasted time.
We used to have to wait until Step 5 to do anything. Then we tried to stop it at Step 3, by blocking & disabling certain plugins. Now we try to stop it at Step 1.
In the vast majority of cases, when someone has attempted to run one of the synthetic website performance testing tools on a site hosted on SiteDistrict, they are doing it for the wrong reason, and with a poor understanding of website performance.
In order to save everyone time, and to encourage people to focus on what actually matters, we block these requests, and urge people to step back, and do some additional homework and learning.
One of the biggest issues with synthetic testing tools is that they may report a bad "score", or a list of things to "improve". But remember, these tests are synthetic, and using the results to try to affect your real-word website performance is a bad idea.
In many cases, these tools might lead you to think you have a performance problem, when you actually don't.
To know if you have an actual problem, you need to rely on communicating with both your actual website visitors and users, and also properly understanding website performance metrics, and then reviewing metrics from real users.
The easiest way to solve a problem, is to realize that you don't have one in the first place.
Some of these synthetic tools, when used incorrectly, can actually cause performance and bandwidth issues on sites that we host. While infrequent, and typically a minor concern, we've opted to protect sites hosted on SiteDistrict from improper usage of these tools and inadvertent issues that could arise, by blocking them in many cases.
Given the other issues above, along with the shortcomings and relatively low value of synthetic data, we feel this is a smart decision.
So, you thought that running a synthetic testing tool was a good idea. We've hopefully showed you why it's typically NOT.
So what should you do instead? We've outlines some steps and provided some useful links to take your website performance expertise to the next level.
Website and WordPress performance is one of our specialties, and we have multiple articles that we recommend reading, to better understand website performance:
Read these pages. Google to learn more about some of the concepts covered. Read them again until you feel like you "get it".
Yes, there is a lot of content, and it make take a while. Website performance is not "easy".
Instead of running synthetic tests and spending hours trying to fix "problems" that might actually not be a real issue, and likely not making any real difference, or possibly making things worse, spend a few hours learning instead, and focus on educating others that you need to work with.
Switch to reviewing and analyzing real user metrics (RUM) for performance. There are many options for reviewing both data collected automatically by Chromium-based browsers and stored in the Chrome UX Report, as well as embedding performance tracking directly into your website and using a third-party dashboard to review.
Check out high-level historical CrUX data using Treo or CrUX Vis. If you use Cloudflare, enable or review their Web Analytics.
If you host your WordPress site with SITEDISTRICT, then head over to our Analytics / Reports / Logs pages in our dashboard, and review the Page Views, Performance, and Web Vitals pages.
See our Measuring Website Performance page for more details.
If you've done your homework, then you will know by now that website performance can differ from one visitor to another, and from one page view to another.
Spend some time analyzing your real user performance metrics to answer this very basic question:
Why do some page views have good scores, and others have poor scores?
If you can reliably answer this question for groups of your page views, then you are close to being ready to make meaningful strides in terms or improving website performance for your visitors.
While synthetic testing tools should never be used as a scoreboard for website performance, some of the better tools actually can serve an important function: as diagnostic tools.
Diagnostic tools let you analytics what is happening under specific conditions - collecting what is sometimes known as "lab data" - and letting you visualize and analyze the results, often using the expertise you've acquired from hours of reading about website performance and analyzing real user data.
If you understand the test conditions, and how they likely map to real-world situations, you can use a synthetic test result to help you understand what is likely going on in similar situations in the real world.
One of the best tools for understanding the performance of a web page load is something called a waterfall chart, and one of the best tutorials on how to read the waterfall chart from a popular tool called WebPageTest is this blog post:
Once you've read that page, and understand - even if at a basic level - much of what it covers, then you are much closer to being ready to perform meaningful website performance analysis and optimization.
If you're not already hosting your WordPress website with SiteDistrict, consider moving it to our platform.
First, you will likely gain immediate performance benefits, with faster uncached server response times, advanced global page caching, our custom CDN, and cutting-edge protection from performance-degrading attacks via our firewall.
But even more useful in many cases is our integrated real-user metrics collection for all sites, and our dashboard tools for reviewing and analyzing these website performance metrics. One of the top reasons people don't approach website performance correctly is because they lack the data and tools. SITEDISTRICT solved that problem.
Finally, if you're a paying customer on SiteDistrict, you have access to our expert support, and we can help you diagnose - and in some cases, help you fix - any remaining performance issues.
This is unfortunately, easier said than done. We have yet to meet a WordPress professional that understands WordPress website performance as deeply and completely as we do.
If you know developers who already work on SiteDistrict, they are at least more likely on average to understand how to approach website performance, even if their mentality comes down to "host it on SiteDistrict and forget about it".
If you can find someone who is willing to read the information we provided above, understands it, agrees with it, and is interested and excited to work with us, then - based on that - it's a promising sign that you've found someone that might be worth hiring.
A smaller number of people might be used to relying on PageSpeed Insights or similar tools to review other aspects of their website, such as for Search Engine Optimization (SEO) or Accessibility.
There are other tools - both free and paid - that are actually much better suited to analyzing your website(s) in this regard. We recommend searching for other tools via Google, or talking to others in your professional network about what they use and prefer.
If you find one of these other non-performance-focused tools to be blocked by SiteDistrict, feel free to Contact Us.
The misuse of synthetic website performance testing tools is extremely common, but you can easily be part of the solution, rather than the problem.
Educate yourself about website performance, ensure you have access to good real-user metrics, and stop wasting time looking at scores that don't matter.