Month: April 2018

Everything should have a value, because everything has a cost

— Tim Kadlec

A few weeks ago, I went to the #perfmatters conference in Redwood City to learn more about front end performance and meet people facing similar issues with performance.

One of the things that is an ongoing challenge at my company is dealing with third party tags. Simon Hearne (@SimonHearne) gave a great talk about actionable solutions for dealing with them. To better organize my thoughts about it, here’s a summary of the talk:

Developers have a tendency to make, test, ship and then put tags on things according to business wishes. The tags can have a negative impact on the site. For all its detractors, AMP did one thing right: it ensured that there wouldn’t be a ton of third party content on the page.

Simon has worked on this for five hears and the hardest thing is managing third party content. Developers seem to have less control and it can feel like we’re losing the battle with third party tags.

We can feel backed into a corner: the business wants tags to serve its business goals:
– Measurement and Analytics
– Ads & Retargeting
– “Optimization” & Testing (a/b tests)
– Comments & Live Chat
– Tag Management

Simon then shared this depressing quote:

We know that Optimizely slows down the site, but it will get us $750K in revenue this year

Here, the business knows there’s a problem, but isn’t convinced that the problem could cost the business anywhere near the $750,000 that they’re making.

This feeds into a “Not my job” issue:

We suspect it slows the site down, we haven’t tested it. Marketing says it’s critical to their latest TV campaign so there’s no point arguing

and

All the tags go through the tag manager, so they should be fine

Even so, has the business (or even the developers) considered the risk that comes with this third party content? There are a bunch of risks:

• Risk of Malicious Code Injection

  Anyone from hackers to user’s ISPs can inject things onto the page, even the NYT had an issue with it!

• Risk of Availability

  On one site, there was a 3rd party tag from China for Chinese customers, but still loaded on the English site. There was no CDN to mitigate the issue, and it blocked 1st party loading for 1500ms (!).

• Risk of Poor Code Quality

  XSS Vulnerabilities: some scripts have document.write in them. A unexpected new release of a tag that’s untested with your site can break things.

• Risk to Performance

  Developers can’t rely on third parties to police themselves. For example, Optimizely says that their downloads over HTTP will not exceed 500ms (!) and they only test in the USA. Also, these type of A/B test tools aren’t equal: most block render.

  Resource timing is the best way to check up on their party tags, but if they don’t have timing-allow-origin in the head, you’re blocked from see some of the best data. There might be a huge redirect chain, but no way to know about it: a 5ms response (good) after a 10 second redirect chain (bad) is possible!

  CPU is the biggest bottleneck. Sites should measure the amount of CPU demand that their JS generates.

  Third parties can delay onload. This can slow things waiting for onload: analytics (which might skew the data). Depending on how your site is set up, can even delay the UI!

  Good practice for mobile development is to let the radio idle. With a third party that’s constantly calling home, that’s not possible. This gets expensive for the user (data costs) and drains their battery.

Clearly, there’s lots of risks. What can be done about it?

• Step 1: Find out What Third Party Tags Are on the Page

  Use WebPageTest on the page and go to the content breakdown by domain.

  WebPageTest protip: add the parameter f=json to get a JSON output of the data that can be manipulated.

  Make sure that you’re monitoring RUM data as well because it can expose tags interacting in unexpected ways that won’t show up in synthetic tests.

• Step 2: Determine the Impact of the Third Party Tags

  Find single points of failure by using WebPageTest to block certain URLs. Use Simon’s third party impact tool (https://github.com/simonhearne/third-party-impact) to see the impact of different tags.

  There’s real benefits to doing this: By doing this analysis, a company switched to a different advertising partner that displayed ads 220ms faster, which led to $12,000 additional revenue per month!

  Use the longtasks API, which gives info about things that take more than 50ms and do A/A tests to determine how tooling is impacting your site.

• Step 3: Measure and Report What Third Party Tags Are Doing

  One option is to set a Content security Policy:
  Header that can be set to block downloads from non-whitelisted domains, prevent CSS processing from non-whitelisted places, etc. Most organizations aren’t ready to start blocking immediately. Use report-only to see what’s going on before you block.

  Tracking with synthetic testing is good, but RUM is the best way to measure 3rd party content because you get a breadth of data.

• Step 4: Defend Ourselves from New Tag Encroachment

  Use Content Security Policy: It helps prevent CryptoJacking and XSS, but you have to maintain it. Sub-resource Integrity is another option: it lets you check a resource against a hash and block if not a match

  Use service workers to prevent long things from blocking, can even cache third party things. Consider self-hosting and proxying.

  If you go these routes, know that maintenance is part of the cost.

• Step 5: Have a Third-Party Policy

  Answer these questions:

  • What does it do?
  • Who uses it?
  • What’s the risk to the site?
  • How do you remove it?

Third party content may be a weak link, but it’s here to stay. Take action and it will be less painful.

Resources:
– Simon’s slides with lots of links: https://simonhearne.github.io/weak-links/
– Cristina Shaver (a tech lead at AirBNB) made notes on the presentation: https://github.com/cshaver/perfmatters-notes/blob/master/day-2/Third-party-content-the-weak-link-in-the-chain_Simon-Hearne.md
– Simon suggested this further reading: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/