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.
@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.
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.
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.
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.