Core Web Vitals 2022

Pas de technologie en particulier, tout est possible ! Seuls l’expérience et l’aisance du développeur pourra faire en sorte d’avoir de bons scores. Il n’empêche pas moins qu’avoir des CDN ou un système de cache performants (coûts supplémentaires en plus de l’hébergement) donnera certainement une longueur d’avance :) 

Il y a un délai de 28 jours ou pas, en fonction de si on parle de données terrain ou laboratoire. Je dirai donc qu’il faut simuler les Core web vitals avec des données internes en utilisant la console et des librairies adéquates que les développeurs ont l’habitude normalement d’utiliser.

Google comme à son habitude aime nous faire faire son travail à sa place en assainissant l’index pour mettre un confort de navigation à ses internautes et une meilleure expérience utilisateur due en partie à une vitesse de chargement et affichage améliorée. Mais il ne peut cependant pas « imposer » aux sites web , aux blogs etc d’investir sur des actions parfois très techniques et les sanctionner si ces actions venaient à ne pas être mises en place. Je dirai donc que la priorité si le score est décent reste pour moi le contenu et les autres leviers SEO (structure/technique , netlinking).

Le choix dans les actions rapides et simples sera forcément limité mais il conviendra de mettre les efforts sur l’optimisation des images, du préchargement des ressources telles que les font (ou polices d’écriture) , de ne pas charger des ressources obsolètes (JS, anciens appels CSS, etc) , de regrouper et minifier les éléments CSS et JS (non tiers), et optimiser l’ordre d’affichage des éléments les plus larges de votre page.

Les sites Desktop jouissent d’une facilité pour passer les Core web vitals dû au fait que les stations desktop soient plus puissantes en termes de hardware pour afficher sur un navigateur un site web, le calcul est plus rapide, le DOM est plus vite rendu, etc etc. C’est pour cela que généralement un score Desktop sera toujours plus élevé qu’un score mobile. De plus , les sites étant majoritairement en RWD , les recommandations mobiles bénéficieront pour la plupart à la version Desktop. « Mobile first » comme on dit! ;)

C’est souvent des images non optimisées, des compressions non existantes pour certaines ressources statiques, des pré-chargements de police non activé, ou des éléments non minifiés ou regroupés quand c’est possible (CSS,JS)   

Pas spécialement pour le portefeuille client que l’on suit… mais les déclassements ont surtout été observés sur des sites anormalement longs.

Si votre site est RWD (responsive web design) il passera certainement le test de compatibilité mobile mais rien ne vous assure qu’il passe avec succès le test des Core Web Vitals ! Cela dépend de plusieurs paramètres comme le socle technique utilisé (CMS, etc) , l’hébergement ou encore la façon dont les ressources sont appelées pour afficher la page…

Oui, il faut prendre en compte, le template/ si on fait du caching et que le template change, il faut remettre en cache, changer le cache et adresser la bonne largeur à Google.

Il y a des tabous connus du SEO, par exemple les fiches produits identiques sur un même produit sur plusieurs sites. Et Google ne pénalise pas malgré sa règle sur le duplicate content. Google est très friand des médias, pour fournir Google News, le format AMP qui se charge rapidement est le focus des médias.

Se fier à l’accompagnement des CDN par rapport à ça. Conseil, leur donner votre meilleur concurrent comme point de départ pour la configuration.

Non, mais ça va le devenir. Google privilégie la réponse à la requête.

Ce n’est pas un ranking factor, selon Google mais ce qui est sûr c’est que Google va mettre le site dans son radar, donc à optimisation équivalente, le site sera déplacé en bas.

Non, moins, parce qu’on est sur une technologie qui utilise le JavaScript (JS) qui va soulager le thread principal.