Pourquoi mon site Webflow est-il lent ?

Les conseils sur ce sujet ne sont pas faux, ils sont seulement sans direction. Compressez vos images, limitez vos polices, minifiez votre code, auditez vos interactions : tout est vrai, tout mérite d'être fait, et rien ne vous dit lequel vous coûte les deux secondes que vous voulez récupérer. Le travail de performance est un diagnostic avant un traitement, et le diagnostic prend une dizaine de minutes. Voici cet ordre des opérations, et ce que chaque résultat désigne réellement.

Par où faut-il commencer à chercher ?

Par une mesure de la page dont les gens se plaignent réellement, sur l'appareil concerné, plutôt que par une checklist. Un rapport de performance vous donne trois choses distinctes que l'on regroupe souvent sous le mot lenteur : le temps d'apparition du contenu principal, le temps de réaction à un appui, et l'ampleur des déplacements de la mise en page pendant le chargement. Elles ont des causes et des correctifs différents, et les confondre explique pourquoi le travail de vitesse ne produit souvent aucune amélioration ressentie. Déterminez laquelle des trois est mauvaise avant de toucher à quoi que ce soit.

Parce que le plus gros élément de la plupart des pages est une image, et le navigateur ne peut finir de dessiner avant son arrivée. Le défaut est rarement que le fichier soit non optimisé dans l'absolu : c'est que les dimensions sont fausses pour l'espace. Une photo exportée en quatre mille pixels de large et affichée dans un conteneur de six cents pixels télécharge environ quarante fois plus de données que l'écran ne peut en utiliser, et aucun réglage de compression ne rattrape cela. Corrigez d'abord les dimensions, puis le format, puis la compression. Vérifiez ensuite que l'image visible d'emblée n'est pas en chargement différé, ce qui retarde précisément ce que vous cherchez à accélérer.

Combien vous coûtent les scripts tiers ?

En général plus que prévu, car ils s'accumulent par addition et ne sont jamais soustraits. Un widget de chat, une balise d'analyse, un outil de heatmap, un module de réservation, deux pixels publicitaires et un carrousel d'avis sont arrivés chacun pour une bonne raison, d'une personne différente, sur deux ans. Personne n'en a jamais retiré un. Chacun apporte son JavaScript, souvent chargé depuis un autre serveur, et plusieurs bloquent la page pendant la négociation. Ouvrez le panneau réseau et listez ce qui se charge vraiment. L'exercice est inconfortable précisément parce que la plupart des équipes ne savent pas à quoi sert la moitié, et c'est là le constat, pas un effet secondaire.

Pourquoi ma page saute-t-elle pendant le chargement ?

Parce que quelque chose arrive tard et occupe une place qui ne lui était pas réservée, poussant vers le bas tout ce qui suit. Les coupables habituels sont les images sans dimensions déclarées, les embeds et iframes qui se dimensionnent après chargement, les polices personnalisées qui remplacent la police de repli avec d'autres métriques, et tout ce qu'un script injecte au-dessus de la ligne de flottaison. Cela mérite d'être corrigé tôt car c'est le moins cher des trois problèmes et le plus irritant pour un lecteur qui vient de toucher un lien qui a bougé. C'est aussi indépendant de la vitesse : une page rapide peut sauter, une page lente peut être parfaitement stable.

Les interactions Webflow le ralentissent-elles ?

Parfois, et moins souvent qu'on ne les accuse. Les interactions ajoutent du JavaScript à la page et un grand nombre sur une même page a un coût réel, mais quelques effets de défilement et de survol sont rarement ce qui freine un site dont la page charge par ailleurs une image d'en-tête non compressée et six balises tierces. Là où les interactions nuisent vraiment, c'est quand elles animent des propriétés forçant le navigateur à recalculer la mise en page à chaque image, ou quand elles s'appliquent à des éléments contenant du texte, ce qui peut laisser la typographie floue. Vérifiez-les après les images et les scripts, pas avant.

Le CMS ralentit-il le site ?

Pas de la façon supposée, car Webflow sert les pages publiées comme des fichiers statiques plutôt qu'en les assemblant à chaque requête. Ce qui peut ralentir une page, c'est la quantité demandée à la collection : une liste affichant cent éléments avec une image chacun, plusieurs listes imbriquées sur une page, ou une vue filtrée qui charge tout puis en masque l'essentiel dans le navigateur. Le correctif consiste en général à afficher moins d'éléments et à paginer, plutôt qu'à changer de plateforme. Si une page de listing est lente et une page statique du même site rapide, c'est le modèle de contenu qu'il faut regarder.

Quelle vitesse est suffisante ?

Assez rapide pour qu'une personne sur un téléphone milieu de gamme en connexion mobile ne décide pas de partir, ce qui n'est pas la même cible qu'un score parfait dans un outil de test. Courir après les derniers points revient souvent à retirer des choses dont le site a besoin, et un test en laboratoire sur connexion rapide vous en dit moins que les données de terrain issues de vraies visites. Fixez la cible d'après la façon dont votre public arrive vraiment : une clinique dont les visiteurs cherchent depuis une salle d'attente a une exigence plus stricte qu'une entreprise dont les acheteurs naviguent depuis un bureau. Optimisez jusqu'à ce que la page paraisse immédiate sur le pire appareil que vous trouviez, puis arrêtez.