Étude de cas sur certains changements majeurs introduits chez Wix pour améliorer les performances de chargement des sites Web de millions de sites, ce qui leur permet d'obtenir de bons scores PageSpeed Insights et Core Web Vitals.
Grâce à l'exploitation des normes du secteur, des fournisseurs cloud et des fonctionnalités de CDN, combinée à une réécriture majeure de l'environnement d'exécution de notre site Web, le pourcentage de sites Wix atteignant un bon score de 75e percentile pour toutes les métriques Core Web Vitals a plus que triplé d'une année à l'autre, selon les données de CrUX et de HTTPArchive.
Wix a adopté une culture axée sur les performances, et de nouvelles améliorations seront déployées auprès des utilisateurs. Comme nous nous concentrons sur les KPI de performances, nous prévoyons une augmentation du nombre de sites qui atteignent les seuils des métriques Core Web Vitals.
Présentation
Le monde des performances est magnifiquement complexe, avec de nombreuses variables et subtilités. Des études montrent que la vitesse du site a un impact direct sur les taux de conversion et les revenus des entreprises. Ces dernières années, le secteur a mis davantage l'accent sur la visibilité des performances et sur la rapidité du Web. À partir de mai 2021, les signaux d'expérience sur la page seront inclus dans le classement dans les résultats de recherche Google.
Le défi unique de Wix est de prendre en charge des 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 divers outils et articles pour aider nos utilisateurs à analyser et à améliorer les performances de leurs sites.
Wix est un environnement géré, et l'utilisateur n'a pas tout en main. Le partage d'infrastructures communes présente de nombreux défis pour tous ces sites, mais offre également des possibilités d'améliorations majeures à tous les niveaux, c'est-à-dire en tirant parti des économies d'échelle.
Parler dans une langue commune
L'une des principales difficultés liées aux performances consiste à trouver une terminologie commune pour discuter des différents aspects de l'expérience utilisateur, tout en tenant compte des performances techniques et perçues. L'utilisation d'un langage commun et bien défini au sein de l'entreprise nous a permis de discuter et de classer facilement les différentes parties techniques et les compromis, de clarifier nos rapports sur les performances et de nous aider à comprendre quels aspects nous devrions améliorer en priorité.
Nous avons ajusté l'ensemble de notre surveillance et de nos discussions internes pour inclure des métriques standards du secteur, telles que les métriques Web Vitals, qui incluent les éléments suivants:
Scores de complexité et de performances du site
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, la réalité est que les sites deviennent de plus en plus complexes et sophistiqués, fonctionnant davantage comme des applications que des documents, et prenant en charge 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 commerciales. Ces fonctionnalités supplémentaires sont souvent associées à certains coûts de performances.
Le parcours
Au commencement, il y avait le HTML
Chaque fois qu'une page Web est chargée, elle commence toujours par une requête initiale à 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 tant que le début de la réponse n'arrive pas (appelé TTFB, temps de latence du premier octet).
Le passé: l'affichage côté client (CSR)
Lorsque vous exploitez des systèmes à grande échelle, vous devez toujours tenir compte de certains 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 réel était généré via JavaScript côté client (c'est-à-dire dans le navigateur). Cela nous permettait de prendre en charge un grand nombre de sites sans avoir à supporter d'énormes coûts opérationnels côté backend.
La CSR nous a permis d'utiliser un document HTML commun, qui était essentiellement vide. Tout ce qu'il a fait a été de déclencher 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: le rendu côté serveur (SSR)
Il y a quelques années, nous sommes passés au rendu côté serveur (SSR), car il était bénéfique à la fois pour le référencement naturel et les performances, en améliorant les délais de visibilité initiale des pages et en assurant une meilleure indexation pour les moteurs de recherche qui ne sont pas entièrement compatibles avec l'exécution de JavaScript.
Cette approche a amélioré l'expérience de visibilité, en particulier sur les appareils/connexions plus lents, et a ouvert la voie à d'autres optimisations des performances. Toutefois, cela signifiait également que pour chaque requête de page Web, une réponse HTML unique était générée instantanément, ce qui est loin d'être optimal, en particulier pour les sites générant 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 exceptions:
- Il change fréquemment. Chaque fois qu'un utilisateur modifie son site ou ses données, comme l'inventaire de la boutique de son site Web,
- Certaines données et cookies étaient spécifiques à l'utilisateur, ce qui signifie que deux personnes visitant le même site voyaient un code HTML légèrement différent. Par exemple, pour prendre en charge les fonctionnalités des produits telles que la mémorisation des articles ajoutés au panier par un visiteur, ou la discussion qu'il a entamée avec l'entreprise précédemment, et plus encore.
- Toutes les pages ne peuvent pas être mises en cache. Par exemple, une page contenant du code utilisateur personnalisé qui affiche l'heure actuelle dans le document ne peut pas être mise en cache.
Au départ, nous avons adopté une approche relativement sûre consistant à mettre en cache le code HTML sans les données des visiteurs, puis à ne modifier que des parties spécifiques de la réponse HTML à la volée pour chaque visiteur, pour chaque appel du cache.
Solution CDN interne
Pour ce faire, nous avons déployé une solution interne: en utilisant le cache HTTP Varnish pour le proxying et la mise en cache, Kafka pour les messages d'invalidation et un service basé sur Scala/Netty qui met en cache ces réponses HTML, mais qui modifie le code HTML et ajoute des données et des cookies spécifiques au visiteur à la réponse mise en cache.
Cette solution nous a permis de déployer ces composants compacts dans de nombreux autres emplacements géographiques et dans plusieurs régions de fournisseurs de services 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% de nos pages vues éligibles. La diffusion de sites à partir d'emplacements supplémentaires a réduit la latence 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 sur le site est mise en cache et invalidée lorsqu'un article est publié/modifié.
Réduire la complexité
L'implémentation de la mise en cache a considérablement amélioré les performances, en particulier au niveau 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.
Toutefois, la nécessité de modifier le code HTML pour chaque réponse a introduit une complexité inutile qui, si elle était supprimée, offrait une opportunité d'améliorer les performances.
Mise en cache du navigateur (et préparation aux CDN)
~ 13%
Les requêtes HTML sont diffusées directement à partir du cache du navigateur, ce qui permet de réduire considérablement la bande passante et les temps de chargement pour les vues répétées.
L'étape suivante consistait à supprimer complètement ces données spécifiques au visiteur du code HTML et à 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 ces cookies vers un nouveau point de terminaison, qui est appelé à chaque chargement de page, mais qui renvoie un JSON compact, qui n'est requis que pour le processus d'hydratation, afin d'atteindre une interactivité complète de la page.
Cela nous a permis d'activer la mise en cache du code HTML par le navigateur, ce qui 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 un ETag HTTP, 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 (Non modifié) au client, sans corps.
De plus, cette modification signifie que notre code HTML n'est plus spécifique au visiteur et ne contient aucun cookie. En d'autres termes, il peut être mis en cache partout, ce qui permet d'utiliser des fournisseurs de CDN qui ont une présence géographique beaucoup plus importante 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 éléments importants de la connexion initiale sont devenus plus importants. L'amélioration de notre infrastructure réseau et de la surveillance nous a permis d'améliorer nos temps DNS, de connexion et SSL.
HTTP/2 a été activé pour tous les domaines utilisateur, ce qui a réduit à la fois le nombre de connexions requises et les coûts liés à chaque nouvelle connexion. Ce changement a été relativement facile à déployer, tout en profitant 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 du transfert de fichiers
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é implémenté pour la première fois il y a près de 30 ans.
La nouvelle compression Brotli apporte des améliorations de compression avec presque aucun compromis et devient progressivement plus populaire, comme décrit dans le chapitre sur la compression de l'Almanach Web annuel. 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 qui le prennent en charge.
En passant à la compression Brotli, nous avons réduit la taille médiane des transferts de fichiers de 21% à 25%, ce qui a réduit l'utilisation de la bande passante et amélioré les temps de chargement.
Réseaux de diffusion de contenu (CDN)
Sélection dynamique du CDN
Chez Wix, nous avons toujours utilisé des CDN pour diffuser tout le code JavaScript et les images sur les sites Web des utilisateurs.
Récemment, nous avons intégré une solution de 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 donné.
Prochainement : domaines utilisateur diffusés par des CDN
La dernière pièce du puzzle consiste à diffuser la dernière partie, la plus critique, 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 API spécifiques au site. La maintenance de cette solution dans de nombreuses nouvelles régions a également ses coûts opérationnels, et l'ajout de nouveaux emplacements devient un processus que nous devons gérer et optimiser en permanence.
Nous travaillons actuellement à l'intégration de divers fournisseurs de CDN pour diffuser l'intégralité du site Wix directement depuis des emplacements de CDN afin d'améliorer la distribution de nos serveurs dans le monde entier et, par conséquent, d'améliorer les délais de réponse. Cela représente un défi en raison du grand nombre de domaines que nous diffusons, qui nécessitent une terminaison SSL au niveau de la périphérie.
L'intégration de CDN rapproche les sites Web Wix des clients plus que jamais et améliore l'expérience de chargement, y compris avec les technologies plus récentes telles que HTTP/3, sans effort supplémentaire de notre côté.
Quelques mots sur la surveillance des performances
Si vous gérez un site Wix, vous vous demandez probablement comment cela se traduit dans les résultats de performances de votre site Wix et comment nous nous comparons aux autres plates-formes de sites Web.
La plupart des travaux effectués ci-dessus ont été déployés au cours de l'année écoulée, et certains sont encore en cours de déploiement.
L'almanach Web de HTTPArchive a récemment publié l'édition 2020, qui comprend un excellent chapitre sur l'expérience utilisateur du CMS. N'oubliez pas que de nombreux chiffres décrits dans cet article datent de la mi-2020.
Nous avons hâte de voir le rapport mis à jour en 2021 et nous surveillons activement les rapports CrUX pour 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 sur laquelle ils peuvent créer des sites comme ils l'imaginent, sans compromettre les performances.
DebugBear a récemment publié une analyse des performances des outils de création de sites Web très intéressante, qui aborde certains des domaines que j'ai 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 presque deux ans et n'a pas été modifié depuis. Toutefois, la plate-forme s'améliore continuellement, et les performances du site avec elle, comme en témoignent les données de ces derniers ans et demi.
Conclusion
Nous espérons que notre expérience vous inspirera à adopter une culture axée sur les performances dans votre organisation, et que les informations ci-dessus vous seront 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 de vous appuyer sur les métriques Core Web Vitals.
- Exploitez la mise en cache du navigateur et les CDN.
- Passez à HTTP/2 (ou HTTP/3 si possible).
- Utilisez la compression Brotli.
Merci de nous avoir fait découvrir notre histoire. Nous vous invitons à poser des questions et à partager vos idées sur Twitter et GitHub, et à rejoindre la conversation sur les performances Web sur vos canaux préférés.