Headless CMS : lequel choisir quand on n’est pas une équipe technique
6 min de lecture
À retenir
- Les Core Web Vitals sont un critère de départage, pas un levier de positionnement à eux seuls.
- LCP est presque toujours l’indicateur à corriger en premier, et l’image d’en-tête en est la cause.
- INP a remplacé FID : il mesure la réactivité réelle, et le JavaScript tiers en est le premier responsable.
- CLS se corrige en une heure : des dimensions explicites sur les images et les emplacements publicitaires.
- Mesurez sur les données de terrain, pas sur un test en laboratoire depuis votre fibre.
Tous les six mois, un article annonce que la vitesse va « révolutionner le SEO ». Puis rien ne change spectaculairement, et les mêmes sites restent en tête.
La réalité est plus nuancée, et plus utile à connaître : les Core Web Vitals ne font pas monter, mais ils font descendre. À contenu comparable, la page la plus lente perd. Et surtout, elle convertit moins — ce qui est un problème bien plus coûteux qu’une position.
Les trois indicateurs, sans jargon
| Indicateur | Ce qu’il mesure | Seuil correct | Cause principale |
|---|---|---|---|
| LCP | Le temps avant que l’élément principal soit visible | < 2,5 s | Image d’en-tête, police bloquante, serveur lent |
| INP | Le délai entre une interaction et la réponse visible | < 200 ms | JavaScript tiers, scripts trop lourds |
| CLS | Les sauts de mise en page pendant le chargement | < 0,1 | Images sans dimensions, bannières insérées après coup |
Ces seuils doivent être tenus pour 75 % des visites réelles. C’est le point que la plupart des équipes ratent : un score parfait sur un test unique lancé depuis un poste en fibre ne dit rien de ce que vivent vos visiteurs en mobilité.
Les six optimisations qui apportent 80 % du gain
1. L’image d’en-tête
C’est le coupable numéro un du LCP, sur presque tous les sites que nous auditons. Une photo de 2,4 Mo en pleine largeur, chargée en JPEG non compressé, à une résolution trois fois supérieure à ce qui est affiché.
Le correctif : format moderne — WebP ou AVIF —, dimensions réelles adaptées à l’affichage, plusieurs tailles proposées selon la largeur d’écran, priorité de chargement explicite sur cette seule image, et chargement différé pour toutes les autres. Gain typique : 1 à 2 secondes.
2. Les polices
Une police web mal chargée bloque l’affichage du texte, ou provoque un changement de rendu brutal en cours de chargement.
Le correctif : préconnexion au domaine qui sert les polices, affichage immédiat avec une police de substitution, et limitation à deux familles et trois graisses. Chaque graisse supplémentaire est un fichier à télécharger.
3. Le JavaScript tiers
C’est le premier responsable d’un mauvais INP. Sur un site professionnel classique, nous trouvons souvent huit à quinze scripts tiers : analyse d’audience, régie publicitaire, chat, carte, test A/B, suivi de conversion, et deux outils que plus personne ne se rappelle avoir installés.
Le correctif tient en trois questions posées pour chaque script : est-il encore utilisé ? peut-il être chargé après l’affichage ? peut-il être déclenché seulement à l’interaction ? Un chat chargé uniquement au clic sur son icône économise souvent 300 à 500 ms d’INP.
4. Les dimensions explicites
Chaque image, chaque iframe, chaque emplacement réservé doit déclarer sa largeur et sa hauteur. Le navigateur réserve alors la place avant même d’avoir téléchargé le contenu, et la page ne saute plus.
C’est l’optimisation la moins chère du lot : quelques heures de travail, un CLS qui passe au vert.
5. Le cache et la compression
Cache long sur les ressources statiques, compression moderne sur les fichiers texte, et une réponse serveur sous 200 ms sur la page d’accueil. Sur un site statique correctement hébergé, c’est acquis ; sur un site dynamique, c’est souvent le premier gain à aller chercher.
6. Ce qui est chargé sans être vu
Carrousel dont les huit images sont chargées d’emblée, carte interactive présente en bas de page, vidéo intégrée en arrière-plan. Tout ce qui se trouve sous la ligne de flottaison peut attendre l’approche du visiteur.
2,5 sSeuil de LCP à tenir sur 75 % des visites réelles
1–2 sGain typique du seul traitement de l’image d’en-tête
3–8 jEffort courant pour passer un site existant au vert
Mesurer correctement
Deux familles d’outils, deux usages différents, et une confusion permanente.
Les tests en laboratoire exécutent la page dans des conditions simulées. Ils sont parfaits pour diagnostiquer une cause et pour comparer avant/après. Ils ne disent rien de votre audience réelle.
Les données de terrain proviennent des visites effectives. Elles sont la seule référence pour savoir où vous en êtes, et elles se consultent dans la Search Console, dans le rapport dédié.
Le décalage à connaître : les données de terrain sont calculées sur une fenêtre glissante de 28 jours. Après une optimisation, l’amélioration met plusieurs semaines à apparaître dans les rapports. Ne concluez pas à un échec au bout de cinq jours.
Ce qui ne sert à rien
Chasser le score parfait. Passer de 92 à 99 sur un test synthétique n’a aucun effet mesurable sur le référencement ni sur les conversions. Passer de 45 à 80 en a un, très net.
Optimiser une page qui ne reçoit personne. Concentrez l’effort sur les dix pages qui apportent le trafic. C’est aussi ce que nous recommandons lors d’une refonte.
Supprimer tout le JavaScript. L’objectif n’est pas un site sans interactivité, c’est un site où l’interactivité ne bloque pas le premier affichage.
La performance web n’est pas un score à afficher en réunion. C’est le temps que vos visiteurs passent à attendre. Le seul chiffre qui compte est celui que vivent 75 % d’entre eux, sur leur téléphone, dans le métro.
Par où commencer demain matin
Ouvrez la Search Console, section Signaux web essentiels. Notez les pages en rouge et en orange. Croisez avec vos dix pages les plus visitées. L’intersection est votre liste de travail — et elle tient généralement sur trois lignes.
