EcoConception Logicielle

Depuis la machine à écrire, dont les premiers prototypes ont été conçus pour la correspondance avec les non-voyants au début du XIXe siècle, jusqu’au sms, inventé par une équipe de recherche finlandaise pour les malentendants à la fin des années 80, nombre d’innovations actuelles sont nées d’une recherche d’accessibilité avant de gagner le grand public. Téléphone, clavier, sms, mail…comme l’explique Cliff Kuang sur Co.Design, l’histoire des outils de communication nous prouve que le handicap est au cœur des processus d’innovation. Les premiers protocoles mail, par exemple, ont été développés par Vint Cerf pour faciliter ses échanges avec sa femme, sourde.

Et pourtant, paradoxalement, la simple consultation d’une page web est encore une épreuve pour beaucoup de personnes en situation de handicap. 

(..)

Le problème n’est donc ni de l’ordre de la technique, ni des compétences, mais plutôt de la culture. Le handicap est encore regardé comme un sujet secondaire, trop spécifique et mal compris. Les personnes handicapées se heurtent donc à une méconnaissance de leurs usages numériques et à un désintérêt de nombreux professionnels du web. 

Même si du point de vue applicatif, HTTP/2 est rétrocompatible avec HTTP/1.1 (un site qui fonctionnait sur HTTP/1 fonctionnera aussi sur HTTP/2), l’utilisation du HTTPS est un prérequis pour bénéficier du HTTP/2. Si vous lisez ce blog, vous savez déjà que ce n’est pas la seule raison pour laquelle passer au HTTPs est nécessaire.

De l’autre côté du tunnel, les navigateurs web sont également prêts pour HTTP/2

(...)

Bonnes pratiques HTTP/1, grosses erreurs en HTTP/2

Sprites CSS, concaténation de fichiers CSS ou JS

Tout développeur front-end en aura entendu parler : regrouper les fichiers CSS, les fichiers JS, ou les images de faibles dimensions ensemble permet de limiter le nombre de requêtes HTTP et donc d’accélérer le chargement.
Ce qui était bénéfique en HTTP/1 risque au final d’aller à l’encontre d’une bonne expérience utilisateur en HTTP/2 : la connexion TCP est unique et multiplexée, en regroupant les fichiers, vous allez notamment perdre les bénéfices de priorité sur les différents flux !

A noter que les premiers retours d’expérience sur l’utilisation de HTTP/2 semblent montrer qu’il convient d’éviter malgré tout l’utilisation de micro-fichiers. Si c’est votre cas, appliquer partiellement le principe de concaténation peut rester intéressant !

Domaines Cookie-less

Nous avons parlé plus tôt des en-têtes HTTP, qui se retrouvent répétés sur chaque requête en HTTP/1, ce qui peut être très problématique si le site utilise des cookies un tant soit peu volumineux. Une parade était d’utiliser un domaine dédié pour tous les contenus qui n’avaient pas besoin des informations transmises via les cookies. On éliminait ainsi simplement les données superflues.
Avec HTTP/2, d’une part le problème n’existe plus (en-têtes compressés) mais surtout, le hack du domaine cookie-less devient néfaste, puisqu’il implique inutilement l’utilisation d’une nouvelle connexion TCP et d’une résolution DNSsupplémentaire !

Domain Sharding

Autre “hack” HTTP/1, le domain sharding consiste à distribuer les ressources d’une page web sur plusieurs domaines, pour s’affranchir de la limitation de parallélisation des requêtes HTTP des navigateurs web. Cette limite étant associée au domaine, et non au serveur, on peut l’éviter en utilisant plusieurs domaines. Là encore, cela implique des connexions TCP et des résolutions DNS supplémentaires.
Là encore, HTTP/2 a résolu le problème initial, grâce au multiplexage cette fois !

Inlining CSS, JS ou images en base64

Conseillé pour les fragments de CSS, de Javascript ou encore les petites images, l’inlining est une autre technique permettant de réduire le nombre de requêtes HTTP/1.
La nécessité de recourir à cette technique est moins évidente en HTTP/2, puisque l’impact de ces requêtes sera moins marqué grâce au multiplexage. Cette technique conserve les inconvénients déjà présents en HTTP/1, à savoir la perte des bienfaits du cache navigateur pour les ressources concernées, et l’on doit ajouter que cela peut aller à l’opposé des effets recherchés par la prioritisation des flux du multiplexage HTTP/2 !
On notera que l’inlining à des fins d’optimisation du chemin critique, pourra lui être éliminé au profit de l’utilisation du Server Push, même s’il faut garder à l’esprit que ce mécanisme reste relativement expérimental.

Vous l’aurez peut-être anticipé : un site web ayant déployé toutes les bonnes pratiques HTTP/1 pour contourner les limitations propres au protocole, pourrait au final être plus lent avec HTTP/2, puisque cumulant des schémas contre-productifs, que les bienfaits du protocole ne suffiront pas à compenser.