Now to test the impact of this large number of third-parties lets block them and re-run the test. Here’s the result:
Kind of what I expected, the third-parties mean the page takes longer to finish. But I had secretly hoped that they were also affecting render performance - that the blocked version would render quicker.
To dig in a bit deeper I looked at the waterfall chart of the blocked version, and I noticed two things: the requests seemed to be sequential rather than parallel, and the CPU was pegged at 100% for most of the time. Curious.
Whenever the CPU is pegged in a Chrome webpagetest result, here’s a pro-tip: enable timeline capture.
This gives you a json file that you can drag into your local Chrome developer tools window:
Loading this up in Chrome Canary lets you analyse the network waterfall in the timeline view, where I saw significant gaps in the processing timeline, and a number of grey requests:
The grey request was one which should have been blocked by webpagetest. You can’t drill into any more details from this view, although it looks like the blocked requests still consume time yet don’t have a response.
In issue 584 on the webpagetest GitHub repo Pat Meenan states:
blocking (or modifying request headers) in Chrome is exceedingly expensive
So, trying again in Firefox and Internet Explorer we get the following results:
And for visual performance, IE gives the best result:
So the final result, to show the impact of third-party content on the user experience comes out below: