Améliorer les performances des sites Web Wix (étude de cas) —

Les performances d'un site Web peuvent faire ou défaire son succès, mais en août 2020, malgré de nombreuses améliorations que nous avions apportées précédemment, telles que la mise en œuvre du Server-Side Rendering (SSR), le ratio de sites Web Wix avec un bon Google Core Web Les scores Vitals (CWV) n'étaient que de 4%. C'est à ce moment-là que nous avons réalisé que nous devions apporter un changement significatif dans notre approche de la performance et que nous devions intégrer la performance dans notre culture.

La mise en œuvre de ce changement nous a permis de franchir des étapes importantes comme la mise à jour de notre infrastructure et la réécriture complète de nos fonctionnalités de base à partir de zéro. Nous avons déployé ces améliorations progressivement au fil du temps pour garantir que nos utilisateurs ne subissent aucune interruption, mais uniquement une amélioration constante de la vitesse de leur site.

Depuis la mise en œuvre de ces changements, nous avons constaté une amélioration spectaculaire des performances des sites Web créés. et hébergé sur notre plateforme. En particulier, le ratio mondial de sites Web Wix qui reçoivent un bon score CWV (vert) est passé de 4 % à plus de 33 %, ce qui signifie une augmentation de plus de 750 %. Nous prévoyons également que cette tendance à la hausse se poursuivra à mesure que nous déployons des améliorations supplémentaires sur notre plate-forme.

Vous pouvez voir l'impact de ces efforts dans le Core Web Vitals Technology Report de Google Chrome User Experience Rapport (CrUX) / Archive HTTP :

Ces améliorations de performances offrent une grande valeur à nos utilisateurs, car les sites qui ont de bons scores Google CWV sont éligibles pour l'amélioration maximale du classement des performances dans les résultats de recherche Google (SERP). Ils ont également probablement des taux de conversion accrus et des taux de rebond inférieurs en raison de l'amélioration de l'expérience des visiteurs.

Maintenant, examinons de plus près les actions et les processus que nous avons mis en place pour obtenir ces résultats significatifs. .

Le Wix Challenge

Commençons par décrire qui nous sommes, quels sont nos cas d'utilisation et nos défis.

Wix est une plate-forme SaaS fournissant des produits et services à tout type d'utilisateur pour créer un site en ligne présence. Cela inclut la création de sites Web, l'hébergement de sites Web, la gestion de campagnes, le référencement, l'analyse, le CRM et bien plus encore. Il a été fondé en 2006 et a depuis grandi pour compter plus de 210 millions d'utilisateurs dans 190 pays et héberge plus de cinq millions de domaines. En plus des sites Web de contenu, Wix prend également en charge le commerce électronique, les blogs, les forums, les réservations et les événements, ainsi que l'adhésion et l'authentification. Et Wix a sa propre boutique d'applications avec des applications et des thèmes pour les restaurants, le fitness, les hôtels et bien plus encore. Pour soutenir tout cela, nous avons plus de 5 000 employés répartis dans le monde.

Ce taux de croissance élevé, associé à l'échelle actuelle et à la diversité des offres, représente un énorme défi pour améliorer les performances. C'est une chose d'identifier les goulots d'étranglement et de mettre en œuvre des optimisations pour un site Web spécifique ou quelques sites Web similaires, et une autre lorsqu'il s'agit de plusieurs millions de sites Web, ayant une telle variété de fonctionnalités et une liberté de conception presque totale. En conséquence, nous ne pouvons pas optimiser pour une mise en page spécifique ou un ensemble de fonctionnalités qui sont connus à l'avance. Au lieu de cela, nous devons nous adapter à toute cette variabilité, principalement à la demande. Du côté positif, puisqu'il y a tellement d'utilisateurs et de sites Web sur Wix, les améliorations que nous apportons profitent à des millions de sites Web et peuvent avoir un impact positif sur le Web dans son ensemble.

Il y a plus de défis pour nous en plus de Échelle et diversité :

