Chaperones and curfews: minimising 3rd party impact
summary
Web pages keep gaining third‑party weight: audits show 85 third‑party scripts on some e‑commerce sites and an average third‑party CPU execution of ~225 ms, which accumulates into seconds of blocking. Practical fixes include identifying vendors with RequestMap/WebPageTest/Chrome DevTools and Lighthouse, switching blocking scripts to async (one change saves ~2s on mobile 3G), using serviceworker timeouts or a kill‑switch env var, proxying or self‑hosting (one retailer saves 1.7s start‑render by self‑hosting), and centralising data via Segment or server‑side tag management.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker intro
- 2:08What are third parties
- 11:10Why use third parties
- 14:22Identifying third-party impact
- 16:08When and where to load third parties
- 23:28Loading scripts asynchronously
- 32:13Self-hosting third-party scripts
- 36:08Preconnecting and preloading resources
- 37:14Evaluating third-party providers
- 38:46Protecting your site from third parties
- 40:31Managing tag managers effectively
- 43:22Leveraging contracts for performance
- 44:47Summary and Q&A
related talks
54mReducing the Speed Impact of Third-Party Tags
53mThird Party Woes
47mIt’s My (Third) Party, and I’ll Cry if I Want To
41mIt’s My (Third) Party, and I’ll Cry if I Want To
52mIt’s My (Third) Party, and I’ll Cry if I Want To
31mIt’s My (Third) Party and I'll Cry If I Want To
46mDeep dive into third-party performance
47mIt's My (Third) Party and I'll Cry If I Want To