SEOのレンダリング：Googleがコンテンツをダイジェストする方法

これは、Bartosz Goralewicz、GoogleのMartin Splitt、およびJasonBarnardの間の会話の記録です。 彼らは、実用的な用語でレンダリングSEOについて議論するためのウェビナーを主催しました。 ここでウェビナーの記録を見ることができますが、たくさんの情報が満載されているので、このトランスクリプトもお役に立てば幸いです。

Bartosz：今日は、Googleの視点からレンダリングを見ていきます。これは、Chromeで見ているものとは少し異なります。したがって、Martinは、これらの濁った海をナビゲートするためにここにいます。

簡単に言えば、私たちの調査では、これはマーティンからのものではありません。2011年頃にGoogle特許でレンダリングとレイアウトについて最初に言及され始めました。私の個人的な理論は、GooglePandaのコンテンツ品質の更新とそれらすべての素晴らしいものが理由です。その日頃に起こり始めました。

そして、多くの新しい発見があります。これは、Googleがレイアウトとレンダリングの両方をどのように見ているかというかなり新しい分野です。これは、ここでマーティンともう少し親しみやすくしたいと思っています。 したがって、これが今日の目標です。これを可能な限りシンプルで使いやすく、実用的なものにすることです。

私が述べたように、私たちがこのトピックを回避するために取得したGoogle特許のほとんどは、これが実際に始まった方法であり、レイアウトに焦点を当てています。

レイアウトは非常に重要であるように思われます。たとえば、折り目の上に表示されるテキストの方が重要であり、ページの一部の要素がたとえばとは少し異なる役割を果たしていることを示す特許がたくさんあります。 、スクロールしなければ見えない位置にある広告またはテキスト。

つまり、これは1つであり、ジェイソンが述べたように、何年もの間JavaScript SEOに焦点を当てていました。さらに深く掘り下げてみると、JavaScript SEOは主に「Googleはコンテンツを正しく表示でき、JavaScriptをHTMLに変更できますか」などであることがわかりました。 、しかし、もう少し深く掘り下げると、これは氷山の一角にすぎないことがわかりました。

Googleがコンテンツをレンダリングする方法とレイアウトの表示方法の多くの側面は、クロール、レンダリング、インデックス作成のこの初期段階の後に発生するSEOのほとんどに影響を与えます。

そこで、私たちは代理店としてJavaScript SEOの分野を少し離れ、レンダリングSEOに飛び込みました。これは、はるかに複雑で、はるかにエキサイティングです。 とはいえ、今日はシンプルにしようとしています。 ジェイソン、あなたはその警備員でなければなりません。

非常にエキサイティングなことがたくさんあります。マーティンから正確な回答が得られない可能性があります。彼はこのスライドを嫌っています。申し訳ありませんが、マーティン。

グーグルがスクリプトを中断するように言及したもの、興味深いものがたくさんありますが、技術的なSEOにそれほど進んでいないすべての人々に、SEOのレイアウトとレンダリングが重要である理由を説明します。 投稿したページ全体がGoogleに表示されない場合があります。

したがって、URLがインデックスに登録されている場合でも、Googleがすべてをインデックスに登録しているとは限りません。 これは、レンダリング、品質、テクノロジーが原因である可能性があるため、非常にカラフルでエキサイティングなものになります。

私たちが今日話すときに私が言及したいことはあなたのウェブサイトの4つの色合いがあるということです。 知らないうちに、私たちの多くはコンテンツをクロークします。これは、JavaScriptを使用したモバイルとJavaScriptを使用しないモバイルでコンテンツの外観が異なるためです。これは、最近のほとんどのWebサイトに当てはまります。したがって、ReactまたはAngularを利用したWebサイトだけでなく、WordPressについても説明します。 、Wix、おそらくDudaも、そしてそれらのより単純なフレームワークのほとんど。 デスクトップでも同じ問題があります。 したがって、コンテンツを操作する方法は非常に多く、主にレンダリングが原因で、このコードがエンドデバイスでどのようにレンダリングされるかがわかります。

それ以上の苦労なしに、始めましょう。 ここにマーティンがいるので、あまり時間をかけません。

どういうわけかそれを始めるためだけに最初の質問があります。 マーティン、SEOをレンダリングすることでランクを上げることができますか？ これがみんなの頭の中にある最初の質問だと思います。

