Clever Age sponsor de la nouvelle édition de We Love Speed – 2019

  • #Communication/marketing/performances commerciales
  • #Conformité (Accessibilité, RGPD…)
  • #Web & UX Design

Publié le Mis à jour le Par ,

La conférence We Love Speed s’est tenue cette année à Lille, après Bordeaux l’an dernier pour la première édition.

Clever Age était de nouveau sponsor de l’événement et 4 collaborateurs étaient présents pour assister aux nombreuses conférences. Celles-ci étaient réparties sur deux salles, pour des thèmes d’une part techniques et d’autre part plus axés sur les retours d’expérience.

Nous avons appris beaucoup des conférences, toutes de grande qualité, et principalement de retours d’expérience réelle. Celles de Wikimedia étaient particulièrement intéressantes.

Les sponsors ont tous fait de petites présentations entre les conférences. Ce fût aussi notre cas. La plupart ont parlé de ce que font leur entreprise et leur lien avec la performance en rappelant qu’ils proposent un produit ou un service qui va dans ce sens, et mentionnent qu’ils recrutent. Cela a bien sûr été notre cas, l’événement coïncidant de plus à quelques jours près avec le lancement de notre agence lilloise. Google en a par contre profité pour évoquer les intéressantes nouveautés liées à la performance web dans leurs outils (lighthouse, CrUX) et leur navigateur Chrome.

Nous allons vous présenter une synthèse des conférences qui nous semblent avoir été les plus marquantes :

Navigateur : les coulisses du chargement

par Estelle Weyl

Slide d’Estelle Weyl

Connaissez-vous toutes les étapes nécessaires au navigateur pour charger une ressource ? C’est à cette question qu’Estelle Weyl essaie de répondre.

D’abord dans les coulisses de HTTP(S), de la résolution IP (DNS) à l’échange des clefs TLS, puis dans la stratégie de téléchargement, avec la règle des « 14 premiers kb » le « TCP slow start » et le « Congestion control ».

Pendant ce temps, au fur et à mesure du chargement, le navigateur construit le DOM.

Estelle rappelle qu’il n’y a pas de rendu ni d’exécution JavaScript pendant le téléchargement du CSS et que le navigateur possède un scanner de pré-chargement qui cherche dans la page les ressources à précharger.

Elle nous explique aussi l’importance de defer et async ainsi que l’importance de fermer les éléments HTML.

Après le DOM, il y a le CSSOM (CSS Object Model), son alter ego responsable du style puis de l’interprétation du JavaScript.
Le reste est une histoire de rendu, une grande suite de style, layout, paint puis composite découlant du DOM et CSSOM.

Petits bonus orientés Firefox :

  • Les developers tools proposent depuis peu un onglet pour parcourir l’Accessibility Object Model.
  • Définir height et width d’une image dans le HTML permet au navigateur d’anticiper le ratio pour réserver l’espace nécessaire avant le téléchargement de l’image.

Comment PagesJaunes s’est hissé dans le top 10 du classement webperf

par Loïc Troquet

Slides de Loïc Troquet

Le socle technique de PagesJaunes est basé sur PHP/Symfony/Twig, Pertim, Varnish, Redis et Mongo, et le projet fonctionne en Continuous Delivery avec plusieurs déploiements par jour.

PagesJaunes s’est donné un an de projet pour améliorer la performance, avec pour objectifs d’améliorer l’expérience utilisateur, de réduire les coûts d’infrastructure (dans le cloud), améliorer le référencement (notamment le temps de crawl), etc.

Les indicateurs clefs de performance suivis par PagesJaunes sont le Time To First Byte, le Time To Interaction, et le Speed Index. Un focus supplémentaire est mis sur le classement de performance du Journal du Net, fait par Fasterize, qui montre une moyenne entre Time To Interaction et Speed Index sur 3 pages représentatives.

Les outils utilisés pour suivre la performance sont nombreux : Dynatrace pour le backend, GoReplay pour reproduire sur l’infrastructure de test 5% du trafic de production, Dareboost en production et staging, sitespeed.io, une instance privée de WebPagetest, Grafana pour le reporting du Real User Monitoring (RUM) avec du JavaScript maison qui alimente les logs pour 10% des visiteurs et visualisation dans Kibana.

Nous vous invitons à regarder la vidéo pour découvrir tous les travaux réalisés. En voici certains notables :

  • Passage à HTTP/2 pour bénéficier du multiplexing des requêtes
  • Optimisation des images responsives : meilleurs choix de formats, utilisation de srcset, optimisation des SVG (retrouvez nos conférences sur le sujet : Quelques solutions facilitant la bonne mise en œuvre des images responsives et La petite clinique des images responsives), ce qui n’a malheureusement pas évité la publication d’une image de 2 Mo en page d’accueil par l’équipe marketing à Noël
  • Suppression temporaire de la solution d’A/B testing (avec 3% de gain de transformation)
  • Activation de la compression Brotli, donnant un gain de poids de 15% en moyenne sur les ressources textuelles HTML, CSS et JavaScript
  • Pré-chargement (prefetch) des deux premiers résultats de recherche pour accélérer leur affichage éventuel

Certains de ces travaux ont nécessité des ajustements d’architecture et/ou provoqué des soucis non anticipés :

  • La nécessité de ramener tous les assets sur le domaine principal www pour bénéficier vraiment de HTTP/2 a conduit à un surnombre soudain de requêtes sur ce domaine, qui a déclenché un blocage par les outils anti scraping (qui représente un risque important chez PagesJaunes)
  • Un changement de page de recherche de référence a conduit Fasterize à tester une page contenant plus de résultats, pénalisant ainsi le classement du Journal du Net, alors que le site devenait globalement plus performant. La page a ultérieurement été réduite de 9300 à 2000 résultats avec l’accord des équipes métiers.

Ce retour d’expérience montre bien, comme celui de Rue du Commerce l’an dernier, qu’améliorer la performance est une tâche de fond, qui nécessite beaucoup d’actions complémentaires, et beaucoup de vigilance.

La suite de notre compte rendu de l’événement We Love Speed prochainement.