Site rapide sur mobile : comment j’ai fait passer le score de 61 à 93

Je conçois des sites rapides, il serait donc normal que le mien le soit aussi. Or la mesure dans Google PageSpeed Insights affichait 61 à 70 points sur téléphone, et le contenu principal n’apparaissait qu’au bout de 5,8 secondes. Sur ordinateur, tout allait bien, mais la plupart des gens visitent les sites depuis leur téléphone.

Je décris ci-dessous ce qui ralentissait précisément le site et comment je l’ai corrigé. Les problèmes que j’ai trouvés se retrouvent sur un très grand nombre de sites d’entreprise, y compris ceux construits sur WordPress.

Résultat : avant et après

Sur ordinateur, le site obtient désormais 100 points. Le tout sans supprimer les animations et sans renoncer à l’éditeur interactif en haut de la page.

Étape 0 : mesurer avant de corriger

PageSpeed Insights simule un téléphone de milieu de gamme avec une connexion mobile lente. C’est une bonne approximation, mais le nombre de points seul dit peu de chose. La question clé est : quel élément Google considère-t-il comme le contenu principal, et pourquoi apparaît-il si tard ?

La réponse m’a surpris. Google ne mesurait pas le titre de la page, mais la photo de la démonstration de l’éditeur, qui s’affichait au bout d’environ 6 secondes. Le fichier se téléchargeait instantanément, mais l’animation de construction du site ne le dévoilait qu’après un certain temps. Sans mesure détaillée, j’aurais cherché le problème à un tout autre endroit.

1. L’animation qui retardait le contenu principal

Pour Google, le contenu principal (LCP) est le plus grand élément visible à l’écran. Si quelque chose de grand apparaît tard, ne serait-ce que dans le cadre d’une animation spectaculaire, le score entier chute.

Sur mon site, deux choses y contribuaient :

• La démo de construction du site démarrait trop tôt. Sur téléphone, elle commençait alors que 75 % de l’éditeur se trouvait encore sous l’écran. Elle démarre désormais lorsque l’éditeur arrive à peu près à mi-hauteur de l’écran. C’est mieux aussi pour le visiteur, qui voit toute la construction et pas seulement sa fin.
• Pour Google, le titre était composé de plusieurs petits morceaux. Chaque ligne du titre était un bloc distinct, et l’animation le découpait en outre mot par mot. Pour Google, cela faisait une douzaine de petits éléments au lieu d’un seul grand. Depuis la modification, le titre est un seul bloc de texte et compte dès le premier instant.

J’ai aussi déplacé l’animation d’entrée de JavaScript vers CSS. Auparavant, le contenu apparaissait, disparaissait au chargement des scripts, puis réapparaissait en glissant. Maintenant, l’animation démarre avec le premier affichage de la page, et le titre passe du flou au net au lieu d’apparaître en fondu.

2. Les décalages au chargement des polices

Le site utilise deux polices : la police sans empattement Geist et l’italique décorative Cormorant. Tant qu’elles ne sont pas téléchargées, le navigateur affiche le texte dans une police de remplacement, par exemple Arial. L’italique de remplacement était 17 % plus large que la vraie, si bien que le titre se coupait différemment et que, au changement de police, tout le contenu en dessous sautait.

La solution : des polices de remplacement aux dimensions ajustées. Le CSS permet de redimensionner Arial et Times New Roman pour qu’ils occupent exactement la même place que les vraies polices (propriétés size-adjust, ascent-override et descent-override). J’ai mesuré les deux polices, et l’écart de largeur est passé de 17 % à 2 %. Le décalage de mise en page est tombé à zéro.

3. Trop de fichiers bloquant l’affichage

Avant d’afficher quoi que ce soit, le navigateur doit télécharger toutes les feuilles de style de l’en-tête de la page. J’en avais cinq : les styles du site, les polices, deux jeux d’icônes et les styles du défilement fluide. Sur une connexion lente, chaque fichier représente un retard supplémentaire.

Corrections :