それは実用的ですか、それは私たちにトラフィック、リード、それらすべての面白くてクールなものをもたらすものですか？

マーティン：つまり、私は通常、ランキングの質問には答えません。ここでは例外を設けます。

一般的に言えば–いいえ。 しかし、具体的に言えば、何かがレンダリングを壊し、コンテンツが表示されないという問題がある場合、Googlebotはコンテンツを表示しないか、正しく表示されません。 、コンテンツが表示されません。

そのため、ページにインデックスを付けない場合があります。 または、ページにインデックスを付けても、関心のあるコンテンツに対してランク付けしない場合があります。 そうです、結局のところ、それは違いを生み、影響を与える可能性があります–もちろんです。

Bartosz：聴衆からの質問に飛び込む前に、私がやりたいことの1つは、レンダリングはシナリオ全体に当てはまるのでしょうか。

鶏が先か卵が先かというシナリオにすぐに入ることができますが、それは常にGoogleがキューを作成し、ページをクロール、レンダリング、そして明らかにオプションでインデックスに登録するということでした。それは単純化しすぎでしょうか。

マーティン：それは少し単純化しすぎていますが、基本的には真実です。 そのため、多くのURLを取得し、非常に多くのURLを取得するため、明らかな理由ですべてを同時にクロールすることはできません。 わかりました、明白な理由で言うべきではありません。 帯域幅の理由から、すべてのURLを常にクロールすることはできません。そのため、使用できるインターネット帯域幅は限られています。

オンラインショップがあり、明日新しいオンラインショップのウェブサイトでオンラインになり、100万の商品URLがある場合、これらすべてのURLを同時にクロールするとサーバーがクラッシュする可能性があるため、これを時間の経過とともに分散させる必要があります。そのため、URLと実際にクロールされているURLを検出するキューが間にあります。

このキューは、URLが最後にクロールされた日時を検索コンソールに表示するという意味で比較的透過的であり、サーバーが通知する方法でも透過的です。 GooglebotユーザーエージェントとIPからこのURLに対して最後にリクエストが行われたのはいつかを確認できるため、非常に透過的なキューになります。

次に何が起こるかというと、クロールすると、受け取ったHTMLを調べたり、HTTPステータスを調べたりすることができます。 404ステータスの場合、処理はここでほぼ終了します。 noindexを示すrobotsメタタグがある場合、作業はここでも終了します。

しかし、大量のHTMLコンテンツを取得し、それと残りのパイプラインの処理を進めることができる場合は、JavaScript実行のためにページをキューに入れます。これを「レンダリング」と呼びます。 2番目のキューは非常に不透明です。ある意味では、レンダリングにかかる​​時間が実際にはわかりません。レンダリングしたとしても、レンダリングするときにわかりません。理論的には、それは偶然ではありません。これはすべてトランザクションプロセスと見なされます。インテークには、検出されたURLがあり、その出力はインデックス付きドキュメントまたはインデックスなしドキュメントです。 それがここで起こり得ることとほぼ同じです。

そして、キューの位置を変更したり、何がレンダリングされるのか、何をレンダリングする必要があるのか​​を理解するという点で、実際にレンダリングについてできることはそれほど多くありません。 検索コンソールでも、 [クロールされたページの表示]を見ると、レンダリングから何が得られるかがわかります。そこに何が表示されるかがわかります。 したがって、スキップした追加のキューはなく、簡略化されたモデルが必ずしも適用されない可能性があるいくつかの複雑な問題があります。 ただし、フローは通常、検出、クロール、キューイング、レンダリング、インデックス作成、そして場合によっては後でランク付けされると想定できます。

ジェイソン：それは本当に明らかです。

Bartosz： 1つだけ明確にしておきたいのは、これがオンラインのトピックに入る前に、ページをレンダリングすることとJavaScriptについても言及したことですが、以前の会話から得たのは、レンダリングはJavaScript。

マーティン：ああ、そうだね。

Bartosz ：つまり、JavaScriptの行がなく、外部スクリプトへの参照がないなど、Javascript以外のWebサイトを持っている場合でも、レンダリングについても考慮する必要があります。

