Guide PageSpeed : corriger les problèmes de performance de votre site WordPress

Quand on cherche à améliorer la vitesse de son site WordPress, l’un des premiers réflexes est d’utiliser Google PageSpeed Insights. C’est un outil gratuit, rapide, et très connu. Il donne un score de performance et une liste de recommandations techniques. Mais encore faut-il savoir l’interpréter.

Entre les sigles (LCP, CLS, TBT…), les conseils parfois contradictoires, et les résultats qui changent d’un test à l’autre, il est facile de se perdre ou de tirer de mauvaises conclusions.

Dans cet article, vous trouverez :

• une explication claire de ce que mesure réellement PageSpeed,
• comment fonctionne le score,
• et surtout, comment comprendre et corriger les recommandations qui ont un impact direct sur la vitesse réelle de votre site.

L’objectif n’est pas de viser un 100/100 parfait, mais un site rapide, fluide et fiable, aussi bien sur ordinateur que sur mobile.

Comprendre Google PageSpeed Insights (et comment s’en servir)

PageSpeed Insights est un excellent point de départ pour améliorer les performances de votre site, mais il peut facilement prêter à confusion. Entre les scores, les métriques techniques et les recommandations parfois trop génériques, il est essentiel de comprendre ce que mesure réellement l’outil, ce qu’il faut en retenir, et comment l’utiliser à bon escient.

À quoi sert PageSpeed, concrètement ?

Le score est une note sur 100, basée sur cinq indicateurs de performance :

• FCP (First Contentful Paint) – 10 %
• LCP (Largest Contentful Paint) – 25 %
• TBT (Total Blocking Time) – 30 %
• CLS (Cumulative Layout Shift) – 25 %
• SI (Speed Index) – 10 %

Chacun mesure une facette différente de l’expérience utilisateur : vitesse d’affichage, stabilité, fluidité…

Pourquoi c’est utile (mais pas suffisant)

PageSpeed est un excellent outil pour détecter les points de friction techniques : fichiers trop lourds, scripts mal gérés, images non optimisées… Il aide à prioriser les actions qui améliorent concrètement la rapidité perçue.

Mais ses recommandations sont génériques. L’outil ne connaît ni votre activité, ni vos visiteurs, ni vos contraintes métier.
Certaines optimisations proposées peuvent être :

• techniquement complexes à mettre en œuvre,
• incompatibles avec des fonctionnalités importantes de votre site,
• ou peu rentables au regard de l’effort nécessaire.

PageSpeed est donc un point de départ, pas un plan d’action tout fait. L’analyse humaine reste indispensable pour faire les bons choix.

Pourquoi les résultats changent à chaque test

Vous avez lancé le même test deux fois et obtenu deux scores différents ? C’est normal. Le score peut varier selon :

• la connexion Internet,
• l’appareil utilisé,
• les scripts chargés dynamiquement (pubs, A/B tests),
• des extensions de navigateur,
• ou même un antivirus actif.

Il ne faut donc pas s’acharner à stabiliser un score. Ce qui compte, c’est la tendance générale, et surtout, le ressenti des vrais utilisateurs.

Est-ce que je dois viser 100/100 ?

Non. Obtenir un score parfait sur PageSpeed peut sembler séduisant, mais ce n’est ni réaliste, ni utile dans la majorité des cas. Atteindre 100/100 implique souvent de supprimer des fonctionnalités, de désactiver des scripts utiles, ou de casser l’équilibre visuel du site.

Ce qu’il faut viser, c’est :

• un site rapide à charger, surtout sur mobile,
• une expérience fluide et stable pour les visiteurs,
• et un score “vert” (au-dessus de 90) sur les indicateurs clés.

Au-delà de ça, il est plus pertinent de se concentrer sur les performances réelles ressenties que sur un chiffre théorique.
PageSpeed est un outil d’aide à la décision, pas une fin en soi.

Est-ce que PageSpeed a un impact direct sur le SEO ?

Pas directement. Le score PageSpeed en lui-même n’est pas utilisé par Google comme critère de classement. En revanche, certains indicateurs mesurés par l’outil — comme le Largest Contentful Paint (LCP) ou le Cumulative Layout Shift (CLS) — font partie des signaux Web Vitals, intégrés à l’algorithme depuis 2021.

