Le blog de ThinkInnovation

La naissance d’un nouveau medium. Acte III

Polices spécifiques, vidéos, animation, exploitation de la troisième dimension... Longtemps l’apanage de Flash, les expériences immersives sont désormais possibles avec les technologies du Web ouvert. Les articles étudiés dans ce dossier s’appuient dessus quoique avec plus de subtilité que la plupart des sites en flash de l’époque. Allons jeter un œil en coulisses.

Un billet publié le 31 mars 2014 par Goulven Champenois.

Mon souci du détail et de l’expérience utilisateur combinés à mon intérêt pour la technique m’ont poussé à devenir intégrateur, ce qu’on appelle aussi désormais un développeur front-end. Je l’avoue, je regarde très souvent le code source des sites que je visite et j’aimerais vous montrer les conséquences pratiques de certains choix sur les trois articles précédemment étudiés par Sébastien et Marie-Cécile (NSA decoded sur le Guardian, The Russia left behind du New York Times, et Les Nouveaux monstres sur l’Équipe), en me concentrant sur les détails plus techniques. [1]

Le temps de chargement

Vous vous souvenez certainement d’une époque (pas si lointaine que ça) où la plupart des sites en Flash commençaient par une animation de chargement. Que voulez-vous, il fallait bien occuper le visiteur pendant que son navigateur chargeait les 5Mo du site à travers une connexion 56k...

La majeure partie des visiteurs surfe désormais en ADSL (voire en fibre optique) avec un navigateur capable d’optimiser le temps de chargement. Cela ne résout pas tous les problèmes pour autant : les visiteurs sont bien moins patients aujourd’hui, et de nombreux facteurs ralentissent le transfert des données (congestion du réseau, pessimisme du protocole TCP, lourdeur du protocole HTTP, ordre de chargement des ressources dans le code source, etc).

Ordre de chargement
Sur le Guardian et le NY Times, le titre, l’illustration et le début du texte s’affichent quasi instantanément, ce qui place le message en exergue. La navigation et les liens de partage se chargent peu après. L’Équipe, en revanche, affiche dans l’ordre :

Le but est peut-être ici de montrer la richesse d’information du dossier, mais en retardant l’affichage du titre de plusieurs secondes le message se trouve parasité et l’utilisateur irrité.

Time to first byte
Cette mesure indique le temps écoulé entre le moment où le navigateur réclame une page et celui où il reçoit les premiers octets. Il est fonction de la distance séparant l’ordinateur du serveur hébergeant le site, et du temps de réponse de ce même serveur. Il est quasiment impossible de descendre à moins de 100 millisecondes : l’information a beau circuler à la vitesse de la lumière dans les fibres optiques, elle doit tout de même parcourir des centaines de kilomètres.

S’il fallait en croire la position géographique, les réponses devraient nous arriver dans l’ordre suivant : d’abord l’Équipe (France), puis le Guardian (Angleterre), et le NYTimes (USA) en dernier. Ce n’est pas le cas en pratique : les premiers octets du Guardian nous arrivent en 150ms, soit deux à trois fois plus vite que les 380ms de l’Équipe ou les 480ms du NYTimes.

Comment fait le Guardian pour réagir aussi vite ? Ce n’est pas de la magie : on peut lire dans les en-têtes HTTP (les métadonnées échangées par les navigateurs et serveurs lorsqu’on demande à afficher une page) que c’est un serveur intermédiaire optimisé pour la vitesse qui s’est chargé de répondre. Ce serveur (Varnish) intercepte les requêtes des visiteurs et soulage le serveur principal en renvoyant les ressources invariantes le plus rapidement possible. Vu les différences de temps de réponse, les investissements techniques et matériels sont payants !

Ces durées en millisecondes peuvent paraître négligeables mais il n’en est rien : l’ordinateur ne peut strictement rien faire tant qu’il n’a rien reçu, ce qui représente près d’une demie-seconde de perdue — alors qu’il y a plusieurs méga-octets à télécharger.
De plus, notre attention est extrêmement volatile : elle commence à s’effilocher après 100ms ; au-delà d’1s, nous perdons peu à peu le fil de notre activité, et au-dessus de 4s retrouver ce que nous étions en train de faire demande un effort. Il faut donc tout mettre en œuvre pour que le visiteur puisse commencer à interagir en moins d’1s.

Délai avant interaction
Il est immédiatement possible de faire défiler les pages du Guardian et du NYTimes, alors que sur l’Équipe, le nom du magazine et le texte "Chargement en cours" restent fixes et l’écran remonte jusqu’au titre quand il a fini de se charger.