ジェイソン：私は質問をしようとしていました：私たちの多くは実際にレンダリングに関心を持っています。なぜなら、その概念、JavaScriptのみであるという考え、私たち全員が関心を持っているからです…？

マーティン：うん。 すべてのウェブサイトがレンダリングされており、皆さんはある程度心配しています。そうです、そうです、それは正しいです。

ジェイソン：基本的に、JavaScriptがない場合、これについてまったく心配する必要はありますか？

マーティン：必ずしも心配する必要はありませんが、それでも影響を受けます。 レンダリングによる潜在的な影響はまだあります。

ジェイソン：わかりました、素晴らしいです。

マーティン：それは、折り目の上のテキストや、Googleがあなたのメインコンテンツがどこにあると考えているかなど、バルトスが以前に言ったことと結びついています。

ジェイソン：そうだね。 それは素晴らしいです。 つまり、基本的には、レンダリングの一部は、基本的にページの各チャンクが果たす役割を理解することです。 Bartoszは、インデックスに登録されていないもの、広告であるもの、ヘッダーであるもの、フッターであるもののスクリーンショットを見せてくれました。 レンダリングは、ページの各部分が果たす役割をGoogleが決定するポイントです。したがって、Bartoszが言っていたことに関して、ページをインデックスに登録するかどうか、優先するかどうかを決定できます。これがメインコンテンツですか。

Bartosz ：それはすべて正しいです。

ジェイソン：しかし、基本的に、それはどのように決定しますか？

マーティン：それで、レンダリングが実際に何であるかについて少し話す必要があるかもしれませんか？ 誰もがそれが何を意味するのか知っているかどうかわからないからですよね？ 私たちはそれをすべきですか？

Bartosz ：申し訳ありませんが、マーティン、これはあなたが今理解していないすべてのアイテムについてすべての質問をするのを見ているすべての人々にとって非常に良い瞬間です。

マーティン：うん！

Bartosz ：マーティンとは、どの時点で聴衆を失うのかわかりませんが、完全に透明にするために対処しようとしていることは、以前の会話からのフィードバックは、時々少しオタクすぎてオタクすぎるというものでした、だから私たちはこれを本当に簡単にしたいのです。

ジェイソン：見事に言った。 レンダリングを定義します、それは何ですか、プロセスは何ですか？

マーティン：そうですね。 HTMLをレシピとして考え、そこにすべての要素がある場合は、テキスト、画像などがたくさんあります。 しかし、あなたは実際にそれをレシピに持っていません、レシピは物を作る方法に関するすべての指示が書かれた一枚の紙です。

Webサイトのリソースは、CSS、JavaScriptファイル、ビデオの画像などの要素であり、実際にページを後で表示するためにロードするものすべてです。

あなたが知っていて、あなたがあなたのブラウザで見るあなたのブラウザで使うウェブサイト–それは最後の料理です。

レンダリングは、ほとんど調理、準備プロセスです。

基本的に、クロールはレシピの大きな本に入り、レシピのページを取り出して、それを私たちの領域に配置します。基本的に、私たちはここで台所のテーブルに立って、料理が始まるのを待つだけです。クロールは基本的にレシピを渡してください。

そして、レンダリングはレンダリングが進むプロセスです。 クローラー、あそこにある10の材料を手に入れてくれませんか？」とクローラーは便利に「はい、必要な10の材料を手に入れました」と言って、料理を始めます。それがレンダリングです。

したがって、レンダリングはHTMLを解析します。 HTMLは基本的に、フォームクロールに関しては、テキストの集まりであり、便利な形式ですが、テキストです。

それを実際にウェブサイトである視覚的表現にするためには、それをレンダリングする必要があります。つまり、すべてのリソースを取得する必要があります。テキストが何を示しているかを基本的に理解する必要があります。

例えば。 ああ、ここにヘッダーがあります。わかりました。そこに画像があります。画像の横に一連のテキストがあり、画像の下に別の見出し、小さい見出し、下位レベルの見出しがあり、基本的にはインデントされています。コンテンツの構造、次にビデオがあり、次にビデオの下にさらにテキストがあり、テキストには3つのリンクがあります。ここ、ここ、ここにあります。

そして、このすべての組み立てプロセス、これが何であるかを理解し、ブラウザウィンドウ内で対話できる視覚的表現に組み立てます。つまり、レンダリングです。

