レンダーバジェットとは？

株式会社JADEさんの記事です。

レンダーバジェットとは何か、あるいはなぜ私は心配するのをやめてサーバーサイドレンダリングを愛するようになったか

あるページがレンダリングの必要性があると判断された場合、そのページはコンテンツの情報が必要となる本格的なインデックス登録の前に、まずは「レンダーキュー」に追加されます。そして Google は、「そのコンテンツが何なのかを実際に見る以前に」、「そのコンテンツがどれくらいインデックスにとって重要なのかを確率的に推測する」、という処理を行わなければなりません。まだレンダリングしていないのに、それをレンダリングするべきなのか否かを事前に判断しなくてはならないのです。

これは形式的には、クロールと同じような構造の問題です。クローリングにおいても Google は、発見したすべてのページに関して、実際にそのページが価値あるものなのかを、「クロールを行う前に」判断し、その優先度を決定しなくてはなりません。

これが何を意味するか？「クロールバジェット」ならぬ、「レンダーバジェット」がある、ということです。

クロールバジェットについては、 Gary Illyes が、Googlebot のクロール バジェットとは？という記事を書いています。詳しく知りたい方は、ぜひそちらを熟読してもらえればと思います。ざっとまとめれば、重要な点は、クロールの優先度という問題に対して、Google は「サイトの人気度・コンテンツの鮮度・サーバーリソース」をベースにそれを決定している、ということです。

クロールにおいて最大のネックとなるのは、クロールされる側のサーバーリソースです。Google は、「このサーバーはどれくらいの負荷に耐えられるのか」を常に予測しながら、そのサイトのユーザーにとっての重要性と、更新の頻度とうまくバランスを取る形でクロールバジェットを決定しています。これはかなり洗練されたシステムで、外部からはあまり注目されることはありませんが、クロールチームは本当に素晴らしい仕事をしているのです。

一方、レンダーにおいて最大のネックとなるのは、レンダリングを行う Google のサーバーリソースです。もちろん JavaScript など新しくクロールする必要のあるリソースは増えますから、レンダーされる側のリソースもある程度重要になってはきます。しかし多くの場合 JavaScript ファイルは複数のページで統一されていますから、Google 側でキャッシングして負荷を減らすことが可能です。ですが、レンダリングする側は逐一最初から行わなくてはなりません。そして、全ウェブの、全ページを、完全に、最も新しいかたちでレンダリングするほどの計算リソースは、いくら Google といえども今のところ持っていないのです。

ですから、Google は、どのページを・いつ・どれくらいレンダーするのか、を決定する必要があります。クロールバジェットとの比喩で言えば、「レンダーバジェット」は、「サイトの人気度と、レンダリングが必要な URL の数」をベースに決定するしかありません。

サイトの人気度と、レンダリングが必要な URL の数。人気で、かつレンダリングが必要な URL が多いサイトに対しては、よりバジェットを多く割り当てる。レンダリングの必要がないサイトには、人気であってもリソースは割り当てない。人気ではないのに、レンダリングが必要なURLが多いサイトには、様子を見ながら少しずつ割り当てる。考えてみれば当たり前のことと思います。

では、完全にクライアントサイドでレンダリングを行うシングルページアプリケーションを新規で作成した場合、レンダーバジェットはどうなるでしょうか。そもそもクロール可能な URL を生成していないケースも数多くあるのですが、それをうまくやったとしましょう。それでもなお、完全に新規のサイトですから、Google にはその重要性がうまく認識できていません。ですから、様子を見ながら少しずつレンダーバジェットを割り当てる、ということになります。結果として、多くの URL がインデックスに登録されないままになってしまいます。

うちのサイトはすでに長い間運用していて、Google にもその人気度が分かっているから、リニューアルしてクライアントサイドレンダリングにしても大丈夫だ、という方もいるかもしれません。どうでしょうか。いままで HTML がそのままサーバーから返ってきており、突然すべての URL がクライアントサイドレンダリングになったら、Google は「すべての URL を再度クロールし」、「その上ですべての URL をレンダーする」、という必要に駆られます。つまり、クロールバジェットとレンダーバジェットの両方が問題になり得るのです。その結果、リニューアルの結果がうまくインデックスに登録されるまでに何ヶ月、あるいは一年以上もかかってしまう、という可能性もあります。

結論から言えば、やはり、大規模なサイトにおけるクライアントサイドレンダリングは、効率的なインデックス登録という点から見れば非現実的です。サイトの検索可能性という観点から考えれば、理想は、レンダリングを行う必要のない HTML をそのままクローラに返すこと。レンダリングは Google にとっては追加的な、「余計な」ステップです。検索エンジン側にリソースを使わせて、インデックスが遅くなってしまいます。ユーザーにはクライアントサイド、クローラーにはサーバーサイド、といういわゆるダイナミックレンダリングを行えば、たしかに検索エンジン側の問題は解決しますが、それは、レンダリングのためのサーバーリソースの問題を、そのまま「自社のサーバーで引き受ける」ということに他なりません。

最終的には、最初から静的な HTML を返すことがインデックス登録にとってはもっと素早く、かつ正確です。特に、新しさが重要になるニュースサイトや、毎日数千や数万単位の URL が生成される UGC などでは、クライアントサイドレンダリングは絶対に行わない方が良い、と断言します。

Google の JavaScript 認識能力は素晴らしく、他の検索エンジンとは比べ物にならないほどレベルが高いものです。改めて外部から特定のサイトの詳細を見る立場で分析しても、ある程度の規模のサイトまでは全く問題なく動いています。これからのさらなる進化も大いに期待でき、個人的にはとても楽しみにしています。

けれども、全てのシステムがそうであるように、今の Google の JavaScript 認識能力は完璧ではありません。完璧でない部分は、ウェブマスターの側でもしっかりとしたサポートが必要です。特に、数万単位の URL が日々生成されるような大規模サイトにおいては、非常に繊細な配慮が必要になります。レンダリング関連の問題は、その最たるものです。

JavaScript活用の大規模サイトはGooglebotにレンダリングを任せるべきではない、と元グーグル社員

グーグルはここ数年で、ユーザーがブラウザで見るときと同じように、JavaScriptやCSSを含めてページを表示して内容をインデックスできるようになっている。この表示再現の処理を「レンダリング」というのだが、レンダリングを実行するには、HTMLから内容を読み取るのに比べてかなり多くのコンピュータ処理が必要だ。グーグルがいくらクラウドの王者だとはいえ、検索のために使えるサーバー資源は無限ではなく、すべてのURLを分け隔てなくレンダリング処理できるわけではない。

そのためグーグルは、「どのページをレンダリングするか」の優先度を決めなければいけない。サイトごとに定められているであろうそうした制限を長山氏は「レンダーバジェット」と名付けているのだ。

SEOコンサルタントのまとめ

私もまだまだ勉強中です。。