Une étude de cas sur certains changements majeurs introduits sur Wix pour améliorer les performances de chargement des sites Web pour des millions de sites, en leur permettant d'obtenir de bons scores PageSpeed Insights et Core Web Vitals.
Grâce aux normes du secteur, aux fournisseurs cloud et aux fonctionnalités CDN, ainsi qu'à une réécriture majeure de l'environnement d'exécution de notre site Web, le pourcentage de sites Wix atteignant un bon score au 75e centile pour toutes les métriques Core Web Vitals a plus que triplé d'une année sur l'autre, selon les données de CrUX et de HTTPArchive.
Wix a adopté une culture axée sur les performances, et d'autres améliorations continueront d'être déployées auprès des utilisateurs. Alors que nous nous concentrons sur les KPI de performances, nous nous attendons à voir augmenter le nombre de sites qui atteignent les seuils des métriques Core Web Vitals.
Présentation
Le monde des performances est beaucoup complexe, avec de nombreuses variables et subtilités. Des études montrent que la vitesse d'un site a un impact direct sur les taux de conversion et les revenus des entreprises. Ces dernières années, le secteur a accordé une plus grande importance à la visibilité sur les performances et à l'accélération du Web. À partir de mai 2021, les signaux d'expérience sur la page seront inclus dans le classement de la recherche Google.
Chez Wix, le défi unique concerne la prise en charge de millions de sites, dont certains ont été créés il y a de nombreuses années et n'ont pas été mis à jour depuis. Nous proposons plusieurs outils et articles pour aider nos utilisateurs à comprendre comment analyser et améliorer les performances de leurs sites.
Wix est un environnement géré et tout n'est pas entre les mains de l'utilisateur. Le partage d'infrastructures communes présente de nombreux défis pour tous ces sites, mais il ouvre également la voie à des améliorations majeures à tous les niveaux, c'est-à-dire des économies d'échelle possibles.
Parler dans une langue commune
L'une des principales difficultés liées aux performances est de trouver une terminologie commune pour discuter de différents aspects de l'expérience utilisateur, tout en tenant compte à la fois des performances techniques et perçues. L'utilisation d'un langage commun et bien défini au sein de l'organisation nous a permis de discuter et de catégoriser facilement les différents aspects techniques et les compromis, de clarifier nos rapports sur les performances et d'identifier les aspects sur lesquels nous devons nous concentrer en premier.
Nous avons ajusté toutes nos discussions internes et de surveillance pour inclure des métriques standards dans l'industrie telles que les Signaux Web, qui incluent:
Complexité du site et scores de performances
Il est assez facile de créer un site qui se charge instantanément, à condition de le rendre très simple en utilisant uniquement du code HTML et de le diffuser via un CDN.
Toutefois, en réalité, les sites deviennent de plus en plus complexes et sophistiqués, fonctionnent davantage comme des applications que comme des documents et sont compatibles avec des fonctionnalités telles que les blogs, les solutions d'e-commerce, le code personnalisé, etc.
Wix propose une très grande variété de modèles, ce qui permet à ses utilisateurs de créer facilement un site avec de nombreuses fonctionnalités professionnelles. Ces fonctionnalités supplémentaires entraînent souvent quelques coûts de performances.
Le parcours
Au début, il y avait le langage HTML
Chaque fois qu'une page Web est chargée, elle commence toujours par une requête initiale adressée à une URL afin de récupérer le document HTML. Cette réponse HTML déclenche toutes les requêtes client supplémentaires et la logique du navigateur pour exécuter et afficher votre site. Il s'agit de la partie la plus importante du chargement de la page, car rien ne se passe avant l'arrivée du début de la réponse (appelé TTFB - time to first byte).
Historique: rendu côté client (CSR)
Lorsque vous exploitez des systèmes à grande échelle, vous devez toujours faire des compromis, tels que les performances, la fiabilité et les coûts. Il y a quelques années, Wix utilisait le rendu côté client (CSR), dans lequel le contenu HTML était généré via JavaScript côté client (c'est-à-dire dans le navigateur), ce qui nous permet de gérer un grand nombre de sites sans entraîner d'énormes coûts opérationnels de backend.
La fonction CSR nous a permis d'utiliser un document HTML commun, qui était essentiellement vide. Elle a uniquement déclenché le téléchargement du code et des données requis, qui ont ensuite été utilisés pour générer le code HTML complet sur l'appareil client.
Aujourd'hui: rendu côté serveur
Il y a quelques années, nous sommes passés au rendu côté serveur, car il s'est avéré bénéfique à la fois pour le SEO et les performances. Cela a permis d'améliorer les temps de visibilité initiale des pages et d'améliorer l'indexation pour les moteurs de recherche qui ne sont pas totalement compatibles avec l'exécution de JavaScript.
Cette approche a amélioré la visibilité, en particulier sur les appareils/connexions plus lentes, et a ouvert la voie à de nouvelles optimisations des performances. Toutefois, cela signifiait également que pour chaque demande de page Web, une réponse HTML unique était générée à la volée, ce qui est loin d'être optimal, en particulier pour les sites enregistrant un grand nombre de vues.
Présentation de la mise en cache dans plusieurs emplacements
Le code HTML de chaque site était principalement statique, mais comportait quelques mises en garde:
- Elle change fréquemment. Chaque fois qu'un utilisateur modifie son site ou modifie ses données, comme l'inventaire du site Web dans le magasin.
- Il comportait certaines données et cookies propres à chaque visiteur. Autrement dit, deux personnes visitant le même site ne voyaient pas le même code HTML. Par exemple, pour proposer des fonctionnalités produit comme la mémorisation des articles qu'un visiteur a placés dans son panier, ou le chat qu'il a commencé avec l'établissement précédemment, et plus encore.
- Toutes les pages ne peuvent pas être mises en cache. Par exemple, une page qui contient du code utilisateur personnalisé et qui affiche l'heure actuelle dans le document ne peut pas être mise en cache.
Au départ, nous avons adopté l'approche relativement sûre consistant à mettre en cache le code HTML sans données de visiteur, puis nous n'avons modifié que certaines parties de la réponse HTML à la volée pour chaque visiteur, pour chaque succès de cache.
Solution CDN interne
Pour ce faire, nous avons déployé une solution interne: l'utilisation du Cache HTTP Varnish pour la transmission par proxy et la mise en cache, de Kafka pour les messages d'invalidation et d'un service basé sur Scala/Netty qui traite ces réponses HTML, mais modifie le code HTML, et ajoute des données et des cookies spécifiques aux visiteurs à la réponse mise en cache.
Cette solution nous a permis de déployer ces composants finis dans de nombreux emplacements géographiques et dans plusieurs régions de fournisseurs cloud, répartis dans le monde entier. En 2019, nous avons lancé plus de 15 nouvelles régions et activé progressivement la mise en cache pour plus de 90% des pages vues éligibles à la mise en cache. La diffusion de sites à partir d'emplacements supplémentaires a réduit la latence du réseau entre les clients et les serveurs diffusant la réponse HTML, en rapprochant le contenu des visiteurs du site Web.
Nous avons également commencé à mettre en cache certaines réponses d'API en lecture seule en utilisant la même solution et en invalidant le cache en cas de modification du contenu du site. Par exemple, la liste des articles de blog du site est mise en cache et invalidée lorsqu'un article est publié ou modifié.
Réduction des complexités
La mise en œuvre de la mise en cache a considérablement amélioré les performances, principalement lors des phases TTFB et FCP, et a amélioré notre fiabilité en diffusant le contenu à partir d'un emplacement plus proche de l'utilisateur final.
Cependant, la nécessité de modifier le code HTML pour chaque réponse introduisait une complexité inutile qui, une fois supprimée, permettait d'améliorer les performances.
Mise en cache du navigateur (et préparations pour les CDN)
~ 13%
Requêtes HTML diffusées directement à partir du cache du navigateur, ce qui permet d'économiser beaucoup de bande passante et de réduire le temps de chargement des vues répétées
L'étape suivante consistait à supprimer entièrement ces données spécifiques aux visiteurs du code HTML, puis à les récupérer à partir d'un point de terminaison distinct, appelé par le client à cette fin, une fois le code HTML arrivé.
Nous avons soigneusement migré ces données et cookies vers un nouveau point de terminaison, appelé à chaque chargement de page, mais qui renvoie un fichier JSON mince, requis uniquement pour le processus d'hydratation, afin d'atteindre l'interactivité complète de la page.
Cela nous a permis d'activer la mise en cache du code HTML dans le navigateur. Cela signifie que les navigateurs enregistrent désormais la réponse HTML pour les visites répétées et n'appellent le serveur que pour vérifier que le contenu n'a pas changé. Pour ce faire, utilisez le HTTP ETag, qui est essentiellement un identifiant attribué à une version spécifique d'une ressource HTML. Si le contenu est toujours le même, nos serveurs envoient une réponse 304 Not Modified au client, sans corps.
En outre, ce changement signifie que notre code HTML n'est plus spécifique aux visiteurs et ne contient plus de cookies. En d'autres termes, elles peuvent être mises en cache n'importe où, ce qui ouvre la voie à l'utilisation de fournisseurs CDN qui bénéficient d'une bien meilleure présence géographique dans des centaines d'emplacements à travers le monde.
DNS, SSL et HTTP/2
Avec la mise en cache activée, les temps d'attente ont été réduits et d'autres parties importantes de la connexion initiale sont devenues plus importantes. L'amélioration de notre infrastructure réseau et de notre surveillance nous a permis de réduire nos délais de connexion, de DNS et de SSL.
HTTP/2 a été activé pour tous les domaines d'utilisateur, ce qui permet de réduire à la fois le nombre de connexions requis et la surcharge liée à chaque nouvelle connexion. Il s'agit d'un changement relativement facile à déployer, tout en tirant parti des avantages en termes de performances et de résilience offerts par HTTP/2.
Compression Brotli (par rapport à gzip)
21 à 25 %
Réduction de la taille médiane des fichiers transférés
Traditionnellement, tous nos fichiers étaient compressés à l'aide de la compression gzip, qui est l'option de compression HTML la plus répandue sur le Web. Ce protocole de compression a été mis en œuvre il y a près de 30 ans !
La nouvelle compression Brotli améliore la compression sans pratiquement aucun compromis et devient progressivement plus populaire, comme décrit dans le chapitre Compression annuel de Web Almanac. Elle est compatible avec tous les principaux navigateurs depuis un certain temps.
Nous avons activé la prise en charge de Brotli sur nos proxys nginx en périphérie, pour tous les clients compatibles.
L'utilisation de la compression Brotli nous a permis de réduire la taille médiane des transferts de fichiers de 21 à 25 %, ce qui nous a permis de réduire l'utilisation de la bande passante et d'améliorer les temps de chargement.
Réseaux de diffusion de contenu (CDN)
Sélection CDN dynamique
Chez Wix, nous avons toujours utilisé des CDN pour diffuser l'ensemble des images et du code JavaScript sur les sites Web des utilisateurs.
Récemment, nous avons intégré une solution proposée par notre fournisseur DNS pour sélectionner automatiquement le CDN le plus performant en fonction du réseau et de l'origine du client. Cela nous permet de diffuser les fichiers statiques à partir du meilleur emplacement pour chaque visiteur et d'éviter les problèmes de disponibilité sur un CDN spécifique.
Prochainement... Domaines utilisateur desservis par des CDN.
La dernière partie du puzzle consiste à diffuser la dernière partie, et la plus importante, via un CDN: le code HTML du domaine de l'utilisateur.
Comme décrit ci-dessus, nous avons créé notre propre solution interne pour mettre en cache et diffuser les résultats HTML et d'API spécifiques au site. La maintenance de cette solution dans un si grand nombre de nouvelles régions entraîne également des coûts opérationnels. C'est pourquoi l'ajout de nouveaux emplacements devient un processus que nous devons gérer et optimiser en permanence.
Nous intégrons actuellement différents fournisseurs CDN pour permettre la diffusion de l'intégralité du site Wix directement à partir d'emplacements CDN. Cela permet d'améliorer la distribution de nos serveurs à travers le monde et d'améliorer ainsi les temps de réponse. Il s'agit d'un défi en raison du grand nombre de domaines que nous traitons, qui nécessitent une terminaison SSL en périphérie.
L'intégration des CDN permet aux sites Web Wix de se rapprocher plus que jamais des clients et d'améliorer davantage l'expérience de chargement, y compris des technologies plus récentes telles que HTTP/3, sans effort supplémentaire de notre part.
Quelques mots sur la surveillance des performances
Si vous gérez un site Wix, vous vous demandez probablement comment cela se traduit par les performances de votre site Wix et comment nous les comparons à celles d'autres plates-formes de sites Web.
La majeure partie du travail effectué ci-dessus a été déployé au cours de l'année écoulée, et certains sont toujours en cours de déploiement.
The Web Almanac de HTTPArchive a récemment publié l'édition 2020 qui comprend un excellent chapitre sur l'expérience utilisateur du CMS. Gardez à l'esprit que bon nombre des chiffres décrits dans cet article datent du milieu de l'année 2020.
Nous avons hâte de voir le rapport mis à jour en 2021, et nous surveillons activement les rapports CrUX de nos sites, ainsi que nos métriques de performances internes.
Nous nous engageons à améliorer continuellement les temps de chargement et à fournir à nos utilisateurs une plate-forme leur permettant de créer des sites comme ils l'imaginent, sans compromettre les performances.
DebugBear a récemment publié une évaluation des performances de l'outil de création de sites Web très intéressante, qui aborde certains des points mentionnés ci-dessus et examine les performances de sites très simples créés sur chaque plate-forme. Ce site a été créé il y a près de deux ans et n'a pas été modifié depuis. Toutefois, la plate-forme s'améliore constamment, et ses performances sont également meilleures. Vous pouvez en vérifier l'expérience en consultant ses données au cours des 18 derniers mois.
Conclusion
Nous espérons que notre expérience vous incitera à adopter une culture axée sur les performances dans votre organisation, et que les informations ci-dessus sont utiles et applicables à votre plate-forme ou à votre site.
Pour résumer :
- Choisissez un ensemble de métriques que vous pouvez suivre de manière cohérente à l'aide d'outils approuvés par le secteur. Nous vous recommandons les métriques Core Web Vitals.
- Exploitez la mise en cache du navigateur et les CDN.
- Migrez vers HTTP/2 (ou HTTP/3, si possible).
- Utilisez la compression Brotli.
Merci d'avoir découvert notre histoire. Nous vous invitons à poser des questions, à partager vos idées sur Twitter et GitHub, et à participer à la discussion sur les performances Web sur vos chaînes préférées.