そして、レンダリングの一部として、最初の段階でJavaScriptを実行します。

JavaScriptは基本的にレシピ内のレシピであるため、JavaScriptは「今度はそれらの玉ねぎを切り刻む」のようになります。 つまり、タマネギという原材料がありますが、タマネギ全体を皿に入れるのではなく、切り刻んで、JavaScriptが必要なのです。

したがって、JSを実行せずにリソースを取得するだけでは、実際に玉ねぎを切り刻んだり、卵を割って開いて何かに泡だて器で入れたりする必要があるステップが実際には得られない可能性があります。

夕食を作ったばかりで、今は本当にお腹が空いていると言えますか？ ごめんなさい！

そして、JavaScriptの実行はレンダリングの一部にすぎませんが、JavaScriptの実行が終了したとき、またはJavaScriptの実行がない場合は、それでも問題ありませんが、その後、これらの断片を組み立てて、どのように行う必要があるかを理解します。たとえば、ページ上でそれらを組み立てると、レイアウトツリーと呼ばれるものになります。レイアウトツリーは、ページ上のどこにあるか、表示されているかどうか、あるものが別のものの後ろにあるかどうかを示します。 。

この情報は、JavaScriptを実行する場合と同様に重要です。これは、JavaScriptが、サーバーによって配信された最初のHTMLに含まれていなかったコンテンツを変更、削除、または追加する可能性があるためです。

つまり、それは一言で言えばレンダリングです。 「HTMLがあります」から「画面にたくさんのピクセルがある可能性があります」まで。 それがレンダリングです。

Bartosz ：マーティンはGoogleで働いているので、言わないことをいくつか追加したいと思います。 それを技術的なSEOの側面から見ると、レンダリングにはかなりのコストがかかります。それがGoogleにどのように影響するかは大きな謎であり、これは私たちが研究を続けるものであり、それを行うためのツールである別の会社を立ち上げました。 簡単に言うと、Googleにとって、モバイルデバイスにとって、レンダリングは非常に高価です。 Alcatel 1Xのように、古い電話のように、おそらくもっと安い電話を持っているなら、JavaScriptをたくさん出荷しているBBCやTheGuardianのようなウェブサイトと格闘するでしょう。 これもGoogleが苦労することです。 しかし、簡単に言えば、レンダリングにはコストがかかります。 そして、私たちの経験では、一部のスクリプト、一部のWebサイトは、Googleに最適にレンダリングされず、さまざまな理由で適切に取得されないことになります。

そして、これがレンダリングSEOの出番です。これは、このトピックの経験を持つ開発チームまたは技術SEOチームに相談する場所です。 そして、あなたは彼らに言っている、多分私のページは私が望むほど速く拾われていない。

レンダリングとインデックス作成の両方の問題の兆候としてよく見られるのは、たとえば、非常に動的なWebサイトがあり、大量のJavascriptがあり、コンテンツの取得が非常に遅いことです。 たとえば、不動産のWebサイトに新しいリストを公開すると、Googleが3週間後にそれをピックアップし、競合他社が1日後にピックアップされることがわかります。 そして、それは私たちが座ってここで何が起こっているのかを調べるときのシナリオです、なぜGoogleはこの側面に苦労しているのですか？

このマーティンについてどう思いますか？

マーティン：ここで面白い瞬間が生まれるので、私はこの質問が好きです。

あなたがそれについて考えるならば、Google検索はこの場合実際のユーザーとまったく同じ苦労をしているからです。 なぜなら、実際のユーザーにとっては、最新の電話を使用している場合でも、非常に高速で幻想的で高価な電話を使用している場合でも、実行回数が増えると、常に消費電力が増えることを意味します。

JavaScriptをインターネットのCO2と呼ぶ人がいます。 私はそれが完全に間違っているとは思いません。 それは非常に素晴らしく適切な比較です。

