Technique : rendu, Core Web Vitals, données structurées

Technique : rendu, performance et données structurées

1. Rendu : ce que le moteur voit dans la source

   Le point le plus rentable du cours, parce qu'il change une page lente et invisible en page simple et comprise — sans toucher au design.

   Deux chemins, deux réalités

   Le moteur fonctionne en deux temps : il récupère le HTML, puis il peut exécuter le JavaScript pour obtenir le rendu final. Entre les deux, il y a un délai, un coût, et des cas où le rendu n'a pas lieu.

   • Contenu dans le HTML initial — le moteur l'indexe directement. C'est le cas le plus simple et le plus fiable.
   • Contenu injecté après exécution — le moteur peut le voir, mais il faut qu'il exécute le script, qu'il attende, et qu'il réussisse. Toute erreur JavaScript peut empêcher le contenu d'apparaître.

   Ce que la documentation en dit exactement

   Google Search Central indique que le moteur « n'indexe pas le contenu qui nécessite des greffons (Java ou Silverlight), ni le contenu rendu dans un canvas », et recommande d'utiliser du HTML sémantique. Le canvas est le cas limite à retenir : un texte dessiné dans un canvas n'existe pas pour un moteur, même s'il est parfaitement lisible pour un humain. C'est aussi un problème d'accessibilité, ce qui en fait un de ces défauts qui se corrigent une fois pour deux usages.

   Le test en une minute

   1. Afficher la source de la page (view-source, ou le terminal), pas la page rendue.
   2. Chercher le texte principal dans cette source.
   3. Si le texte n'y est pas, le moteur devra exécuter du JavaScript pour le voir. Ce n'est pas interdit, c'est plus lent et plus fragile.

   Pour un site dont le contenu est du texte, du premier bloc : il doit être dans le HTML initial. Cette règle simple élimine la majorité des problèmes d'indexation d'applications modernes.

   Le contenu hors DOM

   Deux cas distincts qu'on confond souvent : le texte produit par la propriété CSS content n'est jamais dans le DOM et n'est donc pas vu ; le texte inséré par JavaScript finit dans le DOM, mais tard. Le premier est à supprimer ; le second est à réduire.

   Les liens : même règle

   Un lien dont le href est renseigné en JavaScript est un lien que le moteur ne voit pas au moment de l'exploration. Les liens doivent être dans le HTML initial, comme le texte.

2. Core Web Vitals : trois mesures, un percentile, une fenêtre

   Les Core Web Vitals sont un signal de qualité d'expérience. Ils ne sont pas un facteur de classement dominant — c'est un point que les commentateurs de SEO minimisent. Ils sont un facteur réel, faible pondéré, et ils sont aussi un bon indicateur de ce que vit l'utilisateur.

   Les trois mesures et leurs seuils

   Mesure	Ce qu'elle mesure	Bon	À améliorer	Mauvais
   LCP	Chargement : affichage du plus grand élément visible	≤ 2,5 s	2,5 – 4 s	> 4 s
   INP	Réactivité : délai avant le prochain affichage après une interaction	≤ 200 ms	200 – 500 ms	> 500 ms
   CLS	Stabilité visuelle : déplacements cumulés	≤ 0,1	0,1 – 0,25	> 0,25

   Les quatre détails qui font la différence

   1. Le 75ᵉ percentile, pas la moyenne. C'est la règle qu'on oublie. Google retient la valeur telle qu'elle est experienced par 75 % des visites. Une médiane flatteuse peut masquer 25 % de visites catastrophiques — et ce sont ces visites-là qui font partir l'utilisateur.
   2. Des données de terrain, pas de laboratoire. Les rapports CrUX agrègent les mesures réelles des utilisateurs sur 28 jours glissants. Un score obtenu sur un simulateur est un diagnostic, jamais un résultat.
   3. Mobile et desktop sont évalués séparément. Un même groupe d'URL peut être « bon » sur mobile et « mauvais » sur desktop. Les rapports séparent les deux.
   4. INP remplace FID depuis mars 2024. Un cours qui cite encore FID décrit un outil qui n'existe plus. Les seuils sont inchangés depuis.

   Où trouver la mesure qui compte

   • Search Console — le rapport Core Web Vitals, en données de terrain, groupé par URL. C'est la source qui compte, parce qu'elle est celle que Google utilise.
   • PageSpeed Insights — données de terrain quand elles existent, laboratoire sinon.
   • Lighthouse et DevTools — laboratoire uniquement. Utiles pour diagnostiquer une régression, jamais pour conclure.

   Ce que ces mesures corrigent d'habitude

   • LCP : image principale non optimisée, ressource bloquante, absence de dimensions sur les images, rendu qui attend une requête.
   • INP : tâches longues dans le fil principal, trop de JavaScript tiers, gestionnaires d'événements coûteux. C'est la mesure qui casse le plus de sites depuis 2024.
   • CLS : images et bannières sans dimensions réservées, contenu inséré au-dessus de ce qui existe, polices qui décalent la mise en page.

   La règle de budget

   Une image sans width et height (ou sans aspect-ratio) ne peut pas réserver sa place, donc tout ce qui suit se décale quand elle arrive. Le CLS se corrige en une ligne par image. C'est le rapport effort/résultat le plus élevé de tout le cours, et il concerne aussi bien le SEO que le confort de lecture et l'accessibilité.