Cela signifie qu’un site très lent, instable ou mal optimisé sur mobile peut être pénalisé, notamment si les concurrents directs offrent une meilleure expérience utilisateur.

Cela dit, les performances ne sont qu’un critère parmi d’autres. Le contenu, la pertinence des pages, les liens entrants, l’intention de recherche… restent des facteurs bien plus influents pour le référencement.
Un bon score PageSpeed n’est donc ni une garantie de bon classement, ni une priorité absolue pour tous les sites. Mais c’est un levier utile, surtout quand la concurrence est serrée ou l’audience majoritairement mobile.

Pourquoi mon site est-il rapide sur ordinateur mais pas sur mobile ?

C’est une situation courante. Vous testez votre site sur ordinateur : il est fluide, les pages s’affichent vite.
Mais PageSpeed affiche un score médiocre côté mobile. Pourquoi ?

Par défaut, PageSpeed teste la version mobile du site, avec des conditions strictes : appareil peu puissant, connexion 4G moyenne, écran réduit. Ces contraintes mettent en lumière des problèmes qui ne sont pas visibles sur un ordinateur performant :

• images trop lourdes ou mal redimensionnées,
• animations complexes,
• JavaScript non différé,
• polices mal chargées, etc.

En résumé : votre site peut sembler rapide sur ordinateur, mais être mal adapté aux conditions réelles d’utilisation sur mobile. Et c’est cette expérience mobile que Google considère comme prioritaire.

LCP – Largest Contentful Paint

Le Largest Contentful Paint mesure le moment où le plus gros élément visible (image, vidéo, bloc de texte…) s’affiche à l’écran. C’est un indicateur majeur de la vitesse perçue par l’utilisateur. Si cet élément met trop de temps à apparaître, la page semble lente, même si tout le reste est prêt. Cette section vous aide à identifier et optimiser cet élément clé.

Élément identifié comme « Largest Contentful Paint »

Ce que ça veut dire
C’est l’élément le plus grand (image, bloc de texte ou vidéo) visible sans avoir à faire défiler. Il se trouve au-dessus de la ligne de flottaison, dans la zone affichée automatiquement quand la page s’ouvre. Cet élément sert à mesurer le Largest Contentful Paint (LCP), un des indicateurs majeurs de la vitesse perçue.

Ce qu’il faut faire pour valider ce critère
Repérez l’élément concerné dans PageSpeed. Pour qu’il se charge rapidement :

• évitez le lazy loading sur lui,
• utilisez un format léger (WebP, AVIF),
• compressez-le,
• adaptez sa taille à l’affichage réel,
• et si possible, préchargez-le (<link rel= »preload »>).

Précharger l’image Largest Contentful Paint

Ce que ça veut dire
Le navigateur charge les ressources dans un ordre défini. En préchargeant l’image LCP, vous l’informez que cette image est prioritaire et qu’elle doit être chargée le plus tôt possible. Cela permet d’améliorer significativement le LCP, surtout si l’image est chargée plus tard par du JavaScript.

Ce qu’il faut faire pour valider ce critère
Ajoutez une balise <link rel="preload"> dans le <head> de votre page, avec l’attribut as="image". Exemple :

<link rel="preload" as="image" href="/images/accueil-hero.webp" />

L’image LCP a été chargée de manière différée

Ce que ça veut dire
L’image utilisée pour mesurer le LCP (c’est-à-dire l’image principale visible en haut de la page) a été chargée en lazy loading. Résultat : son chargement a été retardé volontairement par le navigateur, ce qui pénalise le score de performance.

Ce qu’il faut faire pour valider ce critère
Cette image ne doit pas avoir l’attribut loading="lazy". Elle doit être chargée immédiatement, sans attendre que l’utilisateur fasse défiler la page.
Sur WordPress, cela peut nécessiter de :

• désactiver le lazy loading sur cette image spécifique (dans le code ou via un filtre),
• s’assurer que votre thème ou votre constructeur ne l’ajoute pas automatiquement,
• vérifier les réglages du plugin d’optimisation si vous en utilisez un.

En résumé : lazy loading pour les images en bas de page, pas pour celle du haut.

