WordPress - Arobasenet.com

Comment améliorer et accélérer la vitesse du site WordPress ?

Si vous souhaitez accélérer votre site WordPress, l’installation d’un plugin de mise en cache est l’un des meilleurs moyens d’améliorer vos temps de chargement. Continuer la lecture de « Comment améliorer et accélérer la vitesse du site WordPress ? »

14 problèmes courants de référencement et comment les résoudre

Beaucoup de gens considèrent le processus d’optimisation pour les moteurs de recherche (SEO) comme relativement simple, mais c’est tout simplement faux.

L’optimisation du contenu pour les moteurs de recherche nécessite beaucoup d’efforts et d’expertise, surtout si vous considérez que chaque année, il y a des mises à jour ou updates inattendues et erratiques de l’algorithme de Google.

Le référencement peut être défini comme le processus d’optimisation d’un site Web pour un classement plus élevé sur les pages de résultats des moteurs de recherche (SERP).

Il se compose principalement de deux activités : l’optimisation on-page et l’optimisation off-page. L’optimisation on-page fait référence à l’optimisation à l’intérieur d’un site Web, tandis que les pratiques off-page concernent plus la promotion du site, y compris l’obtention de backlinks.

Obtenir les résultats souhaités est un processus continu, le résultat dépend des stratégies appliquées et de la façon dont les problèmes de référencement sont traités.

Pour réussir à obtenir un ranking élevé pour votre site Web, il faut résoudre les problèmes de référencement rencontrés en cours de route. Les problèmes de SEO les plus courants (et leurs solutions) vous sont soumis ici de façon non-exhaustive.

1. Contenu dupliqué

Le même contenu présent sur différentes pages Web est connu sous le nom de contenu dupliqué.

Pour être considéré comme dupliqué par les moteurs de recherche, le contenu peut être identique à 100% ou proche du même. Avoir du contenu en double sur les sites Web crée de la confusion pour les robots d’indexation – les robots des moteurs de recherche ne comprennent pas quelle page explorer et classer.

Les étapes à suivre pour résoudre les problèmes de contenu en double sont les suivantes :

Utilisation de redirections 301
Utilisation de la balise canonique
Ajout de fichier robots.txt

2. Vitesse du site Web

Le temps passé par un utilisateur sur votre site Web dépend du temps de chargement de votre site Web.

Si la vitesse du site Web est bonne sur différents appareils, l’utilisateur ne sera pas irrité et restera sur le site Web. Il devient donc crucial d’avoir une bonne vitesse de chargement du site Web, qui devrait être inférieure à 2 secondes.

L’optimisation de l’image est l’action vitale à prendre en compte pour résoudre le problème de la vitesse de chargement du site Web.

L’optimisation de l’image comprend la sélection du format, le dimensionnement approprié, la compression de l’image et l’ajout de moins d’images avec la minimisation de JavaScript, CSS et HTML.

Il faut également télécharger moins de plugins et optimiser les bases de données.

3. Liens brisés

Les liens sur votre page Web qui ne fonctionnent pas sont connus sous le nom de liens brisés ou rompus. Il existe de nombreuses raisons pour qu’un lien soit rompu, comme renommer une page Web et ne pas modifier les liens internes, créer un lien vers du contenu qui a été supprimé ou déplacé, ou un lien vers une page tierce et donc ne pas savoir quand des modifications sont apportées à la page.

Les problèmes de liens brisés sont résolus en supprimant le lien rompu ou en le redirigeant vers le bon emplacement. La meilleure solution est de faire vivre à nouveau la page, surtout si des liens y figurent.

4. Ratio texte/HTML

Le rapport idéal pour le texte au format HTML devrait être de 25 à 70 %. Ce ratio détermine la quantité de texte qui sera visible par opposition aux éléments HTML.

Les sites avec un texte plus visible se classent plus haut sur les SERP. Pour résoudre le problème :

Validez le code HTML.
Vérifiez la vitesse de chargement du site Web.
Supprimez le texte caché.
Ajoutez du texte simple à la page.
Réduisez la taille d’une page et gardez-la sous 300 Ko.
Utilisez les liens internes.
Compressez vos images.

Balises ALT et images brisées

Les robots d’exploration ne peuvent pas lire les images. Dans ce cas, les balises ALT (texte alternatif) jouent un rôle crucial.

L’attribution de balises ALT appropriées en incluant des mots clés pertinents aide les robots d’exploration à lire l’image. Avec l’aide de balises ALT, Google sera en mesure de fournir les bonnes images sur la page de résultats selon la requête effectuée par l’utilisateur.

Les images brisées, en revanche, sont celles qui n’apparaissent pas.

Pour corriger les images brisées, commencez par vous assurer que vous avez bien téléchargé une image. Vérifiez le nom du fichier et l’extension, ne liez pas les fichiers de votre ordinateur et vérifiez vos chemins d’accès.

5. Balise title et balise meta description

Une meta description est « l’essentielle » de la page Web qui s’affiche sur la page du moteur de recherche et les balises de title aident les utilisateurs à comprendre le sujet après un clic sur le lien du titre.

Selon le référencement, pour obtenir un rang plus élevé sur les SERP, il devient essentiel d’optimiser les pages Web et les blogs en fournissant des balises title appropriées et des meta descriptions avec des mots-clés.

6. URL non optimisées

L’optimisation des URL implique l’insertion de mots clés pertinents et d’informations relatives à la page.

Ainsi, il devient facile pour l’utilisateur et les robots d’indexation de comprendre le contenu d’une URL.

Une URL doit être SEO-friendly ou descriptive. Par SEO-friendly, nous entendons inclure des mots-clés dans l’URL, l’utilisation de lettres minuscules, des traits d’union pour séparer les mots, avoir une URL statique et limiter les dossiers dans la structure de l’URL.

L’optimisation des URL vous aide également à éviter le contenu en double.

7. Navigation incorrecte

Une mauvaise navigation entre les pages Web internes confond les robots des moteurs de recherche.

Avoir une structure de site Web appropriée avec une navigation facile aide les robots d’exploration à explorer vos pages.

Il est bon d’avoir une structure de site Web hiérarchique claire pour réduire le taux de rebond. Suivez la règle des trois clics, par laquelle un utilisateur peut atteindre la page souhaitée en 3 clics sur le site Web.

8. Expérience mobile

Fournir une excellente expérience mobile devrait être une priorité pour les spécialistes du marketing.

Points à prendre en compte lors de la création de l’expérience mobile interactive pour les utilisateurs :

Conceptions de plateformes sur Android et iOS
Avoir un processus d’intégration transparent
Comprendre le contexte des interactions mobiles
Accessibilité conviviale
Tests réguliers

L’expérience utilisateur (UX) de votre site Web est renforcée lorsque les utilisateurs peuvent facilement accéder à vos pages et trouver les résultats souhaités selon leur recherche.

9. Indexation du Site

