Rendu SEO : comment Google digère votre contenu

Ceci est une transcription d'une conversation entre Bartosz Goralewicz, Martin Splitt de Google et Jason Barnard. Ils ont organisé un webinaire pour discuter du rendu SEO en termes pratiques. Vous pouvez regarder l'enregistrement du webinaire ici, mais comme il contient tant d'informations, nous espérons que vous trouverez également cette transcription utile !

Bartosz : Aujourd'hui, nous allons examiner le rendu du point de vue de Google, qui est un peu différent de ce que nous voyons dans Chrome. Martin est donc là pour nous guider dans ces eaux troubles.

Et juste brièvement, dans nos recherches, et encore une fois, cela ne vient pas de Martin, nous avons commencé à voir les premières mentions de rendu et de mise en page dans les brevets de Google vers 2011. Et ma théorie personnelle est que c'est pourquoi les mises à jour de la qualité du contenu de Google Panda et toutes ces choses merveilleuses a commencé à se produire vers cette date.

Et il y a beaucoup de nouvelles découvertes, c'est un domaine assez nouveau de la façon dont Google regarde à la fois la mise en page et le rendu, et c'est quelque chose que nous espérons rendre un peu plus convivial ici avec Martin. C'est donc l'objectif aujourd'hui - rendre cela aussi simple, utilisable et pratique que possible.

Comme je l'ai mentionné, la plupart des brevets de Google sur ce sujet, et c'est ainsi que cela a commencé, se concentrent sur la mise en page.

La mise en page semble être assez importante, et nous savons probablement que, par exemple, le texte apparaissant au-dessus du pli est plus important, et il existe de nombreux brevets qui vous diront que certains éléments de la page ont un rôle un peu différent de, par exemple , des annonces ou du texte sous la ligne de flottaison.

Donc, c'en est un, et pendant des années, nous nous sommes concentrés sur le référencement JavaScript, comme Jason l'a mentionné, et en approfondissant, nous avons réalisé que le référencement JavaScript était principalement, "Google peut-il voir votre contenu correctement, pouvez-vous changer ce JavaScript en HTML" et des choses comme ça , mais quand nous avons plongé un peu plus profondément, nous avons vu que ce n'était que la pointe de l'iceberg.

De nombreux aspects de la façon dont Google rend le contenu et la façon dont ils voient la mise en page vont affecter la plupart du référencement qui se produit après cette phase initiale d'exploration, de rendu et d'indexation.

Donc, en tant qu'agence, nous avons un peu quitté le domaine du référencement JavaScript et nous nous sommes plongés dans le rendu SEO qui est beaucoup plus complexe, beaucoup plus excitant. Même si, nous allons essayer de rester simple aujourd'hui. Jason, tu dois être le gardien de ça.

Il y a beaucoup de choses assez excitantes, nous n'obtiendrons probablement pas de réponses précises de Martin, il déteste cette diapositive, je suis désolé, Martin.

Il y a des choses que Google a mentionnées comme s'ils interrompraient les scripts, beaucoup de petits morceaux géniaux qui sont intéressants, mais juste pour vous dire pour toutes les personnes qui ne sont pas aussi avancées en matière de référencement technique - pourquoi la mise en page et le rendu du référencement sont importants. Parfois, Google ne récupère pas toute la page que vous avez publiée.

Donc, si vous voyez que votre URL est indexée, cela ne signifie pas vraiment que Google a tout indexé. Cela pourrait être dû au rendu, à la qualité, à la technologie, c'est là que ça devient assez coloré et excitant.

Quelque chose que je veux mentionner quand nous parlons aujourd'hui, c'est qu'il y a quatre nuances de votre site Web. Sans le savoir, beaucoup d'entre nous masquent le contenu, car votre contenu a maintenant un aspect différent sur mobile avec JavaScript et sans JavaScript, et cela vaut pour la plupart des sites Web de nos jours, donc ce n'est pas seulement ces sites Web alimentés par React ou Angular, c'est aussi sur WordPress , Wix, peut-être Duda aussi, et la plupart de ces frameworks plus simples. Nous avons également le même problème avec le bureau. Il y a donc tellement de façons différentes d'interagir avec le contenu, et c'est principalement à cause du rendu, de la façon dont ce code sera rendu sur un appareil final.

Sans plus tarder, commençons. Nous avons Martin ici, donc je ne prendrai pas trop de votre temps.

J'ai la première question juste pour le démarrer d'une manière ou d'une autre. Alors Martin, le rendu SEO peut-il m'aider à mieux me classer ? Je suppose que c'est la première question qui est dans la tête de tout le monde.

Est-ce pratique, est-ce quelque chose qui nous rapportera du trafic, des prospects, toutes ces choses amusantes et cool ?

Martin : Je veux dire, je ne réponds généralement pas aux questions de classement, je ferai une exception ici.

D'une manière générale - non. Mais plus précisément, s'il y a un problème où quelque chose casse votre rendu et que le contenu ne s'affiche pas, alors Googlebot ne voit pas le contenu ou ne le voit pas correctement, alors, vous savez, cela peut en fait vous blesser dans le sens de , nous ne voyons pas le contenu.

Nous pourrions donc ne pas indexer la page. Ou nous pouvons indexer la page mais ne pas la classer pour le contenu qui vous intéresse. Alors oui, au final, cela peut faire une différence et avoir un impact – oui, bien sûr.

Bartosz : Une chose que je veux faire avant de plonger dans les questions du public est, où se situe le rendu dans tout le scénario ?

Nous pouvons rapidement entrer dans un scénario de ce qui était le premier, la poule ou l'œuf, mais j'ai toujours compris que Google créait une file d'attente, puis explorait, rendait et, évidemment, indexait éventuellement la page - serait-ce une simplification excessive ?

Martin : C'est un peu trop simpliste, mais c'est fondamentalement vrai. Nous obtenons donc beaucoup d'URL et nous obtenons tellement d'URL que nous ne pouvons pas toutes les explorer en même temps pour des raisons évidentes. Ok, je ne devrais pas dire pour les raisons évidentes. Nous ne pouvons pas explorer toutes les URL tout le temps, en même temps pour des raisons de bande passante, il n'y a donc qu'une quantité limitée de bande passante Internet que nous pouvons utiliser.