Dimensionnez correctement les images

Ce que ça veut dire
Une image trop grande affichée dans une petite zone oblige le navigateur à la redimensionner, ce qui ralentit inutilement le chargement. Par exemple : si une image fait 2000 px de large mais s’affiche en 400 px sur l’écran, vous gaspillez de la bande passante et du temps de rendu.

Ce qu’il faut faire pour valider ce critère
Assurez-vous que chaque image est à la bonne taille pour son affichage réel, en fonction du design et du type d’écran :

• utilisez des tailles d’image adaptées (responsive, avec les bons srcset et sizes),
• évitez de charger une image HD inutilement si elle s’affiche en petit,
• compressez et recadrez les visuels avant de les importer dans WordPress,
• si possible, servez des images différentes selon les tailles d’écran (mobile vs desktop).

L’objectif : ne jamais charger plus que ce qui est nécessaire.

Diffusez des images aux formats nouvelle génération

Ce que ça veut dire
Les formats traditionnels comme JPEG ou PNG sont plus lourds que les formats modernes comme WebP ou AVIF. Ces nouveaux formats permettent de réduire considérablement le poids des images, sans perte visible de qualité, ce qui accélère le chargement.

Ce qu’il faut faire pour valider ce critère
Convertissez vos images en WebP (compatible avec tous les navigateurs récents) ou en AVIF (encore plus léger, mais support partiel).

Sur WordPress, plusieurs options :

• utilisez un plugin d’optimisation d’images qui gère la conversion automatique (ex : Imagify, EWWW, ShortPixel),
• ou convertissez vos images manuellement avant l’import, si vous gérez un volume limité.

L’important est de servir automatiquement le bon format selon le navigateur, sans casser la compatibilité. WebP est aujourd’hui un minimum recommandé.

Encodez les images de manière efficace

Ce que ça veut dire
Une image peut être affichée correctement, mais rester inutilement lourde si elle n’est pas compressée. L’encodage fait référence à la façon dont l’image est optimisée en poids, tout en gardant une qualité visuelle acceptable. Une image mal compressée = chargement plus lent.

Ce qu’il faut faire pour valider ce critère
Compressez toutes vos images avant ou pendant l’import dans WordPress. Les solutions possibles :

• utiliser un plugin d’optimisation comme Imagify, ShortPixel, EWWW,
• ou compresser les images manuellement avec des outils en ligne (TinyPNG, Squoosh…).

L’objectif est simple : réduire le poids au maximum sans que cela ne se voie. Sur le web, 100 Ko bien optimisés valent mieux que 800 Ko “par défaut”.

Réduisez le temps de réponse initial du serveur

Ce que ça veut dire
C’est le temps que met le serveur à commencer à répondre après une requête. Si ce délai dépasse 600 ms, Google considère qu’il ralentit le chargement global de la page. Cela peut être dû à un hébergement lent, une base de données surchargée, ou un site mal optimisé côté back-end.

Ce qu’il faut faire pour valider ce critère
Optimisez les éléments qui influencent directement ce temps de réponse :

• choisissez un hébergement rapide, adapté à WordPress (avec cache serveur),
• activez un plugin de cache (full page et object cache si possible),
• réduisez les requêtes en base de données (nettoyage, suppression de plugins inutiles),
• mettez à jour PHP à une version performante (8.1+ recommandé),
• évitez les thèmes et plugins lourds côté serveur.

Un serveur lent plombe la performance dès le départ, quel que soit le reste de l’optimisation.

Activez la compression de texte

Ce que ça veut dire
Les fichiers texte comme le HTML, le CSS ou le JavaScript peuvent être compressés avant d’être envoyés au navigateur. Cela réduit leur taille pendant le transfert et accélère le chargement de la page. Sans compression, vous envoyez parfois deux à trois fois plus de données que nécessaire.

Ce qu’il faut faire pour valider ce critère
Activez la compression Gzip ou Brotli côté serveur. Voici comment faire selon votre configuration :

• si vous utilisez un plugin de cache (WP Rocket, LiteSpeed Cache, etc.), l’option est souvent activée par défaut,
• sur un serveur Apache ou Nginx, cela se configure via le .htaccess ou les fichiers de conf serveur,
• la plupart des hébergeurs sérieux la proposent par défaut — sinon, c’est un point à exiger.