Les pages indexées sont celles que les robots d’indexation ont visitées, analysées et incluses dans leur base de données de pages Web (index).

Grâce à Google Search Console, les spécialistes du marketing peuvent demander que les pages de leur site soient indexées.

L’indexation est essentielle pour que votre site Web apparaisse sur les résultats de recherche, car les moteurs de recherche utilisent des mots clés et des métadonnées pour la recherche sur site.

10. Sitemaps au format XML

Les sitemaps XML sont une sorte de dossier qui permet aux moteurs de recherche de connaître toutes les URL de votre site Web avec le type de contenu que chaque page contient et comment le trouver.

Vous pouvez trouver le sitemap en tapant en général sitemap.xml à la fin du nom de domaine dans le navigateur.

Les sitemaps au format XML sont créés à l’aide d’outils en ligne tels que Slickplan, Mindnode, Writemaps, PowerMapper et via le plugin Yoast SEO.

Avec les sitemaps XML, il est également essentiel d’avoir un sitemap au format HTML. Le sitemap HTML est une page où toutes les sous-pages du site Web sont répertoriées. Ces sous-pages sont en général visibles par tous les utilisateurs dans le pied de page du site Web.

11. Robots.txt

Lorsque nous ne voulons pas partager certaines informations avec les moteurs de recherche, nous utilisons un fichier robots.txt.

Il s’agit d’un fichier texte créé par les webmasters pour indiquer aux robots d’exploration comment explorer le site Web. Avoir un fichier robots.txt n’est pas nécessaire pour tous les sites Web. On peut visualiser le fichier robots.txt en entrant « robots.txt » à la fin du domaine.

Pour créer un fichier robots.txt, utilisez un éditeur de texte et remplissez l’astérisque et la syntaxe selon les exigences. Créer un fichier robots.txt maximise votre budget de crawl de moteur de recherche.

12. Balise canonique

Les balises canoniques sont la meilleure option pour résoudre le problème du contenu dupliqué. Cela permet de supprimer la confusion de la page à explorer.

Il s’agit d’une balise meta appliquée au niveau de la page dans l’en-tête HTML d’une page Web.

Les problèmes canoniques sont triés de deux manières : en utilisant des redirections 301 ou en ajoutant des balises canoniques à vos pages Web pour permettre aux robots d’indexation de savoir quelle page préférer.

13. Utilisation des données structurées

Les données structurées permettent aux robots d’indexation et de recherche web de mieux comprendre vos données.

Elles sont également connues sous le nom de balisage schéma et améliorent le taux de clics, ce qui entraîne plus de prospects.

Il existe différents outils utilisés pour générer des données structurées, tels que Schema.org, Google Codelabs, Knowledge Navigator, JSON-LD, Schema Generator et plus encore.

Les données structurées incluent également des extraits enrichis (rich snippets) qui aident à améliorer les résultats de recherche sur les SERP.

14. Fonctionnement des formulaires de contact

Le formulaire de contact affiché sur le site web est la source de la génération de prospects.

S’il ne fonctionne pas correctement ou s’il est absent du site Web, cela entraînera une réduction des prospects et des conversions.

La création du formulaire de contact nécessite l’installation et l’activation du plugin WPForms pour le système de gestion de contenu (CMS) WordPress. Pour les autres CMS, cela peut être fait via des scripts et du codage.

Conclusion

Le référencement consiste à planifier vos stratégies après avoir fait des recherches sur les concurrents et l’avoir exécuté avec la bonne approche.

Un rapport d’audit SEO révèle tous les problèmes auxquels un site Web est confronté qui pourraient entraîner un classement inférieur.

Ces problèmes fondamentaux et techniques doivent être réglés le plus tôt possible pour plus de trafic.

La prise en considération de tous les points ci-dessus concernant la façon de résoudre les problèmes techniques de référencement aidera à atteindre un rang plus élevé pour votre site Web sur les moteurs de recherche et améliorer vos ventes.

4 façons d’optimiser pour Google Page Experience Update

Il n’est pas trop tard pour se préparer à la mise à jour de Google Page Experience ou encore de l’améliorer alors même qu’elle est en cours de déploiement.

Découvrez comment obtenir un avantage concurrentiel dans Search.

Si vous n’avez toujours pas réussi à optimiser les métriques Page Experience et que vos concurrents l’ont fait, vous constaterez peut-être qu’ils bénéficient d’un boost de classement que vous manquez.

Dans cet article, vous découvrirez trois domaines prioritaires clés qui vous aideront à vous améliorer pour Google Page Experience Update, ainsi que découvrir plusieurs autres problèmes à avoir sur votre liste de tâches.

1. Travaillez sur votre vitesse de chargement

Le premier des Core Web Vitals de Google est “Largest Contentful Paint” (LCP), qui fait référence au contenu le plus grand et le plus important d’une page Web.

Cette métrique déterminera la rapidité avec laquelle votre page restitue son contenu le plus important, afin que les utilisateurs puissent le voir.

Il existe un certain nombre de façons d’optimiser pour LCP.

Une chose que vous pouvez faire est d’optimiser votre serveur, car des temps de réponse lents peuvent parfois être liés à des serveurs lents.

L’accélération d’un serveur peut impliquer l’exécution de conseils de performances afin que le serveur affiche une page statique lorsqu’elle est demandée plutôt que de créer la page chaque fois que quelqu’un clique dessus.

D’autres composants de page Web qui peuvent ralentir le chargement LCP incluent des images, des vidéos et des éléments au niveau des blocs avec des fonctionnalités de texte.

Si ces éléments sur vos pages sont au-dessus de la ligne de flottaison, plus leur chargement est lent, plus votre LCP est lent.

Pour résoudre ces problèmes, vous devrez compresser vos images et fichiers texte, mettre en cache certaines ressources et précharger certains de vos éléments.

2. Travaillez sur votre interactivité

Le deuxième Core Web Vital est First Input Delay (FID). C’est le temps qu’il faut aux utilisateurs pour pouvoir interagir avec un élément sur lequel ils ont cliqué, tel qu’un lien ou un bouton.

Aux yeux de Google, votre FID devrait viser à être inférieur à 100 millisecondes. Mais parlons de ce que cela signifie.

Les lecteurs sont sans aucun doute familiers avec les pages Web qui les font attendre indéfiniment après avoir cliqué sur un élément pour accéder à une nouvelle page, modifier un panier d’achat, etc.

Eh bien, ce n’est pas bon pour les utilisateurs. Mais pourquoi cela se produit-il ?

C’est principalement parce que le navigateur est trop occupé par d’autres tâches, telles que l’analyse et l’exécution d’un fichier JavaScript lourd.

Maintenant, nous voulons nous concentrer principalement sur les premières interactions des utilisateurs avec une page Web, c’est-à-dire le temps nécessaire au chargement.

Tout comme pour rencontrer quelqu’un de nouveau, les premières impressions comptent. Si les utilisateurs savent dès le départ que votre site est plus lent qu’un escargot, ils partiront probablement et ne reviendront pas.