Si vous avez une boutique en ligne et que vous vous connectez demain avec un nouveau site Web de boutique en ligne et que vous avez un million d'URL de produits, votre serveur risque de planter si nous explorons toutes ces URL en même temps, nous devons donc étaler cela dans le temps , il y a donc une file d'attente entre nous découvrant l'URL et l'URL réellement explorée.

Cette file d'attente est relativement transparente dans le sens où la console de recherche vous indique quand l'URL a été explorée pour la dernière fois et elle est également transparente d'une manière que votre serveur vous indique. Vous pouvez vérifier à quand remonte la dernière requête adressée à cette URL à partir d'un agent utilisateur et d'une adresse IP Googlebot. Il s'agit donc d'une file d'attente très transparente.

Ce qui se passe alors, c'est qu'une fois que nous l'avons exploré, nous pouvons examiner le code HTML que nous avons reçu, nous pouvons examiner le statut HTTP. S'il s'agit d'un statut 404, le traitement se termine à peu près ici. S'il y a une balise meta robots qui indique noindex, notre travail se termine également ici.

Mais si nous obtenons un tas de contenu HTML et que nous pouvons continuer à le traiter ainsi que le reste du pipeline, nous mettons également la page en file d'attente pour l'exécution de JavaScript, ce que nous appellerions le "rendu". La deuxième file d'attente est très opaque, dans un sens vous ne voyez pas vraiment combien de temps il nous faut pour rendre, si nous rendons du tout, quand nous rendons, vous ne savez pas, et ce n'est pas par hasard, car théoriquement, nous voyez tout cela comme un processus transactionnel, dans l'entrée, il y a l'URL que nous avons découverte et la sortie de celle-ci est un document indexé ou un document non indexé. C'est à peu près ce qui peut arriver ici.

Et il n'y a pas grand-chose que vous puissiez faire à propos du rendu en termes de changement de position de la file d'attente ou de faire grand-chose en termes de détermination de ce qui est rendu ou de ce qui devrait être rendu. Vous voyez que dans la console de recherche également, vous voyez ce qui sort du rendu si vous regardez Afficher la page explorée , vous verrez ce que nous y verrions. Il n'y a donc pas de file d'attente supplémentaire que vous avez ignorée, et il y a quelques complications supplémentaires où le modèle simplifié ne s'applique pas nécessairement. Mais vous pouvez supposer que le flux est normalement en train de découvrir, d'explorer, de mettre en file d'attente, de rendre, d'indexer, puis de se classer ultérieurement.

Jason : C'est très clair.

Bartosz : Je veux juste clarifier une chose parce que vous avez mentionné qu'avant que cela n'entre dans un sujet en ligne, vous avez mentionné que vous rendiez la page et vous avez également mentionné JavaScript, mais ce que j'ai appris de nos conversations précédentes, c'est que le rendu ne concerne pas seulement JavaScript.

Martin : Oh, ouais, c'est vrai.

Bartosz : Donc, même si vous avez un site Web non-Javascript, comme s'il n'y avait pas de ligne de JavaScript et pas de référence à des scripts externes, vous devriez également vous préoccuper du rendu.

Jason : J'étais sur le point de poser la question : combien d'entre nous sommes réellement concernés par le rendu parce que cette conception, l'idée que c'est uniquement du JavaScript, nous sommes tous concernés… ?

Martin : Ouais. Tous les sites Web sont rendus et vous êtes tous concernés dans une certaine mesure, oui, c'est vrai, c'est exact.

Jason : Fondamentalement, si vous n'avez pas de JavaScript, devez-vous vous en préoccuper du tout ?

Martin : Vous n'avez pas forcément à vous en soucier, mais vous en êtes quand même affecté. Il y a encore des implications potentielles du rendu.

Jason : D'accord, génial.

Martin : Cela revient à ce que Bartosz a dit plus tôt, comme le texte au-dessus du pli ou où Google pense que votre contenu principal est et des trucs comme ça.

Jason : D'accord, ouais. Ce qui est brillant. Je veux dire, cela dit essentiellement, une partie du rendu consiste essentiellement à comprendre le rôle que joue chaque morceau de la page. Bartosz nous a montré une capture d'écran où certaines d'entre elles n'étaient pas indexées, certaines d'entre elles étaient des publicités, certaines d'entre elles étaient un en-tête, certaines d'entre elles étaient le pied de page. Le rendu est le moment où Google décide du rôle joué par chaque partie de la page, il peut donc prendre cette décision de l'indexer et de la hiérarchiser ou non, en fonction de ce que disait Bartosz - est-ce le contenu principal ?

Bartosz : C'est tout à fait exact.

Jason : Mais au fond, comment décide-t-il ?

Martin : Alors peut-être devrions-nous parler un peu de ce qu'est vraiment le rendu ? Parce que je ne suis pas sûr que tout le monde sache ce que cela signifie, n'est-ce pas ? Devrions-nous faire cela ?

Bartosz : Désolé, Martin, c'est un très bon moment pour toutes les personnes qui regardent pour poser toutes les questions sur chaque élément que vous n'avez pas compris en ce moment.

Martin : Ouais !

Bartosz : Nous n'avons aucune idée avec Martin à quel moment nous allons perdre le public, mais ce que nous essayons d'aborder pour être totalement transparent, le retour de notre conversation précédente était que parfois nous devenions un peu trop geek, trop ringard , donc nous voulons vraiment rendre cela simple.

Jason : Brillamment dit. Définir le rendu, qu'est-ce que c'est, quel est le processus ?

Martin : Exact. Si vous considérez le HTML comme une recette et que vous avez tous les ingrédients là-bas, vous avez un tas de texte, d'images, de trucs. Mais vous ne l'avez pas vraiment dans la recette, la recette est un morceau de papier avec toutes les instructions sur la façon de faire la chose.