Une analyse du code source de ce dernier nous montre la source du problème : les images et vidéos se chargent toutes avant les différentes polices et la barre de navigation/partage du haut de page qui sont pourtant indispensables au premier écran. Modifier l’ordre des éléments dans le code source aurait permis aux navigateurs de charger les ressources dans un ordre plus adapté à la consultation, et permis de se plonger dans le texte quelques précieuses secondes plus tôt. Il aurait peut-être même été possible de se passer de l’écran de chargement !

En l’état, l’Équipe nous place dans le rôle d’un téléspectateur devant un documentaire, là où les autres sites nous donnent la main et nous permettent d’explorer le contenu à notre rythme, sans attendre, comme nous le ferions avec un livre.

Partager

En plus d’être lus, l’un des buts de ces articles est d’être partagé par mail ou sur les réseaux sociaux afin de capter de nouveaux abonnés et des liens entrants (qui contribuent à améliorer le référencement). Vous entendrez les experts du référencement parler de « linkbait » (appât à lien) pour ce type de contenu.

Plusieurs versions, une seule adresse
Il est bien plus facile de partager une page web via Facebook, Twitter ou par email que de mémoriser son adresse et de la taper ou pire, la dicter. Et les emails comme les réseaux sociaux sont massivement consultés depuis smartphones et tablettes : selon une étude du cabinet Return Path, plus de 50% des emails sont désormais ouverts sur mobile ; pour les réseaux sociaux, la part de consultation mobile était déjà majoritaire depuis longtemps (janvier 2013 pour Facebook), et courant 2011 pour Twitter). Plus un contenu sera partagé, plus il sera donc consulté depuis des mobiles ou tablettes.

À ce propos, vous est-il déjà arrivé de charger la version mobile d’un site depuis votre ordinateur de bureau, d’avoir été obligé de choisir entre la version bureau et la version mobile sur tablette, ou d’être redirigé sur un site optimisé pour iPhone alors que vous avez un Blackberry, un Android ou un Windows Phone ? Quand ce n’est pas la douche froide suprême où on est redirigé vers la page d’accueil de la version mobile au lieu de l’article qu’on nous a recommandé. Pas besoin de vous faire un dessin : c’est très pénible.

Pour éviter ces problèmes, il est possible de concevoir un site qui va automatiquement s’adapter à la largeur de l’écran, le fameux "design responsive". Grâce à cette technique, c’est le navigateur qui adaptera le contenu à ses capacités, il n’y aura donc plus besoin de créer et maintenir plusieurs sites spécifiques. L’autre avantage, c’est que les gens ne risquent pas de partager une adresse spécifique aux mobiles ou au tablettes, et que tous les visiteurs accéderont à la version adaptée à leur périphérique de consultation sans souffrir le délai inutile d’une redirection vers une autre page, délai qui peut facilement retarder le Time to first byte d’un quart de seconde.

Le design responsive, en pratique

L’un des grands défis du design responsive consiste à adapter la présentation et la navigation aux dimensions des appareils et au type de défilement (souris vs tactile).

Un autre de ces défis consiste à fournir une expérience de qualité en prenant en compte les limites techniques des appareils mobiles : mémoire vive moins généreuse, processeurs moins puissants, et connectivité souvent limitée. Il faut n’envoyer que le strict nécessaire (les images et les scripts sont souvent spécifiques), prioriser l’ordre de téléchargement, et tester pour s’assurer du bon rendu.

À noter : on redimensionne rarement la fenêtre du navigateur en cours de lecture, mais sur la page de L’Équipe il suffit de réduire ou d’agrandir la fenêtre pour être renvoyé tout en haut de la page, retrouver l’écran de chargement et l’animation initiale, et devoir retrouver le fil de notre lecture en partant de la toute première ligne. C’est probablement un effet de bord indésirable qui ne manquera pas d’ennuyer les visiteurs ayant le malheur de provoquer ce comportement involontairement. Ce qui est dommage, c’est qu’en plus d’être visuellement décalée d’un élément, la barre de navigation de ce dernier ne met pas la barre d’adresse à jour, tout partage enverra donc au début du document. Sans doute un des bugs classiques "off-by-one".

Lecture morcelée

Vu leur longueur, nombreux seront les visiteurs à lire ces dossiers en plusieurs fois. La plupart des ressources d’une page (images, feuilles de style, scripts divers) ne changent pas d’une minute à l’autre, les navigateurs conservent donc la dernière version de ces ressources pour ne pas avoir à les télécharger de nouveau quand on visite la même page ou le même site dans les minutes ou les jours qui suivent. On dit qu’ils mettent les ressources "en cache".