Mais une forte première impression – comme dans une page qui se charge rapidement – ira sur le long terme vers l’augmentation des engagements des utilisateurs avec cette page dans son ensemble.

C’est pourquoi FID est une mesure si importante. Comment y remédier ? Cela dépendra de votre site Web spécifique.

Utilisez des outils tels que PageSpeed Insights pour voir comment vous allez et où vous pouvez vous améliorer.

Vous voudrez peut-être vous pencher sur la division des tâches longues, la réduction de JavaScript et la hiérarchisation du chargement des scripts afin que les éléments les plus importants soient en premier disponibles pour les utilisateurs.

3. Travaillez sur votre Layout Shift (décalage de mise en page)

Enfin, nous avons le troisième Core Web Vital, le Cumulative Layout Shift (CLS). Il s’agit d’une mesure de la quantité de déplacement de la mise en page du contenu de votre page pendant le chargement de la page.

Vous avez probablement rencontré ce problème, aussi.

Vous attendez qu’une page se charge complètement et vous cliquez sur quelque chose pour constater qu’un autre élément a chargé sur la page et a donc poussé l’élément souhaité dans une autre direction.

En conséquence, vous avez cliqué sur quelque chose que vous ne vouliez pas, comme une annonce ou même un bouton « Soumettre la commande ».

Cela fait une mauvaise expérience utilisateur, et c’est pourquoi CLS est suffisamment important pour être considéré comme un élément principal de l’expérience de page ou Page Experience.

Comment pouvez-vous résoudre ce problème afin de profiter des classements que les Core Web Vitals peuvent fournir ?

Vous avez besoin d’un score CLS de 0,1 pour « passer » le test de Google. C’est le maximum que Google veut voir.

Aussi plus élevé, et vos pages Web sont susceptibles de changer un peu. Google considère qu’un score de 0,25 est médiocre.

Si vous utilisez un site WordPress, vous remarquerez probablement que les éléments suivants sont à l’origine de votre CLS :

Images et vidéos sans dimension.
Annonces sans dimension et autres objets intégrés.
Animations et autres contenus dynamiques.
Flashs de texte non stylé.

La correction de CLS s’applique principalement aux mobiles, car Google donne la priorité au mobile-first, mais aussi parce que les appareils mobiles ont des processeurs plus faibles et des ports d’affichage plus petits.

Que devrez-vous faire pour éliminer cette mise en page (layout) ? Cela dépend de ce qui en est la cause, mais si nous prenons 2 exemples ci-dessus :

Les navigateurs ne sauront pas comment espacer les images et les vidéos sans dimensions, ce qui signifie que les zones où elles seront éventuellement changeront probablement au fur et à mesure du chargement d’une page.Vous pouvez verrouiller cela en ajoutant des dimensions spécifiques à vos images et vidéos.
Ensuite, en ce qui concerne les flashs de texte non stylé, vous devrez précharger vos polices.Cela indique aux navigateurs de charger vos polices en tant qu’élément prioritaire – dans la première peinture significative (First Paint). Dans ce cas, vous n’aurez pas de modifications de police discordantes qui entraîneront des cumulative layout shifts ou changements de disposition cumulatifs.

4. Autres éléments de Page Experience à garder à l’esprit

Bien sûr, les Core Web Vitals ne sont pas les seules choses que vous devez étudier pour optimiser votre site pour la mise à jour de l’expérience de page.

Prenez la compatibilité mobile.

Google jugera désormais chaque site par sa compatibilité mobile, en particulier en ce qui concerne des problèmes tels que les petites tailles de texte et l’utilisation des médias Flash, que les appareils mobiles d’aujourd’hui ont tendance à ne pas prendre en charge.

Il y a aussi la question du rapport Expérience sur la page dans Google Search Console.

Il s’agit d’une ventilation des performances de votre site pour Google Page Experience Update, mais qu’en est-il de tous ces propriétaires de sites disant qu’ils ne voient aucune donnée ?

Google a confirmé qu’un rapport vide signifie simplement qu’il n’y a pas assez de données concluantes pour dire dans un sens ou dans l’autre comment votre site fonctionne.

Même si vous avez un trafic décent, la réponse est probablement que vous avez juste besoin de plus de trafic – et pour que ce trafic génère des données pertinentes – si vous voulez que le rapport soit rempli.

Google veut voir une bonne expérience utilisateur non seulement dans le contenu organique, mais aussi avec la publicité.

Vérifiez et assurez-vous que les annonces sur votre site ne sont pas interruptives ou distrayantes.

Et n’oubliez pas que votre site doit être sécurisé (HTTPS) si vous voulez bien faire par la mise à jour de l’expérience de page.

HTTP non sécurisé n’est plus conseillé. Les utilisateurs doivent savoir que leurs données sont sécurisées avec vous sur votre site – et Google doit également le savoir.

La Page Experience Update a été lancé en deux temps

Il y a beaucoup à gérer en ce qui concerne vos Signaux Web Essentiels ou Core Web Vitals et votre Expérience de page, mais en fin de compte, il s’agit de fournir la meilleure expérience utilisateur possible.

Si vous n’avez pas encore prévu de temps pour vérifier et optimiser ces éléments, vous voudrez le faire dès que possible.

Mais pas de panique. Vous ne serez pas pénalisés algorithmiquement pour ne pas vous être encore alignés sur tous les Core Web Vitals et les éléments d’expérience de page.

Cette mise à jour est une sorte de bris d’égalité, selon Google. Si toutes les autres choses sont considérées comme égales, offrir une meilleure expérience telle que déterminée par les métriques ci-dessus pourrait vous donner l’avantage.

Et si vous voyez les classements chuter, ce n’est pas parce que vous êtes punis. Il se peut que vos concurrents directs donnent la priorité à ces optimisations et que vous, vous ne le faîtes pas.

C’est une incitation à bouger !

Source : Searchenginejournal

Twitter serait partant pour adopter l’initiative FLoC de Google

Dire que FLoC, une technologie construite par Google pour remplacer les cookies tiers, a été controversée est presque un doux euphémisme.

De nombreuses entreprises technologiques se sont prononcées contre ou, tout comme WordPress, ont délibérément évité ou bloqué la technologie FLoC, mais il semble que Twitter soit partant pour s’associer à Google pour adopter lui aussi la technologie FLoC.

Jane Wong rapporte que Twitter travaille actuellement sur la collecte de données pour FLoC via son site Web.

Le code source illustré dans le Tweet intégré ci-dessous semble confirmer explicitement le détail. Nous avons également observé indépendamment les mentions de FLoC dans le code source de Twitter.

Cette nouvelle vient quelques semaines seulement après qu’il a été révélé qu’Amazon bloquait lui aussi explicitement FLoC à la fois par des méthodes officielles et non officielles.

