Mai 2021 sera une date importante pour le monde de l’Internet et du référencement Web.
C’est le mois où Google commence à introduire des signaux Core Web Vitals via l’Expérience de Page, comme un facteur de classement pour la page de résultats du moteur de recherche.
Google charge les utilisateurs de logiciels CMS comme WordPress et non les développeurs de CMS de les corriger ou de les réparer pour les Core Web Vitals. Est-ce juste ?
Vous n’êtes pas seul si vous avez du mal à améliorer les scores de Core Web Vitals et à venir à court. Des données anecdotiques suggèrent qu’il est difficile d’obtenir des performances Core Web Vitals élevées.
La raison en est que les éditeurs et les référenceurs SEO tentent de réparer quelque chose qui techniquement n’est pas cassé.
Changement de paradigme dans la façon dont les sites sont développés
Nous en sommes aux premières étapes d’un changement de paradigme majeur dans la façon dont les pages Web sont créées. Un hébergeur web plus rapide est utile, mais il ne répare pas les problèmes de Core Web Vitals.
Les Core Web Vitals sont calculés en aval de l’appareil mobile qui affiche vos pages Web sur un téléphone mobile à des vitesses 3G ou 4G.
C’est de là que proviennent les données des Core Web Vitals et qu’un serveur Web rapide est peu utilisé à ce moment-là si le téléchargement est étranglé par une mauvaise connexion Internet au téléphone.
L’amélioration des Core Web Vitals est moins sur l’hébergement web et plus sur la correction du code.
Réparer ce qui n’est pas cassé
WP Rocket a récemment refondé son site web en utilisant Gutenberg.
C’était une décision courageuse et presque téméraire étant donné que Gutenberg n’avait pas toutes les capacités d’édition du site à l’époque.
Ils ont dû personnaliser la façon dont WordPress gère le CSS et le JavaScript afin d’améliorer les scores de Page Experience de Google.
En d’autres termes, en refondant leur site Web pour être bien noté pour Core Web Vitals, WP Rocket a dû personnaliser WordPress lui-même, pour en faire quelque chose qu’il n’a pas été conçu pour être.
Core Web Vitals pas vraiment friendly
Les normes de Core Web Vitals ne sont pas quelque chose que les développeurs de WordPress ont à l’esprit lors de la création du site WordPress.
C’est pourquoi l’intégration de Tweets (et ça c’est vrai !) dans un post déclenchera le Cumulative Layout Shift.
WordPress et les thèmes ne codent pas pour Google. Ils codent pour les besoins des éditeurs.
Il n’y a pas que WordPress, non plus. La plupart des autres systèmes de gestion de contenu (CMS) ne sont pas intégrés aux meilleures pratiques des Signaux Web Essentiels (Core Web Vitals).
Cela ne signifie pas qu’il y a quelque chose de mal avec WordPress. Il n’y a rien de mal avec WordPress parce que Google dit qu’il y a quelque chose de mal.
Core Web Vitals n’est pas un problème WordPress
Core Web Vitals est un ensemble de mesures développées indépendamment par Google et poussées vers l’éditeur et la communauté SEO pour travailler avec.
WordPress n’a rien à voir avec ça.
Core Web Vitals est apparu en Mai 2020, apparemment sans aucune coordination ou consultation avec l’écosystème des développeurs.
Du côté de WordPress, le développement va de l’avant comme si Core Web Vitals n’existait pas. Alors que du côté de l’éditeur et du SEO, ce sont les utilisateurs de WordPress qui sont accablés par la tâche de « correction » de WordPress, Drupal, phpBB, Blogger de Google, etc.
Dans un monde parfait, le travail de création d’un système qui répond aux besoins des utilisateurs se trouve du côté des développeurs. Mais ça n’arrive pas. WordPress ne voit même pas Core Web Vitals comme un problème WordPress.
Quand quelqu’un a commencé un thread de support dans les forums WordPress à ce sujet, on lui dit de poser sa question dans le forum de support de Google.
Vous devriez le demander sur un forum Google, parce que WordPress n’a rien à voir avec cela.
L’éditeur et la communauté SEO accablés par la conformité
Les éditeurs de WordPress sont coincés à essayer de rendre les sites Web conformes à une norme pour laquelle ces sites Web n’ont jamais été conçus pour se conformer.
C’est la raison pour laquelle tant de gens sont aux prises avec les Core Web Vitals. Les éditeurs et les SEOs sont accablés d’essayer de réparer quelque chose qui, idéalement, devrait être corrigé au niveau du code.
Améliorer les scores Core Web Vitals peut sembler avoir envie d’essayer d’améliorer les performances d’une Honda Civic aux normes d’une Chevrolet Corvette.
Les développeurs n’ont pas construit de Corvette. Ils ont construit une Honda Civic.
Mais Google exige que les conducteurs (et non les fabricants) améliorent les performances à un niveau Corvette. Cela vous semble-t-il juste ?
Est-il raisonnable de demander aux utilisateurs d’un logiciel CMS de l’améliorer plutôt qu’aux développeurs du logiciel ?
Le problème de la conformité logicielle avec Core Web Vitals existe au niveau du code, pas au niveau de l’utilisateur-éditeur de contenu.
Alors, pourquoi les éditeurs et la communauté SEO sont-ils accablés de réparer quelque chose dont ils ne sont que des utilisateurs ?
Google est-il d’une aide quelconque ?
Google fournit beaucoup d’outils pour diagnostiquer les problèmes et offre des articles en profondeur expliquant comment résoudre ces problèmes de codage.
Mais ce sont des problèmes de codage du CMS et non des problèmes d’utilisateurs.
Un exemple de la déconnexion entre la communauté de développement et Google est le problème de Cumulative Layout Shift, où la page Web se déplace et se réorganise au fur et à mesure que les éléments de la page sont téléchargés.
Une raison commune pour le Cumulative Layout Shift est que les images n’ont pas une hauteur et une largeur déclarées. Google recommande des solutions de contournement exotiques comme l’utilisation de CSS pour coiffer les images à l’aide de box de ratio d’aspect.
L’éditeur et le SEO moyen ne vont probablement pas comprendre ce que les boîtes de ratio d’aspect sont et comment calculer les ratios à l’échelle du site d’une manière qui ne casse pas le site.
Jetez un oeil à cela et à la description des boîtes de ratio d’aspect que Google lie, pour voir si cela a du sens pour vous :
Les carrés parfaits et des choses en 16:9 sont grands, mais les valeurs utilisées pour ceux-ci ne sont que des mathématiques simples. Un rapport d’aspect peut être n’importe quoi, et ils sont généralement complètement arbitraires. Une vidéo ou une image peut être recadrée à n’importe quelle taille.
Alors, comment pouvons-nous comprendre le padding-top pour notre 1127.34 × 591.44 SVG ci-dessus ?
Une façon est d’utiliser calc (), comme ceci :
padding-top: calc(591.44 / 1127.34 * 100%);
Voici un autre exemple.
De nombreux modèles Web règlent régulièrement les largeurs d’image via CSS pour qu’elles soient automatiques (width : auto;) sans définir la hauteur et la largeur des images afin de faire des images comme une taille de logo à l'échelle pour s’insérer dans un modèle, peu importe si elle est vue sur un mobile ou un appareil de bureau.
Il s’agit d’une pratique de codage courante qui provoque le Cumulative Layout Shift (CLS).
Ce sont les raisons pour lesquelles WP Rocket a dû creuser et apporter des modifications au CSS et JavaScript du site à l’échelle du site.
Par exemple, WordPress Gutenberg charge tout le CSS qui existe, qu’il soit nécessaire ou non. Le développeur de WP Rocket a donc dû remettre du code pour cela.
C’est ainsi que WP Rocket a expliqué ce qu’ils ont fait dans le cadre de leur refonte :
Il est important de comprendre le problème des Core Web Vitals. Google exige que les éditeurs et les SEOs créent des solutions pour lesquelles la communauté de développement CMS ne montre aucun intérêt pour les traiter.
Voici un exemple des types de compromis auxquels nous sommes confrontés et comment Google change la façon dont nous développons des sites Web.
Parlons des polices.
Rendre le blocage des ressources tierces peut avoir un impact négatif sur “Largest Contentful Paint”. Un goulot d’étranglement commun est le téléchargement des polices à partir d’un site tiers comme Google Fonts.
Il y a un certain nombre de trucs à appliquer qui sont la combinaison de l’utilisation de l’attribut de lien de préchargement et peut-être certains JavaScript, etc, qui rendent le processus de téléchargement de polices tierces compatibles avec Core Web Vitals.
Mais cela tuerait-il votre site que de laisser cette police fantaisiste derrière ?
Une solution simple qui aidera à avoir un meilleurs score est de passer de la police du site Web à une police sans serif que les appareils Apple, Windows et Android ont déjà chargé dans leur système.
Passer à une police attrayante qui est intégrée dans l’appareil signifie que le site n’a plus à attendre pour télécharger une police fantaisiste.
Une approche peut être quelque chose comme ceci :
Il s’agit d’une pratique de codage courante qui provoque le Cumulative Layout Shift (CLS).
Ce sont les raisons pour lesquelles WP Rocket a dû creuser et apporter des modifications au CSS et JavaScript du site à l’échelle du site.
Par exemple, WordPress Gutenberg charge tout le CSS qui existe, qu’il soit nécessaire ou non. Le développeur de WP Rocket a donc dû remettre du code pour cela.
C’est ainsi que WP Rocket a expliqué ce qu’ils ont fait dans le cadre de leur refonte :
... Nous avons déprécié plusieurs blocs qui n’ont pas été utilisés. Nous avons créé un système d’enqueue personnalisé pour avoir les blocs CSS & JS chargés seulement en cas de besoin. Il nous a fallu quelques minutes pour développer ce système.
Nous avons également décidé de ne pas utiliser le fichier Gutenberg CSS. Au lieu de cela, nous avons « migré » le CSS dont nous avions réellement besoin dans notre propre feuille de style, dans un fichier CSS dédié. Cela a fait l’affaire.
Repenser la façon dont les sites sont créés
Il est important de comprendre le problème des Core Web Vitals. Google exige que les éditeurs et les SEOs créent des solutions pour lesquelles la communauté de développement CMS ne montre aucun intérêt pour les traiter.
Voici un exemple des types de compromis auxquels nous sommes confrontés et comment Google change la façon dont nous développons des sites Web.
Parlons des polices.
Rendre le blocage des ressources tierces peut avoir un impact négatif sur “Largest Contentful Paint”. Un goulot d’étranglement commun est le téléchargement des polices à partir d’un site tiers comme Google Fonts.
Il y a un certain nombre de trucs à appliquer qui sont la combinaison de l’utilisation de l’attribut de lien de préchargement et peut-être certains JavaScript, etc, qui rendent le processus de téléchargement de polices tierces compatibles avec Core Web Vitals.
Mais cela tuerait-il votre site que de laisser cette police fantaisiste derrière ?
Une solution simple qui aidera à avoir un meilleurs score est de passer de la police du site Web à une police sans serif que les appareils Apple, Windows et Android ont déjà chargé dans leur système.
Passer à une police attrayante qui est intégrée dans l’appareil signifie que le site n’a plus à attendre pour télécharger une police fantaisiste.
Une approche peut être quelque chose comme ceci :
police-family: Helvetica, Tahoma, sans-serif;
Si Android n’a pas Helvetica ou Tahoma déjà chargé dans le navigateur, alors l’appareil affichera le site en utilisant la police Roboto.
Pour les personnes habituées à utiliser des polices de fantaisie, l’utilisation de polices système peut sembler extrême. Mais c’est un exemple des types de compromis qu’un éditeur web peut avoir besoin de faire, en particulier les éditeurs qui sont dans des créneaux hautement concurrentiels.
Ce genre de décision est une évidence pour un site affilié axé sur la vitesse de chargement de la page et les conversions.
Ce qui se passe aujourd’hui, c’est que nous vivons un moment de transition. Les choses changent, de la façon dont nous avons fait les choses dans le passé à la façon dont les développeurs vont faire les choses (hors de la box) à l’avenir.
Les développeurs ont répondu à la demande de sites mobile-friendly. Avec le temps, ils peuvent commencer à répondre à la demande de sites qui obtiennent de bons scores pour Core Web Vitals.
Pour l’instant, les SEOs techniques et la communauté des développeurs sont coincés à l’idée d’avoir à « corriger » ce qui n’est pas cassé dans le site afin de le faire respecter l’idée de Google de ce à quoi le web devrait ressembler.
Bien sûr, une page qui se charge rapidement et ne se déplace pas autour est une bonne chose. Mais exiger des utilisateurs d’un logiciel CMS d’améliorer le logiciel lui-même est un vrai fardeau.
À ce stade, le fardeau de la fixation du code incombe aux utilisateurs du logiciel de publication et non aux développeurs de ce logiciel. Vous trouvez ça normal, vous ?
Ce qui pourrait arriver, c’est que certains peuvent trouver utile de corriger autant qu’ils le peuvent et laisser le reste pour quand WordPress et d’autres logiciels CMS rattraperont le coup.
Déjà, on a beaucoup parlé des principaux éléments des Signaux Web Essentiels. Plus particulièrement, comment accélérer un site Web.
C’est principalement parce que, des principaux éléments des Core Web Vitals, ce sont ceux qui sont liés à la vitesse de chargement du site web qui ont la pondération la plus élevée.
Bien sûr, beaucoup d’attention devrait être portée à l’amélioration de la vitesse du site. Toutefois, si vous voulez que tous les 3 éléments des Core Web Vitals passent au vert, vous allez devoir faire un peu plus que cela.
Avec cela, voici 5 façons faciles qui devraient aider à améliorer vos principaux Core Web Vitals.
Bref, Google devrait cependant admettre que tout changement à réaliser pour rendre un site plus performant pour les Core Web Vitals devrait idéalement revenir aux développeurs d’outils de création de site CMS (sur lesquels il devrait exercer une pression forte) et non aux simples utilisateurs de CMS (WordPress, Blogger, Wix, Drupal, etc) que nous sommes.
Source : Searchenginejournal
Pour les personnes habituées à utiliser des polices de fantaisie, l’utilisation de polices système peut sembler extrême. Mais c’est un exemple des types de compromis qu’un éditeur web peut avoir besoin de faire, en particulier les éditeurs qui sont dans des créneaux hautement concurrentiels.
Ce genre de décision est une évidence pour un site affilié axé sur la vitesse de chargement de la page et les conversions.
Un moment de transition
Ce qui se passe aujourd’hui, c’est que nous vivons un moment de transition. Les choses changent, de la façon dont nous avons fait les choses dans le passé à la façon dont les développeurs vont faire les choses (hors de la box) à l’avenir.
Les développeurs ont répondu à la demande de sites mobile-friendly. Avec le temps, ils peuvent commencer à répondre à la demande de sites qui obtiennent de bons scores pour Core Web Vitals.
La façon dont les systèmes CMS, les templates et les plugins sont conçus n’a pas été à la hauteur des besoins des éditeurs qui ont besoin de tenir compte des Core Web Vitals.
Pour l’instant, les SEOs techniques et la communauté des développeurs sont coincés à l’idée d’avoir à « corriger » ce qui n’est pas cassé dans le site afin de le faire respecter l’idée de Google de ce à quoi le web devrait ressembler.
Bien sûr, une page qui se charge rapidement et ne se déplace pas autour est une bonne chose. Mais exiger des utilisateurs d’un logiciel CMS d’améliorer le logiciel lui-même est un vrai fardeau.
À ce stade, le fardeau de la fixation du code incombe aux utilisateurs du logiciel de publication et non aux développeurs de ce logiciel. Vous trouvez ça normal, vous ?
Ce qui pourrait arriver, c’est que certains peuvent trouver utile de corriger autant qu’ils le peuvent et laisser le reste pour quand WordPress et d’autres logiciels CMS rattraperont le coup.
5 solutions pour améliorer les Core Web Vitals rapidement
Déjà, on a beaucoup parlé des principaux éléments des Signaux Web Essentiels. Plus particulièrement, comment accélérer un site Web.
C’est principalement parce que, des principaux éléments des Core Web Vitals, ce sont ceux qui sont liés à la vitesse de chargement du site web qui ont la pondération la plus élevée.
Bien sûr, beaucoup d’attention devrait être portée à l’amélioration de la vitesse du site. Toutefois, si vous voulez que tous les 3 éléments des Core Web Vitals passent au vert, vous allez devoir faire un peu plus que cela.
Avec cela, voici 5 façons faciles qui devraient aider à améliorer vos principaux Core Web Vitals.
- Mettre en œuvre un CDN :
Un CDN (Content Delivery Network) est un excellent moyen de s’assurer que votre site web est rapide pour tous les utilisateurs web à travers le monde. Il permet de réduire la distance entre l’utilisateur web et sa demande et l’emplacement du serveur pour obtenir les informations (où un CDN utilise plusieurs serveurs pour fournir des ressources). - Utilisez un cache :
Que donne 1593 x 4529 ? La réponse est 7 214 697, si vous avez passé le temps pour calculer cela.
Maintenant, si je vous demande ce qu’est encore 1593 × 4529, sachez qu’il est de 7 214 697, comme nous venons de le calculer, et de faire un dossier.
C’est exactement ce qu’un cache fait. Il peut améliorer radicalement la vitesse d’une page Web en pré-calculant la page avant que l’internaute n’y arrive. - Reporter de tout JavaScript, y compris les annonces :
Vous voudrez supprimer ou reporter tous les scripts de blocage de rendu qui pourraient influencer la vitesse de chargement de votre site Web.
Javascript empêche la page réelle d’être chargée dès le début. Ainsi, une meilleure façon d’améliorer le temps de chargement perçu est de « reporter » (repousser) les scripts, de sorte que la page se charge, puis les scripts. - Assurez-vous que votre police d’arrière-plan est un match similaire :
La plupart des sites Web utiliseront une police Google (Google Fonts). Le problème avec cela, comme nous l’avons vu plus haut dans cet article, est que, au moment du chargement, le texte se chargera sur la page, en utilisant une police de sauvegarde, puis chargera la police Google une fois que la demande de police a été chargée.
Cela peut causer du Cumulative Layout Shift (CLS) en raison d’une grande différence entre la police de sauvegarde et la police Google.
Ce que vous pouvez faire est d’utiliser cet outil Font Police Matcher pour choisir une police de sauvegarde aussi proche de la police Google que vous utilisez. - Purgez vos plugins inutiles :
Soyons honnêtes. Avez-vous besoin de chaque plugin unique sur votre site ? Vous trouverez probablement un ou deux plugins qui sont futiles ou peuvent être remplacés par quelque chose de beaucoup plus simple.
Si vous pouvez trouver des exemples pour cela sur votre site Web, faites exactement cela. Moins il y aura de code à charger sur un site Web, plus celui-ci sera rapide.
Bref, Google devrait cependant admettre que tout changement à réaliser pour rendre un site plus performant pour les Core Web Vitals devrait idéalement revenir aux développeurs d’outils de création de site CMS (sur lesquels il devrait exercer une pression forte) et non aux simples utilisateurs de CMS (WordPress, Blogger, Wix, Drupal, etc) que nous sommes.
Source : Searchenginejournal