Les ressources du site Web sont les ingrédients, tels que les fichiers CSS, JavaScript et les images des vidéos, tout ce que vous chargez pour donner à la page l'apparence qu'elle a par la suite.

Le site Web que vous connaissez et utilisez dans votre navigateur, vous le voyez dans votre navigateur - c'est le plat final.

Le rendu est à peu près la cuisson, le processus de préparation.

Ramper fondamentalement va juste dans un grand livre de recettes et sort une page avec la recette, puis la met à notre portée, en gros, nous nous tenons ici sur une table de cuisine et nous attendons juste que la cuisine commence, et ramper sera essentiellement donnez-nous la recette.

Et puis le rendu est le processus où le rendu va, « AHA, intéressant ! Crawler, là-bas, pouvez-vous m'apporter ces 10 ingrédients ?", et le crawler dit commodément, "oui, je t'ai eu ces 10 ingrédients dont tu as besoin", et nous commençons à cuisiner, c'est ça le rendu.

Ainsi, le rendu analyse le HTML. HTML fondamentalement, en ce qui concerne l'exploration de formulaires, n'est qu'un tas de texte, formaté de manière pratique, mais du texte.

Afin d'en faire une représentation visuelle qui est vraiment le site Web, nous devons le rendre, ce qui signifie que nous devons récupérer toutes les ressources, nous devons fondamentalement comprendre ce que le texte nous dit.

Par exemple. Oh, donc il y a un en-tête ici, ok, puis il y a une image là, à côté de l'image il y a un tas de texte et puis sous l'image, il y a un autre en-tête, un en-tête plus petit, un en-tête de niveau inférieur, essentiellement en retrait la structure du contenu, puis il y a une vidéo, puis en dessous de la vidéo il y a plus de texte et dans le texte, il y a 3 liens qui vont ici, ici, ici.

Et tout ce processus d'assemblage, cette compréhension de ce que c'est et son assemblage dans une représentation visuelle avec laquelle vous pouvez interagir dans la fenêtre de votre navigateur - c'est le rendu.

Et dans le cadre du rendu, à la toute première étape, nous exécutons le JavaScript.

Parce que JavaScript se trouve être essentiellement une recette dans la recette, JavaScript peut être comme "maintenant hacher ces oignons". Vous avez donc les ingrédients crus qui sont les oignons, mais vous ne mettez pas les oignons en entier dans votre plat, vous les coupez, et c'est pour cela que le JavaScript est nécessaire.

Donc, si je n'exécute pas le JS et que je ne fais que récupérer les ressources, je risque de ne pas passer à l'étape où j'ai réellement besoin de hacher les oignons, ou de casser un œuf et de le fouetter en quelque chose, qui sait.

Pouvez-vous dire que je viens de préparer le dîner et que j'ai vraiment faim en ce moment ? Je suis vraiment désolé !

Et l'exécution de JavaScript n'est qu'une partie du rendu, mais lorsque l'exécution de JavaScript est terminée, ou s'il n'y a pas d'exécution de JavaScript, c'est bien aussi, mais que se passe-t-il ensuite, nous assemblons, découvrons ces éléments et comment nous devons, comme, les assembler sur la page et cela mène à quelque chose appelé arbre de mise en page, et l'arbre de mise en page nous indique la taille des choses, où elles se trouvent sur la page, si elles sont visibles ou non, si une chose est derrière une autre chose .

Ces informations sont importantes pour nous tout autant que l'exécution du JavaScript, car le JavaScript peut modifier, supprimer ou ajouter du contenu qui n'était pas dans le HTML initial tel qu'il a été fourni par le serveur.

Donc, c'est le rendu en un mot. De "Nous avons du HTML" à "Nous avons potentiellement un tas de pixels à l'écran". C'est le rendu.

Bartosz : Je veux ajouter quelques choses que Martin ne dira pas, car il travaille chez Google. D'un point de vue SEO technique, le rendu est assez coûteux - comment cela affecte exactement Google est un grand mystère et c'est quelque chose que nous continuons à rechercher, nous avons même lancé une société distincte, un outil pour le faire. Bref, le rendu est assez cher pour Google, pour les appareils mobiles. Si vous avez comme un Alcatel 1X, comme un téléphone plus ancien, peut-être un téléphone moins cher, il va avoir du mal avec un site Web comme la BBC, The Guardian, qui expédie beaucoup de JavaScript. C'est aussi quelque chose avec lequel Google va lutter. Mais pour faire court, le rendu coûte cher. Et d'après notre expérience, certains scripts, certains sites Web ne s'affichent pas de manière optimale pour Google, et ils finissent par ne pas être récupérés correctement pour un certain nombre de raisons.

Et c'est là que Rendering SEO entre en jeu. C'est là que vous parlez à votre équipe de développement ou à votre équipe de référencement technique ayant de l'expérience dans ce sujet. Et vous leur dites, peut-être que mes pages ne sont pas récupérées aussi vite que je le voudrais.

Ce que nous verrions assez souvent comme un signe de problèmes à la fois de rendu et d'indexation, c'est par exemple que vous avez un site Web très dynamique, vous avez une tonne de Javascript et vous voyez que votre contenu est récupéré très lentement. Par exemple, vous publiez une nouvelle annonce sur un site immobilier et vous voyez que Google la récupère au bout de 3 semaines, et vos concurrents sont récupérés au bout d'une journée. Et c'est un scénario où nous nous asseyons et examinons ce qui se passe ici, pourquoi Google se débat-il avec cet aspect ?

Que pensez-vous de ce Martin ?

Martin : J'aime la question parce qu'elle crée un moment intéressant ici.

Parce que si vous y réfléchissez, Google Search a exactement le même combat qu'un utilisateur du monde réel dans ce cas. Parce que pour un utilisateur du monde réel, même si vous utilisez un téléphone moderne, ainsi qu'un téléphone très rapide, fantastique et coûteux, plus d'exécution signifie toujours plus de consommation d'énergie.

Il y a eu des gens qui ont appelé JavaScript le CO2 d'Internet. Je ne pense pas que ce soit complètement faux. C'est une comparaison très agréable et pertinente.

