E-commerce : la perception de la vitesse du site Web fait toute la différence

Nous savons tous que la vitesse d'un site Web peut faire une énorme différence dans le taux de conversion et l'adhérence d'un site Web de commerce électronique.

Une étude de cas réalisée par SOASTA a affirmé que l'amélioration de la vitesse de chargement des pages mobiles augmentait le taux de conversion de plus de 25 %. Dans sa volonté constante de donner la priorité à l'utilisateur, Jeff Bezos, fondateur et PDG d'Amazon, est connu pour être obsédé par la vitesse de chargement des pages et pousse constamment ses employés à réduire la vitesse des pages du site Web d'Amazon.

La montée de la domination mobile a amplifié le besoin d'une vitesse de chargement des pages plus rapide, car les utilisateurs naviguent souvent sur des sites Web avec des connexions plus lentes.

Il existe de nombreux outils pour vous aider à améliorer la vitesse des pages Web tels que Yslow ou Google Pagespeed Insights, et il existe diverses meilleures pratiques telles que la minification et la fusion css et js, l'utilisation de sprites css et la minimisation des demandes réseau qui un développeur frontal doit suivre pour s'assurer que la vitesse de la page est maximisée.

Le problème que nous avons est qu'une fois que vous suivez les meilleures pratiques standard et réalisez les gros gains, vous commencerez bientôt à voir des rendements décroissants sur les efforts pour améliorer la vitesse globale de la page.

Vous pouvez passer beaucoup de temps à faire des améliorations incrémentielles de plus en plus petites et ce sera un processus long et coûteux. Les développeurs front-end possédant les compétences et l'expérience nécessaires pour travailler à ce niveau sont étonnamment rares et coûteux.

Il y a certaines choses que vous ne pouvez pas contrôler, comme la latence du réseau ou les vitesses de connexion mobile, et il y a donc une limite à ce qui peut être réalisé avec la vitesse de page brute. Sur une connexion 3G, n'importe où entre 600 ms et 1 s est consommé par des frais généraux de réseau obligatoires, auxquels vous ne pouvez rien faire. Sur la base d'un temps de chargement de page souhaité de 2 s, cela ne nous donne que 1 s pour jouer avec. Ce n'est pas beaucoup.

Il est indéniable que la vitesse brute des pages est très importante et tous les développeurs doivent au minimum suivre les meilleures pratiques standard.

Cet article, cependant, ne va pas expliquer comment accélérer le chargement de votre page. Il y a beaucoup d'articles à ce sujet et c'est un peu technique.

Cet article va se concentrer sur la perception de la vitesse de la page.
Qu'est-ce qui est le plus important ? À quelle vitesse la page se charge-t-elle ou à quelle vitesse l'utilisateur perçoit-il qu'elle se charge ?

La perception est sûrement ce qui compte le plus pour l'utilisateur.

Vitesse du site : premières impressions

Concentrons-nous sur la page d'accueil de votre site Web. Il contiendra probablement une navigation supérieure, une barre de recherche, une bannière de héros, peut-être des liens vers des catégories clés, un carrousel et du contenu. Les pages d'accueil ont tendance à être assez lourdes en contenu et le chargement rapide de tout ce contenu sur une connexion mobile va être un gros défi.

La clé ici est de donner la priorité au chargement du contenu critique en premier, avant tout autre contenu - donnez à l'utilisateur quelque chose d'important à voir le plus rapidement possible.

Pendant qu'ils traitent ces informations critiques, vous pouvez alors commencer à charger le niveau de contenu suivant.

Sur un appareil mobile, une grande partie du contenu va commencer sous la ligne de flottaison et doit donc être chargée après le contenu qui se trouve au-dessus de la ligne de flottaison. Il est courant de fusionner et de réduire JavaScript. Ceci est normalement considéré comme une bonne pratique, mais cela peut vous empêcher de donner la priorité au chargement de JavaScript critique avant le code moins critique. Au lieu de cela, vous pouvez envisager de diviser votre JavaScript minifié et fusionné et de le charger progressivement au fur et à mesure de vos besoins. Il n'est pas nécessaire de charger le JavaScript requis pour effectuer une recherche avant même de charger le champ de recherche. Les utilisateurs ne saisiront pas de caractères dans le champ de recherche pendant au moins quelques secondes après le chargement d'une page.

Regardons un site qui fait cela très bien. Amazon a divisé la livraison des actifs et du contenu pour s'assurer que l'utilisateur reçoit le contenu critique dès que possible, puis il charge progressivement les actifs dans l'ordre de priorité.

Ce test a été exécuté sur un simulateur d'iPhone 6 avec une bonne connexion 3G et la mise en cache désactivée. Après le chargement initial de la page, j'ai lancé une actualisation matérielle.

En un peu plus de 600 ms, j'ai quelque chose qui commence à se charger avec mon nom dans l'en-tête. Vous remarquerez également que seuls 6 appels réseau ont été effectués et 5 assets chargés (3 fichiers css et 2 images).

À peine 50 ms plus tard, je vois maintenant les éléments clés de l'en-tête ainsi que la bannière du héros principal. J'ai déjà la perception de la vitesse car le contenu clé m'est livré très rapidement et il y a quelque chose que mes yeux et mon cerveau doivent traiter pendant que du contenu supplémentaire est en cours de chargement.

Après seulement 1 seconde, la navigation principale est chargée. Vous remarquerez qu'il n'y a pas de barre de défilement visible à ce stade. Cela signifie qu'il n'y a actuellement aucun contenu sous le pli. Un temps précieux n'a pas été perdu pour charger ce contenu que l'utilisateur ne peut pas voir. Vous remarquerez également que seulement 13 demandes ont été faites jusqu'à présent.

