目次
レンダリングについて（Google Webmaster Conference）/レンダリングとは？
「海外SEO情報ブログ」の記事を抜粋します。
Google検索のレンダリングとは？――Google Webmaster Conferenceのライトニングトークより #GWCPS
Google Webmaster Conference Mountain View でのライトニングトークをレポートします。
Rendering: レンダリング
レンダリングによって、ユーザーが見ているものと同じものを Googlebot が見ることができる。
レンダリングは基本的には、ブラウザのように振る舞う必要がある。
複雑でコンピューティングの多くの処理を必要とする。
Chrome の機能で Googlebot はレンダリングする。課題
レンダリングには次の 2 つの要素が必要。
Fetch（フェッチ）でコンテンツやリソースを取得
●JavaScript の実行
●Googlebot がフェッチし、Chrome が（JS の実行などで）レンダリングする。
レンダリングが完了しページのスナップショットを撮ると、それがインデックスされる。
これらの処理をウェブ規模、数兆ページで実行しなければならない。フェッチの課題
●robots.txt によるアクセス制限
●サーバーに負荷をかけないための限定したクロール
完全なフェッチができないので、ウェブの実際の状態と違いが生まれる。1 ページにつき 50 〜 60 個のリソースを取得する（robots.txt に従った後）。
60 〜 70 % はキャッシュされている。
フェッチの回数が 20 倍になる（※すずき補足: ここよくわからない😌）。フェッチの手間を省くために、
●Googlebot は HTTP キャッシングに従わない――本当は、キャッシュしすぎて大元をフェッチすべきなのにキャッシュから返そうとする人たちがいるから
●すべてをフェッチしないこともある――フェッチを最小限に抑えるJavaScript の課題
パフォーマンスに関わる。
●限られた CPU パワーしか使えない
●JS の実行が無意味だったら途中で中断しなければならない
●CPU の使いすぎはインデックスに悪影響を与えるJavaScript のレンダリングに失敗する主な原因
ほとんどのページは問題ないが、次のような問題が起こることがある。
●エラーのループ（robots.txt によるブロック、機能の欠損）
●クローキング
●仮想通貨のマイニング（非常に重く、インデックスを壊す）補足
技術的には、Googlebot がリソースを取得（フェッチ）し Web Rendering Service (WRS、ウェブ レンダリング サービス) がレンダリングします。
Googlebot はサーバーに負荷をかけないようにしつつも、ウェブ上のコンテンツとリソースを可能な限り多くフェッチしようと試みます。
僕たちとしては、Googlebotのフェッチ、言い換えればクロールを妨げないサイト構成が必要になります。Googlebot がいったんフェッチしたあとは、WRS の出番です。
Google の Web Rendering Service は、Chrome と同じです（完全に同じではないけれど）。
現在は、Chrome がアップデートすると数週間後に WRS もアップデートするようになっていましたね。
常に、最新のChrome と同等のレンダリングエンジンを利用します。とはいえ、JS の実行は多大なコンピューティングリソースを必要とします。
JS を実行できたとしても、静的なページに比べると動的なページは、インデックス速度が落ちることがあります。
それ以上に、適切に実行されないこともありえます。JavaScript を多用したサイトでは、URL 検査ツールでの検証が重要です。
環境によっては、SSR やダイナミックレンダリングが必要になることもあります。
レンダリングについてとは？
▼そもそも「レンダリング」とはどういう事でしょうか？
レンダリングとは、数値などのデータを読み込み、そのデータの条件やルールに従って適切な形に可視化すること。 レンダリングエンジンとはソフトウェアの内部に組み込まれる部品のことで、ブラウザなどにも、HTMｌを解析して可視化するレンダリングエンジンが組み込まれている。
ユーザーはさまざまなブラウザやデバイスで検索結果を見ます。ウェブコンテンツがユーザーに対してどのように表示され、動作するかを理解するためにGooglebotは「レンダリング」というプロセスを行います。レンダリングは、GoogleがURLを取得しそのページのコードファイル（HTMLなど）を実行します。これは、ブラウザがウェブコンテンツを表示する原理と同じです。次に最初に取得したコードファイルが参照するすべてのリソース（画像、CSSなど）をクロールし、最終的にページの外観を作成します。これにより、Googleはコンテンツをより深く理解します。
（SEOの基礎！Googleクローラを知りクロールとレンダリングの重要性を理解する 黒子の観察者より）
「ダイナミックレンダリング」とは、高度なJavaScriptを多用しているサイトであっても、検索エンジンが適切にインデックスできるようにするための仕組みだ。具体的には、次のようにする仕組みをサーバー側で用意しておく。
アクセスしてきたのが人間が使っているブラウザのときには、ページ内容を作るためのJavaScriptを返す（通常の動作）
アクセスしてきたのが検索エンジンのロボットである場合には、あらかじめ（ある程度）HTML化した状態のものを返す
GooglebotがJavaScriptやCSSを解釈できるようになったとはいえ、完全ではない。Googlebotが解釈できない最新のJavaScriptもあるし、HTMLの状態でタグとして書いておくほうが安全なものもある。
「グーグルにインデックスされるページ内容が、ユーザーが見ているものと同様である」ようにするための仕組みが「ダイナミックレンダリング」だととらえてほしい。
「Google Webmaster Conference製品サミット」ツイートまとめ
▼「Google Webmaster Conference」についてはこちらの記事にまとめています。レンダリングの部分抜粋。
「Google Webmaster Conference製品サミット」ツイートまとめ
「Google Webmaster Conference Product Summit-GooglePlex」というカンファレンスのツイートまとめ記事です。
●データの取得とクロールは興味深いものでした。
レンダリング：フェッチの問題-制限付きアクセス（robots.txt）。 制限されたクロールボリューム（サーバーに過負荷をかけたくない）。 例えば 1ページあたり50?60フェッチ。 60?70％のキャッシュヒット率。 1ページあたり約20フェッチ、または20X #gwcps
Rendering: Fetching Problems - Limited access (robots.txt). Limited crawl volume (don't want to overload your server). e.g. 50-60 fetches per page. 60-70% cache hit rate. About 20 fetches per page, or 20X #gwcps
— Glenn Gabe (@glenngabe) November 4, 2019
●フェッチにキャッシュに依存しないでください：
フェッチ。 コーナーがカットされます。 巧妙なキャッシュトリックに頼らないでください。 #gwcps
Fetching. Corners will be cut. Don't rely on clever caching tricks. #gwcps pic.twitter.com/3sNuH3tZSp
— Jennifer Slegg (@jenstar) November 4, 2019
●レンダリング：GoogleがJavaScriptのレンダリングに関して問題を抱えている1つの方法は、暗号通貨マイナーであると知っていましたか？ 彼らが使用したものはGoogleのレンダリングエンジンをオーバーロードし、インデックス作成に影響を与えるとGoogleは言ったと思う。
FYI Cryptoマイナーはレンダリングを壊します#gcwps
FYI Crypto miners will break your rendering #gcwps pic.twitter.com/I3iNXaTPjx
— MyCool King (@iPullRank) November 4, 2019