これがグーグル検索であり、これが実際にあなたのウェブサイトを使用しているユーザーであり、私たちは同じ船に乗っています。あなたがそれを高くするほど、それは私たちにとって経験として悪くなります。 Google検索は実際には気にしません。必要なリソースに投資するだけで、多くの最適化を行って、無駄な時間とエネルギーをできるだけ少なくします。 しかし、明らかに、それを最適化する場合、良い副作用は、ユーザーが必要とするバッテリーが少なくて済むため、おそらくユーザーも幸せになることです。古い電話は、あなたが出したもので問題なく動作し、消費できるようになります。競合他社は気にせず、実際には携帯電話での使用に不便なものを作成しているため、Webコンテンツであり、競合他社ではない可能性があります。 つまり、これはGoogleとUXの違いではなく、同じ問題や同じ課題のようなものであり、Google検索を含め、私たち全員が直面しているので、それは素晴らしいことです。

ジェイソン：私の見解では、あなたは次のように言っています：最適化して、グーグルにとってより簡単にする–グーグルが私たちに与える報酬は何ですか？ それはあなたにとってそれがより速いということだけですか、それであなたは同時により多くをすることができますか？

マーティン：実際には、レンダリングは外部で行われるため、レンダリングは非同期です。つまり、レンダリングが行われるまで待ってから処理するのではなく、基本的に可能な限り並行して実行しようとします。 たとえば、構造化データが最初のHTMLにある場合、レンダリングが行われている間、クロールの直後にそれを取得する可能性があるため、そこではわずかな利点が得られます。 あなたは実際にそこでより大きな利点を得るかもしれません。

コンテンツが絶えず変化するものがある場合は、プロセスのできるだけ早い段階でそれを利用できるようにします。同じことが、カノニカル、タイトル、メタディスクリプション、構造化データにも当てはまります。より頻繁にまたはより速く。

ジェイソン：ええ、早いほど、それを拾う可能性が高くなり、そこに着く前に降りる可能性は低くなります。

そして、スキーママークアップについて言及し、レイアウトツリーについて話していました。このレイアウトツリーが登場し、スキーママークアップはそのレイアウトツリーの一部である可能性があり、基本的にこれはスキーマであると言うので、私は非常に興味をそそられます。広告、これはヘッダーです、それは正しいですか？ スキーマはその一部ですか？

マーティン：スキーマは視覚的な要素ではないため、レイアウトツリーの一部ではありません。 したがって、視覚的または潜在的に表示されるものはすべて、レイアウトツリーの一部です。 スキーママークアップは表示されません。

たくさんの木が関わっていて、みんなを混乱させたくありません。 基本的に何が起こるかというと、テキストを最初に受け取った瞬間に、それを個々の要素に分解し、ドキュメントオブジェクトモデルを作成します。これは、人々が参照するDOMです。 DOMは基本的にブラウザの言い方です。つまり、このタイトルにテキストが含まれ、このツリーの別のノードになります。次に、このテキストブロックがここにあり、テキストブロック内にテキストが含まれるリンクがあります。リンク、そしてここに画像があります。これがページにあるすべてのものであり、スキーママークアップ、すべてのメタタグ、タイトルなどが含まれます。

メタ情報、スキーマ、JavaScript、CSSなどの非表示のものは、レイアウトツリーの一部ではありません。 CSSは、その効果によって間接的にツリーに解析されます。 適切な方法として、CSSOMもあります。これは、HTMLの場合とまったく同じですが、CSSの場合です。 また、DOMにマップして、CSSでDOM要素やHTML要素にスタイルを設定した外観を作成します。 しかし、それ自体はレイアウトツリーに表示されません。

ジェイソン：バルトス、あなたは索引付けされていない要素を示していました。 そして、それはおそらくレイアウトツリーであり、インデックス作成の段階に入る前に、「面白くない、長すぎる、または軽すぎる」という決定を下しています。 それはあなたがそれをバルトスと理解する方法ですか？

Bartosz ：コンテンツの一部がインデックスに登録されない理由はいくつかあります。 それは必ずしもレンダリングのせいではありません、それは心に留めておくべき重要なことです。

時々それは部分的にレンダリングのせいです。 デスクトップには表示されているがモバイルには表示されていないコンテンツを見る場合、それはレンダリングが原因ですが、問題はGoogleがそれを間違った方法でレンダリングしたことではなく、デスクトップと同じコンテンツを表示していないことです。モバイルの場合、これは非常に頻繁に発生します。たとえば、eコマースストアの場合です。