Brotli est plus efficace que Gzip, mais les deux sont valables. Vérifiez que la compression est bien en place avec un outil comme https://www.giftofspeed.com/gzip-test/.

FCP – First Contentful Paint

Le First Contentful Paint mesure le temps nécessaire pour afficher le tout premier contenu visible (texte, logo, image…). C’est le moment où l’utilisateur commence à percevoir que la page répond. Si ce délai est trop long, la sensation de lenteur s’installe immédiatement. Cette section vous aide à optimiser ce point clé du ressenti utilisateur.

Éliminez les ressources qui bloquent le rendu

Ce que ça veut dire
Certaines ressources, comme les fichiers CSS ou JavaScript, empêchent le navigateur d’afficher la page tant qu’elles ne sont pas chargées. Résultat : l’utilisateur voit une page vide plus longtemps, même si le contenu est prêt. Ces ressources sont dites “bloquantes”.

Ce qu’il faut faire pour valider ce critère
L’objectif est de permettre au navigateur de commencer l’affichage sans attendre ces fichiers :

• identifiez le CSS critique (celui utilisé au-dessus de la ligne de flottaison) et intégrez-le directement dans le <head>,
• chargez le reste du CSS en différé (media="print" avec retour à all, ou via JavaScript),
• ajoutez defer ou async aux scripts JavaScript non essentiels,
• évitez les plugins WordPress qui chargent beaucoup de scripts inutiles sur toutes les pages.

La priorité : permettre à la page d’apparaître le plus tôt possible, même si tout n’est pas encore chargé.

Réduisez la taille des ressources CSS / JavaScript

Ce que ça veut dire
Les fichiers CSS et JavaScript peuvent contenir des espaces, des commentaires, ou du code non utilisé. Plus ces fichiers sont lourds, plus ils prennent de temps à se télécharger et à s’exécuter. Google recommande de réduire leur taille pour accélérer le chargement.

Ce qu’il faut faire pour valider ce critère

• Minifiez vos fichiers CSS et JS : supprimez tout ce qui est inutile (espaces, retours à la ligne, commentaires). La plupart des plugins de cache WordPress proposent cette option.
• Combinez les fichiers si c’est pertinent (mais attention aux conflits).
• Vérifiez que vous ne chargez pas de fichiers inutiles sur certaines pages (ex. : un script de formulaire chargé sur toutes les pages alors qu’il ne sert qu’en contact).
• Évitez les thèmes ou constructeurs qui injectent du code globalement, même là où il n’est pas utilisé.

Moins de code = moins de poids = un site plus rapide.

Réduisez les ressources CSS / JS inutilisées

Ce que ça veut dire
Beaucoup de thèmes, plugins ou constructeurs chargent des fichiers CSS ou JavaScript même si leur contenu n’est pas utilisé sur la page affichée. Par exemple : un plugin de formulaire peut charger son style sur toutes les pages, alors qu’il n’est utilisé qu’en page contact.

Ce qu’il faut faire pour valider ce critère

• Identifiez les fichiers inutiles avec un outil comme Asset CleanUp ou Perfmatters.
• Désactivez les scripts et styles qui ne servent pas sur certaines pages.
• Remplacez les plugins trop lourds ou mal optimisés par des alternatives plus ciblées.
• Si vous développez un thème sur mesure, ne chargez que les fichiers nécessaires à chaque template.

L’idée : chaque page ne doit charger que ce qu’elle utilise vraiment. Le reste doit être retiré ou différé.

Utilisez des formats vidéo pour le contenu animé

Ce que ça veut dire
Les GIF animés sont très lourds et inefficaces. Ils utilisent un ancien format peu compressé, ce qui ralentit fortement le chargement de la page. Google recommande de les remplacer par des vidéos courtes, qui sont beaucoup plus légères à qualité équivalente.

Ce qu’il faut faire pour valider ce critère