• Conserver la conception et le comportement existants
  Une exigence clé que nous nous sommes fixée était d'améliorer les performances de tous les sites Web existants construits sur Wix sans altérer aucun aspect de leur apparence. Donc, essentiellement, ils doivent continuer à ressembler et à fonctionner exactement de la même manière, mais à fonctionner plus rapidement.
• Maintenir la vitesse de développement
  L'amélioration des performances nécessite une quantité importante de ressources et d'efforts. Et la dernière chose que nous voulons, c'est avoir un impact négatif sur l'élan de nos développeurs, ou notre capacité à publier de nouvelles fonctionnalités à un rythme élevé. Ainsi, une fois un certain niveau de performance atteint, nous voulons pouvoir le préserver sans être constamment obligé d'investir des efforts supplémentaires, ni de ralentir le processus de développement. En d'autres termes, nous devions trouver un moyen d'automatiser le processus de prévention des dégradations des performances.
• Éducation
  Afin de créer un changement dans l'ensemble de notre organisation, nous devions obtenir tous les employés, partenaires et même clients concernés. au courant des performances rapidement et efficacement. Cela a nécessité beaucoup de planification et de prévoyance, et pas mal d'essais et d'erreurs.

Créer une culture de la performance

Au départ, chez Wix, la performance était une tâche assignée à un groupe dédié relativement petit au sein de l'entreprise. Cette équipe a été chargée d'identifier et de résoudre les goulots d'étranglement de performance spécifiques, tandis que d'autres dans l'ensemble de l'organisation n'ont été sollicitées qu'au cas par cas. Bien que des progrès notables aient été réalisés, il était difficile de mettre en œuvre des changements significatifs juste pour des raisons de rapidité. les travaux en cours sur diverses fonctionnalités et capacités ont souvent fait obstacle. Un autre facteur limitant était le manque de données et d'informations sur les goulots d'étranglement afin que nous puissions savoir exactement où concentrer nos efforts pour un effet maximal.

Il y a environ deux ans, nous sommes arrivés à la conclusion que nous ne pouvons pas continuer avec cette approche. Cela, afin de fournir le niveau de performance dont nos utilisateurs ont besoin et qu'ils attendent, nous devons opérer au niveau organisationnel. Et que si nous ne fournissons pas ce niveau de performance, cela sera préjudiciable à notre entreprise et à notre succès futur. Il y a eu plusieurs catalyseurs pour cette compréhension, certains dus aux changements dans l'écosystème Web en général, et d'autres à notre propre segment de marché en particulier :

• Changements dans le paysage des appareils
  Il y a six ans, plus de 70 % des sessions pour Wix les sites Web proviennent d'ordinateurs de bureau, et moins de 30 % proviennent d'appareils mobiles. Depuis lors, la situation s'est inversée et plus de 70 % des sessions ont désormais lieu sur mobile. Alors que les appareils mobiles ont parcouru un long chemin en termes de vitesse du réseau et du processeur, beaucoup d'entre eux sont encore considérablement sous-alimentés par rapport aux ordinateurs de bureau, en particulier dans les pays où la connectivité mobile est encore faible. Par conséquent, à moins que les performances ne s'améliorent, de nombreux visiteurs subissent une baisse de la qualité de l'expérience qu'ils reçoivent au fil du temps.
• Attentes des clients
  Au cours des dernières années, nous avons constaté une évolution significative des attentes des clients en matière de performances. Grâce aux activités de Google et d'autres, les propriétaires de sites Web comprennent désormais qu'avoir une bonne vitesse de chargement est un facteur majeur dans le succès de leurs sites. En conséquence, les clients préfèrent les plates-formes qui offrent de bonnes performances – et évitent ou abandonnent celles qui ne le font pas.
• Classement de recherche Google
  En 2018, Google a annoncé que les sites avec des pages particulièrement lentes sur mobile seraient pénalisés. Mais à partir de 2021, Google a modifié son approche pour plutôt augmenter le classement des sites mobiles qui ont de bonnes performances . Cela a accru la motivation des propriétaires de sites et des référenceurs à utiliser des plates-formes capables de créer des sites rapides. Cela inclut des fonctionnalités telles que des vidéos et des animations, des interactions sophistiquées et une plus grande personnalisation. À mesure que les sites Web deviennent de plus en plus lourds et complexes la tâche de maintenir les performances devient de plus en plus difficile.