Voici la recherche Google et voici les utilisateurs qui utilisent réellement votre site Web, et nous sommes dans le même bateau. Plus vous le faites cher, plus l'expérience est mauvaise pour nous. Google Search ne s'en soucie pas vraiment, nous avons juste besoin d'investir dans les ressources dont nous avons besoin et nous faisons beaucoup d'optimisations pour nous assurer que nous perdons le moins de temps et d'énergie possible. Mais évidemment, si vous optimisez cela, un effet secondaire agréable est que vos utilisateurs seront probablement aussi plus heureux car ils ont besoin de moins de batterie, leur ancien téléphone fonctionnera toujours bien avec ce que vous mettez là-bas, et ils pourront consommer votre contenu Web et peut-être pas celui de vos concurrents parce que vos concurrents ne s'en soucient tout simplement pas et produisent en fait quelque chose qui est moins pratique à utiliser sur leurs téléphones. Donc, ce n'est pas quelque chose où vous opposez Google à UX, c'est un peu le même problème ou le même défi, et nous y sommes tous confrontés, y compris Google Search, donc c'est sympa.

Jason : De mon point de vue, vous dites : optimiser, faciliter les choses pour Google – quelle est la récompense que nous donne Google ? Est-ce simplement que c'est plus rapide pour vous, donc vous pouvez faire plus en même temps ?

Martin : Pas vraiment, parce que le rendu se passe à l'extérieur, le rendu est asynchrone donc cela signifie que ce n'est pas que nous attendons que le rendu se produise et ensuite nous traitons, nous essayons essentiellement de faire autant en parallèle que possible. Par exemple, si des données structurées sont présentes dans le code HTML initial, nous pouvons les récupérer juste après l'exploration, pendant le rendu, vous obtenez donc des avantages marginaux. Vous pourriez en fait y obtenir de plus grands avantages.

Si vous avez quelque chose dont le contenu change constamment, rendez-le disponible le plus tôt possible dans le processus, et il en va de même pour les canoniques, les titres, la méta description, les données structurées - le plus tôt possible, c'est bon pour vous en termes de sélection. plus fréquemment ou plus rapidement.

Jason : Ouais, plus c'est tôt, plus il y a de chances que vous le récupériez, moins il est probable que vous le déposiez avant d'arriver.

Et vous avez mentionné le balisage de schéma et vous parliez de l'arbre de mise en page, et je suis incroyablement intrigué parce que vous obtenez cet arbre de mise en page, le balisage de schéma fait potentiellement partie de cet arbre de mise en page, et vous dites essentiellement que c'est le schéma, c'est le annonces, ceci est l'en-tête, est-ce exact ? Le schéma en fait-il partie ?

Martin : Le schéma ne fait pas partie de votre arbre de mise en page car ce n'est pas un élément visuel. Ainsi, tout ce qui est visuellement ou potentiellement visible fait partie de l'arborescence de mise en page. Le balisage de schéma ne serait jamais visible.

Il y a un tas d'arbres impliqués et je ne veux pas confondre tout le monde. Fondamentalement, ce qui se passe, c'est qu'au premier moment où nous avons le texte, nous le décomposons en éléments individuels et créons un modèle d'objet de document - c'est le DOM auquel les gens se réfèrent. Le DOM est simplement la façon dont le navigateur dit : j'ai donc ce titre, qui contient du texte, c'est un autre nœud dans cet arbre, puis j'ai ce bloc de texte ici, et à l'intérieur du bloc de texte, il y a un lien qui contient du texte le lien, puis ici est une image et vous savez, c'est tout ce qui est sur la page, et cela inclut le balisage de schéma ainsi que toutes les balises méta et le titre et tout.

Tout ce qui est invisible comme les méta-informations, le schéma, JavaScript et CSS ne fait pas partie de l'arborescence de mise en page. Le CSS est indirectement, par ses effets, également analysé dans l'arborescence. Pour faire bonne mesure, il y a aussi un CSSOM et c'est exactement la même chose que pour HTML, mais pour CSS. Et il correspond au DOM pour créer l'apparence que vous avez stylisée en CSS sur les éléments DOM, sur les éléments HTML. Mais sur lui-même, il n'apparaîtrait pas dans l'arborescence de mise en page.

Jason : Bartosz, vous montriez des éléments qui ne sont pas indexés. Et c'est probablement l'arborescence de mise en page, vous prenez une décision avant d'arriver à l'étape d'indexation, "Nous n'en voulons pas, ce n'est pas intéressant ou trop long ou trop léger." C'est comme ça que tu le comprends Bartosz ?

Bartosz : Il existe un certain nombre de raisons pour lesquelles une partie du contenu peut ne pas être indexée. Ce n'est pas toujours la faute du rendu, c'est un élément clé à garder à l'esprit.

Parfois, c'est en partie la faute du rendu. Si vous regardez du contenu visible sur ordinateur mais pas visible sur mobile, c'est à cause du rendu, mais le problème n'est pas que Google l'a rendu d'une mauvaise manière, le problème est que vous n'affichez pas le même contenu pour ordinateur et pour mobile, ce qui arrive assez souvent, par exemple pour les magasins de commerce électronique.

Donc, il peut y avoir un certain nombre de raisons, parfois, nous supposons, et c'est quelque chose que Martin devrait soit confirmer soit nier, nous supposons que Google ignore un élément de la page qui, d'une manière ou d'une autre, n'est pas vraiment important ou pertinent pour le contenu. Donc, si vous avez du contenu, je pense que c'est ce dont nous avons parlé la dernière fois, Martin, à propos des chiens, et ci-dessous, vous avez un tas de publicités de vélos en tant qu'"articles similaires", alors bien souvent celles-ci ne seront pas récupérées par Google. Et pourquoi cela se produit, c'est probablement que Martin a un peu plus de connaissances.