したがって、いくつかの理由が考えられます。これは、マーティンが確認または拒否しなければならないことであり、Googleは、ページの要素をスキップして、コンテンツにあまり重要または関連性がないと想定しています。 ですから、コンテンツがあれば、これが前回マーティンが犬について話したことだと思います。以下に「類似アイテム」としての自転車広告がたくさんありますが、それらはGoogleに取り上げられないことがよくあります。 そして、これが起こる理由は、おそらくマーティンがもう少し知識を持っているということです。

マーティン：それはレンダリングではなく、コンテンツを分析しているだけです。 これについて公に何を言ったかはわかりませんが、ポッドキャストのエピソードの1つで取り上げたと思います。たとえば、目玉の注釈と呼ばれるものがあり、他にもいくつかの注釈があります。セマンティックコンテキストおよび潜在的にレイアウトツリーで。

しかし、基本的には、HTMLのコンテンツ構造からそれをすでに読み取って理解することができます。 「これは、ここで取得したこのテキストコンテンツ全体に対して行ったすべての自然言語処理からのように見えます。これは、主にトピックA（ドッグフード）に関するもののようです。次に、関連するリンクのように見える他のことがここにあります。製品ですが、それは実際には目玉の一部ではなく、ここでは実際にはメインコンテンツではありません。追加のもののようで、ボイラープレートがたくさんあります。」したがって、メニューはこれらすべてのページでほぼ同じに見えることがわかりました。これは、このドメインの他のすべてのページにあるメニューのように見えます。または、これは以前に見たことがあります。

私たちは実際にドメインや「ああ、これはメニューのように見える」でさえ行きません。 ボイラープレートのように見えるものを理解し、それもまた異なる重みが付けられます。

そのため、他のコンテンツのメイントピックに関連しないコンテンツがページにある場合は、思ったほど考慮されない可能性があります。 リンクの検出やサイト構造の把握などに引き続きその情報を使用しますが、ページにドッグフードの単語が10000語、自転車の単語が2000〜3000語の場合、これは自転車に適したコンテンツではない可能性があります。

ジェイソン：セマンティックHTML5は何か役に立ちますか？

マーティン：それは私たちを助けますが、私たちが探しているのはそれだけではありません。

ジェイソン：そうですね。 これは少し助けになりますが、推測できるので、サイト全体を再構築する必要がある大きな問題ではありません。

マーティン：はい。

Bartosz ：ですから、このトピックを閉じて先に進むと、関連するアイテムなど、そのコンテンツの一部も表示されることがあります。これは、JavaScriptに依存していることがよくあります。 多くのJavaScriptで非常に頻繁に。

つまり、私たちの経験では、要素が非常に重く、ページの価値に実際に足りない場合もあります。たとえば、同様のアイテムのカルーセルのように、テクノロジー主導の場合もあります。たくさんのレンダリングを行う必要があり、最終的には価値がないからです。

あなたもそうしますか、時々それを量りますか、あなたは持っていますか、これは答えるのが非常に難しい質問になるでしょう、あなたは大丈夫と言うつもりのアルゴリズムを持っていますか、これはレンダリングするのに1トンかかりますが、それはそれをもたらしません多くの価値があるので、スキップする必要があります。 それはあなたが話すことができるものですか？ これが避けるべき質問かどうかわかりませんか？

マーティン：それは避けるべき質問ではなく、興味深い質問です。

私の知る限りではありません。 「これはレンダリングが重いので、あまり価値がないのでスキップします」というようなものではありません。これは、検討するのに興味深いヒューリスティックですが、現時点ではそうは思わない。 しかし、私たちがやっていることは、最終的には非常に具体的であり、明確なカットオフの瞬間がないため、ここでは意図的に曖昧にしています。変化するために、そして私は人々が意味をなさない何かに集中することを望んでいません。

「わかりました、これは十分長い間レンダリングされています。私たちは良いと思います」と言う瞬間があります。 ヒューリスティックもたくさんありますが、基本的に、実際のユーザーが「これは長すぎる」と考える場合は、長すぎると見なします。

そうそう。

Bartosz ：それで、聴衆にとって、かなり強調すべきことの1つは、これはウェビナーの前に私たちが話したことだと思います。あなたはリソースについてかなり言及しました。 Googleの生活を楽にするために、どのようなリソースを心配する必要がありますか？

