Content Performance Policy

Hi,

If AMP have shown us anything it is that Perf Matters™ and guaranteed performance matters even more.

Too many mobile sites are too slow, not due to lack of developers trying to make them faster, but because developers often have little control over third parties and page components that are managed by other teams. AMP is a framework that guarantees that a site will be performant, by limiting what it can do to avoid anti-patterns.

I believe we need a standard alternative to provide similar performance guaranties. We need to allow performance-conscious developers to opt-in to the browser’s “fast-path”, and to self-impose interventions in order to avoid performance anti-patterns on their site.

A very early draft of that concept can be found on http://yoavweiss.github.io/ContentPerformancePolicy/#introduction.

@tkadlec wrote about the thinking behind the proposal.

It’s still very early stage, but if there’s interest, I’d be happy to move the repo to the WICG org, and continue work on it here.

This sounds great.

As far as image-lazy-load, would it accept a number as its argument, to define how many of “the first few” images won’t be lazy-loaded?

Hi Yoav,

As you probably imagine, I’m very interested in this space.

I would love to help: while doing deep dives and talking to the different stakeholders, I’ve learned a few things that I hope will be useful to this effort.

This is really great Yoav! We’ve been exploring ideas along these lines as well. I’ll file a bunch of GitHub issues with questions / suggestions I have.

@Tigt - That’s what I had in mind, but it’s still very much an open question. We would need to look at the use-case and build a good story for this directive and complementary APIs that would enable developers to control the loading of those images.

@KenjiBaheux Very happy to have you on board Let’s chat!

@RickByers - Thanks for the comments and suggestions! I’ll answer on the issues

Any objections to moving the repo to the WICG org?

+1 to move the repo

repo moved! https://github.com/WICG/ContentPerformancePolicy

Hi all, FYI, this (French) article on Numerama yesterday, “Google AMP, ou quand notre impatience menace le Web”, says:

Mais le World Wide Web Consortium (W3C), qui a en charge l’élaboration des normes du HTML et dont les travaux sont publics et les décisions consensuelles, est donc mis sur la touche au profit d’un standard parallèle, fait entre soi selon la règle du plus fort. Il y aura désormais d’un côté les pages HTML conformes aux recommandations du W3C, et de l’autre les mêmes pages HTML AMP conformes aux restrictions strictes imposées par le groupe.

… which means:

But the World Wide Web Consortium (W3C), which is in charge of the development of HTML standards and whose work is public and decisions consensual, is sidelined in favor of a parallel standard, made according the rule of the strongest. There will now be on one side HTML pages that comply with W3C recommendations, and on the other the same HTML pages AMP meeting the stringent restrictions imposed by the group.

I’m trying to point this topic in the article’s comments section.

Are you sure the article is referring to this effort? Reading that section over and over (in both French and English) leaves me baffled as to what it actually means.

Hi Yoav,

I am not sure, actually!

When I pointed PLH to the Numérama piece yesterday, he pointed me back to this discourse topic saying that WICG started to get interested. I saw that you referred to AMP, so that looked like a match to me.

I’m happy to remove the reply entirely if it is misleading/unhelpful.

Oh no, your comment here is very helpful. Thanks for pointing out the article I was just wondering if it’s referring to this, as the article is rather vague.

Hey Yoav,

Cool stuff. It seems like there are potentially two kinds of directives (at least):

1. declarations that the page is going to behave in a certain way, so that browsers can be optimistic in performance assumptions.

2. declarations that embedded content needs to have certain activities / behaviours curtailed; sort of a “perf sandbox.”

Most of what you have so far seem to be the latter. FWIW, since you’re modelling this on CSP, this might help in those cases: https://w3c.github.io/webappsec-csp/embedded/

It would probably be wise to opt for the latter kind of directive, because lying to the browser about optimistic assumptions it can make (which will happen) is likely to cause more perf trouble than it solves.

Agreed. It’s the difference between CSS’s will-change (optimistic, can be misused and hurt your perf) and contain (restrictive, enforces all the qualities it needs in order to hard-optimize). The former can be useful sometimes, but it should be rare; we should mostly be designing the latter.