Martin : Ce n'est pas du rendu, c'est juste nous qui analysons le contenu. Je ne sais pas ce que nous avons dit publiquement à ce sujet, mais je pense que j'en ai parlé dans l'un des épisodes du podcast - nous avons une chose appelée l'annotation de la pièce maîtresse par exemple, et il y a quelques autres annotations que nous avons là où nous regardons au niveau du contexte sémantique ainsi que potentiellement de l'arborescence de mise en page.

Mais fondamentalement, nous pouvons déjà lire cela à partir de la structure de contenu en HTML et le comprendre. "Cela ressemble à tout le traitement du langage naturel que nous avons fait sur l'ensemble de ce contenu textuel que nous avons obtenu ici, il semble qu'il s'agisse principalement du sujet A - la nourriture pour chiens - et puis il y a cette autre chose ici qui semble être des liens vers des liens connexes. produits mais ça ne fait pas vraiment partie de la pièce maîtresse, ce n'est pas vraiment le contenu principal ici, ça semble être des trucs supplémentaires, puis il y a un tas de passe-partout », alors nous avons compris que le menu était à peu près le même sur toutes ces pages, et cela ressemble au menu que nous avons sur toutes les autres pages de ce domaine, ou nous l'avons déjà vu.

Nous n'allons même pas réellement par domaine ou, "Oh, cela ressemble à un menu". Nous déterminons ce qui ressemble à un passe-partout et qui est également pondéré différemment.

Donc, s'il vous arrive d'avoir du contenu sur une page qui n'est pas lié au sujet principal du reste du contenu, nous pourrions ne pas lui accorder autant d'attention que vous ne le pensez. Nous utilisons toujours ces informations pour découvrir des liens et déterminer la structure de votre site et tout cela, mais si votre page contient 10 000 mots sur la nourriture pour chiens et comme 2 000 à 3 000 mots sur les vélos, alors ce n'est probablement pas un bon contenu pour les vélos.

Jason : Semantic HTML5 vous aide-t-il d'une manière ou d'une autre ?

Martin : Ça nous aide mais ce n'est pas la seule chose que nous recherchons, oui.

Jason : D'accord, d'accord. C'est une légère aide mais ce n'est pas quelque chose de majeur pour lequel nous devrions reconstruire tout notre site, car vous pouvez le deviner.

Martin : Oui.

Bartosz : Donc, juste pour fermer ce sujet et aller de l'avant, comme parfois vous verrez également une partie de ce contenu, comme des éléments connexes - cela repose assez souvent sur JavaScript. Très souvent sur beaucoup de JavaScript.

Donc, vous savez, d'après notre expérience, parfois si un élément est très lourd et ne correspond pas vraiment à la valeur de la page, comme encore un carrousel d'éléments similaires, parfois c'est axé sur la technologie, parfois nous supposons que c'est car c'est une tonne de rendu à faire et il n'y a aucune valeur au final.

Est-ce que tu fais aussi, est-ce que tu pèses ça parfois, est-ce que ça va être une question très difficile à répondre, est-ce que tu as un algorithme qui va dire ok, ça coûte une tonne à rendre, mais ça n'apporte pas ça beaucoup de valeur, nous devrions l'ignorer. Est-ce quelque chose dont vous pouvez parler ? Je ne sais pas si c'est une question que nous devrions éviter?

Martin : Ce n'est pas une question à éviter, c'est une question intéressante.

Autant que je sache, non. Nous ne sommes pas du genre "oh, c'est lourd à rendre, nous allons le sauter car cela n'ajoute pas beaucoup de valeur", ce serait une heuristique intéressante à considérer, mais je ne pense pas que nous le fassions pour l'instant. Ce que nous faisons cependant, c'est que finalement, et je dis finalement, très précis et je suis volontairement vague ici parce qu'il n'y a pas de moment limite très clair et s'il y en a eu, je veux dire qu'il y en a, mais c'est sujet changer, et je ne veux pas que les gens se concentrent sur quelque chose qui n'a pas de sens.

Il y a un moment où on se dit « ok, ça fait assez longtemps que ça rend, je pense que ça va ». Il y a encore un tas d'heuristiques en place, mais fondamentalement, si un vrai utilisateur considérait, "c'est trop long", alors nous le considérerions aussi trop long.

Donc voilà.

Bartosz : Je pense donc que pour le public, une chose à souligner un peu, c'est quelque chose dont nous avons parlé avant le webinaire, vous avez mentionné un peu les ressources. De quelles ressources devons-nous nous préoccuper pour faciliter la vie de Google ?

Martin : Pour être honnête, je m'inquiéterais surtout des fichiers JavaScript.

Bartosz : Non, des ressources comme les ressources du serveur. La dernière fois, vous l'avez assez bien expliqué et je pense que cela apporterait de la valeur au public.

Martin : Qu'est-ce que j'ai dit à l'époque ?

Bartosz : Vous avez mentionné que vous vous souciez peu de la RAM, que vous vous souciez du CPU par exemple. Je ne me souviens pas de ce que vous avez dit à propos du stockage, mais c'était aussi quelque part dans la conversation. Mais d'après mon hypothèse, le processeur est un élément clé à surveiller en ce moment, donc si votre site Web nécessite beaucoup de temps CPU pour le rendu, c'est quelque chose à examiner, c'est quelque chose à optimiser. Serait-ce correct?

Martin : Ouais, alors maintenant je sais où nous voulons en venir avec la question, merci beaucoup de m'avoir aidé là-bas, Bartosz.

Oui, donc comme je l'ai dit à l'origine, dans le navigateur et dans la recherche Google, le rendu prend approximativement le texte en pixels à l'écran.

La dernière partie n'est pas vraie pour la recherche Google. Google Web Rendering Service, qui est la partie de la recherche Google qui rend réellement, ne se soucie pas des pixels, donc nous ne peignons pas les pixels réels, donc si vous voyez quelque chose qui coûte très cher en peinture, je serai heureux de vous expliquer que si cela crée de la confusion, si vous avez quelque chose qui coûte très cher en peinture, vous n'avez pas à vous en soucier, car nous n'utilisons pas de GPU réels pour peindre des pixels, nous ne nous soucions donc pas de quoi que ce soit lié à la peinture.

