L’évolution de la Progressive Web App à l’Équipe
En 2017, nous étions parmi les premiers à lancer une Progressive Web App pour notre site mobile. 2 ans plus tard, c’est au tour de la version pour ordinateur d’évoluer vers cette tendance, amenée à devenir le standard d’un web challengé par les usages mobiles.
Nom de code « Universal PWA »
Dans le cadre d’un projet de refonte de l’ensemble de nos produits digitaux, nous avons saisi cette opportunité pour remettre sur la table une idée plus ancienne : fusionner nos versions desktop et mobile au sein d’un seul et même site. Avec néanmoins l’exigence de ne pas nuire aux performances de l’un ou l’autre, et donc d’aller au delà du simple site responsive.
Baptisé « Universal PWA » (UPWA), ce projet dans le projet est devenu central dans notre démarche de mutualisation des développements : doté d’une API permettant d’être embarqué et piloté offline, le code source d’UPWA permet de servir le contenu des pages à destination du web mais également des apps — en complément des pages natives — et du back-office.
Si à terme, les gains d’efficacité et de coûts de ce modèle semblaient évidents, il fallait néanmoins réfléchir à une UX qui rende l’intention viable techniquement.
Des ateliers UX au déploiement en production
Plusieurs mois avant que les premières lignes de codes soient écrites, lead devs, UX designers, et chefs de produit se sont réunis en ateliers hebdomadaires autour de la conception des maquettes graphiques. Peu à peu s’est mis en place le design system, avec des guidelines, un langage visuel commun, et une librairie de composants à disposition.
Une team agile a été constituée pour bâtir ces nouvelles fondations. Plusieurs POC ont permis d’affiner les choix techniques et d’estimer l’ampleur du travail. Leur avancée a été rythmée par des démos bimensuelles, permettant à l’ensemble des équipes de rester connecté avec ce nouveau produit, qui s’est progressivement dilué dans l’ensemble des feature teams.
Un mois avant la mise en production, une version bêta a été proposée à nos abonnés avec un double enjeu : faire monter progressivement la charge sur notre infra, et recueillir du feedback de nos utilisateurs pour ajuster certains choix fonctionnels. Grâce à cette phase de recette grandeur nature, la bascule a pu s’opérer le Jour J sans problème majeur.
Des choix techniques innovants
Quelques convictions profondes étaient présentes dès le démarrage du projet, notamment celle de vouloir mettre en place une architecture en micro-services, avec des APIs dynamiques consommées à la fois côté back-end et front-end. La version destinée au front intégrant une sur-couche décorative d’informations concernant l’affichage, spécifiée grâce au standard JSON schema.
Par ailleurs nous devions impérativement changer de framework JavaScript, AngularJS étant sur la fin. Le choix s’est assez vite porté sur VueJS pour sa réputation de performance et la facilité qu’il offrait à migrer le code existant. Nous n’avons pas regretté ce choix, bien au contraire, d’autant que la courbe d’apprentissage de toute l’équipe a été assez bluffante.
Vient la question du rendering des pages. Dans un contexte où 30% des visites de l’Équipe proviennent du SEO, il n’était pas question de passer en Single Page Application sur tout le site sans avoir un recours à fournir aux robots pour crawler des pages HTML. Pour cela, nous avons créé la Snapshot API, un service NodeJS qui se charge de faire le pre-rendering des pages à la demande. Ces demandes sont traitées dans deux types de file d’attente RabbitMQ : l’une, prioritaire, gère les demandes issues du back-office, l’autre celles des utilisateurs finaux visitant des pages non pré-rendues ou dont la durée de vie a expirée.
En revanche, certains choix, comme par exemple celui d’abandonner le sous-domaine dédié au mobile (m.lequipe.fr), n’ont été décidés que dans la dernière ligne droite !
L’exigence de la web performance
Sous l’impulsion de François Boury, le sujet de la webperf est depuis de nombreuses années une préoccupation permanente de nos équipes techniques. La fusion des entités desktop et mobile ne pouvait s’envisager au détriment de nos temps d’affichage sur mobile.
La solution a été le recours au code splitting. En complément du lazy loading, dont le principe est de charger les contenus (images, textes, … etc.) à la volée, le code splitting permet de conditionner le chargement des ressources (fichiers JavaScript, CSS, … etc.) à la présence ou non des composants dans la page. Par exemple : inutile de charger les CSS de la colonne de droite du site lorsque je suis sur mobile, puisqu’elle n’est pas affichée. Cela représente une économie non négligeable de requêtes et de kilo-octets à télécharger.
La mise en place du pre-rendering pour tous nos utilisateurs nous a fait progresser de manière impressionnante sur le temps d’affichage du premier écran. En effet, le premier chargement du site est rendu directement par le serveur, le JavaScript n’intervient que dans un second temps pour hydrater la page et assurer le routing de la suite de la navigation.
Grâce au service worker embarqué dans la progressive web app, un utilisateur qui visite L’Équipe installe dans le cache de son navigateur les ressources lui permettant d’accélérer significativement le chargement de ses prochaines visites. Précision : ce type de gain n’est visible qu’avec des mesures RUM (Real User Monitoring), pas avec des outils classiques de mesure de la webperf (ou synthetic monitoring) qui ne prennent pas en compte le cache côté client.
Un gros travail a été réalisé pour l’adaptation des images à la fois à la taille de l’écran et à la qualité de la connexion. D’autres composants gourmands en bande passante ont reçu le même type d’optimisation avec des comportements adaptés à des connexions internet lentes.
Enfin, pour endiguer le phénomène d’empilement des scripts tiers qui à eux seuls peuvent plomber tous les efforts fait en faveur de la webperf, nous avons mis au point un système de feature switch afin de n’activer les scripts éligibles que ponctuellement et pour une durée limitée.
Les premiers résultats de l’ensemble de ces mesures étaient très encourageants sur Speedcurve :
- Temps de chargement (Speedindex) : -40% sur mobile, -50% sur ordinateur
- Nombre de requêtes externes : = sur mobile, -75% sur desktop
- Vitesse de remplissage de l’écran (First meaningful paint) : -25% sur mobile, -75% sur ordinateur
- Vitesse d’interaction avec le site (Time to interactive) : -15% sur mobile, -70% sur ordinateur
En résumé, UPWA c’est…
- du contenu qui se charge plus vite
les chiffres viennent confirmer une impression unanimement ressentie - une expérience utilisateur homogénéisée
qu’on soit sur app ou site, mobile ou desktop, l’expérience est unifiée - un site mobile first ready
prêt pour répondre aux nouvelles exigences des moteurs - une plus grande efficacité de production
développements mutualisés, déploiements plus rapides - de l’innovation et une montée en compétence des équipes techniques
avec le pouvoir d’attraction des technos récentes sur les développeurs - un site web installable comme une application
grâce aux évolutions des PWA sur Desktop
Si vous avez aimé cet article, n’hésitez pas à suivre le compte lequipe-tech !
