Retour d'expérience

PageSpeed : pourquoi votre score stagne (et ce qu'on voit sur le terrain)

Atteindre un score supérieur à 90 n'est pas une garantie. Plusieurs causes précises plombent les scores, souvent invisibles à l'œil nu. 26 ans de projets clients nous ont appris à les reconnaître.

Analyser mon site maintenant

Gratuit • Résultat en 30 secondes • Sans inscription

Exemple de résultats clients

98
Client automobile
après optimisation
41
Site WordPress
avant refonte
Optimisé 98/100
Non optimisé 41/100
3
Causes principales
identifiées terrain
2,5s
Seuil LCP Google
(Largest Contentful Paint)
95+
Score moyen clients
Sudimedia production
53%
Abandons si chargement
> 3 secondes (mobile)

Ce que PageSpeed Insights mesure vraiment

Beaucoup de PME découvrent leur score PageSpeed par hasard - souvent via un audit SEO ou un prestataire qui en parle. Premier réflexe : taper l'URL dans l'outil Google, voir un chiffre rouge, et se demander ce qu'on peut faire rapidement pour le faire monter.

C'est un bon instinct. Mais comprendre pourquoi le score est mauvais est plus utile que de chercher à l'améliorer mécaniquement. Google mesure en réalité l'expérience réelle de vos visiteurs : combien de temps avant que le contenu principal s'affiche (LCP), est-ce que la page bouge pendant le chargement (CLS), est-ce que les éléments répondent vite aux clics (INP). Ces métriques sont directement liées au comportement des visiteurs et à votre référencement naturel.

Ce qu'on observe sur le terrain depuis 26 ans de projets : les mauvais scores ne viennent presque jamais d'une cause unique mystérieuse. Ils viennent de deux ou trois problèmes précis, souvent les mêmes, que personne n'a pris le temps de corriger.

À noter

Atteindre 98/100 n'est pas systématiquement possible ni même l'objectif pertinent pour tous les sites. Un score entre 80 et 95 est tout à fait respectable selon les contraintes techniques. L'objectif est d'identifier et corriger ce qui impacte réellement l'expérience utilisateur - pas de courir après un chiffre parfait.

Les 3 causes qu'on rencontre le plus souvent

Sur les projets que nous reprenons ou auditons, ces trois problèmes reviennent de manière quasi systématique. Seuls ou combinés, ils suffisent à faire plonger un score de 80 points.

Images non optimisées

Impact fort

Une photo de produit uploadée directement depuis un appareil photo peut peser 4 à 8 Mo. Sur mobile avec une connexion 4G moyenne, c'est entre 3 et 6 secondes de chargement pour cette seule image. Le passage au format WebP réduit typiquement le poids de 25 à 35% par rapport au JPEG. Sans compresser ni redimensionner, chaque image devient un frein visible dans le LCP.

JavaScript bloquant

Impact fort

Google Tag Manager, analytics, chat en temps réel, scripts de personnalisation - chaque outil tiers chargé dans le <head> bloque l'affichage de la page. Le navigateur attend que le script soit téléchargé et exécuté avant d'afficher quoi que ce soit. Un site qui charge 6 scripts marketing au démarrage peut perdre 2 secondes rien que pour ça, même avec une bonne infrastructure.

CSS/JS non minifiés, trop de requêtes

Impact modéré

Un fichier CSS non minifié contient espaces, commentaires et retours à la ligne. Sur un gros fichier, ça peut représenter 30 à 40% du poids inutile. Mais le vrai problème vient souvent du nombre de fichiers chargés séparément : 8 fichiers CSS de 20 Ko chacun = 8 requêtes HTTP au lieu d'une. Sur hébergement mutualisé en particulier, chaque requête supplémentaire coûte en latence.

Configuration serveur sous-optimale

Impact variable

Souvent sous-estimée : l'absence de cache navigateur correctement configuré, pas de compression Gzip/Brotli activée, headers HTTP mal renseignés. Sur OVH mutualisé, ces paramètres sont accessibles via .htaccess mais rarement configurés par défaut. Une bonne configuration permet de diviser par 2 ou 3 le temps de chargement des ressources statiques sur les visites suivantes.

Outil gratuit Sudimedia

Diagnostic PageSpeed en 30 secondes

Entrez votre URL et obtenez le score Desktop + Mobile, les Core Web Vitals et les recommandations prioritaires - sans inscription, sans installation.

Tester mon site maintenant

Gratuit • Résultats immédiats • Données Google PageSpeed Insights officielles

Ce qu'on a fait sur un cas concret

Un client dans l'automobile nous sollicite pour reprendre son site. L'ancien prestataire avait livré quelque chose de visuellement correct, mais les performances étaient préoccupantes. Premier passage dans PageSpeed Insights :

Avant reprise
41
Mobile
LCP : 6,2s • CLS : 0,28
Plusieurs scripts bloquants
Après optimisation
98
Mobile
LCP : 1,2s • CLS : 0,01
Core Web Vitals 100%

Le diagnostic a révélé trois problèmes cumulés : les photos de véhicules étaient servies en JPEG original (entre 2 et 5 Mo chacune), un plugin analytics tiers était chargé en mode bloquant dans le <head>, et aucune règle de cache navigateur n'était en place. La correction a pris deux jours. Le score est passé de 41 à 98 sur mobile - sur hébergement OVH mutualisé standard, sans serveur dédié ni CDN exotique.

Ce n'est pas toujours aussi spectaculaire. Sur certains sites avec beaucoup de fonctionnalités interactives ou de scripts tiers imposés par le métier (CRM, tracking publicitaire, chat...), atteindre 90+ demande des arbitrages. Mais dans la majorité des cas, le potentiel d'amélioration est significatif et les corrections sont identifiables.

Ce qu'on apprend de ce cas

L'hébergement mutualisé n'est pas l'ennemi. On entend souvent qu'il faut un VPS ou du CDN pour performer. Ce cas montre que la configuration et le code pèsent bien plus lourd que l'infrastructure pour la grande majorité des sites PME. Un site bien codé et correctement configuré sur mutualisé battra presque toujours un site mal optimisé sur serveur dédié.

Ce qu'on vérifie en premier sur un audit

Quand on reçoit un site à auditer, voici l'ordre dans lequel on regarde les choses - du plus impactant au plus fin.

Poids et format des images Y a-t-il des images non compressées ou servies en JPEG/PNG là où du WebP suffirait ? Est-ce que les images sont redimensionnées côté serveur ou servies en taille originale ?
Scripts tiers dans le <head> GTM, analytics, chat, A/B testing - combien de scripts bloquants sont chargés avant le rendu ? Peuvent-ils être différés (async/defer) sans casser les fonctionnalités ?
Compression serveur Gzip ou Brotli activé ? Sans compression, les fichiers texte (HTML, CSS, JS) transitent en clair à taille maximale. C'est une configuration .htaccess de 5 lignes qui peut alléger de 60 à 80% le poids des ressources textuelles.
Cache navigateur Les ressources statiques (logo, CSS, JS, polices) ont-elles un cache long défini ? Sans ça, chaque visite retélécharge tout depuis zéro, même pour un utilisateur qui revient deux heures plus tard.
Nombre de requêtes HTTP Peut-on regrouper plusieurs fichiers CSS ou JS en un seul ? Chaque requête a un coût en latence, particulièrement sur mobile. La concaténation et la minification restent des gains faciles à obtenir.
Nos autres outils gratuits

Vous gérez aussi la délivrabilité de vos emails ? Nous avons développé un DMARC Reader pour analyser vos rapports d'authentification email sans exposer vos données. Parsing automatique, génération de prompts IA, accès gratuit sur demande.

Et si votre configuration SPF/DKIM/DMARC vous pose des doutes, notre Email Checker vérifie l'ensemble de votre configuration en quelques secondes.

Votre site a besoin d'un audit complet ?

L'outil donne le diagnostic. Mais si les résultats révèlent des problèmes complexes - architecture, scripts métier bloquants, infrastructure - nous pouvons aller plus loin avec un audit technique complet et un plan d'action concret.

Parler de votre projet
Tester mon site