Les mises en page coûteuses sont délicates, et avec les mises en page, je veux dire spécifiquement le travail de mise en page qui se produit sur le thread principal - car cela coûte du temps CPU et le temps CPU est ce qui nous est le plus précieux. Le stockage et la mémoire, pas si critiques, pour autant que je sache d'après les sites Web d'aujourd'hui, ils sont généralement coûteux car ils monopolisent les ressources du processeur.

Jason : Et une question ici aussi, pour aller de l'avant, c'est : plus vous voyez un type de site spécifique, est-il plus facile à afficher ? Ou n'y a-t-il aucune conséquence à utiliser une plateforme comme Duda ou WordPress ? Est-ce que cela aide ou est-ce complètement en dehors de la boîte?

Martin : Ça peut aider ou pas. La raison en est qu'en théorie, la bonne chose à propos des plates-formes est que chaque fois qu'elles optimisent la plate-forme réelle, vous obtenez cette optimisation gratuitement. Vous n'avez rien à faire à ce sujet, donc c'est bien. Si vous construisez votre propre truc, alors vous devez faire le travail d'optimisation et jamais une optimisation ne tombe comme par magie sur vos genoux et les choses s'améliorent. Mais c'est vrai pour à peu près n'importe quel CMS ou plate-forme préfabriqué, open-source, ou partagé, utilisé publiquement. D'autre part, les plates-formes, parce qu'elles sont si larges et généralistes, elles portent souvent beaucoup de poids mort, simplement parce que certains sites Web peuvent utiliser une certaine fonctionnalité, et si votre site Web ne le fait pas, alors il porte en fait ce poids encore, et ce n'est peut-être pas génial.

Jason : Est-il important pour moi, en tant que webmaster ou développeur, de supprimer le poids mort, même s'il ne fait rien juste pour s'en débarrasser afin qu'il ne gêne pas ?

Martin : Désolé, tu peux repasser devant moi ?

Jason : Tu parlais du poids mort, si je peux l'enlever est-ce une victoire phénoménale pour moi ?

Martin : Oui, mais le problème avec les plates-formes, c'est que normalement, vous ne pouvez pas...

Bartosz : Donc, je pense que nous pouvons aussi faire un petit pas en arrière sur le budget du crawler, qui a été mentionné. Donc, une chose avec le rendu est que parfois, disons, comme c'est quelque chose que nous ne regardons pas lorsque nous examinons le budget du robot d'exploration et, nous en tant que référenceurs, qu'il ne s'agit pas seulement du fichier HTML principal, mais si vous avez un JavaScript fichier qui va se développer, qui va être traité et qui va demander environ 10 fichiers supplémentaires, ce sont tous, si je comprends bien, ceux-ci entrent également dans le budget du robot d'exploration.

Il y a donc beaucoup de valeur, comme je le constate, à réduire le nombre de demandes. Évidemment, c'est un peu plus complexe que de simplement réduire le nombre de requêtes et de créer un énorme fichier, mais il y a beaucoup de valeur à simplifier à la fois le code, le nombre de requêtes et le poids - essentiellement, le coût du rendu.

Comme vous l'avez mentionné, Martin, certains sites Web sont de véritables gourmands. Donc, vous avez besoin d'une tonne de ressources pour les parcourir. Et ces ressources, il ne s'agit pas seulement de rendu comme je le vois. C'est aussi, vous savez, des centaines de demandes, un fichier changeant l'autre fichier. Cela doit également être difficile à rendre à l'échelle.

Martin : La bonne chose est que le service de rendu Web utilise l'infrastructure d'exploration pour effectuer des récupérations de ressources, ce qui signifie qu'il utilise une infrastructure spécialement conçue pour explorer le Web à grande échelle.

Donc la partie réseau n'est pas la pire. Ce qui est délicat, c'est que dans l'ordre, alors, ok...

Il y a un autre problème, ou, un autre défi ici, qui est le défi du calendrier et des ordres de grandeur.

Si vous écrivez un programme informatique, les programmes ont tendance à faire l'une des deux choses suivantes : soit ils sont liés au processeur, soit ils sont liés aux E/S. Qu'est-ce que cela signifie?

Si j'ai un programme qui ne fait que calculer des nombres, alors je lui donne deux chiffres et il fait quelque chose. Disons que nous essayons de calculer pi aussi précisément que possible, donc nous voulons arriver au milliardième chiffre de pi.

C'est une opération qui ne nécessitera que des calculs dans le CPU. Le processeur est conçu pour le calcul des nombres, il va donc être très rapide pour le faire, mais notre programme sera ce qu'on appelle lié au processeur.

Cela signifie que la vitesse d'exécution du programme et le temps qu'il faut pour accomplir son travail sont liés à la quantité de ressources CPU que vous pouvez lui consacrer, ce qui est généralement plus prévisible que quelque chose qui est lié aux E/S.

Que signifie IO-bound ?

IO-bound signifie, si je dis "Écrivez-moi un programme qui répertorie tous les fichiers sur mon disque dur ou sur ce CD-ROM ou cette clé USB."

Ce programme n'a plus besoin, tout comme, de passer par le CPU et ne fera que retourner des nombres au CPU. Mais maintenant c'est en fait, mon programme demande un matériel externe, par externe je veux dire en dehors du CPU.

Le CPU doit demander au disque dur, au lecteur de CD-ROM, au lecteur de stylo, peu importe, d'obtenir les données et les données doivent être placées dans un endroit où le CPU peut y accéder, puis le CPU le lit et fait un décision basée sur les données trouvées.

Fondamentalement, il lit le premier répertoire et il trouve le premier fichier dans le répertoire, le lit, le fichier revient, maintenant il doit lire le deuxième fichier… Et c'est ce qu'est la limite IO - input-output -.

The choking factor, the thing that determines how fast something can be done here is no longer the CPU, it's the input-output, how long does this take.

The fastest is… if you talk to what is called a CPU cache, that memory that's usually inside what we would call the CPU, the central processing unit, the second fastest is if you read from local memory, from RAM. The next fastest would be a local SSD drive. And so on and so forth.