• Une meilleure standardisation des outils et des mesures
  La mesure des performances des sites Web était auparavant difficile et nécessitait une expertise spécifique. Mais ces dernières années, la capacité d'évaluer la vitesse et la réactivité des sites Web s'est considérablement améliorée et est devenue beaucoup plus simple, grâce à des outils tels que Google Lighthouse et PageSpeed ​​Insights. De plus, l'industrie s'est principalement normalisée sur les mesures de performance Core Web Vitals (CWV) de Google, et leur surveillance est désormais intégrée à des services tels que la Google Search Console.

Ces changements ont radicalement changé notre perception du site Web. performance d'être juste une partie de nos offres pour devenir un objectif impératif de l'entreprise et une priorité stratégique. Et que pour réaliser cette stratégie, la mise en œuvre d'une culture de la performance dans l'ensemble de l'organisation est un must. Pour y parvenir, nous avons adopté une approche à deux volets. Tout d'abord, lors d'une mise à jour de l'entreprise « à tous les niveaux », notre PDG a annoncé qu'à l'avenir, assurer de bonnes performances pour les sites Web construits sur notre plate-forme sera une priorité stratégique pour l'ensemble de l'entreprise . Et que les différentes unités au sein de l'entreprise seront mesurées sur leur capacité à atteindre cet objectif.

Dans le même temps, l'équipe de performance a subi une énorme transformation afin de soutenir la hiérarchisation des performances à l'échelle de l'entreprise. Il est passé du travail sur des améliorations de vitesse spécifiques à l'interface avec tous les niveaux de l'organisation, afin de soutenir leurs efforts de performance. La première tâche consistait à fournir une formation sur ce que signifie réellement la performance d'un site Webet comment elle peut être mesurée. Et une fois que les équipes ont commencé à travailler à partir des connaissances, cela signifiait organiser des revues de conception et de code axées sur les performances, une formation et une éducation, ainsi que fournir des outils et des ressources pour soutenir ces efforts en cours.

À cette fin, l'équipe s'est appuyée sur l'expertise. qu'il avait déjà acquis en travaillant sur des projets de performance spécifiques. Et il s'est également engagé avec la communauté de la performance dans son ensemble, par exemple en assistant à des conférences, en faisant appel à des experts du domaine et en étudiant des architectures modernes telles que le Jamstack.

Measuring And Monitoring

Peter Drucker, l'un des meilleurs – des consultants en gestion connus, qui ont déclaré : 

 « Si vous ne pouvez pas le mesurer, vous ne pouvez pas l'améliorer ». quelles métriques doivent être mesurées afin de déterminer les performances d'un site Web ? Au fil des ans, de nombreuses métriques ont été proposées et utilisées, ce qui a rendu difficile la comparaison des résultats tirés de différents outils. En d'autres termes, le domaine manquait de normalisation. Cela a changé il y a environ deux ans, lorsque Google a introduit trois métriques principales pour mesurer les performances des sites Web, connues collectivement sous le nom de Google Core Web Vitals (CWV).

Les trois métriques sont :

1. LCP : La plus grande peinture de contenu (mesure la visibilité)
2. FID : First Input Delay (mesure le temps de réponse)
3. CLS : Cumulative Layout Shift (mesure la stabilité visuelle )

CWV ont permis à l'industrie de se concentrer sur un petit nombre de mesures qui couvrent les principaux aspects de l'expérience de chargement de sites Web. Et le fait que Google utilise désormais CWV comme signal de classement de recherche fournit une motivation supplémentaire aux personnes pour les améliorer. Web Vitals” de Barry Pollard

Chez Wix, nous nous concentrons sur le CWV lors de l'analyse des données de terrain, mais nous utilisons également des mesures en laboratoire pendant le processus de développement. En particulier, les tests en laboratoire sont essentiels pour la mise en œuvre des budgets de performances afin d'éviter les dégradations de performances. Les meilleures implémentations de budgets de performance intègrent leur application dans le processus CI/CD, ils sont donc appliqués automatiquement et empêchent le déploiement en production lorsqu'une régression est détectée. Lorsqu'une telle régression se produit, elle interrompt la construction, forçant l'équipe à la réparer avant que le déploiement ne puisse se poursuivre.

