Core Web Vitals n’est pas vraiment votre problème?

1. Changement de paradigme dans la façon dont les sites sont développés
2. Réparer ce qui n’est pas cassé
3. Core Web Vitals – Inamical
4. Core Web Vitals n’est pas un problème WordPress
5. Les éditeurs et la communauté SEO ont le fardeau de la conformité
6. Google est-il utile?
7. Repenser la création des sites
8. Un moment de transition

Vous n’êtes pas seul si vous avez du mal à améliorer les scores Core Web Vitals et venir court. Des preuves anecdotiques suggèrent qu’il est difficile d’atteindre des performances de Core Web Vitals élevées. La raison en est que les éditeurs et le SEO essaient de réparer quelque chose qui n’est techniquement pas cassé.

Changement de paradigme dans la façon dont les sites sont développés

Nous sommes au début d’un changement de paradigme majeur dans la façon dont les pages Web sont créées. Un hôte Web plus rapide est utile, mais il ne résoudra pas les problèmes de Core Web Vitals.

Les Core Web Vitals sont calculés en aval sur l’appareil mobile qui parcourt vos pages Web sur un téléphone mobile à des vitesses 3G ou 4G. C’est de là que proviennent les données Core Web Vitals et un serveur Web rapide est peu utile à ce stade si le téléchargement est limité par une mauvaise connexion Internet au téléphone.

Publicité

Continuer la lecture ci-dessous

L’amélioration de Core Web Vitals concerne moins l’hébergement Web que la correction du code.

Réparer ce qui n’est pas cassé

WP Rocket a récemment repensé son site Web en utilisant Gutenberg. C’était une décision courageuse et presque imprudente étant donné que Gutenberg ne disposait pas de capacités d’édition de site complètes à l’époque.

Ils ont dû personnaliser la façon dont WordPress gère les CSS et JavaScript afin d’améliorer les scores d’expérience de page Google.

En d’autres termes, lors de la refonte de leur site Web pour obtenir de bons résultats pour Core Web Vitals, WP Rocket a dû personnaliser WordPress lui-même, pour en faire quelque chose pour lequel il n’avait pas été conçu.

Core Web Vitals – Inamical

Les standards Web Vitals de base ne sont pas quelque chose que les développeurs WordPress ont à l’esprit lors de la création de WordPress. C’est pourquoi l’intégration de tweets dans un article déclenchera un changement de disposition cumulatif.

WordPress et les thèmes ne codent pas pour Google. Ils codent pour les besoins des éditeurs qui, jusqu’en mai 2020, n’étaient pas un besoin des éditeurs.

Ce n’est pas seulement WordPress non plus. La plupart des autres systèmes de gestion de contenu ne contiennent pas les meilleures pratiques Core Web Vitals.

Publicité

Continuer la lecture ci-dessous

Cela ne signifie pas qu’il y a quelque chose qui ne va pas avec WordPress. Il n’y a rien de mal avec WordPress car Google dit qu’il y a quelque chose qui ne va pas.

Core Web Vitals n’est pas un problème WordPress

Les Core Web Vitals sont un ensemble de métriques développées indépendamment par Google et transmises à l’éditeur et à la communauté SEO pour travailler avec.

WordPress n’a rien à voir avec cela. 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 avance comme si Core Web Vitals n’existait pas. Alors que du côté des éditeurs et du référencement, ce sont les utilisateurs de WordPress qui sont chargés de «réparer» WordPress, Drupal, phpBB etc.

Dans un monde parfait, la tâche de créer un système qui répond aux besoins des utilisateurs incombe aux développeurs. Mais cela ne se produit pas.

WordPress ne voit même pas Core Web Vitals comme un problème WordPress.

Quand quelqu’un a commencé un fil de support dans les forums WordPress à ce sujet, ils ont été invités à demander dans le forum d’assistance de Google.

« Vous devriez demander sur un forum Google, car WordPress n’a rien à voir avec cela. »

Les éditeurs et la communauté SEO ont le fardeau de la conformité

Les éditeurs WordPress sont bloqués en essayant de rendre les sites Web conformes à une norme à laquelle ces sites n’ont jamais été conçus pour se conformer.

C’est la raison pour laquelle tant de personnes sont aux prises avec Core Web Vitals. Les éditeurs et les référenceurs sont chargés d’essayer de corriger quelque chose qui devrait idéalement être corrigé au niveau du code.

Améliorer les scores Core Web Vitals peut donner l’impression d’essayer d’améliorer les performances d’une Honda Civic aux normes d’une Chevy Corvette.

Les développeurs n’ont pas construit de Corvette. Ils ont construit une Honda Civic.

Mais Google exige que les conducteurs (pas les fabricants) améliorer les performances au niveau Corvette. Cela vous semble-t-il juste?

Est-il raisonnable de demander aux utilisateurs d’un logiciel 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.

Publicité

Continuer la lecture ci-dessous

Alors, pourquoi les éditeurs et la communauté SEO sont-ils chargés de réparer quelque chose dont ils ne sont que des utilisateurs?

Google est-il utile?

Google fournit de nombreux outils pour diagnostiquer les problèmes et propose des articles détaillés expliquant comment résoudre ces problèmes de codage.

