Deep dive into third-party performance
A deep-dive into the impact of third-party tags on web performance.
Every third-party tag is someone else's code, running on your users' devices, with your name on it. This talk is seven times that went wrong.
About the talkPermalink to this heading
By late 2019 the median website was 37% third-party requests by count (HTTP Archive, October 2019). Analytics, advertising, optimisation, JavaScript CDNs and tag managers all arrive with a business case, and all of them execute with the same privileges as the code you wrote yourself.
This talk works through seven real incidents — outages, revenue losses, and one case of a "performance" tool making things measurably slower — and pulls a defence out of each.
What's coveredPermalink to this heading
- A thirty-second wait. A social sharing script blocked
document.readyand took critical application logic down with it during a China launch. Sync is still king, so feature-flag it and defer it. - A 30% conversion drop. A silent third-party update broke a checkout button. Subresource Integrity prevents unannounced changes, and was live on just 5.15% of pages.
- The tool that cost a second. An unload-event listener added roughly a second of latency. Synthetic tests never saw it; RUM did.
- A 26% revenue swing. A review provider degraded Android badly enough that removing it lifted Android revenue by 26%. Adaptive tag loading is the middle path.
- Malicious ads and crypto miners. Content Security Policy (6.11% adoption) and
connect-srcrestrictions, plus CPU metrics to catch what network metrics miss. - A/B testing tools. Render-blocking by design, with a 500ms default SLA. Proxy through your CDN, self-host, or move it to the edge.
- A loading order. Immediate for experimentation and tag management, fast for session and performance tracking, late for ads, reviews and live chat.
As Tim Kadlec puts it in the deck: "Everything should have a value because everything has a cost."