3. Données structurées : décrire, pas manipulative

   Les données structurées (JSON-LD dans le code) permettent de décrire le sens d'une page : ce qu'est un cours, un auteur, une organisation, un avis. Elles peuvent aussi rendre la page éligible à des affichages enrichis dans les résultats.

   L'avertissement que la documentation insiste sur

   Google précise que les données structurées ne doivent contenir que du contenu visible sur la page, et que masquer une information pour la crawler est une pratique trompeuse susceptible d'entraîner une action manuelle. Autrement dit : le balisage décrit la page, il ne la complète pas. Un cours déclaré dans le JSON-LD mais invisible pour l'utilisateur est une déclaration fausse.

   Ce qui a du sens pour un site de formation

   • Organization — nom, URL, logo, contacts. Stable, peu de risque, utile sur toutes les pages.
   • Course — la nature du contenu, avec nom, description et fournisseur. Le type existe, mais Google ne l'exploite pas toujours dans les résultats enrichis.
   • BreadcrumbList — le fil d'Ariane. C'est le balisage dont l'effet visuel est le plus fiable, parce qu'il peut remplacer un fil d'Ariane purement visuel.
   • FAQPage — pour les questions fréquentes affichées sur la page. À noter : l'affichage enrichi de questions est plus rare qu'il y a quelques années, et le balisage reste pertinent pour la compréhension.

   L'erreur classique : le balisage qui ne correspond pas à la page

   Un même Course réutilisé sur toutes les pages de cours d'un site, avec le même nom et la même description. C'est du balisage mensonger : il décrit un contenu qui n'est pas celui de la page. Le test : chaque valeur du JSON-LD doit pouvoir être retrouvée ailleurs sur la page.

   Comment vérifier

   Deux vérifications, dans cet ordre : valider le balisage avec l'outil de test des résultats enrichis, puis comparer le balisage au contenu affiché. La seconde est la seule qui serve à quelque chose, et c'est celle que personne ne fait.

4. Mobile, HTTPS et international : le socle non négociable

   Mobile d'abord, pas mobile en plus

   La documentation des développeurs liste en tête de ses exigences : le site doit être sécurisé, rapide, accessible et fonctionner sur tous les appareils. Ce n'est pas une recommandation de confort, c'est un prérequis d'éligibilité au Search Essentials.

   Le responsive design n'est pas l'adaptation automatique

   Un site en user-scalable=no ou avec une taille de police trop petite sur mobile est un défaut d'accessibilité qui devient un défaut SEO, parce que les deux partagent la même cause : on a supposé l'appareil plutôt que de concevoir pour l'incertitude de la taille.

   HTTPS : le prérequis que plus personne ne discute

   Un site servi en HTTP affiche un avertissement dans le navigateur et perd la confiance. Le signal est aussi technique : les liens internes doivent tous pointer vers la même version du site, HTTPS, sinon chaque lien est une redirection, et une redirection par lien est une penalisation de performance.

   L'internationalisation : le piège des URLs

   • Une langue par URL, déclarée par hreflang, et cohérente avec la langue réellement servie. Une URL qui annonce une langue et sert une autre est une erreur d'indexation.
   • Une seule version par langue par page, sinon les versions se font concurrence entre elles.
   • Les versions linguistiques ne se déclare pas canoniques les unes vers les autres : ce sont des pages distinctes, pas des doublons.