Mais ce sont des problèmes de codage 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 du décalage de mise en page cumulatif, 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 courante du décalage de mise en page cumulatif est que les images n’ont pas de tailles de hauteur et de largeur déclarées. Google recommande des solutions de contournement exotiques, telles que l’utilisation de CSS pour styliser les images à l’aide de boîtes de rapport hauteur / largeur.

L’éditeur et le SEO moyens ne comprendront probablement pas ce que sont les boîtes de rapport hauteur / largeur et comment calculer les ratios à l’échelle du site de manière à ne pas casser le site Web.

Regarde à ceci et description des boîtes de rapport hauteur / largeur que Google associe et voyez si cela vous convient:

Publicité

Continuer la lecture ci-dessous

«Les carrés parfaits et les trucs 16: 9 sont excellents, mais les valeurs utilisées pour ceux-ci ne sont que de simples calculs. Un rapport hauteur / largeur 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 déterminer le haut du rembourrage pour notre SVG 1127,34 × 591,44 ci-dessus?

Une façon est d’utiliser calc (), comme ceci:

padding-top: calc (591,44 / 1127,34 * 100%); « 

Bonté gracieuse!

Voici un autre exemple. De nombreux modèles Web définissent régulièrement les largeurs d’image via CSS pour être automatiques (width: auto;) sans régler la hauteur et la largeur des images afin de rendre les images comme un logo à l’échelle de la taille pour s’adapter à un modèle, qu’il soit affiché sur un mobile ou un appareil de bureau. C’est une pratique de codage courante qui provoque un décalage de disposition cumulatif.

Ce sont les raisons pour lesquelles WP Rocket a dû creuser et apporter des modifications au CSS et au JavaScript à l’échelle du site.

Par exemple, WordPress Gutenberg charge tous les CSS existants, qu’ils soient nécessaires ou non. Le développeur de WP Rocket devait donc coder une solution pour cela.

Publicité

Continuer la lecture ci-dessous

C’est ainsi WP Rocket expliqué ce qu’ils ont fait dans le cadre de leur refonte:

«… Nous avons déprécié plusieurs blocs qui n’étaient pas utilisés. Nous avons créé un système de mise en file d’attente personnalisé pour que le bloc CSS et JS ne soit chargé qu’en cas de besoin. Il ne nous a fallu que quelques minutes pour développer ce système.

Nous avons également décidé de ne pas utiliser le fichier CSS Gutenberg. 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 création des sites

Il est important de comprendre le problème Core Web Vitals. Google exige que les éditeurs et les référenceurs mettent en place des solutions que la communauté de développement de CMS ne montre pas d’intérêt à aborder.

Voici un exemple des types de compromis auxquels nous sommes confrontés et de la manière dont Google change la façon dont nous développons des sites Web.

Parlons des polices.

Le blocage du rendu des ressources tierces peut avoir un impact négatif sur la plus grande peinture de contenu. Un goulot d’étranglement courant est le téléchargement de polices à partir d’un site tiers tel que Google Fonts.

Publicité

Continuer la lecture ci-dessous

Il existe un certain nombre d’astuces à appliquer qui combinent l’utilisation de l’attribut de lien de préchargement et peut-être du JavaScript, etc. qui rendent le processus de téléchargement de polices tierces Core Web Vitals convivial.

Mais est-ce que cela tuerait votre site de laisser cette police sophistiquée?

Une solution simple qui aidera à mieux marquer est de changer la police du site Web en une police sans empattement que les appareils Apple, Windows et Android ont déjà chargée dans leur système.

Le passage à une police attrayante intégrée à l’appareil signifie que le site n’a plus à attendre pour télécharger une police sophistiquée.

Une approche peut être quelque chose comme ceci:

font-family: Helvetica, Tahoma, sans-serif;

Si Android n’a pas déjà chargé Helvetica ou Tahoma dans le navigateur, l’appareil affichera le site en utilisant la police Roboto.

Capture d’écran de l’exemple de police Roboto

<img src="https://cdn.searchenginejournal.com/wp-content/uploads/2021/02/roboto-6034d70a0b4fb.png" alt="Capture d'écran de la police Roboto" />

Pour les personnes habituées à utiliser des polices sophistiquées, 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 niches hautement compétitives.

Publicité

Continuer la lecture ci-dessous

Ce type de décision est une évidence pour un site affilié axé sur la vitesse des pages 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 boîte) à l’avenir.

Les développeurs ont répondu à la demande de sites adaptés aux mobiles. Avec le temps, ils peuvent commencer à répondre à la demande de sites qui obtiennent de bons résultats pour Core Web Vitals.

La façon dont les systèmes CMS, les modèles et les plugins sont conçus n’a pas répondu aux besoins des éditeurs qui ont besoin de prendre en compte Core Web Vitals.

Pour le moment, les référenceurs technologiques et la communauté des développeurs sont obligés de «réparer» ce qui n’est pas cassé 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 qui ne se déplace pas est une bonne chose. Mais obliger les utilisateurs d’un logiciel à améliorer le logiciel lui-même est un fardeau.

Publicité

Continuer la lecture ci-dessous

À ce stade, le fardeau de la fixation du code incombe au utilisateurs du logiciel d’édition et non sur le développeurs de ce logiciel. Cela vous semble-t-il correct?

Ce qui peut arriver, c’est que certains peuvent trouver utile de réparer autant qu’ils le peuvent et laisser le reste pour le moment où WordPress et d’autres logiciels CMS se rattrapent.

— to www.searchenginejournal.com