Network, unfortunately, is thousands and thousands of times slower than any of these local file accesses and these are a thousand times slower than memory access, and that's thousands of times slower than the access of the cache in the CPU.

And be careful, when I say cache, I mean a very specific tiny type of memory chip.

There is another cache, which we are using because we are IO-bound, as you can imagine, we have to fetch the resources. So it's not about the CPU or executing the JavaScript.

What takes a lot of time is going to the network and fetching the JavaScript from your server and getting that back, that is always going to be thousands of times slower than having it stored somewhere on a, let's say, hard drive, on an SSD drive somewhere in our data center.

So, we have a completely different cache, not the cache I mentioned earlier, that's a CPU internal bit and piece and we don't care about that.

We have a cache where basically whenever our crawler infrastructure fetches a resource, we store it on a drive inside our data center. So we are reducing these thousands of thousands of seconds down to a few seconds. And the problem is that if you split up your application across lots of files, let's say, a dozen files, a dozen of JavaScript files specifically, then we have to fetch all of these, now we only have to fetch these once probably and we can cache them.

But what if these files constantly change? Then we can't cache them. What's worse is, you may think “Oh, that's just one big file and all of it is in one file and that's better to cache!” No!

Because if you split it up the right amount, let's say instead of dozens of files, you now have 4 files, and from these 4 files only 2 change on a daily basis or on a weekly basis, then we can use the cache for at least the other files that never change. Good job.

But if you have all of this in one big file and it will constantly change and we can never make use of our cache. So we always have to go through the much slower network – that's a consideration that's very tricky to navigate.

And I can't give you hard and fast rules or numbers for it either.

It's a case-by-case basis, you wanna figure out how much of the stuff really has to change a lot, what other stuff is kind of stable and doesn't change as much, you wanna separate these two things.

Jason : Does that also mean that the network, the slowness of the network if you're pulling in files from different sites? That also?

Martin : Yes.

Jason : Which brings us to the question from Simox Cox, which is aimed at you, Martin: what can we do to help render Google's own scripts, analytics, and fonts?

Martin : You don't have to worry about analytics, because as far as I'm aware we are skipping analytics, with fonts, I think we are skipping them as well.

Jason: So we don't have to worry about them from the rendering perspective.

Martin: No, not from the rendering perspective, let's stick with that.

Bartosz : Just to add to that, one thing, at least to my knowledge, that you don't have to worry about with that is image fetches. That's why it's worth having image dimensions in the code because WRS – Web Rendering Service – also doesn't request images.

If you think about that, if you have a lean website of just HTML, CSS, like a lean JavaScript file, this does the trick. In our experience, this can improve rendering, indexing, crawling quite a bit just by cleaning up, a little bit of code-housekeeping, let's call it that.

Jason : You said about images though, it's very interesting because from a rendering, and getting the layout tree perspective, setting the size of the image or specifying is phenomenally important, and most lazy developers like myself don't bother doing it.

Bartosz : So, if you do that, according to my knowledge, Google doesn't have to request those files. So that's quite cool because you also cut the time of those requests, and you make Google's job a bit easier. Let's go to other questions.

Jason : Johann had a question: Is the rendering stage mandatory for a page to get indexed or could it be considered for indexing without the rendering stage?

Martin : It could hypothetically happen, but in practice it normally doesn't.

Jason: So all pages need rendering, with 1 or 2 exceptions, but none of us are likely to be concerned by that specific exception.

Bartosz: So I'm assuming this comes from those two waves of indexing. So Martin, what's the status on that right now? It's complicated as far as I can remember.

Martin : So I joined Google in April 2018, I remember that. Once I did my onboarding, Google onboarding, all of that lovely, cuddly nice time that you get when you get onboarded at Google, once that was over I sat down at my desk, and then I talked to John, Maria, Tom, and eventually, they were like, “We're prepping for Google I/O” and I saw the slide deck and I looked at two waves of indexing and I said to John, “Are you sure we wanna go with that?”, and he's like, “Yes, I think that makes it clearer, what happens”, and I'm like, “Yes, okay, I can see that it's a nice and easy explanation.”

And at least I, I know that John wasn't surprised, but I was surprised by the conclusions people drew from that.

And I was like oh God, okay, lesson learned here, that was an oversimplification. It was making what happens behind the scenes to simple and it implied a bunch of stuff that were not meant to be implied, for instance there's like “Yeah, things get indexed without the rendering happening, and then the rendering happens afterwards and changes the indexing.”

Jason: But that isn't the case?

Martin: It can be in certain cases, but it's very rare. It's also my fault because I looked at it and I said, okay, that's good.

Bartosz: To be fair, we saw, and everyone in the community dealing with JavaScript saw, quite often JavaScript would change metadata. Why you'd do that is beyond me.

Anyhow, sometimes you have one title, or one meta description with JavaScript disabled, without rendering, and you have a different one when Google renders.

And we saw websites when different pages were indexed differently. And that's why many people in the SEO community were like, okay, this page is waiting for the second wave of indexing.

Anyhow, Jason, let's go with another question.

Jason: No, right, the question you were asking there, people rewriting titles, for example, people do it with Google Tag Manager because they can't get their hands on their titles because they can't get the access to it.

That is a phenomenal problem for you guys. I mean, what you're saying is, from what I understand, sometimes you pick up the original one, sometimes you pick up the one inserted by Google Tag Manager.

Martin: Yeah, yeah.

Bartosz: And this goes beyond just meta title and description. You will see JavaScript rewriting the links, rewriting the whole structure, breadcrumbs, and with this happening, this must be really difficult to index that page and crawl that page quickly and efficiently.

Jason: So maybe we can change that to the question about, when a page changes overtime with the JavaScript even as it's loading which is the case with the meta title I just gave, how much of a problem is that for Google, so we're turning that into a more general question?

Martin: Sorry, can you run that past me again?

Jason: The fact that as the page, the page loads and things change before the users even interact with it, because you coded the things in to override because you're not very good at your job. How much of a problem does that cause?

Martin: Unless you have proof that it really is a problem for you, I wouldn't worry about it.

