Assurer des temps de chargement inférieurs à la seconde pour votre site de commerce électronique est un travail difficile. Chez Layer0, nous avons essayé d’en faire un processus beaucoup plus simple, et Layer0 est là pour vous aider à atteindre cette étape. Ce que nous avons fait ici, c’est de créer une liste de contrôle que vous pouvez suivre pour vous assurer que votre site de production est incroyablement rapide et que vous passez le moins de temps à l’accomplir.
Tout d’abord, parlons de la façon dont nous mesurons la vitesse:
Mesure des performances
** Nous avons utilisé SpeedCurve (SC) dans ce cas, mais vous pouvez utiliser WebPageTest ou tout autre produit
Nous nous concentrons sur les mesures LCP pour nos mesures. Nos objectifs sont les suivants :
- Page d’accueil <1.5s
- Navigation PLP à PDP : 0.5s
Il est également important de garder à l’esprit les 3 cas suivants car cela affecte l’expérience du consommateur quand (A) aller directement aux PLP/PDP en raison du trafic de recherche organique et (b) lors de la navigation vers les pages panier/paiement – essentiel pour nos clients du point de vue commercial :
- PLP comme page de destination
- PDP comme page de renvoi
- PWA -> origine/héritage (par ex. vers panier/caisse)
Commençons par quelques vérifications de base qui pourraient nous aider à obtenir des gains de vitesse majeurs
- Assurez-vous que les squelettes sont utilisés et que la disposition est stable.
- Message « en attente de… » (ou similaire) dans la fenêtre du navigateur (un problème connu dans WebPageTest utilisé par SC) : inspectez les images de cascade pour voir si c’est la seule cause de dégradation des métriques.
- Le basculement entre image basse résolution et image haute résolution pourrait également entraîner une dégradation des métriques dans SC – inspectez les images de cascade pour voir si c’est la seule cause.
- Artefacts provenant de composants personnalisés (par rapport aux composants RSF natifs qui sont construits en tenant compte des meilleures pratiques) – styles/éléments qui provoquent un rendu excessif du ou des composants. Inspectez à nouveau les images en cascade pour voir s’il y a des artefacts visibles (par exemple, image basse résolution -> carrousel d’images sur la> transition PLP-PDP)
Navigation PLP vers PDP
La navigation des pages PLP (résultats de recherche ou pages catégorie/marque) vers les pages PDP est l’élément de navigation le plus important du parcours complet du consommateur. Pour chaque achat effectué, un utilisateur moyen navigue vers 8,8 pages PDP. Même un ralentissement mineur de la page à une fréquence aussi élevée peut avoir un impact négatif important sur l’expérience utilisateur. Voici quelques choses que vous pouvez suivre pour assurer une expérience utilisateur PLP à PDP parfaite:
- Utilisez un squelette pour la page au-dessus du pli et assurez-vous de la stabilité de la mise en page
- Assurez-vous que le contenu au-dessus du pli correspond à la hauteur de l’écran de l’appareil de l’utilisateur.
- Assurez-vous que la mise en cache est correctement configurée. Cela signifie mettre en cache les données de page génériques et non les points de données spécifiques à l’utilisateur. (Consultez notre guide sur la mise en cache pour plus de détails)
- Utiliser le préchargement (consultez notre guide sur le préchargement pour plus de détails)
- Utilisez la même occurrence de miniatures partout pour éviter le scintillement avec le composant ForwardThumbnail
- Transmettez autant d’informations de PLP à PDP dans les props de page pour afficher ces informations sur PDP
Chargement de la page d’accueil
La page d’accueil est généralement la première interaction qu’un utilisateur a avec le site Web. Assurer un bon départ dans le voyage est essentiel pour fournir un flux d’utilisateurs heureux à la caisse et à la passation de commande. Voici quelques-unes des choses que vous pouvez suivre pour assurer une expérience de la page d’accueil exceptionnelle :
- Assurez-vous que la mise en cache est correctement configurée. Cela signifie la mise en cache des données de page génériques et non la mise en cache de points de données spécifiques à l’utilisateur.
- Charge paresseuse sous le contenu du pli
- Utiliser la balise de préconnexion
- Optimiser les images
- Retarder l’hydratation jusqu’à ce que le chargement de la page soit terminé
- Autres améliorations
Chargement de page PDP
Passer du temps à optimiser la page d’accueil et PLP à PDP navigation serait sans valeur si l’utilisateur n’a pas une grande expérience sur la page PDP elle-même. S’assurer que les informations les plus importantes sont disponibles pour l’utilisateur dès que possible et retarder les objets qui ne sont pas immédiatement visibles ou exploitables est essentiel pour optimiser le chargement des pages PDP. Voici quelques-uns des éléments à garder à l’esprit lors de l’optimisation des pages PDP:
- Mettez en cache les ressources et les données génériques, y compris les réponses API, pour garantir une récupération immédiate des données et réduire les goulots d’étranglement sur les systèmes dorsaux.
- Chargement paresseux du contenu sous le pli
- Utilisez une première image optimisée pour réduire les temps de chargement.
- Utilisez des miniatures séparées et des images de pincement et de zoom, et chargez uniquement des images sur demande.
Chargement de la page PLP
- Préchargez les images PDP pour obtenir des résultats au-dessus du pli.
- Chargement paresseux du contenu sous le pli
- Réduisez ou évitez les demandes pour déterminer les changements de page PLP, par exemple pour les changements de couleur d’arrière-plan ou d’autres éléments visuels.
Quelques autres pointeurs
Les méthodes mentionnées ci-dessus couvrent la plupart des choses avec lesquelles un utilisateur interagit tout au long du voyage. Mais il y a plus à une plateforme que ce qui est visible. S’assurer que le fonctionnement interne de la plateforme est optimisé est la prochaine étape que nous devons franchir. Voici quelques points à vérifier pour récupérer des gains de performances supplémentaires :
- TTL: vérifiez la taille du bundle en utilisant ANALYZE=true npm run build
- FCP: si un client choisit d’utiliser une WebFont, LH score baisse peut être ressenti.
- Index de vitesse : avoir des pop-ups sur l’écran réduit l’index de vitesse de la page
- Évitez les longues tâches d’exécution dans la portée du module, c’est-à-dire côté client.
- Les hooks React sont sujets à un re-rendu inutile. Bien que peu susceptibles d’affecter les métriques, ils font un site Web lent.
- Utilisez les scores PSI pour comprendre l’impact des changements de code plutôt que les scores LH de la machine locale et/ou les résultats SpeedCurve. Utilisez le mode 4G sur la production pour obtenir des scores LH réalistes.