• Un seul fichier CSS au lieu de cinq. La fusion se fait automatiquement à la publication du site, et dans le code source les fichiers restent séparés.
• Des scripts avec l’attribut defer. Ils se téléchargent en parallèle et s’exécutent dans le même ordre, mais ne retardent pas le premier affichage.
• Les styles du chat chargés en arrière-plan. Le bouton du chat n’apparaît de toute façon qu’une fois les scripts chargés.

4. Icônes : 1 500 dans le fichier, 135 utilisées

Les icônes du site proviennent de la bibliothèque Phosphor, chargée sous forme de police. Les fichiers complets contenaient environ 1 500 icônes et pesaient 280 Ko au total. J’en utilise 135.

À la publication, le site repère lui-même les icônes utilisées et réduit à celles-ci les fichiers de styles et de polices. Il reste 28 Ko, soit dix fois moins. Les icônes ont le même aspect, et si j’en ajoute une nouvelle, elle sera intégrée automatiquement au fichier lors de la publication suivante.

5. Photos : la bonne taille et le bon format

C’est le problème le plus courant des sites d’entreprise, et chez moi aussi le plus important :

• Les photos des cartes faisaient 1 440 px de large, alors qu’elles s’affichaient dans des cadres de 285 à 557 px. Les cartes reçoivent désormais des versions WebP de 800 px de large. Les grandes cartes peuvent toujours charger la photo complète grâce à l’attribut srcset lorsque l’écran est en haute résolution. Les photos de réalisations seules sont passées de 2,9 Mo à 0,9 Mo.
• Le chargement différé ne fonctionne pas toujours. Les photos avaient loading="lazy", mais le navigateur les téléchargeait quand même tout de suite. Lors de la première mise en page, avant que les scripts aient construit les sections situées plus haut, elles se trouvaient près du début de la page. La solution a été de réduire les fichiers et de contrôler délibérément ce qui se charge et quand.
• La démo téléchargeait d’avance les photos de cinq secteurs. Elle télécharge maintenant celles du secteur en cours juste avant la construction, et les autres seulement lorsque la présentation passe réellement d’un secteur à l’autre. Économie : environ 1,6 Mo à chaque visite.

Bonus : la page défilait toute seule au rechargement

Au passage, un défaut mineur mais agaçant est apparu : après un rechargement, la page s’ouvrait légèrement défilée vers le bas. Le navigateur mémorise la position de défilement par rapport à un élément précis. Chez moi, les scripts construisent la moitié de la page après le chargement ; cet élément se retrouvait donc plus bas et la page sautait de 80 à 180 px.

Désormais, un rechargement repart toujours du haut, et le bouton « Retour » ramène exactement au même endroit, car le site mémorise lui-même la position.

Ce que cela signifie pour votre site

Sur les sites d’entreprise que j’analyse, les mêmes causes reviennent le plus souvent :

1. Des photos directement issues de l’appareil photo ou d’une banque d’images, de plusieurs mégaoctets, au lieu de fichiers adaptés à leur place dans la page.
2. Un diaporama ou une vidéo en haut de la page, qui apparaît avec retard et devient le contenu principal aux yeux de Google.
3. Un thème lourd et une douzaine d’extensions, dont chacune ajoute ses propres styles et scripts sur chaque page.
4. Plusieurs familles de polices sans remplacements ajustés, ce qui fait sauter le texte.
5. L’absence de mesure. Sans vérifier quel élément est le contenu principal, il est facile de corriger autre chose que ce qu’il faut.

La vérification prend une demi-minute : saisissez l’adresse dans l’outil Analyser votre site, et vous obtenez le score de vitesse de Google accompagné d’une liste de causes précises.

Combien coûte l’accélération d’un site

Je réalise les petites corrections, comme la compression des photos, le ménage dans les extensions et les réglages du serveur, dans le cadre de la maintenance technique à partir de 149 PLN par mois. Lorsque le site repose sur un thème lourd et que les corrections coûteraient plus cher qu’une nouvelle version, la refonte de site coûte à partir de 2 900 PLN. Tous les prix sont HT.

Examinons votre site

Analysez votre site gratuitement et envoyez-moi le rapport depuis la page de résultat, ou écrivez-moi via le formulaire. Je vous répondrai sous 24 heures sur ce qui ralentit le site et sur le coût de la correction. Les nouveaux clients bénéficient de 20 % de remise sur la première commande.