Content Performance Policy : une étape supplémentaire pour un web plus rapide ?

Cet article est un peu particulier, car je vais aujourd’hui vous parler d’une proposition qui pourrait devenir une norme, et non pas d’une bonne pratique déjà existante.

Nous vous recommandons depuis plus d’un an dans nos rapports d’audit web l’utilisation de Content Security Policy pour sécuriser davantage vos sites web, notamment vis-à-vis d’attaque XSS.
L’idée de CSP est de permettre aux éditeurs de sites web de mettre en place une politique de sécurité, qui sera ensuite appliquée par le navigateur web. Cela permet notamment d’interdire l’utilisation de fichiers JavaScripts non autorisés par l’éditeur du site, ou encore de forcer l’utilisation du HTTPs pour les ressources de la page.

Tim Kaldec et Yoav Weiss se sont donc inspirés de ce mécanisme, pour le transposer au sujet de la performance web, en proposant un nouvel en-tête HTTP (Content Performance Policy) permettant de déclarer précisément le degré de compatibilité d’une page avec certaines bonnes pratiques de performance web. À la charge ensuite du navigateur web, de forcer l’application des bonnes pratiques annoncées qui ne seraient pas respectées par l’éditeur.

C’est en quelque sorte un contrat de qualité de service que le site annonce, et que les navigateurs vont ensuite le contraindre à appliquer.  

Exemple : mon site web annonce au navigateur web (via la directive no-blocking-font) ne pas avoir besoin de télécharger une police de caractères pour commencer à afficher le contenu textuel. Si jamais ce n’est pas vrai, le navigateur web devrait alors changer son comportement par défaut, et commencer à afficher le texte malgré tout.

Je vous propose de découvrir dans cet article les motivations derrière Content Performance Policy (à travers un résumé de l’article de Tim Kaldec), de découvrir quelques éléments de la proposition de spécification (qui reste à un état très préliminaire), ainsi que notre point de vue sur cette approche. En effet, nous disposons avec Dareboost d’un point de vue un peu particulier, puisque nous avons travaillé à produire un outil fiable de diagnostic autour du respect des bonnes pratiques de performance web (notamment).  

Pourquoi Content Performance Policy ?

Nous ne l’avons pas encore évoqué ici, mais  si vous nous suivez sur Twitter (si ce n’est pas le cas, allez-y !), vous ne l’aurez pas manqué : Google a récemment fait bouger les lignes avec son projet AMP.

En bref : offrir un framework, centré sur la recherche de la rapidité, pour la réalisation de sites mobiles. Mais il vont beaucoup plus loin, en mettant en avant les sites utilisant cette technologie dans les résultats de recherche mobile, et ce depuis le 24 février.

Tim Kaldec le dit parfaitement : AMP est une technologie intéressante, l’initiative l’est également. Mais Google favorise UNE technologie, et l’utilisation d’AMP n’est pourtant absolument pas un prérequis pour offrir un site rapide et une expérience utilisateur de qualité.

Tim poursuit son analyse en mettant en avant que Google ce serait en fait simplifié le travail.

Je l’avais évoqué dans cet article sur le Red Slow Label, il est très complexe de déterminer si un site est lent ou rapide, car de nombreux paramètres doivent rentrer en jeu.

D’ailleurs ni le Red Slow Label ni le Slow to Load n’ont pour l’instant donné de suite. En privilégiant ainsi AMP, Google simplifie l’équation : les sites utilisant AMP sont privilégiés, et puis il y a le reste du monde…

Je me permets de citer Tim pour appuyer ce propos :

So when we look at what AMP offers that you cannot offer yourself already, it’s not a high-performing site—we’re fully capable of doing that already. It’s this verification.

Personnellement je n’en reste pas moins impressionné par ce qui a été accompli de ce côté, il y a eu une très forte adhésion, et la performance web a sans doute élargi son public.  

Mais peut-être pour de mauvaises raisons…

Tim Kaldec et Yoav Weiss se sont donc interrogés sur le sujet, pour offrir un mécanisme de vérification similaire, qui permette de privilégier les sites web avec une expérience utilisateur de qualité, mais sans pour autant s’appuyer sur une technologie particulière, et  pour rester dans une philosophie d’un web ouvert et divers.

