La cible

Sur le web, c’est à mon avis une mauvaise idée d’établir un lien entre le positionnement de son site, sa cible de communication, et des notions techniques de support en intégration. Bien souvent, ça sert d’excuse pour faire son travail d’intégrateur pauvrement. « Le site ne fonctionne pas sur Windows Phone, mais c’est ok, ce n’est pas notre cible. » Ou « Le site fait 3 Mo mais c’est ok, notre cible a une bonne connexion. »

Je pense que la cible du web est le mieux résumée par Tim Berners Lee (ici lors de la cérémonie d’ouverture des Jeux Olympiques de Londres en 2012).

"This is for Everyone", Tim Berners Lee lors de la cérémonie d'ouverture des Jeux Olympiques de Londres en 2012

Le web c’est pour tout le monde. Cela signifie qu’en tant qu’intégrateur, en tant que concepteur web, vous devez faire en sorte que votre site soit accessible au plus grand nombre. Bien sûr, c’est une vision idéaliste. C’est la cible à atteindre. Mais le contexte d’un projet et ses contraintes, comme par exemple le temps consacré à l’intégration, fait qu’on n’y arrivera pas toujours. Mais parfois, les modifications les plus simples peuvent avoir des conséquences inattendues.

En décembre dernier, Chris Zacharias racontait une anecdote comme je les aime sur son travail d’optimisation sur Youtube.

Il y a trois ans, quand j’étais développeur web chez Youtube, l’un des ingénieurs séniors a commencé à se plaindre du poids trop élevé de la page de lecture d’une vidéo. La page gonflait jusqu’à 1,2 Mo et des douzaines de requêtes. Cet ingénieur s’exclamait ouvertement « Si ils peuvent écrire un clone complet de Quake en moins de 100 Ko, on n’a aucune excuse pour ça ! ». Étant donné que j’étais d’accord avec lui et que j’étais content de trouver un nouveau projet, j’ai décidé de défendre cette cause et de faire passer la page de lecture de vidéo à moins de 100 Ko. Dans la navette pour chez moi ce soir là, j’ai codé un prototype. J’ai décidé de limiter les fonctionnalités à un header basique, le lecteur vidéo, cinq vidéos associées, un bouton de partage, un bouton de favoris, et dix commentaires chargés en AJAX. J’ai appelé ce projet « Feather« .

Même avec aussi peu de fonctionnalités, la page pesait déjà 250 Ko. J’ai creusé dans le code et j’ai réalisé que nos outils d’optimisation (comme Closure compiler) étaient incapables d’exclure du code qui n’était pas utilisé dans la page elle-même (ce qui serait une attente injuste pour un tel outil dans ces circonstances). Le seul moyen de réduire le code encore plus était d’optimiser à la main les CSS, JavaScript et sprites d’images. Après trois jours pénibles, je suis parvenu à une solution bien plus maigre. Mais je n’étais toujours pas sous les 100 Ko. Alors qu’on venait de finir d’écrire le lecteur vidéo en HTML5, j’ai décidé de l’utiliser plutôt que le lecteur bien plus lourd en Flash. Bam ! 98 Ko et seulement 14 requêtes. J’ai parsemé le code de contrôles de surveillance basiques, et j’ai lancé cette version pour une fraction de notre trafic.

Après une semaine de collecte de données, les chiffres nous sont parvenus… Et ils étaient déconcertants. La moyenne totale de la latence de la page sous Feather avait augmenté. J’avais diminué le poids de la page et le nombre de requêtes à un dixième de ce qu’il y avait avant, et d’une manière ou d’une autre, les chiffres montraient que les vidéos mettaient plus longtemps à se charger sous Feather. Ce n’était pas possible. En creusant dans les chiffres un peu plus et après de nombreux tests répétés, ça n’avait aucun sens. J’allais abandonner le projet, ma vision du monde totalement brisée, quand mon collègue a découvert la réponse : la géographie.

Quand nous avons visualisé les données géographiquement et les avons comparé par région, il y avait une augmentation disproportionnée du trafic d’endroits l’Asie du Sud, l’Amérique du Sud, l’Afrique et même des régions isolées de Sibérie. Et quelques enquêtes supplémentaires ont révélé que, dans ces endroits, le temps moyen de chargement d’une page sous Feather était de plus de deux minutes ! Cela signifiait qu’une page classique de vidéo, à plus d’un méga-octet, prenait plus de vingt minutes pour se charger ! C’était la sanction infligée avant même que le flux vidéo n’ait la chance d’afficher la première image. En conséquence, des populations entières ne pouvaient simplement pas utiliser Youtube car c’était trop long pour voir quoi que ce soit. Avec Feather, même s’il fallait plus de deux minutes pour afficher la première image d’une vidéo, regarder une vidéo était devenu une vraie possibilité. En une semaine, l’existence de Feather s’est propagé dans ces zones géographiques et nos chiffres ont été complètement faussés en conséquence. De nombreuses personnes qui ne pouvaient pas utiliser Youtube auparavant en avaient soudainement la possibilité.

Grâce à Feather, j’ai appris une leçon précieuse sur l’état du web à travers le reste du monde. Nombre d’entre nous avons la chance de vivre dans des régions avec un bon débit, mais il y a encore de larges portions du monde pour qui ce n’est pas le cas. En gardant notre code client petit et léger, vous pouvez littéralement ouvrir votre produit à de nouveaux marchés.

Si vous bloquez activement l’accès à votre site sur mobile ou pour des vieilles versions de navigateur, ou si votre page fait plus de 5 Mo, vous risquez effectivement de vous rendre compte que votre audience n’utilise pas de mobile et a une bonne connexion. Mais ça ne signifie pas que c’est le cas de votre cible.