Il existe divers produits de budgétisation des performances et outils open source disponibles, mais nous avons décidé de créer notre propre service de budgétisation personnalisé appelé [

Perfer. En effet, nous opérons à une échelle beaucoup plus grande que la plupart des opérations de développement Web, et à tout moment, des centaines de composants différents sont développés chez Wix et sont utilisés dans des milliers de combinaisons différentes sur des millions de sites Web différents.

Cela nécessite le possibilité de tester un très grand nombre de configurations. De plus, afin d'éviter de casser les builds avec des fluctuations aléatoires, les tests qui mesurent les métriques de performance ou les scores sont exécutés plusieurs fois et un agrégat des résultats est utilisé pour le budget. Afin de prendre en charge un nombre aussi élevé de tests sans impacter négativement le temps de construction, Perfer exécute les mesures de performances en parallèle sur un cluster de serveurs dédiés appelé WatchTower. Actuellement, WatchTower est capable d'exécuter jusqu'à 1 000 tests Lighthouse par minute.

Après le déploiement, les données de performances sont collectées de manière anonyme à partir de toutes les sessions Wix sur le terrain. Ceci est particulièrement important dans notre cas, car la grande variété de sites Web Wix rend effectivement impossible le test de toutes les configurations et scénarios pertinents « en laboratoire ». En collectant et en analysant les données RUM, nous nous assurons d'avoir le meilleur aperçu possible des expériences des visiteurs réels des sites Web. Si nous identifions qu'un certain déploiement dégrade les performances et nuit à cette expérience, même si cette dégradation n'a pas été identifiée par nos tests en laboratoire, nous pouvons rapidement l'annuler.

Un autre avantage des mesures sur le terrain est qu'elles correspondent à l'approche adoptée par Google afin de collecter des données de performance dans la base de données CrUX. Étant donné que ce sont les données CrUX qui sont utilisées comme entrée pour le signal de classement des performances de Google, il est très important d'utiliser la même approche pour l'analyse des performances.

Toutes les sessions Wix contiennent un code d'instrumentation personnalisé qui rassemble les métriques de performances et transmet ces informations de manière anonyme à nos serveurs de télémétrie. En plus des trois CWV, ce code signale également le temps jusqu'au premier octet (TTFB), la première peinture de contenu (FCP), le temps de blocage total (TBT) , et Time To Interactive (TTI), ainsi que des métriques de bas niveau telles que le temps de recherche DNS et le temps de négociation SSL. La collecte de toutes ces informations nous permet non seulement d'identifier rapidement les problèmes de performances en production, mais également d'analyser les causes profondes de ces problèmes. Par exemple, nous pouvons déterminer si un problème a été causé par des modifications apportées à notre propre logiciel par les modifications apportées à la configuration de notre infrastructure, ou même par des problèmes affectant les services tiers que nous utilisons (tels que les CDN).

Mise à niveau de nos services et Infrastructure

À l'époque où j'ai rejoint Wix il y a sept ans, nous n'avions qu'un seul centre de données (avec un centre de données de secours) aux États-Unis qui était utilisé pour servir les utilisateurs du monde entier. Depuis lors, nous avons considérablement augmenté le nombre de centres de données et en avons plusieurs répartis dans le monde entier. Cela garantit que, quel que soit l'endroit d'où nos utilisateurs se connectent, ils seront desservis à la fois rapidement et de manière fiable. De plus, nous utilisons des CDN de plusieurs fournisseurs pour assurer une livraison rapide du contenu quel que soit l'emplacement . Ceci est particulièrement important étant donné que nous avons maintenant des utilisateurs dans 190 pays.

Afin de tirer le meilleur parti possible de cette infrastructure améliorée, nous avons complètement repensé et réécrit des parties importantes de notre code frontal. L'objectif était de déplacer autant de calculs que possible des navigateurs vers des serveurs rapides. Ceci est particulièrement avantageux dans le cas des appareils mobiles, qui sont souvent moins puissants et plus lents. De plus, cela a considérablement réduit la quantité de code JavaScript qui doit être téléchargé par le navigateur.

La réduction de la taille de JavaScript profite presque toujours aux performances car elle diminue la surcharge du téléchargement réel ainsi que l'analyse et l'exécution. Nos mesures ont montré une corrélation directe entre la réduction de la taille de JavaScript et l'amélioration des performances :

Un autre avantage du déplacement des calculs des navigateurs vers les serveurs est que les résultats de ces calculs peuvent souvent être mis en cache et réutilisés entre les sessions, même pour des visiteurs indépendants, réduisant ainsi considérablement le temps d'exécution par session. En particulier, lorsqu'un visiteur navigue sur un site Wix pour la première fois, le HTML de la page de destination est généré sur le serveur par Server-Side Rendering (SSR) et le HTML résultant peut ensuite être propagé vers un CDN.

Les navigations vers le même site — même par des visiteurs non apparentés — peuvent alors être servies directement à partir du CDN, sans même accéder à nos serveurs. Si ce workflow vous semble familier, c'est parce qu'il est essentiellement le même que le mécanisme à la demande fourni par certains services Jamstack avancés.

Remarque : « à la demande » signifie qu'au lieu de la génération de site statique effectuée au moment de la construction, le code HTML est généré en réponse à la première demande du visiteur et propagé vers un CDN au moment de l'exécution.

De la même manière que Jamstack, le code côté client peut améliorer l'interface utilisateur, la rendant plus dynamique en appelant des services backend à l'aide d'API . Les résultats de certaines de ces API sont également mis en cache dans un CDN, le cas échéant. Par exemple, dans le cas d'une icône de paiement de panier, le code HTML du bouton est généré sur le serveur, mais le nombre réel d'articles dans le panier est déterminé côté client, puis rendu dans cette icône. De cette façon, le HTML de la page peut être mis en cache même si chaque visiteur peut voir une valeur de nombre d'éléments différente. Si le code HTML de la page doit changer, par exemple, si le propriétaire du site publie une nouvelle version, la copie dans le CDN est immédiatement purgée.

Afin de réduire l'impact des calculs sur les terminaux, nous avons déplacé la logique métier qui doit s'exécuter dans les navigateurs vers Web Workers. Par exemple, la logique métier invoquée en réponse aux interactions de l'utilisateur. Le code qui s'exécute dans le thread principal du navigateur est principalement dédié aux opérations de rendu réelles. Étant donné que les Web Workers exécutent leur code JavaScript à partir du thread principal, ils ne bloquent pas la gestion des événements, permettant au navigateur de répondre rapidement aux interactions des utilisateurs et à d'autres événements.

Exemples de code qui s'exécute dans Web Les travailleurs incluent la logique commerciale de diverses solutions verticales telles que le commerce électronique et les réservations. L'envoi de demandes aux services principaux est principalement effectué à partir des Web Workers, et les réponses sont également analysées, stockées et gérées dans les Web Workers. En conséquence, l'utilisation de Web Workers peut réduire le blocage et améliorer considérablement la métrique FID, offrant une meilleure réactivité en général. Dans les mesures en laboratoire, cela a amélioré les mesures TBT.

Les sites Web modernes offrent souvent une expérience utilisateur plus riche en téléchargeant et en présentant beaucoup plus de ressources multimédias, telles que des images et des vidéos, que jamais auparavant. Au cours de la dernière décennie, la quantité médiane d'octets d'images téléchargés par les sites Web, selon la base de données Google CrUX, a plus que huit fois ! C'est plus que l'amélioration médiane des vitesses du réseau au cours de la même période, ce qui entraîne des temps de chargement plus lents. De plus, nos données RUM (mesures de terrain) montrent que pour près des ¾ des sessions Wix, l'élément LCP est une image. Tout cela met en évidence la nécessité de fournir des images aux navigateurs aussi efficacement que possible et d'afficher rapidement les images qui se trouvent dans la zone d'affichage initialement visible d'une page Web.

Dans le même temps, il est crucial de fournir des images de la plus haute qualité. possible afin de fournir une expérience utilisateur attrayante et agréable. Cela signifie que l'amélioration des performances en dégradant sensiblement l'expérience visuelle est presque toujours hors de question. Les améliorations de performances que nous mettons en œuvre doivent préserver la qualité d'origine des images utilisées, sauf indication contraire explicite de l'utilisateur.

Une technique pour améliorer les performances liées aux médias consiste à optimiser le processus de livraison. Cela signifie télécharger les ressources multimédias requises le plus rapidement possible. Afin d'atteindre cet objectif pour les sites Web Wix, nous utilisons un CDN pour fournir le contenu multimédia, comme nous le faisons avec d'autres ressources telles que le HTML lui-même. Et en spécifiant une longue durée de mise en cache dans l'en-tête de réponse HTTP, nous autorisons également la mise en cache des images par les navigateurs. Cela peut améliorer considérablement la vitesse de chargement pour les visites répétées sur la même page en évitant complètement de télécharger à nouveau les images sur le réseau.

Une autre technique pour améliorer les performances consiste à fournir plus efficacement les informations d'image requises en réduisant le nombre d'octets nécessaires. à télécharger tout en préservant la qualité d'image souhaitée. Une méthode pour y parvenir consiste à utiliser un format d'image moderne tel que WebP. Les images codées en WebP sont généralement 25 à 35 % plus petites que les images équivalentes codées en PNG ou JPG. Les images téléchargées sur Wix sont automatiquement converties en WebP avant d'être transmises aux navigateurs qui prennent en charge ce format.

Très souvent, les images doivent être redimensionnées, recadrées ou autrement manipulées lorsqu'elles sont affichées dans une page Web. Cette manipulation peut être effectuée à l'intérieur du navigateur à l'aide de CSS, mais cela signifie généralement qu'il faut télécharger plus de données que ce qui est réellement utilisé. Par exemple, tous les pixels d'une image qui ont été rognés ne sont pas réellement nécessaires mais sont toujours livrés. Nous prenons également en compte la taille et la résolution de la fenêtre d'affichage, ainsi que la profondeur des pixels d'affichage, pour optimiser la taille de l'image. Pour les sites Wix, nous effectuons ces manipulations côté serveur avant le téléchargement des images, de cette façon nous pouvons nous assurer que seuls les pixels réellement nécessaires sont transmis sur le réseau. Sur les serveurs, nous utilisons des modèles d'IA et de ML pour générer des images redimensionnées avec la meilleure qualité possible.

Une autre technique utilisée pour réduire la quantité de données d'image qui doit être téléchargée en amont est le images de chargement paresseux[. Cela signifie ne pas charger les images qui sont entièrement en dehors de la fenêtre d'affichage visible jusqu'à ce qu'elles soient sur le point de défiler. Différer le téléchargement d'images de cette manière, et même l'éviter complètement (si un visiteur ne fait jamais défiler jusqu'à cette partie de la page), réduit la contention du réseau pour ressources qui sont déjà requises dès le chargement de la page, comme une image LCP. Les sites Web Wix utilisent automatiquement le chargement paresseux pour les images, ainsi que pour divers autres types de ressources.

Looking Forward

Au cours des deux dernières années, nous avons déployé de nombreuses améliorations sur notre plate-forme destinées à améliorer les performances. Le résultat de toutes ces améliorations est une augmentation spectaculaire du pourcentage de sites Web Wix qui obtiennent un bon score pour les trois CWV par rapport à il y a un an. Mais la performance est un voyage, pas une destination, et nous avons encore beaucoup plus d'actions et de plans futurs pour améliorer la vitesse des sites Web. À cette fin, nous étudions de nouvelles fonctionnalités de navigateur ainsi que des modifications supplémentaires à notre propre infrastructure. Les budgets de performance et la surveillance que nous avons mis en place garantissent que ces changements offrent des avantages réels.

De nouveaux formats de médias sont introduits et ont le potentiel de réduire encore plus la taille des téléchargements tout en conservant la qualité de l'image. Nous étudions actuellement AVIFqui semble être particulièrement prometteur pour les images photographiques pouvant utiliser une compression avec perte. Dans de tels scénarios, AVIF peut fournir des tailles de téléchargement considérablement réduites, même par rapport à WebP, tout en conservant la qualité de l'image. AVIF prend également en charge le rendu progressif qui peut améliorer les performances perçues et l'expérience utilisateur, en particulier sur les connexions plus lentes, mais ne fournira actuellement aucun avantage pour CWV. propriété. Cette propriété permet au navigateur d'ignorer l'effort de rendu d'un élément HTML jusqu'à ce qu'il soit réellement nécessaire. En particulier, lorsque le paramètre content-visibility:auto est appliqué à un élément hors écran, ses descendants ne sont pas rendus. Cela permet au navigateur d'ignorer la plupart des travaux de rendu, tels que le style et la disposition de la sous-arborescence de l'élément. Ceci est particulièrement souhaitable pour de nombreuses pages Wix qui ont tendance à être longues et riches en contenu. En particulier, le nouvel éditeur de sites réactifs EditorX de Wix prend en charge des mises en page sophistiquées de grille et de boîte flexible qui peuvent être coûteuses à rendre pour le navigateur, de sorte qu'éviter les opérations de rendu inutiles est particulièrement souhaitable. Malheureusement, cette propriété n'est actuellement prise en charge que dans les navigateurs basés sur Chromium. De plus, il est difficile d'implémenter cette fonctionnalité de manière à ce qu'aucun site Web Wix ne soit jamais affecté négativement en termes d'apparence visuelle ou de comportement.

Priority Hints est une fonctionnalité de navigateur à venir que nous étudions également. , qui promet d'améliorer les performances en offrant un meilleur contrôle sur le moment et la manière dont les navigateurs téléchargent les ressources. Cette fonctionnalité informera les navigateurs des ressources les plus urgentes et qui doivent être téléchargées avant les autres ressources. Par exemple, une image de premier plan peut se voir attribuer une priorité plus élevée qu'une image d'arrière-plan, car elle est plus susceptible de contenir un contenu important. D'un autre côté, s'ils sont mal appliqués, les indices de priorité peuvent en fait dégrader la vitesse de téléchargement, et donc également les scores CWV. Les indices prioritaires font actuellement l'objet d'un essai d'Origin dans Chrome.

En plus d'améliorer la propre infrastructure de Wix, nous travaillons également à fournir de meilleurs outils à nos utilisateurs afin qu'ils puissent concevoir et mettre en œuvre des sites Web plus rapides. Étant donné que Wix est hautement personnalisable, les utilisateurs ont la liberté et la flexibilité de créer des sites Web rapides et lents sur notre plate-forme, en fonction des décisions qu'ils prennent lors de la création de ces sites. Notre objectif est d'informer les utilisateurs sur la performance de leurs décisions afin qu'ils puissent faire les choix appropriés. Ceci est similaire à l'outil SEO Wiz que nous fournissons déjà.

Résumé

La mise en œuvre d'une culture de la performance chez Wix nous a permis d'appliquer des améliorations de performances à presque chaque partie de notre pile technologique – de l'infrastructure à architecture logicielle et formats de médias. Bien que certaines de ces améliorations aient eu un impact plus important que d'autres, c'est l'effet cumulatif qui fournit les avantages globaux. Et ces avantages ne sont pas seulement mesurables à grande échelle ; ils sont également évidents pour nos utilisateurs, grâce à des outils tels que WebPageTest et Google PageSpeed ​​Insights et aux commentaires réels qu'ils reçoivent de leurs propres utilisateurs.

Grand aperçu)

Les retours que nous recevons nous-mêmes, de nos utilisateurs et de l'industrie dans son ensemble, et les avantages tangibles dont nous bénéficions nous poussent à continuer d'améliorer notre vitesse. La culture de la performance que nous avons mise en œuvre est là pour rester.

Related Resources

(vf, yk , il)