Quand une boutique paraît lente, on incrimine d’abord les images lourdes ou un thème surchargé. Mais il y a une chose que peu de gens remarquent : la manière dont une application de menu affecte la vitesse de chargement. Le menu se trouve tout en haut de la page, c’est donc l’un des premiers éléments que le navigateur doit gérer. Une application de navigation mal conçue peut plomber toute la boutique.
Cet article comporte deux parties. La première porte sur le mécanisme : pourquoi une application de menu ralentit les choses. La seconde porte sur les signaux d’alerte, afin que vous puissiez vérifier votre propre boutique au lieu de deviner.
Pourquoi une application de menu affecte la vitesse de la boutique
En apparence, une application de menu n’est qu’une poignée de boutons. Mais en coulisses, elle charge généralement du JavaScript, des polices, des icônes et des images. Chaque élément a un coût en vitesse. Voici les quatre causes les plus fréquentes.
Un JavaScript lourd qui doit s’exécuter avant l’apparition du menu
Beaucoup d’applications de menu construisent leur interface avec du JavaScript. Quand un client ouvre la page, le navigateur doit télécharger le fichier, l’analyser, puis l’exécuter — et c’est seulement à ce moment-là que le menu apparaît.
Plus le JavaScript est lourd, plus cette étape prend du temps. Sur un ordinateur puissant, vous le remarquez à peine. Mais la plupart des acheteurs commandent sur leur téléphone, et les téléphones de milieu de gamme traitent le JavaScript bien plus lentement. Un fichier de quelques centaines de Ko se charge en un instant sur un ordinateur, mais sur un téléphone Android bon marché, cela peut prendre une seconde entière.
Pour une boutique, cette seconde, c’est le temps que le client passe à fixer un écran vide, sans aucun menu à toucher.
Le blocage du rendu : l’application retient toute la page en attendant le menu
Ce point est souvent négligé. Selon la documentation de Google, le JavaScript bloque l’analyseur par défaut : pendant que le navigateur construit la page et rencontre une balise de script, il doit s’arrêter, terminer l’exécution de ce script, et seulement ensuite poursuivre la construction.
C’est ce qu’on appelle le blocage du rendu. Une application de menu qui place son script au mauvais endroit et n’utilise pas l’attribut async ou defer peut bloquer le rendu de la page entière, et pas seulement celui du menu.
Le résultat concret : un client clique sur un lien produit, mais la page se fige un instant parce qu’elle attend la fin du script du menu. Il ne voit ni l’image, ni le prix, rien encore. Pendant ce temps, ce qui doit vraiment se charger vite, c’est le contenu qui vend, pas la barre de menu.
Chaque icône, police et image est une requête HTTP
Un beau menu s’accompagne souvent d’icônes issues d’une police personnalisée, parfois même d’une image de fond ou d’un logo pour chaque élément. Chaque ressource est une requête HTTP — un aller-retour où le navigateur demande au serveur de lui envoyer un fichier.
Chaque requête demande du temps pour établir la connexion et attendre une réponse. Dix icônes, c’est dix allers-retours. Ajoutez une police personnalisée rien que pour le menu et la liste s’allonge. Chacune est petite, mais ensemble cela s’accumule — surtout pour les clients sur une connexion 3G/4G faible, dans une zone mal couverte.
Un menu épuré qui utilise des icônes SVG en ligne ou la police système déjà présente sur l’appareil peut réduire un bon nombre de ces requêtes.
CLS : un menu qui se charge tard décale la mise en page
Le CLS (Cumulative Layout Shift, décalage cumulé de la mise en page) est l’une des métriques des Core Web Vitals de Google. Il mesure l’ampleur des déplacements de l’interface pendant le chargement de la page. Selon Google, un bon seuil est un CLS inférieur à 0,1.
Toujours selon Google, le CLS survient souvent lorsque le JavaScript insère tardivement du contenu dans la page, repoussant les éléments existants vers le bas. Une barre de menu ou une bannière de navigation qui se charge après le contenu principal en est un exemple classique : elle apparaît, occupe de l’espace et pousse tout ce qui se trouve en dessous vers le bas.
Vous l’avez sans doute déjà vécu en faisant vos achats : vous vous apprêtez à toucher « Ajouter au panier », mais juste à cet instant le menu surgit, la mise en page se décale, et vous touchez le mauvais bouton à la place. C’est le CLS — à la fois agaçant et une raison pour les clients de partir.
Les signes que votre menu ralentit la boutique
Maintenant que vous comprenez le mécanisme, voici la partie pratique : comment savoir si votre application de menu pose problème. Pas besoin de connaissances techniques poussées, juste quelques outils gratuits.
Lancez PageSpeed Insights
Rendez-vous sur pagespeed.web.dev, collez l’adresse de votre boutique et lancez l’analyse. Cet outil de Google attribue une note à votre page et liste les problèmes sous deux sections : Opportunités et Diagnostics.
Surveillez les lignes qui mentionnent les ressources bloquant le rendu (render-blocking resources) ou réduire le temps d’exécution du JavaScript (reduce JavaScript execution time). Si un nom de fichier ou une description évoque navigation, menu ou drawer, il y a de fortes chances que l’application de menu fasse partie de ce qui ralentit les choses.
Lancez les deux modes, Mobile et Desktop. La note Mobile est généralement plus basse et plus proche de l’expérience réelle de vos clients, puisque la plupart commandent sur téléphone.
Utilisez l’onglet Network de Chrome DevTools
Ouvrez votre boutique dans Chrome, appuyez sur F12 pour afficher les DevTools et choisissez l’onglet Network. Rechargez la page, puis filtrez par type JS pour ne voir que les fichiers JavaScript.
Le tableau qui s’affiche indique le poids de chaque fichier et le temps qu’il met à se charger. Cherchez les fichiers dont le nom ressemble à celui de votre application de navigation. Si un fichier de menu pèse quelques centaines de Ko et met du temps à finir de charger, c’est une preuve concrète plutôt qu’une supposition.
Une petite astuce : les DevTools offrent des options pour simuler un réseau lent (throttling) et un processeur faible. Activez-les pour imiter l’appareil d’un vrai client, et vous obtiendrez des chiffres bien plus proches de la réalité que ceux de votre propre machine.
Comparez les scores avant et après l’installation de l’application
L’approche la plus honnête consiste à mesurer avant et après. Avant d’installer une nouvelle application de menu, lancez PageSpeed Insights et notez le score ainsi que les métriques LCP, INP et CLS. Après avoir installé l’application et construit le menu, relancez l’analyse et comparez.
Selon Google, les bons seuils sont un LCP inférieur à 2,5 secondes, un INP inférieur à 200 millisecondes et un CLS inférieur à 0,1. Si, après l’installation de l’application, le LCP augmente ou le CLS dépasse 0,1, c’est que cette application vous coûte en vitesse.
Cela compte, car la boutique moyenne n’utilise pas qu’une seule application. Selon des données citées par de nombreuses sources, une boutique Shopify typique a environ six applications installées, et certaines en utilisent jusqu’à trente. Chaque application ajoute un peu de poids, et ensemble cela finit par représenter un chiffre qui n’est pas négligeable. Et la vitesse est directement liée au nombre de personnes qui quittent la page — avec un taux moyen d’abandon de panier déjà autour de 70 % selon le Baymard Institute, chaque seconde supplémentaire peut aggraver ce chiffre.
Choisissez une application de menu qui se soucie de la vitesse
Toutes les applications de menu ne ralentissent pas la boutique. La question est de savoir si l’application a été conçue avec la vitesse en tête : un JavaScript épuré, pas de blocage du rendu, peu de requêtes inutiles, et de l’espace réservé pour le menu afin qu’il ne décale pas la mise en page.
C’est notre priorité absolue lorsque nous concevons Navi+. Navi+ crée des menus sans code pour Shopify et pour n’importe quel site web — Tab Bar, Mega Menu, Slide Menu, FAB, Grid Menu — avec des configurations distinctes pour mobile et ordinateur, et il est optimisé pour ne pas plomber vos Core Web Vitals. Vous devriez tout de même mesurer par vous-même à l’aide des étapes ci-dessus, avant et après l’installation ; c’est le moyen le plus fiable de vérifier.
En résumé, l’application de menu fait partie de l’expérience, mais ne la laissez pas ralentir sournoisement toute votre boutique. Quelques minutes passées à lancer PageSpeed Insights et à examiner l’onglet Network vous donneront une réponse claire.
Cet article fait partie du guide plus complet sur la Navigation et vitesse de chargement — Choisir une application de menu qui ne nuit pas aux Core Web Vitals.