Normally it shouldn't be that much of a problem because normally, the clearly better content and information should definitely be there after rendering and might or might not be there previous to rendering.

What is tricky is when that's not the case, one, and the other thing is coming back to what I said earlier, the earlier you can get us data, the better, and I'll append to that.

Because when you think about it, if we were having a conversation, and I tell you oh, by the way, the restaurant to the left is terrible and the restaurant on the right is really, really good, but then 10 seconds later I'm like, no, actually, the restaurant on the left is amazing, the restaurant on the right I wouldn't bother with.

What do you do with that? That's kind of the same, if I have a title and a canonical at the beginning of the process and then that changes, then which one is the right one? How do we find out?

Bartosz: One thing to remember is, if you're leaving that decision to crawlers, and I'm not only talking about Google, because that also goes to Twitter, Facebook, Bing, all the other creatures of the web, if you leave that decision to Google, you create like a layer of chaos in your structure.

Because you don't know which pages are gonna be picked up which way, and even if just some of them won't be picked up properly, which again, sorry Martin, probably I'm not helping, but we're seeing a lot of cases where the signals from your end, so you have one version with HTML, one version with JavaScript – oversimplifying – then we're seeing different artifacts when this website is being crawled and rendered and indexed.

And I think this is proper development, this is something we need to, that's why we try to talk about these topics with Martin quite a bit, because this is something in the gray area between SEOs and devs.

Because, you know, it's a very difficult topic right now, is this something that technical SEOs should focus on? Not all companies have the luxury of technical SEOs in-house. Or is it something that the dev team should worry about? I guess the main topic is to look into that.

We have a tool – What Would JavaScript Do? – and if you google the tool, you can see, okay, which elements of the page are being changed with JavaScript. So this is very simple, just do that, look into those elements, just match those two and you're good. Even if you have to depend on JavaScript.

Martin: To be the devil's advocate for the developers, if all you have is client-side rendering and there are situations where you might for some reason have to do that, then it's not super easy to provide something server-side first, like in the initial HTML, and then updating something that is missing or that's very generic into something more specific and more high-quality, with JavaScript, is still a good thing over not doing it at all.

I'm not saying it's good, I'm not saying it's optimal and I absolutely 100% agree with Bartosz that you should make it match, but if you really can't, it is a way of doing things, it's just more shaky and error-prone than if you can avoid that.

Jason : One question many people are asking is, do authoritative sites get more “rendering” resources from Google or it doesn't matter?

Martin: No. You have to have this one meta tag, meta cheese=”” and then your favorite cheese, if it's the right kind of cheese and it changes weekly, then you get more rendering resources from John personally.

Bartosz: To support Martin's statement, being 100% serious right now, we're seeing websites, like home pages of newspapers, of huge eCommerce stores where you'd see main content not being picked up and we're seeing small websites indexed properly with similar technological stack, so I have to confirm, we're also not seeing like huge websites or heavily linked websites having some kind of benefit.

(…)

Bartosz : In general, something that we talked about with Martin. Rendering is so crucial with all the websites pushing so much JavaScript right now. And I guess, Martin, what would be…

Is there any way we can make rendering more interesting, more sexy in a way as SEO community?

I think this is something we talked about it so many times. We both know that rendering is so important and for the first time Google is not that black box anymore, we have so much data, Martin is available with all the answers, just… Not too many people seem to care about it.

We launched the Rendering SEO manifesto like June last year, I was thinking this would change the industry, I was thinking, this was gonna be this explosion within the industry, but this is not being picked up. And Martin, is there anything we as SEOs can do to push the envelope on this one?

Martin : That's again a tricky one because technically, I spoke to the rendering team about this, and they're like, “We like that rendering is not sexy”, and I'm like “Yeah, but there are people very worried about it and there is a bunch of stuff where you can miss out.”

I would just love people to experiment more. There are a few people in the community that are experimenting a lot, Giacomo Zecchini being one of them, I know that Dave Smart is experimenting a lot. And it's just really, really cool to see people experimenting and telling me what they're observing and checking in why what they're observing is what they're observing.

Je vais vous donner un exemple très simple. Adam Gent a été le premier à souligner très publiquement qu'ils voient des fonctionnalités prises en charge par Googlebot dans le rendu JavaScript qui n'étaient pas prises en charge auparavant, c'est donc lui qui nous a surpris publiquement en déployant le Googlebot à feuilles persistantes, et cela m'a fait très heureux. Parce qu'un groupe de personnes vient de demander quand ça arrive, et je ne peux pas vraiment dire parce que nous ne pouvons évidemment pas annoncer quelque chose à l'avance parce que l'annonce pourrait remonter dans le temps ou qu'il pourrait y avoir un problème avec. Mais si quelqu'un dit comme, « Hey Martin, nous voyons cette chose. Que se passe-t-il ici ?", alors je peux dire, voyez, c'est ce qui se passe en ce moment, nous augmentons le pourcentage de rendus qui utilisent le Googlebot à feuilles persistantes. Et cette page que vous venez d'avoir est celle qui a vu le nouveau Googlebot à feuilles persistantes.

Je pense que c'est Giacomo Zecchini qui m'a fait remarquer un comportement bizarre avec les web workers, ce qui est vraiment intéressant parce que j'en parle depuis longtemps à l'équipe de rendu, et ils me disent "Personne ne l'utilise, passez votre chemin ce!" et maintenant les gens commencent à l'utiliser et je me dis, nous devons nous pencher dessus.

Il y a comme beaucoup de petites surprises intéressantes qui normalement n'ont pas d'importance, elles n'ont pas un grand impact en termes de classement ou d'indexation ou quoi que ce soit, mais c'est intéressant de les observer.

Et j'aimerais juste que plus de geeks se joignent à nous et juste, vous savez, jouent et explorent.

Jason : Cela vaut pour tous les aspects du référencement. Plus nous expérimentons, explorons et partageons, plus notre communauté apprend, mais aussi plus vous en apprenez sur la façon dont nous abordons cela et comment vous pouvez nous aider à nous aider.