Bien sûr, cela vient alors que Google en est encore aux premiers jours d’apporter FLoC à ses utilisateurs. La technologie, jusqu’à présent, n’a pas été confirmée pour à peu près tous les navigateurs grand public et est publiquement rejetée par certaines options soucieuses de la vie privée.

Google a également récemment reporté son échéance pour déployer la technologie aux masses de près d’une année complète. En l’état actuel des choses, FLoC ne se déploie que pour certains utilisateurs du navigateur Google Chrome.

Twitter is working on collecting FLoC from users

FLoC is a web tracking tech created by Google that groups people into “cohorts” based on their browsing history https://t.co/Wjn6fh2DIV pic.twitter.com/QA1B2ztyXX

— Jane Manchun Wong (@wongmjane) July 2, 2021

Twitter travaille sur la collecte de FLoC auprès des utilisateurs.

FLoC est une technologie de tracking Web créée par Google qui regroupe les utilisateurs en « cohortes » en fonction de leur historique de navigation.

Google reporte FLoC à la mi-2023

Google a annoncé début Mars 2021 que les cookies tiers sont terminés – du moins, en ce qui concerne ses réseaux publicitaires et son navigateur Chrome.

Cela représente un changement important pour le secteur de la publicité et semble être un pas en avant pour la vie privée, mais c’est aussi un changement limité. Cela ne signifie pas que Google cessera de collecter vos données, et cela ne signifie pas que l’entreprise cessera d’utiliser vos données pour cibler les annonces.

Ce que Google cessera de faire, c’est de vendre des publicités Web ciblées sur les habitudes de navigation des utilisateurs individuels, et son navigateur Chrome n’autorisera plus les cookies qui collectent ces données.

Les sociétés de publicité qui s’appuient sur les cookies devront trouver un autre moyen de cibler les utilisateurs. Google pense qu’il l’a déjà fait.

Pendant ce temps, Google suivra et ciblera toujours les utilisateurs sur les appareils mobiles, et il ciblera toujours les annonces aux utilisateurs en fonction de leur comportement sur ses propres plates-formes, qui constituent la majorité de ses revenus et ne seront pas affectées par le changement.

En d’autres termes, bien que l’annonce aura d’énormes implications pour l’industrie de la publicité numérique, elle ne le fera probablement pas pour Google lui-même.

Les cookies tiers sont utilisés par les plates-formes publicitaires pour vous suivre lorsque vous vous déplacez sur Internet, en créant un profil de vous et de vos centres d’intérêt en fonction des sites que vous visitez et en l’utilisant pour vous envoyer des publicités.

Les cookies tiers de Google se trouvent sur des millions de sites Web, alimentant l’entreprise d’une tonne d’informations sur les sites que vous visitez, ce qui alimente une partie de son énorme activité publicitaire.

Mais le public est de plus en plus conscient des questions de protection de la vie privée ces jours-ci, et les organismes de réglementation adoptent de plus en plus de lois sur la protection de la vie privée.

C’est là qu’intervient l’apprentissage fédéré des cohortes ou Federated Learning of Cohorts (FLoC) de Google, qui, selon Google, est une technologie publicitaire « axée sur la vie privée » et « est basée sur les centres d’intérêt ».

Avec FLoC, Chrome gardera une trace des habitudes de navigation d’un utilisateur sur le Web, puis placera l’utilisateur dans diverses audiences, ou « cohortes », en fonction de ces habitudes.

Les annonceurs cibleront ensuite leurs annonces sur des cohortes, plutôt que sur un utilisateur individuel.

Donc, si vous recherchez un navigateur qui ne collecte pas vos données pour les publicités – en tant qu’individu ou dans le cadre d’une audience anonyme – vous voudrez peut-être en essayer un autre.

Soit dit en passant, vous pouvez désactiver la personnalisation des annonces, le suivi des activités et supprimer les données que Google a collectées à votre sujet ici.

Google vous fournira donc techniquement des publicités ciblées, mais il le fera de manière plus anonyme et moins effrayante.

Google affirme que les annonceurs peuvent obtenir presque le même retour sur investissement de FLoC qu’ils le feraient grâce au tracking basé sur les cookies, et teste actuellement FLoC avec les annonceurs pour voir s’il fonctionnera comme son remplacement de cookie.

FLoC peut ne pas fonctionner à la fin, mais Google est au moins assez confiant en lui pour déclarer que les cookies vont mourir, et encore une fois, Google ne les remplacera pas par un type similaire de tracker individuel.

Mais, Google prévoit désormais d’éliminer progressivement les cookies tiers dans Chrome d’ici 2023.

Google a aussi déclaré que Chrome cherchait à « éliminer progressivement les cookies tiers sur une période de 3 mois, à partir de la mi-2023, et ce, jusqu’à la fin de 2023 ».

Ce calendrier est soumis à l’approbation de l’Autorité de la concurrence et des marchés du Royaume-Uni.

