In your Synthetic Third Party dashboard, we automatically group all third party requests in your third party waterfall chart. This lets you easily identify all the third party services used on your website.
For each third party, you get the number of requests and size for each content type. There's also a first party comparison you can toggle on/off to see what proportion of your requests come from first party vs third party.
Tracking the number or size of third-party requests isn't enough
We don't believe that just looking at the number of requests or the size of requests a third party makes is a good enough indicator that they are a bad actor. A well-built web page that manages its requests can easily negate any issues by delaying those request till after the page is rendered and interactive.
What really matters is how a third party might be blocking the rendering or the interactivity of the page.
These third party blocking metrics are a far better indicator of who might be causing real issues on your page:
- Blocking JS or CSS requests. This tells you if the rendering of the page is being delayed by a blocking request from a third party.
- Blocking CPU caused by a third party. Blocking CPU is any JS function that takes longer than 50ms (also known as a long task), which often leads to page jank. Blocking CPU stops your users from smoothly interacting with your page and delays other metrics like First CPU Idle and Time To Interactive.
In this example, Vidible has 594ms of blocking CPU, causing jank on the page, while all the other third parties don't trigger any signifiant CPU activity at all. This helps you quickly focus in on which third parties are causing real user experience problems.
1. Review your Third Party Synthetic dashboard
When you review your dashboard, you'll want to double check that resources have been grouped correctly.
We use the URL you're testing to identify the first party domain and any sub domains. So if you're testing "website.com" we'll also include any subdomains like "cdn.website.com" as a first party.
All other requests will either be identified as a known third party service or will be lumped together into the "Unrecognized Third Party" group. There's a good chance there might be other domains in that group that you consider first party. You can move resources into the first party group by adding them to Settings > First Party.
Unrecognized Third Party
We use the open source project third-party-web to identify known third party services. If there are other popular third party services that you think should be recognized but aren't, you can let SpeedCurve support know (firstname.lastname@example.org) or contribute them directly to the project.
Custom Third Party
In Settings > Third Party you can also build your own custom third party with a set of filters that match on the URL or your resources.
A custom third party is actually just a group of resources and doesn't have to be strictly used for tracking a third party. You can even track the history and set performance budget and get alerts for a single request. If your task is to trim down a specific JS request and make sure its size or CPU usage is within budget, then you can setup a specific filter, set a performance budget, and monitor your improvements.
Custom third party filters support basic wildcard matching with an asterisk (
*). Multiple wildcards are allowed, for example
2. Turn on "Track History"
For any third party in your waterfall, you can turn on "Track History" and we'll start collecting detailed third party metrics every time we run a test. You can then monitor a third party over time and set performance budgets and alerts.
This is a great way to keep an eye on any changes a third party might be making and alerting you to impacts on your page. You could even agree to an SLA with a third party and then use SpeedCurve to monitor and enforce it, keeping everyone honest and on the same page.
3. Create performance budgets for specific third parties
After you've started tracking third parties, you can create performance budgets and get alerts on any of your third party metrics.
So first check the grouping of your third parties, then start tracking them and set performance budgets to track their impact on your user experience!