• Convertissez les GIF animés en vidéos au format MP4 ou WebM, selon la compatibilité visée.
• Intégrez-les via la balise <video> en autoplay, en boucle et sans son si besoin.
• Servez-les avec les bons attributs (playsinline, muted, autoplay, loop) pour une expérience fluide.
• Évitez de les charger en fond ou en haut de page si ce n’est pas nécessaire.

Résultat : un rendu plus fluide, un poids réduit, et une performance bien meilleure.

Supprimez les modules en double dans les groupes JavaScript

Ce que ça veut dire
Certains plugins ou thèmes chargent plusieurs fois les mêmes bibliothèques JavaScript (comme jQuery, Swiper, etc.). Ces doublons augmentent le poids de la page et ralentissent l’exécution du code, sans aucun bénéfice.

Ce qu’il faut faire pour valider ce critère

• Inspectez les fichiers JS chargés avec l’onglet “Réseau” (Network) de votre navigateur ou avec des outils comme PageSpeed ou GTmetrix.
• Identifiez les doublons : mêmes fichiers ou mêmes fonctions chargés plusieurs fois.
• Supprimez les plugins redondants ou configurez-les pour ne pas charger automatiquement leur script si un autre plugin le fait déjà.
• En développement sur mesure, assurez-vous de ne pas enregistrer deux fois la même ressource dans functions.php.

Moins de doublons = exécution plus rapide, page plus légère.

CLS – Cumulative Layout Shift

Le CLS mesure les décalages visuels qui se produisent pendant le chargement de la page : images qui repoussent du texte, boutons qui changent de place, polices qui modifient la mise en page… Ces micro-sauts nuisent à l’expérience utilisateur. Cette section vous montre comment les éviter pour offrir un affichage stable dès les premières secondes.

Éviter les changements de mise en page importants

Ce que ça veut dire
Quand des éléments apparaissent ou se chargent sans que leur emplacement soit prévu, la page “saute” pendant le chargement. Ces décalages sont gênants pour l’utilisateur et dégradent le Cumulative Layout Shift (CLS).

Ce qu’il faut faire pour valider ce critère

• Réservez toujours de l’espace pour les contenus dynamiques (images, iframes, bannières, boutons, etc.).
• Définissez des dimensions fixes (largeur et hauteur) pour les images et les vidéos.
• Évitez de charger des blocs (ex : pubs, messages cookies, widgets) sans espace préalloué.
• Chargez les polices correctement pour éviter les “sauts” de texte (voir font-display: swap).

En gros : si un élément est censé s’afficher, le navigateur doit savoir où il va apparaître dès le début. Pas de surprises visuelles pour l’utilisateur.

Les éléments d’image possèdent une width et height explicites

Ce que ça veut dire
Quand une image n’a pas d’attributs width et height, le navigateur ne sait pas quelle place lui réserver à l’avance. Résultat : la page peut “sauter” une fois l’image chargée, ce qui nuit à la stabilité visuelle et au score CLS.

Ce qu’il faut faire pour valider ce critère

• Ajoutez toujours les attributs width et height aux balises <img>, même si vous utilisez des tailles responsives.
• Sur WordPress, cela se règle en amont :
  • vérifiez que vos thèmes et constructeurs respectent cette règle,
  • évitez les shortcodes ou blocs personnalisés qui insèrent des images sans dimensions.

Ces attributs permettent au navigateur de réserver la place pour l’image, évitant tout décalage pendant le chargement. C’est un petit détail technique qui a un vrai impact sur l’expérience utilisateur.

La totalité du texte reste visible pendant le chargement des polices Web

Ce que ça veut dire
Par défaut, certains navigateurs attendent que la police personnalisée soit chargée avant d’afficher le texte. Cela provoque un “flash” de page vide (ou invisible), appelé FOIT (Flash of Invisible Text), ce qui ralentit la lecture et nuit à l’expérience utilisateur.

Ce qu’il faut faire pour valider ce critère
Utilisez font-display: swap dans vos fichiers de polices (via CSS ou les options du thème). Cela indique au navigateur d’afficher d’abord une police système temporaire, puis de la remplacer une fois la vraie police chargée.

Sur WordPress, vous pouvez :

• héberger les polices localement et gérer le CSS vous-même,
• ou utiliser un plugin qui gère automatiquement le font-display: swap (comme OMGF ou certaines options de cache).