Il existe un autre type de cache, situé cette fois entre les serveurs et l’ordinateur des visiteurs : les serveurs proxy. Souvent déployés par les grandes entreprises souhaitant éviter que la bande passante de leur connexion soit encombrée par les mêmes fichiers téléchargés par différentes personnes plusieurs fois par jour, on en trouve également aux nœuds d’interconnexion des fournisseurs d’accès afin de mutualiser et d’économiser la bande passante à l’échelon du dessus.

Pour que les ressources mises en cache soient toujours d’actualité, les serveurs de contenu original ajoutent pour chaque ressource des métadonnées indiquant si elles peuvent être mises en cache, par qui, et pour combien de temps. Étudions les métadonnées.

Pour le Guardian, les ressources autorisent proxy et navigateurs à les garder en cache pendant 28 jours. C’est interdit en revanche pour la page HTML, ce qui permet au compteur de visite d’être systématiquement appelé à chaque consultation. De plus, le chemin vers la plupart des ressources inclut un numéro de version, il suffit donc de changer le nom de fichier ou le numéro de version pour obliger les proxy et navigateurs à charger la dernière version de la ressource, ce qui peut se déclarer dans le HTML. Quand on redemande la page, le deuxième téléchargement ne pèse que 300ko, une infime fraction des presque 16Mo téléchargés la première fois !

Pour le New York Times, les ressources sont mises en cache pendant un jour (en indiquant une date de péremption éloignée de 24h), mais cette fois aucune restriction pour la page HTML, les navigateurs et serveurs proxy pourront donc fournir leur version durant 24h. La page est moins longue et ne précharge pas les vidéos mais on passe quand même ici de 2Mo à 62ko.

Il n’y a que deux choses vraiment compliquées en informatique : invalider les caches, et trouver des noms.


(Philip Karlton, cité dans la documentation de Varnish)

Le dossier de l’Équipe confirme bien ce diction car, si la page HTML est mise en cache pendant 10 minutes (avec Cache-Control : max-age=600 et Expires configuré de la même manière), les ressources en revanche ont trois métadonnées contrôlant la mise en cache. La première indique la date de dernière modification du fichier (novembre 2013 pour la plupart), la deuxième indique que les navigateurs et proxys doivent considérer leur version comme obsolète au bout d’une semaine (via l’en-tête Cache-Control). La troisième ? Elle indique que les ressources expirent le 7 décembre 2013.

Heureusement, la plupart des proxys et navigateurs ignoreront cette information contradictoire et garderont donc les ressources pendant 10 minutes au lieur de les redemander systématiquement après le 7 décembre 2013.

En pratique, le serveur Apache a probablement été configuré ainsi :
ExpiresByType image/jpg "modification plus 24 days"
au lieu de
ExpiresByType image/jpg "access plus 24 days"
Notez le changement entre "modification" et "access".

On pourrait ne voir là qu’un détail, mais la page Les nouveaux monstres pèse au total la bagatelle de 50 Mo une fois chargées toutes les images, scripts, polices et surtout vidéos. La mise en cache est un mécanisme permettant de soulager massivement le serveur et la bande passante ; non négligeable en temps normal, il se montre particulièrement utile pour un contenu à forte viralité tel que celui-ci.

En effet, il suffit parfois d’être mentionné par un influenceur ou par une publication à grande audience pour que le nombre de visites explose temporairement comme l’ont constaté les équipes d’ALittleMarket : moins de 30 minutes après leur passage dans l’émission Capital sur M6, ils passent de 2000 visites/minutes à plus de 36000 ! Vous imaginez si 36000 personnes essaient de charger une page de 50Mo dans la même minute ? Le serveur devrait renvoyer près de 2 téraoctets par minute pour arriver à servir tout le monde correctement. C’est possible, mais les hébergeurs qui proposent cela sont loin d’être gratuits, vous pouvez me croire...

Même sans en arriver là, optimiser les performances d’un site est bon pour les serveurs, pour l’environnement (chez Shopzilla, une phase d’optimisation a permis d’éteindre un serveur sur deux), pour le référencement, et bien sûr pour les visiteurs !

Ce billet est classé dans .


[1NB : Des bugs dans Chrome entre les versions 26 et 34 empêchent l’affichage des polices spécifiques.

Partager sur Twitter

Un message, un commentaire ?

Qui êtes-vous ?
Votre message
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Vous êtes sur le blog de ThinkInnovation

Nous créons des solutions qui satisfont nos clients et partenaires.

Nous avons une vraie philosophie : « Care, Connect, Crystallize ».

Retrouvez nous sur Twitter !