Table des matières
Définition du Largest Contentful Paint (LCP)
Le concept de Largest Contentful Paint, ou LCP, fait partie des critères de performance mesurés par Google PageSpeed. Ces critères sont connus sous le nom de Core Web Vitals.
On peut traduire Largest Contentful Paint en français : plus grand contenu affiché.
Le LCP mesure précisément le temps qui s’écoule entre le début du chargement de la page, et l’affichage de son plus grand contenu affiché. Ce contenu peut-être une image, un texte ou autre.
Le LCP est donc un peu l’inverse du First Contentful Paint, ou FCP. Ce FCP désigne, lui, l’affichage du premier contenu chargé.
L’enjeu du LCP consiste à ne pas faire attendre l’internaute pendant que ce plus grand contenu se charge.
Pour vous, l’enjeu du LCP consiste aussi à ne pas perdre en route ce visiteur, client potentiel. Les gens sont peu patients et quittent un site qui tarde à charger.
De plus, les Core Web Vitals sont probablement un facteur de classement sur Google. Les pages lentes sont donc privées par Google d’une partie de leur trafic potentiel.
Une bonne raison de s’occuper de ce problème. Donc, il faut optimiser le LCP !
Google lui-même nous fixe l’objectif : un bon LCP est inférieur à 2,5 secondes :
Si vous ne vous sentez pas capable d’optimiser votre site, parce que tout cela est complexe et ennuyeux, je peux le faire pour vous :
Service d’optimisation des performances
Le problème du LCP
L’analyse d’une page web sur PageSpeed Insights montre par exemple ce gros problème de Largest Contentful Paint :
Sur cette page web, le LCP est tout un bloc de code HTML. Il s’agit d’un slider fait avec Elementor, qui fait automatiquement défiler plusieurs photos.
L’énorme LCP s’explique donc ainsi :
- pour fonctionner, ce slider doit d’abord charger une masse de CSS et de JS
- il doit aussi charger chaque image
- et pire, ces images sont 5 fois plus grandes que la taille affichée, servies dans un format non-optimal, et non-compressées
La superposition de ces problèmes aboutit à un LCP énorme. 11 130 millisecondes, soit 11 secondes.
Une analyse superficielle du problème de LCP conduirait à une fausse conclusion. On se dirait : éliminons ce slider et tout ira mieux. Mais non.
De manière moins flagrante, le souci de LCP s’explique aussi probablement par d’autres facteurs :
- les images ne sont pas servies depuis un CDN, mais depuis le serveur d’origine. Ce serveur sature parce qu’il a une trop longue liste de tâches à traiter
- le site n’utilise pas de cache objet
- le site semble ne pas utiliser de cache tout court
- PHP n’est pas forcément bien configuré
- le site WordPress charge peut-être beaucoup d’options inutiles
- …
Voici maintenant des solutions pour améliorer votre LCP.
Solutions pour optimiser le LCP
L’affichage du « plus grand contenu affiché » est déterminé par plusieurs facteurs. C’est pourquoi l’optimisation du LCP ne peut se faire que par une série d’optimisations.
A problème complexe, solutions complexes !
Optimiser les images
Si le LCP sur vos pages concerne souvent des images, alors une solution globale sera d’optimiser les images.
Je recommande d’utiliser un service comme ShortPixel, que j’utilise sur tous mes sites. Ou, un service équivalent.
- remplace les vieux formats non-optimisés JPG et PNG par un format plus moderne et compressé, WEBP ou AVIF. La même image devient ainsi souvent 50 à 90% moins lourde.
- peut servir les images depuis un CDN. Cela décharge beaucoup le serveur d’origine, qui n’a pas à s’en occuper. Deux listes de tâches sont accomplies par 2 serveurs en simultané. On gagne donc en vitesse de chargement.
Lazy-loader les fichiers, reporter en defer et async
Lazy-load signifie chargement paresseux. Cela consiste à ne charger les ressources que quand on en a vraiment besoin.
Le fonctionnement standard, non-opti, d’un site, est le suivant :
- le HTML ordonne le chargement de dizaines de fichiers qui constituent la page
- et ce, sans souci aucun de la chronologie d’utilisation de ces fichiers
Par exemple, je pourrais avoir une image d’1 Mo (énorme, donc) en pied de page : pour afficher les éléments du premier écran, il faudrait que le navigateur attende d’avoir reçu tous les fichiers. C’est évidemment assez bête. ça flingue le LCP.
Donc, la solution est de lazy-loader et reporter le chargement de tout ce qui peut l’être :
- les images qui ne sont pas affichées dès le premier écran
- les fichiers CSS et JS qui ne déterminent pas l’affichage du premier écran
Par exemple, si vous avez un plugin de vente, il est évident qu’on n’a aucun besoin de son code JS dans les 5 premières secondes. Donc, on peut rendre son chargement « defer » ou « async », le reporter, car on sait qu’il ne sera pas utilisé immédiatement. Ce report du chargement des ressources les moins utiles, rend plus rapide le chargement des éléments à afficher tout de suite.
Je gère mon lazy-load avec LiteSpeed. De nombreux thèmes et plugins peuvent aussi permettre d’activer le lazy-load des images et le report du chargement des fichiers JS et CSS.
Attention ! Il ne faut pas mettre n’importe quoi en lazy-load. J’ai vu un site où le logo était défini en lazy-load, c’est absurde. On dit au navigateur de charger plus tard un élément qui a vocation à s’afficher illico ! Lazy-loader un élément LCP n’a aucun sens.
Servir les ressources CSS et JS depuis un CDN
Un CDN, Content Distribution Network, est donc un réseau de distribution de contenus. Ces contenus sont les fichiers de votre site.
Avec un CDN, les fichiers CSS et JS de votre site sont copiés sur un réseau d’autres serveurs.
Chaque fois qu’un internaute dans le monde demande une page de votre site, il se passe ceci :
- votre serveur d’origine traite du code PHP, génère du code HTML
- ce code HTML lui dit d’appeler des fichiers CSS et JS
- le serveur transmet la demande au CDN
- le serveur est donc libre pour s’occuper d’autre chose
- le CDN envoie les fichiers rapidement, car en moyenne il est plus rapide que les serveurs
- le serveur récupère tout et envoie les fichiers au navigateur, qui peut donc faire un rendu de la page plus vite
Un CDN améliore donc substantiellement le LCP à l’échelle de l’ensemble des pages d’un site.
J’utilise le CDN de LiteSpeed, Quick.cloud.
CloudFlare est aussi une excellente solution CDN.
Concaténer et minifier les ressources CSS et JS
Concaténer signifie « faire un gros paquet avec plein de fichiers« . Au lieu d’envoyer 20 fichiers CSS séparément, on les additionne dans un seul gros fichier.
Minifier signifie « supprimer tous les caractères non-nécessaires dans ces fichiers« . Cela donne des fichiers un peu moins lourds.
Cette solution ne s’applique pas toujours, donc il faut réfléchir avant d’agir. Ou, tester et comparer.
La concaténation et la minification des fichiers JS est délicate. Elles cassent souvent des choses, donc je m’en méfie.
La concaténation du CSS n’est une bonne idée que si vos fichiers ne sont pas servis en http/3. Car dans ce cas, les servir individuellement est plus rapide.
De plus, envoyer un gros paquet, suppose de passer du temps à fabriquer ce gros paquet. Pour que ce soit efficace, il faut impérativement utiliser un cache et un CDN.
Sinon, le Largest Contentful Paint augmente, dès lors qu’il dépend du chargement de fichiers CSS et JS.
Eliminer le CSS et le JS superflus
Surtout, ces fichiers CSS et JS sont une plaie de l’optimisation. Sur WordPress, système que j’adore, le moindre plugin va rajouter son CSS et son JS. En général, en masse et à l’aveuglette.
Par exemple, un plugin qui ne concerne que certaines pages va faire charger son CSS et son JS sur toutes les pages. Des plugins très intéressants comme Elementor et WooCommerce, ont ce gros défaut. Il n’est pas rare de voir que 95% du CSS chargé sur une page y est inutilisé.
La solution consiste alors à utiliser un système de « critical CSS« . Perso j’utilise LiteSpeed Cache, combiné avec Quic.cloud, et leur fonctionnalité de CCSS (critical CSS). D’autres services, comme WP Rocket, font la même chose.
Ils analysent chaque page. Et créent un fichier CSS propre à cette page. Ce fichier ne contient que le code CSS réellement utilisé. Obtenant donc une forte réduction de la taille des fichiers CSS. Et donc, une amélioration du LCP.
Améliorer le temps de réponse du serveur
Par définition, si le temps de réponse du serveur est lent, l’affichage de tout contenu sera ralenti. Donc le LCP sera élevé.
Sur WordPress, c’est assez souvent dû aux options. Il s’agit des paramètres de WordPress et de ses plugins. Ces options sont chargées en mémoire depuis la table wp_options de la base de données. Or, souvent, on n’a aucun besoin de charger ces options automatiquement. La solution consiste donc à désactiver l’autoload des plus grosses options non-nécessaires.
J’ai traité ce problème dans un article : Nettoyer les options avec SweepPress.
Un temps de réponse du serveur lent peut aussi s’expliquer par l’absence de cache.
Installer un cache
Un cache fera baisser votre LCP. Son rôle consiste à garder une copie de toute ressource qui a été chargée récemment. Par exemple, si un internaute a demandé votre page d’accueil, la page a été créée en HTML par un code PHP, et ce HTML a appelé des fichiers CSS et JS. Si on garde tout en cache, c’est comme si on conservait un clone d’une pizza déjà cuite, au lieu de repartir de zéro.
Avec un cache, tous les fichiers demandés récemment sont prêts à être servis. Quand PageSpeed vient mesurer la vitesse d’une page présente en cache, ses fichiers lui sont servis plus vite et la note LCP est donc bien meilleure. (Cela améliore aussi le FCP, le Speed Index, etc.)
Il existe différents types de cache. Mon préféré est LiteSpeed. Très complexe, mais très puissant. Sinon, il y a WP Total Cache (complexe aussi). Ou, plus simple mais moins puissant : Cache Enabler.
Installer un cache objet
Le cache objet est l’équivalent d’un cache, mais pas pour les fichiers : pour les « objets« . Ces objets sont en fait des bouts de code PHP. Au lieu de relancer les mêmes instructions PHP à chaque chargement de page, on va garder leur résultat en mémoire.
Par exemple, un code PHP pourrait dire :
$site_title = get_bloginfo('name');
Ce code crée une variable, qui s’appelle $site_title. Cette variable va chercher le nom du site dans la base de données.
Ne pas avoir de cache, c’est un peu comme si chaque fois qu’on vous demande votre prénom, vous deviez aller consulter votre carte d’identité pour répondre.
Le cache objet va donc mémoriser plein d’infos nécessaires au chargement du site, en évitant le temps
- à exécuter toujours le même code PHP
- à aller chercher les mêmes données en base de données
Et donc, cela accélère le chargement du Largest Contentful Paint.
Comme cache objet j’utilise :
- Redis Cache, combiné avec LiteSpeed (qui pourrait aussi utiliser Memcached)
- ou ACPu Manager
Activer la compression Gzip ou Brotli
Gzip et Brotli sont deux algorithmes de compression des fichiers. Ils opèrent au niveau du serveur. Ils sont devenus assez ordinaires, mais pas toujours activés par défaut sur les serveurs.
Vous pouvez savoir si vos fichiers sont servis compressés, en utilisant l’inspecteur de votre navigateur, puis en allant voir les headers de vos fichiers.
Si Gzip ou Brotli ne sont pas activés, activez-les dans les options PHP. Si vous avez le choix, préférez Brotli, plus efficace.
Sur un serveur O2Switch, Gzip est activé par défaut.
Le CDN de LiteSpeed active Brotli par défaut.
Mettre à jour PHP
PHP, c’est le langage qui fait tourner WordPress et beaucoup d’autres sites, Wix, Joomla, SquareSpace etc.
Or, PHP gagne en performance, en vitesse, à chaque nouvelle version.
Une optimisation classique, surtout sur des sites gérés par des webmasters amateurs, consiste à mettre à jour PHP. Et à ajuster ses réglages (mémoire, options diverses).
Améliorer le chargement des polices
Si le Largest Contenful Paint concerne un texte, alors son affichage peut-être retardé par le chargement du fichier de la police de caractères.
En effet, si vous dites au navigateur : « Le nom de mon site s’affiche dans une police funky hébergée sur un serveur lent », il mettr longtemps à récupérer le fichier et afficher ce nom.
La solution : hébergez la police en local, pour ne pas dépendre d’un serveur externe. Un cache s’occupera de garder cette police en mémoire à chaque chargement.
Même avec une police locale, il faut le temps qu’elle se charge.
Un réglage permet d’afficher le texte dans une police qu’a déjà le navigateur, sans attendre que la bonne police se charge :
font-display: optional;
On peut préférer l’instruction
font-display: swap;
mais elle a l’inconvénient de créer du CLS, Content layout Shift, un décalage dans la mise en page.
L’optimisation, un processus continu
Faites tout cela, ou rien que la moitié, et vous aurez déjà considérablement amélioré votre LCP.
Au passage, vous aurez aussi gagné en First Contentful Paint et en Speed Index, et votre note globale de performances Core Web Vitals aura monté. Vos pages seront plus rapides. L’expérience utilisateur de votre public sera meilleure.
L’optimisation est un processus complexe, graduel et continu. Tout changement peut avoir des effets secondaires, en bien comme en mal. Un nouveau plugin activé va ajouter du CSS et du JS, des options, donc du temps. On doit donc optimiser touche par touche, et surveiller la qualité des performances.
Si vous vous attaquez seul à ce problème sans avoir le bagage technique requis, vous risquez fort de ne pas y arriver. Besoin d’aide ? Contactez-moi !
Service d’optimisation des performances