Objectif : ne jamais bloquer l’affichage du texte à cause d’une police. Le contenu doit être lisible immédiatement.

SI – Speed Index

Le Speed Index mesure la vitesse à laquelle les éléments visibles de la page s’affichent progressivement. Un mauvais score signifie que la page met trop de temps à “se remplir”, même si elle finit par charger. Cette section vous aide à optimiser le rendu visuel dans son ensemble, pas seulement les premiers éléments.

Éviter d’énormes charges utiles de réseau

Ce que ça veut dire
Si votre page pèse trop lourd (plusieurs mégaoctets), elle sera plus lente à charger, surtout sur mobile ou avec une connexion moyenne. PageSpeed recommande de garder la taille totale de la page aussi légère que possible, y compris images, scripts, polices, etc.

Ce qu’il faut faire pour valider ce critère

• Compressez les images et utilisez des formats modernes (WebP, AVIF).
• Supprimez les plugins ou scripts inutiles qui alourdissent le site.
• Évitez d’intégrer des fichiers volumineux (vidéos, animations, carrousels non optimisés).
• Activez la minification CSS/JS, la compression serveur (Gzip/Brotli), et la mise en cache.
• Servez des ressources adaptées à chaque type d’écran : inutile de charger du 4K sur mobile.

Chaque kilo-octet compte. Un site léger est un site rapide.

Éviter une taille excessive de DOM

Ce que ça veut dire

Le DOM (Document Object Model) correspond à la structure HTML de la page. Quand il est trop complexe — avec trop de balises, trop de niveaux imbriqués, ou trop d’éléments inutiles — cela ralentit le navigateur, surtout sur mobile. PageSpeed recommande de garder un DOM simple et efficace.

Ce qu’il faut faire pour valider ce critère

• Limitez le nombre total de nœuds HTML (évitez les pages avec des centaines d’éléments inutiles).
• Réduisez les niveaux d’imbrication (ex. : <div><div><div><p>…</p></div></div></div> à simplifier).
• Évitez les constructeurs de pages ou thèmes qui génèrent un HTML trop verbeux.
• Supprimez les blocs inutilisés ou dupliqués (ex. : sliders désactivés, sections vides).
• Préférez un code HTML propre et structuré, surtout pour les pages longues ou complexes.

Un DOM allégé améliore la vitesse, mais aussi la stabilité de la page et le rendu sur les navigateurs modestes.

Évitez de créer des chaînes de requêtes critiques

Ce que ça veut dire
Certaines ressources (scripts, styles, polices…) dépendent d’autres fichiers pour se charger. Quand ces fichiers sont chaînés — un fichier A doit être chargé pour lancer B, qui appelle C — cela ralentit le rendu de la page. Plus la chaîne est longue, plus l’affichage est bloqué.

Ce qu’il faut faire pour valider ce critère

• Minimisez les dépendances entre vos fichiers : évitez que plusieurs ressources critiques se chargent les unes après les autres.
• Utilisez preload pour les fichiers vraiment prioritaires (CSS, polices, images LCP…).
• Regroupez les fichiers CSS/JS quand c’est pertinent pour réduire le nombre de requêtes.
• Supprimez les scripts inutiles ou retardez leur exécution (defer, async, ou chargement conditionnel).

L’objectif est simple : permettre au navigateur de tout charger rapidement, en parallèle, sans devoir attendre qu’un fichier ait fini de charger pour en commencer un autre.

Connectez-vous à l’avance aux origines souhaitées

Ce que ça veut dire

Quand votre site charge des ressources depuis des domaines externes (polices Google, scripts tiers, CDN…), le navigateur doit établir une connexion à ces domaines. Cela prend du temps (résolution DNS, handshake SSL…). En préconnectant, vous gagnez du temps en lançant cette étape dès le début.

Ce qu’il faut faire pour valider ce critère

Ajoutez une balise <link rel="preconnect"> dans le <head> de votre page pour chaque domaine externe essentiel. Exemple pour Google Fonts :

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

À noter :

• Utilisez crossorigin si la ressource l’exige (comme les polices),
• Ne préconnectez que les domaines prioritaires : trop de préconnexions peuvent devenir contre-productives.

