HTTP2 for front-end web developers

To get websites to load in an acceptable time using HTTP1 we have developed a series of techniques; hacks really; to eke performance out of this old protocol. They are:

  • Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
  • Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
  • Serving assets from a cookie-less domain.
  • Sharding: creating different domains or sub-domains to host assets like images.

Avec l’arrivée de HTTP 2, ces quatre optimisations tendent à devenir inutiles, voire contre productives.

Pour les deux premières, le pipelining devient plus intelligent (donc réellement utilisable) et au besoin le serveur peut pousser les contenus sans même attendre qu’ils soient demandés par le client.

Pour les deux suivantes, le système de compression des entêtes et de multiplexage rend le retour sur investissement d’une nouvelle connexion TCP à un domaine tiers franchement contestable. Vous risquez de perdre de la performance au lieu d’en gagner.

La leçon est intéressante. Pendant quelques années les développeurs ont cherché à contourner les navigateurs, croyant pouvoir être plus smart. Le problème c’est que les navigateurs et les protocoles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des développeurs peuvent désormais faire plus de mal que de bien. C’est toute une littérature qu’il va falloir mettre à jour.

Informations personnelles pour les sites e-commerce

J’aimerai tant un site e-commerce qui ne me demanderait pas de créer un compte pour faire un achat. Qu’il me soit obligatoire de décliner nom et adresse pour par exemple acheter un livre en ligne… est plus que gênant

Je regarde la super lampe déco, je clique sur « acheter », je saisis une éventuellement adresse de livraison, puis mon numéro de carte bancaire, je valide, et voilà !

Je n’ai pas besoin de plus pour acheter mon pain à la boulangerie, un lit ou une armoire dans mon magasin de meuble, ou un livre à ma librairie. Tout ce qui vient en plus avant la finalisation de la commande me fera fuir.

Parce qu’il y a parfois un besoin d’une relation après vente, je peux comprendre qu’on me demande aussi un numéro de téléphone ou un email, même si ce n’est pas strictement nécessaire. On pourra m’y envoyer un jeton d’accès pour me relier à mes commandes ou m’authentifier si besoin.

Je ne vois aucune raison incontournable d’imposer la saisie de plus d’informations [en fait si, voir commentaires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décliner mon identité.

Rien n’empêche de proposer la saisie de bien plus d’informations, mais après la commande, et de façon totalement optionnelle.

Tomber en marche

Celle ci je ne peux me retenir de la copier car elle est magnifique :

$override = null;
if ($notify_admin and $conf['browser_language'])
{
  if (!get_browser_language($override['language']))
  {
    $override=null;
  }
}

À première vue, le code ne fait rien. À la seconde lecture non plus, je vous rassure.

Après explication, la méthode get_browser_language utilise un passage par référence (oui, avec ce nom là…), c’est à dire que la variable qui est passée en argument pourra voir sa valeur modifiée.

Eureka! En sortie de code on pourrait bien avoir une variable $override qui contient quelque chose. On a au passage fait une création de tableau implicite en utilisant la syntaxe avec crochets sur une valeur nulle (conseil : ne jamais faire ça si vous souhaitez rester lisible).

La seconde affectation $override=null sert si jamais get_browser_language a bien modifié $override['language'] mais a renvoyé une valeur évaluée à false.

Mais pourquoi cette seconde affectation à null ? Et bien il se trouve que la fonction get_browser_language renvoie false si elle ne modifie pas la variable passée par référence. Dans ce cas le code d’appel aurait quand même créé un tableau dans $override à cause de override['language'], il faut donc revenir en arrière et écraser ce tableau créé implicitement.

À retenir :

  1. Ne jamais créer de tableau implictement avec l’opérateur crochet sur une valeur null.
  2. Ne jamais attendre un retour par référence sur une fonction qui s’appelle « get_* »
  3. Globalement, ne quasiment jamais utiliser le passage par référence pour récupérer une simple valeur.

Ici en plus vu qu’on utilise déjà l’évaluation à true ou false du retour de get_browser_language, autant lui faire retourner directement la langue, ou null si aucune n’est trouvée.