Code 16: Taking Back Control over Third Party Content — Yoav Weiss

Performance is one of those areas that web developers simply have to be aware of, understand and take responsibility for. And as with other overarching and underpinning principles that developers must take into account — security and accessibility are other good examples — there are, in fact, very specific ways in which devs can improve web performance.

Which brings me to Yoav Weiss. Because that’s what he does. He talks the talk and he walks the walk in his role as Principal Architect at Akamai Technologies, a web performance specialist who is constantly pushing for a faster web.

As is implied in the presentation title, Yoav’s talk at Code 16 focused on the role that third party content can play in negatively affecting site performance, and how this might be mitigated.

Here’s our Wrap summary.

Taking Back Control over Third Party Content

Yoav Weiss, Web Performance Specialist

Yoav Weiss

Key points

Developers improve performance by optimising 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.

Analysing one site showed that 1Mb downloaded was actual content, but required downloading another 11Mb, 7Mb of which was JavaScript.

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.

Our ecosystem is broken”.

Code 16: Yoav Weiss

Takeaways

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.

Once you bring in third parties, they can do pretty much whatever they want.”

Code 16: Yoav Weiss

Caveats

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.

Resources

@yoavweiss
slides
website
github
Content Performance Policy

Tweets

Code 16: Yoav Weiss

Comments are closed.