Préconnecter, c’est anticiper. Et l’anticipation, en performance web, fait toute la différence.

TBT – Total Blocking Time

Le Total Blocking Time (TBT) mesure le temps où le navigateur est occupé à exécuter du code JavaScript, au point de bloquer l’affichage ou les interactions. Trop de scripts, des traitements trop longs ou mal gérés, et votre site devient lent à répondre. Cette section détaille les recommandations PageSpeed qui visent à alléger la charge sur le thread principal et à fluidifier l’expérience utilisateur.

Délai d’exécution de JavaScript

Ce que ça veut dire
PageSpeed mesure combien de temps les scripts JavaScript prennent à s’exécuter. Si ce délai est long, le navigateur reste occupé à traiter le code au lieu d’afficher la page. Résultat : l’utilisateur attend, parfois sans voir de contenu à l’écran.

Ce qu’il faut faire pour valider ce critère

• Identifiez les scripts les plus lourds (Google Tag Manager, sliders, widgets, animations…).
• Supprimez ou remplacez les plugins qui injectent beaucoup de JavaScript inutile.
• Différez l’exécution des scripts non critiques avec defer ou async.

Si vous utilisez un constructeur de page, désactivez les modules inutiles.

Le but est de réduire au minimum le temps que le navigateur passe à “réfléchir” au lieu d’afficher.

Réduire le travail du thread principal

Ce que ça veut dire
Le “thread principal” est le cœur du navigateur. C’est lui qui gère l’affichage, les interactions, le chargement des ressources… S’il est surchargé (par du JS, des calculs ou des traitements lourds), tout le site devient lent ou réagit mal.

Ce qu’il faut faire pour valider ce critère

• Évitez les effets ou animations complexes qui demandent beaucoup de calcul (parallax, carrousels JS lourds, etc.).
• Réduisez le nombre de tâches longues (plus de 50 ms), en optimisant ou en supprimant les scripts concernés.
• Utilisez des animations CSS légères plutôt que des scripts.
• Si nécessaire, répartissez les traitements JS dans des Web Workers (solution avancée).

Un thread principal allégé, c’est une page qui réagit vite, sans blocage ni latence.

Évitez les tâches longues dans le thread principal

Ce que ça veut dire
Une tâche longue, c’est un bloc de code JavaScript qui monopolise le navigateur pendant plus de 50 millisecondes sans s’arrêter. Pendant ce temps, la page ne peut pas réagir : pas d’affichage, pas de clics pris en compte. C’est ce qui crée des sensations de lenteur ou de “gel” de l’interface.

Ce qu’il faut faire pour valider ce critère

• Identifiez les tâches longues avec les outils de développement Chrome (onglet “Performance”) ou PageSpeed.
• Fractionnez les traitements lourds en plusieurs petits morceaux exécutés de façon asynchrone.
• Limitez l’usage de scripts tiers ou d’animations complexes.
• Utilisez des solutions comme requestIdleCallback() ou des Web Workers si vous avez besoin de faire des traitements plus lourds sans bloquer l’affichage.

L’idée : ne jamais laisser le navigateur “coincé” trop longtemps sur un morceau de code. Il doit rester disponible pour afficher, répondre et interagir.

Évitez d’utiliser de l’ancien code JavaScript dans les navigateurs récents

Ce que ça veut dire
Certains scripts chargés sur votre site contiennent du code destiné à d’anciens navigateurs. Ce sont souvent des “polyfills” ou des versions compilées avec des outils comme Babel. Or, les navigateurs modernes n’en ont plus besoin, et ce code devient inutilement lourd et lent à exécuter.

Ce qu’il faut faire pour valider ce critère

• Servez une version moderne (ES6+) du JavaScript aux navigateurs récents, et une version “ancienne” uniquement si nécessaire (stratégie differential serving).
• Si vous utilisez des bibliothèques tierces, assurez-vous qu’elles ne forcent pas une compatibilité inutile (ou utilisez une version plus récente).
• Si vous compilez vous-même du code (via Webpack, Vite, etc.), désactivez les transpileurs pour les navigateurs déjà compatibles.

L’objectif : ne pas charger plus que nécessaire pour les utilisateurs modernes. Moins de code, plus de performance.

