We have a complex love-hate relationship with the third party content on our sites, and it has taken a turn for the worse. On the one hand, third party content often pays the bills. On the other hand, recent developments have increased its “cost”. HTTP/2 means third party content is even more of a performance burden than before, the weight of that content is taking up a larger and larger percentage of our site’s overall bytesize, ad-blockers mean users have had enough, and projects like Google AMP and Facebook Instant Articles mean that embedders feel the same.
Our lack of control over what 3rd parties are doing on our sites is showing. How can we gain it back?
In this talk, we will discuss mitigation techniques to reduce the performance and security impact third parties have on our site as well as monitoring what these scripts are doing.
We will also talk about a long term plan to restore sanity to the ecosystem. We need mechanisms that will enable us to put the developers back in the driver’s seat and at the same time enable smarter ad blockers, so that responsible 3rd parties can remain a source of income. I’ll propose such mechanisms.
Developers improve performance by optimizing the critical rendering path, compressing images and making them responsive, anything they can.
Business requirements introduce code for third party content, and performance improvements disappear.
Other research has shown that 50% of the data downloaded on mobile is ad content.
Ad blockers have risen in use and extended to mobile browsers to control the ad madness.
Some content providers have introduced their own formats to force content to be reduced to a minimum for a distraction-free user experience.
Advertisers have responded in one way by making ads lightweight, served over https, supporting user choice and non-invasive.
Publishers are trying to influence users on how to manage rather than block ads.
Metrics used by third party content providers don’t focus on the user.
At one level we need to address the symptoms, at a deeper level address the underlying issues.
Ad content is often intrusive, confusing, misleading, greedy for bandwidth and processing power and sometimes dangerous to users.
Potential ways of mitigating the situation include:
- Using async loading – synchronous loading leads to huge performance penalties.
- Accelerating ad loading by using preconnect and preload.
- Using service workers.
- Using content-security-policy (CSP) to tell browsers what kind of content to accept and from where.
- Isolating and managing third party content code with Iframes with a sandbox feature.
- Using SafeFrame to allow third party content constrained access to the DOM.
- Getting third party content developers to use passive touch events rather than active.
- Getting third party content developers to use intersection observers that don’t take over scroll and touch events and continuously poll elements.
Do-not-track was an attempt to allow users to opt out of tracking, but when they did, ad providers stopped respecting it, which shows that browsers must be allowed to enforce user wishes.
Policies have been proposed to W3C around managing and limiting the effect on performance of specific features, including Synchronous XHR and document write.
A broad Content Performance Policy would also propose resource size limits so third party content providers can’t waste users’ bandwidth and data allowances, and priorities for CPU bandwidth so the most important content is not blocked.
Work is now also going into how the user experience can be defined so that policies can be set.
The best hope lies in giving site owners greater control so they can manage the user experience, smarter third part content embedding that does not block the user experience and ad blockers that take performance into account.
This is not a case of anyone being evil: everyone is doing what they think and hope is best.
Browsers are meant to give control to users – that’s why we call them user agents.
Initiatives like Google’s AMP don’t necessarily load faster but they load fast enough while delivering better performance.
To reach all users, publishers now have to consider HTML, AMP, Apple News and FB’s Instant Articles.
Ad blockers have led to ad blocker blockers and then ad blocker blocker blockers.
Even with async loading, you’ll still have arbitrary code with full access to everything.
Preload and preconnect are less efficient for dynamic content.
There’s no way as yet to implement CSP on frames, which may limit its usefulness, and ultimately CSP is meant to be a security-oriented feature.
Third party content providers may not want to be iframed, their content may not be fully functional in iframes and content in iframes will still continue to add to the CPU load.
SafeFrame is not supported by all third party content providers.
None of this addresses privacy issues, as user data tracking is performed on the server, so the browser doesn’t have much say in it.