Chaperones and Curfews: Minimising 3rd Party Impact

Chaperones and Curfews: Minimising 3rd Party Impact

Talk given at PerfMatters 2019 – https://perfmattersconf.com

Every year websites get heavier – but the majority of growth isn’t coming from code written at the organisations running them... it’s coming from 3rd parties.

Long gone are the days when it was viable to build everything internally, but their impact on performance is already getting a little out-of-hand. We don’t want to be the fun police throwing everyone out, but we can start to moderate the party.

In this talk we won’t be looking to remove 3rd parties altogether – nobody likes having their toys taken away; instead we’ll be taking the practical approach of accepting that 3rd parties aren’t going anywhere and look at what strategies we can employ for maintaining performance and safeguarding against slowdowns, outages and abuse.

F085bf2092cb300bac787cc5bc65d301?s=128

Ryan Townsend

April 03, 2019
Tweet

Transcript

  1. Chaperones and curfews Minimising 3rd party impact Photo by Spenser

    on Unsplash
  2. Who am I? Ryan Townsend @ryantownsend

  3. None
  4. None
  5. • What are third parties? • Why are they problematic?

    • Why use them at all? • What can I do to mitigate against their impact?
  6. What are third parties?

  7. Any infrastructure or service on a separate origin that you

    don’t control
  8. Why are third parties a problem?

  9. Rewind back to Velocity 2011…

  10. None
  11. None
  12. The web lived happily ever after.

  13. Except it didn’t.

  14. • Social media buttons • Tag managers • Ads •

    A/B testing tools • Personalisation • Analytics & Event Capture • Independent Customer Reviews • Retargeting • Affiliate trackers • Live chat • Hosted webfonts • Comment platforms • Videos • Developer Utilities
  15. Source: Steve Souders / HTTP Archive

  16. Source: Yottaa Average # of 3rd Parties 2015 2016 2017

    2018 85 60 37 15
  17. “Can I bring a +1?”

  18. requestmap.webperf.tools

  19. But it’s not just the volume…

  20. “There is zero performance overhead to using our synchronous script

    […] our typical response time is around 200ms” – Popular Third Party Provider
  21. Source: Steve Souders / HTTP Archive

  22. And it’s not just the network…

  23. Continual JavaScript execution 1 second

  24. “Third party script execution is the majority chunk of the

    web today” – Patrick Hulce, Lighthouse
  25. The average execution time per third-party is 225ms

  26. 85 third-parties x 225ms = 19s

  27. It’s not even just the visitors who are affected…

  28. • Inaccurate development & QA experience • Unable to perform

    commit/build-time linting • Governance processes in the hands of the 3rd party
  29. Why use third parties?

  30. None
  31. None
  32. None
  33. • You can’t build it all yourself • You shouldn’t

    build it all yourself • You’re hacking around technical limitations • You’re hacking around organisational limitations
  34. So, what can we do?

  35. Identify your third parties

  36. requestmap.webperf.tools

  37. Long-running JavaScript Large payloads webpagetest.org/easy

  38. None
  39. • It’s My (Third) Party and I’ll Cry If I

    Want To
 Harry Roberts (@csswizardry) • AB Testing, Ads & Other 3rd Party Tags
 Andy Davies (@andydavies) • Performance Audit (Live)
 Tim Kadlec (@tkadlec) • Raiders of the Fast Start
 Katie Sylor-Miller (@ksylor)
  40. Consider your loading strategy

  41. 1. Where/when do you need to load it?

  42. 2. How critical is it?

  43. Progressive enhancement isn’t just for first-party JavaScript

  44. 3. Do we need ALL of it?

  45. None
  46. • Check for GZIP/Brotli compression • Subset fonts • Centralise

    data capture (e.g. Segment) • Disable loading libraries
  47. You can’t all bring jQuery as your +1!

  48. Check for image transformation

  49. Avoid tech debt

  50. Optimise your 3rd party scripts

  51. 4. Can you load it asynchronously / deferred?

  52. None
  53. “But what about the flicker!?”

  54. Curfew

  55. font-display: fallback

  56. Implement this one NASTY trick… you’ll never believe what happened

    next
  57. None
  58. None
  59. None
  60. <head> <script> function showBody() { document.body.style.display = 'block'; } setTimeout(showBody,

    3000) </script> <script src="https://myadprovider.com/" onload="showBody()" onerror="showBody()" importance="high" async> </script> </head> <body style="display:none"> ... </body> when the script loads/fails: show the body hide the whole body after 3 seconds: show the body regardless
  61. None
  62. function timeout(delay){ return new Promise(function(resolve, reject) { setTimeout(function() { resolve(new

    Response('', { status: 408, statusText: 'Request timed out.' })) }, delay) }) } self.addEventListener('fetch', function(event) { // if the request is not for example.com, serve requests normally if (!event.request.url.includes('example.com')) { return } return event.respondWith(caches.match(event.request).then(function(response) { return response || Promise.race([ timeout(2000), fetch(event.request) ]) })) }) attempt the request force a 2-second timeout service-worker-timeout.twnsnd.com
  63. 5. Can you self-host the resources?

  64. • No DNS lookup • No connection setup • No

    SSL negotiation • “Better” HTTP/2 prioritisation • You can fingerprint and use far-future expiry • Plays nicer with Content-Security-Policies *
  65. What about changes?

  66. None
  67. Dual-phase loading

  68. https://medium.com/caspertechteam/we-shaved-1-7-seconds-off-casper-com-by-self-hosting-optimizely-2704bcbff8ec

  69. https://medium.com/caspertechteam/we-shaved-1-7-seconds-off-casper-com-by-self-hosting-optimizely-2704bcbff8ec

  70. 6. Can we preconnect or preload?

  71. Choose your friends

  72. None
  73. None
  74. The Windows 95 launch really got out of hand

  75. None
  76. Protect your site from 3rd parties

  77. None
  78. Kill Switch

  79. Feature-Policy

  80. sync-xhr, document-write, legacy-image-formats, max-downscaling-image, unsized-media, image-compression, font-display-late-swap, lazyload, unoptimized-images

  81. Protect your site from your company

  82. Tag Managers

  83. It’s all our fault

  84. • Embed manually and maintain a clear release runway •

    Migrate long-term scripts to core site • Server-side tag management
  85. TWO TAG MANAGERS?

  86. None
  87. None
  88. Remember you have leverage

  89. Everybody wins…

  90. “Huge props to WordAds for reducing their impact from ~2.5s

    to ~200ms on average!” – Patrick Hulce, Lighthouse
  91. 32,000 sites benefitted.

  92. • You don’t make friends taking toys away • Understand

    really how your third parties are used • Work with what you’ve got and optimise • Assume third parties will burn you • Protect yourself • Work with them for the better of the whole web
  93. Thank you! Ryan Townsend CTO, SHIFT – @ryantownsend twnsnd.com/perfmatters