Avant que cela ne se produise, l’entreprise souhaite que les « technologies clés » aient été lancées d’ici la fin de 2022. Cela inclut le FLoC (chrome://settings/privacySandbox) largement désactivé et d’autres API de préservation de la vie privée.

Dans l’ensemble, il s’agit du plan en deux étapes pour les cookies tiers dans Google Chrome:

Étape 1 (à partir de fin 2022) :
Une fois le test terminé et les API lancées dans Chrome, Google annoncera le début de l’étape 1.Au cours de l’étape 1, les éditeurs et l’industrie de la publicité auront le temps de migrer leurs services. Google s’attend à ce que cette étape dure 9 mois, et il surveillera attentivement l’adoption et les commentaires avant de passer à l’étape 2.
Étape 2 (à partir de la mi-2023) :
Chrome supprimera progressivement la prise en charge des cookies tiers sur une période de 3 mois se terminant fin 2023.

Ce qu’il faut bien comprendre, c’est que Google en a fini avec les cookies, mais cela ne signifie pas qu’il a fini de vous suivre.

Une interdiction des cookies tiers ne nuira pas à l’activité publicitaire de données de première partie du géant de la recherche.

Lors de l’annonce de 2020, Google avait déclaré qu’il visait l’élimination progressive « d’ici deux ans ». L’entreprise fournira bientôt un calendrier plus détaillé qui sera mis à jour régulièrement.

En attendant, c’est Twitter qui apporte un soutien de poids à FLoC de Google.

Source : 9to5google

96% des sites ne passent pas les 3 signaux Core Web Vitals

À l’approche du lancement de l’algorithme Google Page Experience Update, cette étude de Searchmetrics révèle comment les sites Web fonctionnent par rapport aux points de repère de Google.

Une grande expérience utilisateur est au cœur de Google Core Web Vitals Update et les nouvelles mesures pourraient avoir un impact significatif sur votre classement !

Dans l’étude approfondie de Searchmetrics.com, il a été découvert que seuls 4% des sites Web ont obtenu un bon score dans tous les 3 signaux Core Web Vitals.

.

Vous ne pouvez donc pas ignorer l’impact futur que Core Web Vitals pourrait avoir sur votre site Web.

Découvrez les gagnants et les perdants actuels, comment Searchmetrics.com a évalué leurs scores et utilisé ces informations pour réduire le risque que les Core Web Vitals affectent le rendement de votre entreprise.

La communauté SEO s’apprête à accueillir la prochaine mise à jour de Core Web Vitals, qui devrait être lancé à la mi-Juin 2021.

Ce nouvel algorithme Google met l’accent sur l’expérience utilisateur.

Trois mesures de Core Web Vitals (CVW) – Largest Contentful Paint, First Input Delay et Cumulative Layout Shift – évalueront les éléments critiques de l’expérience utilisateur, y compris la stabilité visuelle, l’expérience de chargement de la page et l’interactivité.

Cette performance sera ensuite utilisée comme signal de classement et devrait affecter le classement des pages.

Mais pour beaucoup, cette mise à jour soulève plus de questions que de réponses :

Dois-je changer quelque chose sur mon site web pour me préparer à cette mise à jour ? Si oui, quoi ?
Google va-t-il immédiatement déclasser les classements des sites web ayant de mauvais scores CWV ?
Dans quelle mesure les sites Web concurrents sont-ils performants en termes de CWV ? Quels repères dois-je viser ?
D’autres facteurs de classement sont-ils interconnectés avec mon score Core Web Vitals ?
Dans quelle mesure est-il facile d’optimiser les sites Web créés avec des plateformes builder/CMS telles que WordPress ou Wix ?
Les entités de Google (p. ex., YouTube) obtiennent-elles de bon résultats dans Core Web Vitals ?

Searchmetrics a donc voulu dans son étude approfondir et trouver des réponses axées sur les données à ces questions.

Il a donc analysé plus de 2 millions d’URL à travers les Core Web Vitals et d’autres mesures pour comprendre :

La performance des sites Web.
Si les repères de Google sont réalistes et utiles pour les entreprises.

Mais avant de plonger dans les données, nous allons comprendre ce que sont les Core Web Vitals et, plus important encore, la logique derrière eux.

Qu’est-ce que Core Web Vitals & ses Benchmarks ?

Il existe trois paramètres Core Web Vitals :

Largest Contentful Paint (LCP) mesure le temps de rendu du plus grand bloc d’image ou de texte visible dans le viewport.L’idée clé est de fournir une mesure simple qui montre la rapidité avec laquelle le contenu principal d’une page se charge.
Pour fournir une bonne expérience utilisateur, LCP doit se produire dans les 2,5 secondes qui sont après le début du chargement de la page.
First Input Delay (FID) mesure quand un utilisateur interagit pour la première fois avec la page.Pour fournir une bonne expérience utilisateur, les pages doivent avoir un FID de moins de 100 millisecondes.
Cumulative Layout Shift (CLS) est un score qui mesure la quantité de changements du contenu pendant le rendu des pages.Beaucoup de changement de contenu crée une expérience utilisateur négative.
Pour offrir une bonne expérience utilisateur, les pages doivent maintenir un CLS inférieur à 0,1.

Il existe trois paramètres Core Web Vitals

Qu’est-ce que Google essaie d’accomplir avec Core Web Vitals ?

D’après Google, cette mise à jour a 2 objectifs principaux :

Pour accroître l’accent mis par Google sur l’expérience utilisateur. En termes simples, si un utilisateur a une bonne expérience sur une page Web, Google devrait classer cette page plus haut.
Faciliter la conception des performances du site Web par les marques et les entreprises et améliorer l’expérience utilisateur.

Pourquoi maintenant ?

Nous vivons dans un monde où les utilisateurs veulent profiter d’un contenu de haute qualité aussi bien que possible sur tous les appareils. Mais les sites Web le fournissent-ils ?

Nous savons tous combien il est frustrant de rechercher rapidement un article de news pour constater que la page prend une éternité pour se charger.

Lorsque vous arrivez enfin sur la page et faites défiler ou cliquez sur quelque chose alors que la page bouge ou change, comme une bannière publicitaire qui tente de vous vendre quelque chose.

Google Core Web Vitals Update est à bien des égards une réponse aux sites Web qui ne sont pas à la hauteur des attentes des utilisateurs. C’est un message clair que ne pas donner la priorité aux utilisateurs peut avoir un effet négatif sur votre ranking.

Qu’est-ce qui cause de mauvaises performances web?

De nombreux facteurs sont à l’origine de mauvaises performances web.

À bien des égards, les temps de chargement lents sont un symptôme de ce qui est devenu une pratique courante pour la création d’un site Web.

Les plates-formes de création de sites Web

Plutôt que de créer quelque chose sur mesure, les entreprises se tournent de plus en plus vers les créateurs de sites Web tels que Squarespace ou Wix pour gagner du temps.

Le problème est que ces constructeurs de sites Web sont faciles à utiliser sur la surface, ils peuvent être difficiles à optimiser sous le capot.

Souvent, les pages Web conçues à l’aide de ces modèles chargent tous les scripts, feuilles de style et blocs de code même s’ils ne sont pas nécessaires.

Cela peut provoquer ce qu’on appelle un ballonnement de code – lorsque du code inutile est chargé sur une page Web, ce qui entraîne des temps de chargement de page lents.

Économie Web centrée sur le plugin

La logique d’une plate-forme comme WordPress est également centrée sur le plugin.

Cela signifie que si vous avez besoin de faire quelque chose au-delà de l’ajout de contenu de base, comme l’optimisation des images ou le lazy loading sous la ligne de flottaison, alors vous aurez besoin d’utiliser un plugin.

Ces plugins sont des solutions rapides, mais sont une autre source de ballonnement de code.

Les chiffres de l’étude de Searchmetrics

L’étude de Searchmetrics sur Google Core Web Vitals a révélé que moins de 4% des sites Web américains qui ont été analysés obtiennent un score « Bon » dans tous les 3 Core Web Vitals.

Bien que les sites se classant dans le top 5 des positions de recherche Google ont légèrement mieux performé que ceux en dehors de ce top 5, ils avaient toujours les mêmes problèmes de performances globales.

Les sites Web manquent de stabilité visuelle

La plus grande pierre d’achoppement a été la stabilité visuelle, mesurée par le Cumulative Layout Shift. Peu de sites Web ont obtenu un score \ »Bon\ » dans cette mesure.

Searchmetrics dit avoir trouvé que le score moyen du CLS du Top 20 se situe à 0,38, bien au-dessus du bon seuil de Google qui est de 0,1 et même en dehors du seuil modéré de 0,25.

Cela s’explique par l’augmentation du contenu dynamique tels que les emplacements publicitaires, les boîtes d’abonnement aux newsletters et les sites Web ne réservant pas d’espace dans la mise en page pour ces éléments.

Le ballonnement du code est réel

Compte tenu du nombre de sites Web créés par des plates-formes telles que Squarespace et Wix, les données de Searchmetrics confirment que le ballonnement du code (Bloat code) est un véritable problème.

En moyenne, les 20 principaux sites Web américains sur Google Search pourraient économiser environ 1 seconde en temps de chargement de page simplement en supprimant le JavaScript inutilisé.

Les images et vidéos sont encore mal optimisées

L’une des principales causes de la lenteur de la vitesse de chargement était les fichiers d’actifs volumineux tels que les images et les vidéos.

Les sites Web devraient viser à reporter le chargement de tout actif en bas de la ligne de flottaison et se concentrer uniquement sur ce qui est nécessaire.

L’utilisation de formats de nouvelle génération comme le WebP de Google peut également entraîner une réduction substantielle de la taille de l’actif.

Qu’en est-il de YouTube ?

Searchmetrics a également filtré YouTube des résultats.

Fait intéressant, il a remarqué une amélioration significative des mesures liées à la vitesse de chargement.

Cela signifie que YouTube fonctionne mal dans des mesures telles que Largest Contentful Paint.

En tant que site web lourd d’actifs, il faut s’y attendre, cependant, YouTube parvient à surmonter cela et se classe toujours haut.

Les benchmarks de Core Web Vitals de Google sont-ils réalistes ?

Searchmetrics a analysé les performances des Core Web Vitals pour le bureau et le mobile et il estime que – peut-être étonnamment –

Mais pourquoi est-ce que c’est comme ça ?

Google étrangle les données pour émuler un appareil mobile de milieu de gamme lors de l’analyse des performances mobiles.

Toutefois, cela conduit à des temps lents qui ne reflètent pas nécessairement l’état actuel du web mobile.

Alors est-il juste de punir les sites Web pour les mauvais scores Core Web Vitals ?

Les efforts déployés par Google pour rendre les mesures de l’expérience utilisateur plus transparentes pourraient aider les entreprises à améliorer objectivement leurs sites pendant leur développement.

Plutôt que de demander des fonctionnalités et des éléments de conception, les entreprises pourraient informer les cibles Core Web Vitals que les développeurs web doivent atteindre.

Cependant, c’est plus difficile à imaginer pour les créateurs web “out-of-the-box” comme Wix et WordPress.

Ils comptent souvent sur le chargement de nombreux éléments de mise en page dynamique et l’utilisation de plugins JavaScript pour accomplir des tâches relativement basiques.

Pour rester compétitives, ces plates-formes CMS devront améliorer leur jeu en aidant les sites Web à atteindre les objectifs d’expérience utilisateur et en offrant des moyens transparents pour optimiser les performances du site Web.

Core Web Vitals affectera-t-il les classements en Juin 2021 ?

C’est la question à 1 million de dollars.

Avec tant de sites Web qui fonctionnent mal dans les Core Web Vitals, il semble peu probable que Google punissent les entreprises dans l’ensemble.

Toutefois, l’analyse complète de Searchmetrics devrait servir de rappel que l’expérience utilisateur n’est actuellement pas assez bonne sur la plupart des sites Web.

S’attaquer à ce problème maintenant, ainsi que les meilleures pratiques de développement web qui placent l’utilisateur au centre de la scène, sera bénéfique à long terme.

Il est difficile de prédire exactement combien Google utilisera les scores Core Web Vitals pour déterminer les classements, mais il est certain que les sites Web avec d’excellentes expériences utilisateur auront un avantage concurrentiel crucial.

Une bonne expérience utilisateur envoie de bons signaux d’utilisateur à Google qui vont favoriser ou booster les classements.

Source : Searchenginejournal

WordPress propose de bloquer FLoC de Google par défaut

On estime que 40% de tous les sites utilisent WordPress. Si la proposition est mise en œuvre, cela pourrait être un coup dévastateur pour les capacités de ciblage publicitaire de Google.

WordPress propose de bloquer FLoC par défaut

Une proposition qui bloquerait le remplacement de Google pour les cookies tiers, Federated Learning of Cohorts (FLoC), par défaut sur les sites WordPress a été présentée dimanche.

On estime que plus de 40% de tous les sites utilisent WordPress, ce qui signifie que si cette proposition est implémentée, une part substantielle du comportement de navigation peut être cachée à la technologie de ciblage publicitaire de Google.

Comment ça va fonctionner ?

En vertu de la proposition, FLoC serait désactivé par l’ajout de quelques lignes de code qui désengagent les sites WordPress de transmettre la cohorte d’intérêt de l’utilisateur à Google.

Cette fonctionnalité n’est pas unique à WordPress; chaque langage de programmation qui alimente les sites Web comporte généralement une fonctionnalité similaire.

Ce serait relativement facile à implémenter si un propriétaire de site Web ou un développeur voulait le faire, mais si WordPress désactive FLoC par défaut, cela pourrait être un coup à grande échelle pour les capacités publicitaires de Google.

Pourquoi le bloc a été proposé ?

La proposition de WordPress cite l’article de l’Electronic Frontier Foundation intitulé « FLoC de Google est une idée terrible » et déclare que

De plus, la proposition mentionnait également les préoccupations relatives à la protection de la vie privée associées au suivi des utilisateurs et au partage de leurs données « apparemment sans consentement éclairé ».

Pour ces raisons, WordPress traite FLoC comme un problème de sécurité, ce qui signifie qu’il peut patcher la prochaine version mineure pour bloquer FLoC et apporter aussi le patch aux versions précédentes de WordPress.

De nombreux sites WordPress reportent la mise à jour lorsqu’une nouvelle version majeure sort parce que la mise à jour peut causer des problèmes de compatibilité avec d’autres parties de leur site, de sorte que le blocage de FLoC dans la prochaine version mineure ainsi que dans les versions précédentes de WordPress peut signifier que le code FLoC-disabling (qui désactive FLoC) apparaît sur plus de sites plus tôt.

WordPress rejoint un groupe croissant d’opposants à FLoC

Les arguments de l’Electronic Frontier Foundation contre FLoC ont été repris par les acteurs de différents secteurs de l’Internet : les navigateurs Vivaldi et Brave basés sur le Chrome désactivent l’extension Chrome de FLoC et DuckDuckGo bloque également FLoC.

Les principaux rivaux de Google sur le marché des navigateurs, Microsoft, Mozilla et Apple, ne se sont pas engagés à bloquer FLoC.

Microsoft et Mozilla évaluent diverses propositions (y compris FLoC) qui combleraient le vide laissé par les cookies tiers, selon The Verge a tweeté une position similaire.

Néanmoins, il est très peu probable que leurs navigateurs soutiennent finalement la proposition de Google.

Pourquoi s’en soucier ?

WordPress est le système dominant de gestion de contenu, de sorte que le blocage de FLoC par défaut pourrait obscurcir une part significative du comportement de l’utilisateur.

Cela diminuerait, à son tour, la capacité des annonceurs à atteindre efficacement les clients potentiels par le biais du ciblage basé sur les cohortes de Google.

Google a déclaré qu’il allait mettre fin à la prise en charge des cookies tiers dans le courant de 2022. Toutefois, à mesure que FLoC va de l’avant pour remplacer les cookies tiers, de plus en plus d’acteurs soulignent le fait qu’il ne peut pas protéger les utilisateurs, ou qu’il peut être anticoncurrentiel.

Cette date limite de 2022 que Google a fixé pour lui-même est maintenant en vue, mais il semble que Google est le seul à bord avec FLoC.

Comme les cookies tiers sont en fin de course, le Web décidera si FLoC est un succès ou pas — cette proposition de WordPress peut être considérée comme un vote très important contre FLoC.

Source : Searchengineland

Facebook facilite l’exportation des posts textuels vers WordPress, Docs et Blogger

Facebook a annoncé une nouvelle fonctionnalité qui permettra aux utilisateurs d’exporter leurs publications et Notes Facebook vers un certain nombre de services tiers.

Bien que l’entreprise offre depuis longtemps des outils qui vous permettent de télécharger les informations que vous avez publiées sur Facebook, le lancement de l’outil aujourd’hui offre un moyen plus pratique d’enregistrer ces données — en vous permettant d’exporter vos Notes et publications textuelles vers des services populaires comme Google Docs, Blogger ou WordPress.com.

Facebook déclare dans son post :

Pour donner aux gens plus de contrôle et de choix sur leurs données, nous introduisons aujourd’hui deux nouveaux types de portabilité des données, les publications Facebook et les Notes.

Les utilisateurs peuvent désormais transférer directement leurs Notes et posts vers Google Docs, Blogger et WordPress.com.

Ces mises à jour étendent la portée de l’outil qui permet déjà aux gens de transférer leurs photos et vidéos vers Backblaze, Dropbox, Google Photos et Koofr.

Afin de mieux refléter la gamme des types de données que les gens peuvent désormais transférer aux services de nos partenaires, nous rebaptisons l’outil « Transférez vos informations ».

Les utilisateurs de Facebook trouveront cette dernière fonctionnalité sous le menu « Vos informations Facebook » dans “Paramètres”, où vous cliquerez ensuite sur « Transférer vos informations ».

Vous pouvez y sélectionner la destination pour transférer les données (Google Docs, WordPress.com ou Blogger), vous connecter au compte que vous sélectionnez et confirmer le transfert.

Une série d’invites vous permettra de passer à travers le processus de transfert de vos données vers l’une des destinations disponibles.

Pour protéger les données, Facebook dit qu’il demandera aux utilisateurs de saisir à nouveau leur mot de passe avant le début du transfert, ce qu’il fait également avec d’autres exportations.

Le processus va chiffrer les données au fur et à mesure qu’elles se déplacent entre Facebook et l’autre service, note l’entreprise.

Cette nouvelle fonctionnalité s’inscrit dans le cadre du Data Transfer Project, une initiative de partage de données inter-entreprises lancée en 2018 dans le but de vous permettre de déplacer les données sur différents services et plateformes en ligne de manière transparente.

Apple, Google, Microsoft et Twitter sont également impliqués dans le projet, offrant des outils similaires d’exportation de données.

La fonctionnalité est pratique pour les utilisateurs qui souhaitent partager des publications ou des notes spécifiques qu’ils ont créées via Facebook. Néanmoins, il est important de noter que les données transférées n’archiveront pas les commentaires d’autres utilisateurs puisque ces commentaires sont considérés comme appartenant à un compte distinct.

Les nouveaux outils d’exportation de données aident Facebook à s’aligner sur deux lois récentes sur la réglementation technologique : la Consumer Privacy Act de Californie et le Règlement général sur la protection des données (RGPD) de l’Union européenne.

Les deux lois exigent que les entreprises fournissent des renseignements personnels dans un format facilement utilisable sur demande, bien que les détails du format et des mesures d’interopérabilité ne soient pas précisés.

Source : Theverge

Le SEO est à la poursuite des Core Web Vitals de Google

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 :

… 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.

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

WordPress atteint les 40% de part de marché de tous les sites Web

WordPress a atteint la barre fatidique des 40% de part de marché de tous les sites Web du monde contre 35,4% en janvier 2021, mais 64,3% de tous sites Web utilisant un CMS (système de gestion de site), selon les données de W3Techs.

Ces chiffres sont dérivés du Top 10 millions de sites Web d’Alexa, ainsi que du Top 1 million de la liste de Tranco liste.

Selon les estimations de W3Techs, toutes les 2 minutes, un autre site du Top 10 millions commence à utiliser WordPress.

Parmi les 1.000 premiers sites, la part de marché de WordPress est encore plus élevée, à 51,8 %, et s’élève à 66,2 % pour les nouveaux sites.

En suivant le taux de croissance au cours des 10 dernières années, W3Techs montre WordPress en pente constante vers le haut.

Matthias Gelbmann, PDG de Q-Success, maison mère de W3Techs, a expliqué les raisons de la méthodologie :

La raison pour laquelle nous ne comptons pas tous les sites Web, c’est parce qu’il y a tellement de noms de domaine qui ne sont pas utilisés ou sont utilisés à des fins douteuses.

Nous voulons exclure les millions de domaines, de sites de spam et de sites stationnés (parqués) qui n’ont tout simplement pas de contenu réel. Nous sommes convaincus que l’inclusion de tous les domaines trash rendrait nos statistiques beaucoup moins utiles, car des millions d’entre eux exécutent simplement une pile de logiciels qui génère automatiquement du contenu inutile.

Afin de mesurer le « Web significatif », la méthodologie de W3Techs exclut les sites avec des pages de contenu affichées par défaut par Apache, Plesk et cPanel, les noms de domaine expirés et les pages suspendues de compte.

Il exclut également les sites avec le message WordPress par défaut (« Bonjour le monde ! Bienvenue sur WordPress. C’est votre premier post. Modifiez ou supprimez-le, puis commencez à écrire! »).

En janvier 2021, Squarespace a dépassé Drupal et Wix pour devenir le 4ème CMS le plus populaire avec 2,5% de part de marché, derrière Joomla (3,4%), Shopify (5,3%) et WordPress (64,3%), concernant les CMS.

Bien que la plupart des CMS open source sont maintenant en déclin progressif avec des concurrents propriétaires en hausse, WordPress reste un phare du logiciel libre pour la création de site qui continue de soutenir son incroyable croissance.

Source : Wptavern

.tb_button {padding:1px;cursor:pointer;border-right: 1px solid #8b8b8b;border-left: 1px solid #FFF;border-bottom: 1px solid #fff;}.tb_button.hover {borer:2px outset #def; background-color: #f8f8f8 !important;}.ws_toolbar {z-index:100000} .ws_toolbar .ws_tb_btn {cursor:pointer;border:1px solid #555;padding:3px} .tb_highlight{background-color:yellow} .tb_hide {visibility:hidden} .ws_toolbar img {padding:2px;margin:0px}.tb_button {padding:1px;cursor:pointer;border-right: 1px solid #8b8b8b;border-left: 1px solid #FFF;border-bottom: 1px solid #fff;}.tb_button.hover {borer:2px outset #def; background-color: #f8f8f8 !important;}.ws_toolbar {z-index:100000} .ws_toolbar .ws_tb_btn {cursor:pointer;border:1px solid #555;padding:3px} .tb_highlight{background-color:yellow} .tb_hide {visibility:hidden} .ws_toolbar img {padding:2px;margin:0px}

Google ajoute l’animation et la monétisation au plugin Web Stories

Les mises à jour du plugin WordPress Web Stories facilitent la monétisation et apportent de nouvelles fonctionnalités de conception qui aident les éditeurs à créer un réseau web plus attrayant.

Google a annoncé des mises à jour pour le plugin WordPress Web Stories, l’amenant à la version 1.3.0.

Les mises à niveau prennent en charge une option de publicité basée sur des formulaires pour faciliter la monétisation ainsi que d’autres options de conception créative comme l’animation et des mises en page supplémentaires.

Pour rappel, le plugin Web Stories pour WordPress est un nouveau type de contenu pour le web. L’idée est de fournir du contenu « consommable immédiatement », du contenu de courte durée, que les consommateurs de contenu peuvent lire en de courtes pauses.

Les Web Stories sont donc un format pour les personnes qui veulent de l’information rapide en rafales.

Cependant, certains éditeurs ont adopté le format comme un canal d’acquisition de trafic en promouvant (teasing) un article à travers des Web Stories et en forçant les lecteurs à cliquer pour aller sur le site principal pour lire l’article en entier.

Mais ce n’est pas l’utilisation correcte du format et Google a récemment averti qu’il ne classerait pas les Web Stories « teaser ».

L’annonce de Google affirme que les web stories devraient être considérées comme du contenu principal, tout comme les articles ou les billets de blog sont considérés comme du contenu principal.

Google annonce donc dans un récent post :

Si vous avez pris le train des Web Stories en marche au cours des derniers mois et utilisez WordPress comme système de gestion de contenu (CMS) de votre site Web, il y a de fortes chances que vous créiez des stories à l’aide de Web Stories pour WordPress.

Pour vous aider à tirer le meilleur parti de l’éditeur visuel, voici un tour d’horizon de toutes les fonctionnalités les plus récentes et les plus grandes depuis que nous avons publié la version 1.2 au début de Décembre 2020 (et par la suite 1.3 cette semaine).

Monétisation via Google Ad Manager et Google AdSense

Peut-être que la mise à jour la plus importante du plugin WordPress Web Stories est une intégration plus facile à AdSense et à la fonctionnalité Beta Programmatic Demand via Ad Manager.

Google a activé une méthode basée sur le formulaire pour ajouter de la publicité aux Web Stories, sans aucun codage.

Ainsi, un des meilleurs avantages de Web Stories par rapport à ses homologues sociaux est qu’elles peuvent être monétisées par vous, le créateur.

C’est l’une des raisons pour lesquelles Google dit considérer les Web Stories comme du contenu principal pour votre site Web, similaire à des billets de blog ou des vidéos.

Voici une capture d’écran montrant combien il est facile d’ajouter de la publicité en utilisant le plugin WordPress Web Stories.

L’écosystème des publicités Web Story est toujours en train d’émerger, mais AdSense et même la demande programmatique via Ad Manager sont déjà pris en charge. Vous pouvez maintenant activer ces intégrations pour vos Stories dans les paramètres du plugin WordPress Web Stories sans aucun codage nécessaire.

La demande programmatique

La demande programmatique peut également servir à remplir des éléments de campagne associés à des blocs d\’annonces dans vos stories Web. D\’autres partenaires de demande seront bientôt proposés.

Mises en page

Le plugin Web Stories dispose maintenant d’une section de mises en page qui permettra à un éditeur de mélanger facilement et assortir différents modèles de mise en page.

Cette nouvelle section de design facilite l’ajout de fonctionnalités de conception attrayantes sans avoir à modifier l’ensemble de la mise en page des Web Stories.

Parfois, vous ne voulez pas passer à un modèle de Story entièrement nouveau. Vous voulez juste plus de choix pour les styles de liste, sections ou couvertures sans changer le reste de votre Story.

Des animations assez professionnelles

Google a également ajouté des animations plus complexes qui sont intégrées aux modèles, ce qui rend la création des web stories beaucoup plus professionnelle en appuyant juste sur un bouton.

Les nouvelles animations intégrées vous permettent d’ajouter une pincée dynamique à vos Web Stories. Mieux encore, les modèles sont avec des animations intégrées au-delà des effets de base.

Testez comment l’une de vos pages de Story s’animera à l’aide du bouton de lecture dans le coin inférieur droit sous la page actuelle.

Ce n’est que le début des animations dans l’éditeur, dixit Google.

Dans les mois suivants, il compte faire suivre avec des effets combinés avec des animations du style Ken Burns et une chronologie puissante qui vous permet de contrôler les propriétés comme l’assouplissement, les retards et plus dans des détails plus granulaires.

L’effet d’animation Ken Burns, c’est lorsqu’une caméra traverse une image, de la gauche vers la droite (ou de la droite vers la gauche), en offrant une expérience dramatique et engageante à une image par ailleurs statique.

Rayon de bordure et d’angle

Google a également ajouté un moyen d’ajouter des bordures incurvées aux mises en page.

Ces deux ajouts peuvent ne pas être aussi flashy que certaines des autres nouvelles fonctionnalités, mais les bordures et le rayon de la bordure sont des blocs de construction de base qui devraient vous rendre la vie plus facile pour de nombreux types de mises en page.

Checklist avant publication

Pour compléter les mises à niveau des fonctionnalités, il y a une liste de contrôle de pré-publication qui avertit les éditeurs des améliorations qui éliront une Web Story admissible à Google Discover ainsi que des problèmes d’accessibilité.

Se souvenir de tout ce que vous devez faire dans le cadre de votre processus de création web story est beaucoup, même si vous avez intériorisé tous les épisodes de Storytime.

Pour vous aider à ne rien oublier d’important, l’éditeur dispose désormais d’un onglet \ »Liste de contrôle pré-publication\ ».

La liste de contrôle pré-publication vous alerte donc sur les questions critiques qui peuvent rendre votre Story inadmissible à apparaître sur des plates-formes telles que Google Discover, et offre des recommandations sur les lacunes communes d’accessibilité comme le faible contraste et plus encore.

En plus de ces nouvelles fonctionnalités, l’équipe a corrigé plusieurs dizaines de bugs qui interfèrent avec d’autres plugins et a amélioré l’interopérabilité avec d’autres plugins.

L’interopérabilité est une qualité du plugin qui le fait travailler avec d’autres plugins.

Vous pouvez télécharger le nouveau plugin WordPress Web Stories ici.

Source : Google