マーティン：正直に言うと、JavaScriptファイルについて心配することがほとんどです。

Bartosz ：いいえ、サーバーリソースなどのリソースです。 前回はかなり上手く説明してくれたので、聴衆に価値をもたらすと思います。

マーティン：当時、私は何と言いましたか？

Bartosz： RAMについてはそれほど気にしないとおっしゃいましたが、たとえばCPUについては気にしています。 ストレージについてあなたが言ったことを覚えていませんが、それは会話のどこかでもありました。 しかし、私の仮定では、CPUは現時点で注意すべき重要な要素であるため、Webサイトのレンダリングに多くのCPU時間が必要な場合、これは調査するものであり、最適化するものです。 それは正しいでしょうか？

マーティン：ええ、それで私は質問の行き先がわかりました。バルトス、私を助けてくれてありがとう。

はい、最初に言ったように、ブラウザとGoogle検索では、レンダリングは大まかにテキストを画面上のピクセルに変換します。

最後の部分はGoogle検索には当てはまりません。 実際にレンダリングするGoogleSearchの一部であるGoogleWebRendering Serviceはピクセルを気にしないため、実際のピクセルをペイントしていません。したがって、ペイントが非常に高価なものを見つけた場合は、喜んで説明します。混乱を招きます。ペイントが非常に高価なものがある場合は、実際のGPUを使用して実際にピクセルをペイントすることはないため、ペイントに関連することは何も気にしないため、心配する必要はありません。

高価なレイアウトには注意が必要です。レイアウトでは、メインスレッドで行われるレイアウト作業を具体的に意味します。これは、CPU時間とCPU時間が私たちにとって最も貴重なものであるためです。 今日のWebサイトからわかる限り、ストレージとメモリはそれほど重要ではありませんが、CPUリソースを大量に消費するため、ほとんどの場合高価です。

ジェイソン：そして、ここでも1つの質問があります。それは、特定の種類のサイトを見るほど、レンダリングが簡単になるということです。 または、DudaやWordPressのようなプラットフォームを使用した結果はありませんか？ それは役に立ちますか、それとも完全に箱の外にありますか？

マーティン：それは役立つかもしれないし、役に立たないかもしれない。 その理由は、理論的には、プラットフォームの良いところは、実際のプラットフォームを最適化するたびに、この最適化を無料で利用できることです。 あなたはそれについて実際に何もする必要がないので、それは素晴らしいことです。 あなたがあなた自身のものを作るならば、あなたは最適化の仕事をしなければなりません、そして決していくつかの最適化が魔法のようにあなたの膝に落ちて、物事は良くなっています。 しかし、これは、ほとんどすべての既成の、オープンソースの、または共有された、公的に使用されているCMSまたはプラットフォームに当てはまります。 一方、プラットフォームは非常に広範で一般的であるため、一部のWebサイトが特定の機能を使用している可能性があるという理由だけで、多くの場合、多くの重荷を背負っています。それでも、それは素晴らしいことではないかもしれません。

ジェイソン：ウェブマスターや開発者として、自重を取り除くためだけに何もしていなくても、邪魔にならないようにすることは重要ですか？

マーティン：すみません、それをもう一度私を追い越してくれませんか？

ジェイソン：あなたは自重について話していました、私が取り除くことができれば、それは私にとって驚異的な勝利ですか？

マーティン：はい、でもプラットフォームの問題は、通常はできないということです…

Bartosz ：ですから、前述のクローラーの予算に少し戻ることもできると思います。 したがって、レンダリングに関する1つのことは、たとえば、これはクローラーの予算を見るときに見ていません。SEOとしては、メインのHTMLファイルだけでなく、JavaScriptを使用している場合もあります。展開するファイル、処理されるファイル、さらに10個のファイルのように要求するファイル、これらはすべて、私が理解しているように、クローラーの予算にも含まれます。

ですから、私が見ているように、リクエストの数を減らすことにはかなりの価値があります。 明らかに、これはリクエストの数を減らして1つの巨大なファイルを作成するよりも少し複雑ですが、コード、リクエストの数、および重みの両方を単純化することには多くの価値があります。基本的にはレンダリングのコストです。

