Améliorer les Core Web Vitals d’un site de cuisine ne demande pas de tout casser. Les pages de cuisine cumulent des photos lourdes, des scripts publicitaires et des encarts qui sautent au chargement, ce qui ralentit l’affichage de la recette et agace le lecteur. En hiérarchisant les corrections à partir des données de PageSpeed Insights, on attaque d’abord ce qui pèse sur le LCP, l’INP et le CLS. Les gains concernent les images, les scripts, la stabilité.
Lire les données avant de toucher au code
PageSpeed Insights classe les problèmes par métrique et par page. On y voit d’un coup d’œil si le LCP dépasse 2,5 secondes, si l’INP reste au-dessus de 200 millisecondes ou si le CLS franchit 0,1, car l’outil regroupe les données de terrain et de laboratoire par métrique pour chaque URL testée. Le FID doit rester sous les 100 millisecondes.
Ces seuils de confort ne sont pas un style de notation. Ils correspondent à ce qu’un lecteur de recette ressent quand il attend la photo, touche un bouton de portion ou voit la page bouger pendant la lecture d’une étape.
Que faire de ces chiffres une fois le rapport ouvert ? On commence par les pages qui génèrent le plus de visites, pas par la page d’accueil, parce que ces pages concentrent la majorité du trafic organique et que les corrections y produisent un impact plus large. Les fiches recette concentrent la majorité des visites. Si le rapport y remonte un LCP médiocre, on y consacre d’abord les efforts, et les catégories attendront.
Pour relire un rapport sans s’éparpiller, l’approche de philippe-larroche.fr aide à isoler ce qui relève du serveur, du rendu et des interactions, évitant de confondre un problème de temps de réponse avec un problème de stabilité visuelle.
Les données de terrain de Chrome surpassent les simulations locales. Elles orientent directement les corrections vers le chargement des images et le poids des scripts, deux postes qui se disputent la bande passante : une image lourde retarde l’affichage, un script monopolise le processeur.
Réduire le poids des images sans refonte
Le LCP d’une fiche recette dépend souvent de la photo d’en-tête, chargée en pleine largeur sur mobile alors qu’elle est téléchargée dans une taille supérieure à l’affichage réel. Compressez-la sans perte visible, redimensionnez-la pour les écrans réels, choisissez un format moderne comme le WebP ou l’AVIF. Ces gestes prennent moins de temps qu’une refonte et produisent des gains immédiats.
C’est le plus agaçant : la photo met du temps à apparaître alors que le texte est déjà là, surtout quand le lecteur fait défiler le pas à pas et que la page se fige, car le navigateur doit télécharger une image trop lourde avant de l’afficher. Il suffit de générer plusieurs tailles et de laisser le navigateur choisir. C’est une correction de gabarit, pas une refonte.
Reconnaître les coupables dans une fiche recette
Sur une page de recette, les problèmes d’images se concentrent à quelques endroits faciles à reconnaître : photos d’en-tête, carrousels, vignettes de recettes similaires. On les retrouve dans tous les rapports, rarement dans un ordre différent. Les gestes à retenir ne touchent pas à la structure de la page.
- La photo d’en-tête en taille d’origine, même sur mobile.
- Un carrousel lourd sans servir la recette.
- Les vignettes de recettes similaires oubliées dans le budget.
- La miniature de l’ingrédient principal sans format moderne.
- Le logo et les icônes en PNG alors qu’un SVG suffirait.
On ajoute le chargement paresseux pour tout ce qui n’est pas visible au premier écran, ce qui reporte le téléchargement des images secondaires jusqu’à ce que l’utilisateur approche de leur position. La photo principale reste prioritaire. Ça réduit fortement les ressources téléchargées avant l’affichage.
Des scripts plus discrets pour un INP correct
Un temps d’interaction supérieur à 200 millisecondes se ressent dès qu’on ouvre le menu des ingrédients ou qu’on touche le bouton des portions, car les scripts bloquent le fil principal. Chargez en différé, supprimez l’inutile, retardez le non-urgent. Ces corrections rendent la page plus réactive.
Sur une page de recette, le lecteur veut lire la liste des ingrédients puis les étapes, et attend que chaque interaction réponde sans délai, parce que la cuisine demande des gestes rapides. Mieux vaut une seule bannière chargée tardivement que trois scripts qui se disputent le processeur.
Les polices web, widgets de réseaux sociaux et lecteurs vidéo ajoutent leur part de latence, surtout quand ils chargent en même temps que la recette et décalent la lecture des étapes. Chargez-les après coup, ou gardez-les seulement sur les pages utiles. D’abord le visible, ensuite le confort.
Stabiliser la mise en page autour des recettes
Un CLS supérieur à 0,1 provoque des sauts pendant la lecture, et le doigt appuie là où se trouvait la phrase une seconde plus tôt, transformant la consultation en rattrapage permanent sur mobile. Les coupables sont connus : bannières publicitaires, photos sans dimensions, polices web. Réservez l’espace publicitaire, fixez la hauteur des images, affichez une police système. La recette ne bouge plus, et le lecteur ne clique plus à côté du bouton visé.
Ces ajustements demandent un peu de rigueur : réserver une hauteur fixe pour la bannière, indiquer les dimensions des images et éviter d’injecter un encart de newsletter au milieu des étapes, car toute insertion tardive décale les éléments affichés et provoque des clics manqués. Un site qui bouge décourage plus qu’une photo lourde.
Le confort de lecture se mesure aussi en millisecondes
Améliorer un blog culinaire sans tout refondre revient à traiter le poids des visuels, la discrétion des scripts et la stabilité de la mise en page, trois leviers qui influencent directement la perception de rapidité. Le rapport d’audit de Google sert à prioriser les corrections, pas à effrayer avec des scores globaux. Chaque recette gagne en confort de lecture, et le référencement suit.