Réduire au maximum l’utilisation de code tiers

Ce que ça veut dire
Les scripts tiers (Google Maps, Facebook Pixel, chat, analytics, vidéos intégrées…) sont souvent lourds, bloquants, et échappent à votre contrôle. Plus vous en avez, plus ils ralentissent le chargement, en particulier sur mobile.

Ce qu’il faut faire pour valider ce critère

• Supprimez les scripts tiers non essentiels. Par exemple : ne chargez pas un widget de chat en dehors des heures ouvrées.
• Différez leur chargement (lazy load, déclenchement au clic ou au scroll).
• Regroupez les outils si possible (ex. : utiliser un seul service d’analyse au lieu de deux).
• Intégrez des versions légères ou alternatives si disponibles (par exemple, Maps statique au lieu d’un iframe interactif).

Chaque script externe est un “frein” potentiel. Gardez le strict nécessaire et chargez le reste au bon moment, pas au chargement de la page.

Ressources tierces pouvant être chargées de façon différée avec des façades

Ce que ça veut dire
Certains éléments tiers (comme YouTube, Google Maps, ou les widgets de réseaux sociaux) sont très lourds à charger. Mais souvent, ils ne sont pas utilisés immédiatement. Une façade (ou « placeholder ») permet de remplacer temporairement ces contenus par une image ou un bloc statique, puis de charger le vrai contenu seulement quand l’utilisateur interagit.

Ce qu’il faut faire pour valider ce critère

• Intégrez YouTube, Google Maps, ou d’autres contenus via un système de lazy load avec façade.
• Par exemple, affichez une miniature ou une capture d’écran avec un bouton “Lire” ou “Afficher”, qui déclenche ensuite le chargement du vrai contenu.
• Des plugins comme WP YouTube Lyte, WP Rocket ou Perfmatters permettent de le faire simplement sur WordPress.
• Pour une façade manuelle : utilisez un <div> avec une image ou un SVG, puis remplacez-le dynamiquement au clic avec du JavaScript.

Cette technique réduit fortement le nombre de requêtes et le poids initial de la page, tout en gardant le contenu disponible si l’utilisateur le demande.

Évite document.write()

Ce que ça veut dire
La méthode document.write() injecte du contenu HTML pendant le chargement de la page. C’était courant il y a des années, mais aujourd’hui, elle ralentit le rendu, bloque le thread principal, et peut casser l’ordre d’exécution des scripts. Elle est surtout problématique sur mobile.

Ce qu’il faut faire pour valider ce critère

• Ne l’utilisez pas dans vos propres scripts.
• Remplacez-le par des méthodes modernes comme appendChild(), insertAdjacentHTML() ou tout simplement des blocs HTML pré-rendus.
• Si un script tiers (publicité, widget, outil de suivi) utilise document.write(), cherchez une alternative plus récente ou un chargement différé.
• Certains plugins ou services anciens doivent être évités s’ils ne proposent pas de version sans document.write.

Aujourd’hui, cette méthode est considérée comme obsolète et risquée. Il vaut mieux la bannir totalement.

Conclusion

Corriger PageSpeed ne veut pas dire viser le 100/100 à tout prix. Ce score est un indicateur, pas un objectif. Ce qui compte vraiment, c’est que votre site s’affiche vite, réponde sans délai, et inspire confiance dès les premières secondes.

Un bon score vient d’un site bien structuré, léger et optimisé intelligemment. Mais attention : appliquer toutes les recommandations à la lettre, sans tri, peut nuire à l’expérience utilisateur. Certaines optimisations sont inutiles, voire contre-productives selon le contexte.

Pour avoir une vue d’ensemble claire sur les bons leviers à actionner, je vous recommande de lire mon guide complet sur l’optimisation des performances WordPress. C’est l’article central qui rassemble les points essentiels : vitesse, structure, hébergement, plugins, images, etc.

Et si vous préférez un regard extérieur ou un accompagnement technique, je propose un audit gratuit de votre site WordPress, ainsi que des interventions ciblées pour améliorer ses performances sans casser ce qui fonctionne.

Votre site mérite mieux qu’un score : il mérite d’être rapide, stable et rassurant.