La Content Performance Policy est alors née ! (même si il semblerait que l’équipe d’AMP avait déjà des préocupations sur le sujet)

Comme cela ne peut être le framework ou la technologie sous-jacente qui impose le respect des bonnes pratiques de performance comme le fait AMP, ce sera le rôle du navigateur web.

En tant que site web, j’annonce ce que je sais bien faire, et je dois m’y contraindre, sans quoi le navigateur web le fera à ma place.

Content Performance Policy, des limites ?

Résumons :

  • Google a “imposé” la performance web à de nombreux éditeurs, dépendants du référencement naturel et donc contraints à mettre en place tous les efforts pour tirer profit de la valorisation des sites AMP par le moteur.
  • Content Performance Policy ne remet pas du tout en cause ce schéma, je pense que tout l’écosystème a conscience que les moteurs de recherche peuvent exercer une pression positive pour valoriser la performance web. Mais CPP remet en cause la valorisation unilatérale d’AMP, et veut au contraire permettre de valoriser l’ensemble des sites offrant une expérience utilisateur de qualité.
  • AMP faisait intervenir Google et les éditeurs, alors que Content Performance Policy rajoute dans l’équation les éditeurs de navigateurs web, qui seront les garants des objectifs des sites web

Évidemment, au sein de l’équipe Dareboost, nous sommes enthousiastes de voir de tels sujets. Nous nous sommes régulièrement interrogés sur les moyens que Google pouvait avoir pour pénaliser les sites trop lents, et nous avons automatisé dans notre outil la détection de problèmes de performance, en allant plus loin que les autres outils.

Nous avons régulièrement réalisé des benchmarks sur des échantillons importants de sites web.

C’est pourquoi nous avons souhaité profité de cet article pour apporter notre point de vue sur cette proposition, car nous partageons entièrement ses constats initiaux, et qu’il nous parait utile d’y participer !

Interdépendance des acteurs

La première difficulté que nous mettrions en avant est probablement la nécessité de faire intervenir à la fois les éditeurs de navigateur web, et la force de frappe d’une incitation de la part des moteurs de recherche pour valoriser l’utilisation de CPP.

Sans l’incitation des moteurs de recherche, CPP restera probablement cantonné à la sphère actuelle de la performance web, sans en faire bouger les lignes comme on a pu l’évoquer avec AMP. Sans implémentation par les navigateurs web, CPP reste l’annonce d’une  intention, jamais vérifiée, et l’on risque de voir des dérives similaires à celles du Mobile Friendly (une simple déclaration dans le code source d’une page HTML – <meta name= »HandheldFriendly » content= »true » /> –  pour que Google considère un site comme mobile friendly, même si rien d’autre n’a été mis en place).

La performance ou rien ?

Pour rappel, voici les directives proposées (en date du 25/02), accompagnées d’une rapide explication :

  • no-blocking-external : La page n’utilise pas de scripts ni de CSS externes bloquants
  • max-internal-blocking-size : La quantité de JS et de CSS bloquants est limitée
  • no-blocking-font : L’affichage du texte n’est pas bloqué par le téléchargement d’une police
  • passive-events-only : Pas de surcharge d’évènements JS comme le scroll
  • no-intrinsic-dimensions-layout : L’affichage de nouveaux éléments sur la page ne “déplace” pas les contenus déjà affichés
  • dom-read-write-batching : les accès répétés aux DOM sont traités par lots
  • image-lazy-load : les images non visibles ( sous la ligne de flottaison), sont chargées à la demande
  • cpu-throttle : des opérations sur-consomatrices pour le processeurs pourront être traitées avec une priorité plus basse
  • resource-limit : la page s’engage à ne pas nécessiter plus qu‘un certain volume de données à télécharger
  • no-auto-play : les vidéos éventuelles ne se lancent pas automatiquement

A la lecture de cette liste, un autre point est à soulever : la compréhension de CPP et de ces différentes directives implique un degré de maîtrise avancé sur des sujets assez variés.

C’est probablement un premier frein à son adoption. Être capable de se positionner sur les différents sujets, d’en comprendre les impacts, et d’accepter les conséquences d’une éventuelle violation d’une déclaration est loin d’être anecdotique.