En un peu moins de 2 secondes, j'ai maintenant une nouvelle section de contenu important.

En moins de 3 secondes, je perçois maintenant que la page s'est entièrement chargée alors que la page a en fait mis un peu moins de 5 secondes à se charger dans son intégralité. Cela suggère que je perçois que le site est complètement chargé alors qu'il n'est en fait chargé qu'à 60%.

Le moment réel de la livraison du contenu variera d'une personne à l'autre, mais cela illustre très clairement comment Amazon donne la priorité au chargement du contenu mobile pour s'assurer que le contenu critique est chargé aussi rapidement que possible et que les utilisateurs perçoivent le site comme commençant à se charger très rapidement.

Examinons maintenant un site Web qui ne le fait pas si bien. Ce test a été exécuté en utilisant exactement les mêmes outils et la même vitesse de réseau que le test Amazon précédent. Alors que le site Charles Tyrwhitt donne la priorité à certains contenus, il y a beaucoup plus qui pourrait être fait pour se rapprocher de l'optimisation d'Amazon.

Je ne vois aucun contenu pendant près de 7,5 secondes. Immédiatement, j'ai l'impression que ce site est lent sur mon appareil mobile. Bien que le site donne la priorité au contenu de l'en-tête ainsi qu'à une bannière de héros, vous pouvez voir que plus de 90 demandes ont été faites à ce stade et, comme je peux voir la barre de défilement, il est clair que le contenu doit avoir été chargé sous le pli.

Après 8,5 secondes, je peux voir qu'un carrousel commence à se charger. Le nombre de requêtes n'a pas changé, ce qui suggère que la majeure partie des requêtes liées au contenu sont effectuées dès le début du chargement de la page.

Ce n'est qu'au bout de près de 22 secondes que je m'aperçois que le site est désormais entièrement chargé. La page a en fait pris un total de 28,4 secondes pour se charger complètement. Cela suggère que je perçois que la page était complètement chargée alors qu'elle était en fait chargée à 77%.

Il est facile de voir la nette différence entre les 2 expériences. Alors que la page d'accueil mobile d'Amazon se charge beaucoup plus rapidement que la page d'accueil de Charles Tyrwhitt, des efforts ont été faits pour s'assurer que les utilisateurs perçoivent qu'elle est encore plus rapide. L'utilisateur commence à voir quelque chose se charger dans les 12,5 % du temps de chargement total de la page, tandis que les utilisateurs du site Web de Charles Tyrwhitt ne voient que quelque chose se produire dans les 26 % du temps de chargement total de la page. La page d'accueil d'Amazon a fait 6 requêtes réseau avant que l'utilisateur ne voie les progrès alors que la page d'accueil de Charles Tyrwhitt a fait 90 requêtes.

Ce n'est pas censé être trop critique envers Charles Tyrwhitt car ils ne sont en aucun cas uniques dans la façon dont ils ont construit leur site Web. La meilleure pratique acceptée a été suivie dans un certain nombre de domaines, mais il semble que beaucoup plus pourrait être fait pour améliorer la perception de la vitesse ainsi que la vitesse réelle.

Améliorez la vitesse du site Web en donnant la priorité au CSS

Il est assez courant pour les développeurs front-end de placer la majorité du css d'un site Web dans une poignée de fichiers et d'utiliser toujours du css externe plutôt qu'inline. Le problème que cela provoque est qu'un gros fichier CSS doit être chargé avant que tout contenu puisse être montré à un utilisateur.

Une solution à cela consiste à diviser vos fichiers CSS et à les charger en séquence avec le contenu critique. Si nous regardons l'exemple d'Amazon, ils chargent un fichier CSS d'une taille de seulement 6,5 ko comme l'une de leurs 6 requêtes initiales. Ce fichier contient le css nécessaire pour styliser le contenu critique de leur page d'accueil. En fait, la taille totale de tous les fichiers CSS qui sont demandés avant que l'utilisateur ne voie le contenu sur la page d'accueil mobile d'Amazon est inférieure à 40 000 alors qu'elle est supérieure à 500 000 sur la page d'accueil de Charles Tyrwhitt.

Cette pratique vous permet de fournir très rapidement du contenu critique à l'utilisateur et contribue à renforcer la perception de la vitesse.

Faites de même avec JavaScript

En plus de donner la priorité au css, vous devriez considérer comment vous le faites également avec JavaScript. Presque tous les sites Web de commerce électronique s'appuieront fortement sur JavaScript pour fonctionner. C'est correct tant que JavaScript ne bloque pas le chargement du contenu critique. Si je reprends l'exemple du site Web de Charles Tyrwhitt et que je désactive JavaScript sur mon navigateur, je vois maintenant le contenu se charger en 4,5 secondes. Il s'agit d'un changement massif dans ma perception de la vitesse de ce site Web et le JavaScript chargé avant le contenu critique n'a eu aucun impact sur ce contenu et il n'y a donc aucune raison pour que le JavaScript ne puisse pas être chargé après ce contenu.

Les développeurs Web peuvent apprendre beaucoup de la façon dont un site Web tel qu'Amazon se concentre sur la perception de la vitesse de leur site Web ainsi que sur la vitesse réelle. Bien que leur site Web soit clairement très rapide, les utilisateurs le perçoivent comme encore plus rapide en raison de la manière dont ils accordent la priorité à l'affichage du contenu critique de l'utilisateur avant toute autre chose.

On a beaucoup parlé de l'impact que la vitesse peut avoir sur votre taux de conversion, et les détaillants devraient envisager d'investir dans l'optimisation des performances perçues de leur site Web ainsi que de la vitesse réelle du site Web.