There's been an explosion in 3rd-Party Tags…
And as Tim Kadlec once said "Everything should have a value, because everything has a cost".
So how do we measure the performance cost of all the 3rd-party tags we keep adding to our sites?
Although Chrome supports blocking individual requests, my favourite approach still uses WebPageTest.
If you're interested in the Chrome approach Umar covered how to use DevTools to block a network request just after it was released in Chrome Canary – it still works the same way today and now you can even block whole domains too.
One of the reasons I prefer WebPageTest is its side-by-side comparison of the filmstrip is a really powerful way to communicate the impact of tags to co-workers, bosses and clients.
Creating the Comparison
The first step is to test a page with nothing blocked i.e. in it's default state.
Remember to enable video capture, and labelling the tests will make it easier to differentiate them when viewing the filmstrip. In the spirit of being obvious I often label this step 'Original' or 'Default'!
Next we need to create a test with some requests blocked – I tend to label this one '3rd-Parties Blocked' or similar depending on what's actually blocked
There are a few ways to block requests:
Using the Block Field
The easiest way to block requests is to add entries to the block field:
The block field takes a space separated list of values and like its name suggests blocks any requests containing one of the values.
As it's a substring match it's pretty generous with what it accepts – anything from a single letter to a full URL – so if you add
.comWebPageTest will block all requests with .com anywhere in the URL.
I use the block field approach more often than the script based approaches below.
Using a Script
Alternatively there are three script commands that can be used to block requests - they're straightforward and self-explanatory.
block– followed by a space separated list of substrings
This works in the same way as the block field in the previous example.