あなたが言ったように、マーティン、ウェブサイトのいくつかは本当のガズラーです。 したがって、それらを通過するには、たとえば、大量のリソースが必要です。 そしてそれらのリソース、それは私が見ているようにレンダリングすることだけではありません。 また、何百ものリクエストがあり、一方のファイルがもう一方のファイルを変更します。 これもスケールでレンダリングするのは難しいはずです。

Martin ：良い点は、Webレンダリングサービスがクロールインフラストラクチャを使用してリソースをフェッチすることです。つまり、大規模なWebをクロールするために特別に構築されたインフラストラクチャを使用します。

したがって、ネットワーク部分は最悪ではありません。 トリッキーなのは、順番に、そう、わかりました…

別の問題、またはここで別の課題が発生します。これは、タイミングと桁違いの課題です。

コンピュータプログラムを作成している場合、プログラムは2つのことのいずれかを実行する傾向があります。CPUバウンドまたはIOバウンドのいずれかです。 どういう意味ですか？

数値計算だけを行うプログラムがある場合は、2つの数値を入力すると、何かが実行されます。 円周率をできるだけ正確に計算しようとしているので、円周率の1兆桁に到達したいとします。

これは、CPUでの数値計算が必要な操作です。 CPUは数値計算用に構築されているので、それを実行するのは非常に高速ですが、私たちのプログラムはいわゆるCPUバウンドになります。

これは、プログラムの実行速度とプログラムがそのジョブを完了するのにかかる時間は、プログラムに投入できるCPUリソースの量によって制限されることを意味します。これは、通常、IOバウンドのものよりも予測可能です。

IOバウンドとはどういう意味ですか？

IOバウンドとは、「ハードドライブ、このCD-ROM、またはこのUSBドライブにあるすべてのファイルを一覧表示するプログラムを作成してください」という意味です。

このプログラムは、CPUを介して実行する必要がなくなり、基本的にはCPUに数値を反転させるだけです。 しかし、実際には、私のプログラムは外部のハードウェアに要求します。外部とは、CPUの外部を意味します。

CPUは、ハードドライブ、CD-ROMドライブ、ペンドライブにデータを取得するように要求する必要があり、データはCPUがアクセスできる場所に配置する必要があります。その後、CPUはデータを読み取り、見つかったデータに基づいて決定します。

基本的に、最初のディレクトリを読み取り、ディレクトリ内の最初のファイルを見つけて読み取り、ファイルが戻ってきます。次に、2番目のファイルを読み取る必要があります。これがIO –入出力–バウンドです。

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.

非常に簡単な例を示します。 Adam Gentは、以前はサポートされていなかったJavaScriptレンダリングでGooglebotによってサポートされている機能を目にしていることを最初に公に指摘したので、常緑のGooglebotの展開で私たちを公に捕らえたのは彼でした。とても幸せです。 なぜなら、多くの人がいつ来るのかと尋ねたばかりであり、発表が時間的にずれたり、問題が発生したりする可能性があるため、明らかに事前に発表することができないため、私は本当に言えません。 しかし、誰かが「マーティンさん、私たちはこのことを見ています。 ここで何が起こっているのでしょうか？」と言えば、これが今起こっていることです。常緑のGooglebotを使用しているレンダリングの割合を増やしています。 そして、あなたがちょうどそこに持っていたこのページは、新しい常緑のグーグルボットを実際に見たものでした。

Webワーカーとの奇妙な振る舞いに私を捕らえたのは、Giacomo Zecchiniだったと思います。これについては、レンダリングチームと長い間話し合っていたので、非常に興味深いものでした。それ！" そして今、人々はそれを使い始めています、そして私はそれを調査する必要があるようです。

通常は問題にならない、興味深い小さな驚きがたくさんあります。ランキングやインデックス作成などの点では大きな影響はありませんが、それらを観察するのは興味深いことです。

そして、私はもっと多くのオタクが私たちに加わってくれるのが大好きです、そしてあなたが知っている、遊んでそして探検してください。

ジェイソン：それはSEOのすべての側面に当てはまります。 私たちが実験し、探索し、共有すればするほど、私たちのコミュニティはより多くのことを学びますが、私たちがこれにどのように取り組んでいるのか、そして私たちが自分自身を助けるのをどのように助けることができるのかについても学びます。