Cela représente également un effort de maintenance considérable : là où l’on risquait auparavant un ralentissement du site, détectable avec une solution de monitoring comme Dareboost ;) pour une correction rapide, on s’exposerait ici à des problèmes fonctionnels lourds (exemple : je m’engage à ne pas utiliser plus de 800ko de données sur ma page, si une image de 700ko est rajoutée par exemple par le biais d’un CMS – et donc en dehors de mon cycle de recette – les navigateurs vont bloquer les données dépassant le seuil. Mais on ne dispose d’aucun contrôle sur ce qui fera l’objet du blocage, cela pourrait être une CSS ou un JS indispensable).

On retrouve naturellement des freins similaires à ceux présents sur la Content Security Policy.  Ainsi, les projets avec des outils du type A/B Testing ou encore Tag Manager vont voir de véritables risques à l’utilisation de Content Performance Policy.

Il est très intéressant de pouvoir contraindre les contenus provenant de tierces parties, mais j’aurais tendance à dire que cette contrainte doit s’appliquer en amont, lors du choix du prestataire/partenaire. Ici on risque de détériorer le fonctionnement du site car un tel prestataire en serait venu à enfreindre ses engagements lors d’une mise à jour par exemple.     

Un référentiel commun à adopter

Enfin, ce sera ma dernière “critique”,  mais peut être la plus forte étant donnée la problématique initiale : comment positionner en terme d’importance ces éléments les uns par rapport aux autres ? Comment avoir suffisamment de garanties disponibles dans cette liste pour apporter assez de force à la démarche, et en faire un critère de vérification tel qu’attendu par Google ? Même si cela devient le cas, la question des seuils se posera (resource-limit, max-internal-blocking-size), et pour remporter l’adhésion des éditeurs de site, les différents acteurs se basant dessus (navigateurs, adblockers, moteurs de recherche, etc) devraient réussir à parler d’une seule voix.   

Comme rappelé par l’équipe du projet AMP, nous ne devons pas oublier que les choses qui sont lentes aujourd’hui ne le seront peut-être plus demain, ainsi cette base commune devrait en plus être capable d’évoluer facilement.   

 

Je n‘en trouve pas moins l’idée extrêmement intéressante, un grand bravo et merci à ceux qui ont planché sur le sujet !  Et ne surtout pas voir dans les interrogations précédentes une critique de la démarche, mais bien des points de vigilance qui nous viennent après une première lecture.    

Je pense qu’il est nécessaire d’ajouter de la granularité : pouvoir appliquer certaines règles uniquement à certaines ressources (pour maîtriser les impacts d’une violation de la règle selon le degré critique du point de vue fonctionnel : que ce soit mon contenu, une tierce partie indispensable ou nice-to-have, ma politique ne sera certainement pas la même.)

Il me parait également intéressant de distinguer les engagements que le navigateur pourrait faire respecter sans préjudice majeur en cas d’infraction (ex: no-auto-play, no-blocking-font) et ceux sur lesquels je n’imagine aucun fallback en cas d’infraction (ex : max-internal-blocking-size).

Votre avis sur le sujet est évidemment le bienvenu en commentaire, ou et vous pouvez également contribuer directement à la proposition.

 

3 réflexions au sujet de « Content Performance Policy : une étape supplémentaire pour un web plus rapide ? »

  1. L’argument de l’image trop grosse contribuée dans un CMS ne tient pas, le CMS doit permettre de contraindre le volume des données.

    Mais je m’aligne complètement sur toute la réflexion globale !

    1. J’aurais dû préciser : tout à fait d’accord sur le fait que c’est le rôle d’un CMS de pouvoir limiter le poids de l’image. Par contre, là il est question du poids global de la page résultante, en faisant intervenir des contenus de tierces parties, etc. Donc ça ne me parait pas réaliste de demander aux CMS de faire le job.

      1. Il ne faut pas oublier que qui dit CMS dit dynamisme ce qui rend un peu obsolète l’argument du CMS qui devrait pouvoir écrire ces regles à la volee. Sinon je doute fortement de l’efficacité d’une tel directive car ça ne change rien en terme de Dev. Par contre vu que le web est géré par des entreprises now, pourquoi avoir deprecié l’appcache? Car ça resolvais plein de problèmes et il y avait une certaine efficacité et un vrai impact sur la rapidité.

Les commentaires sont fermés.