PR




[PR]ランサーズ

SEO SEO用語集

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

投稿日:2019年8月7日 更新日:

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

株式会社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コンサルタントのまとめ

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

▼「クロールバジェット」について
【SEO】「クロールバジェット」とは?

「クロールバジェット」という用語をSEOの世界ではしばしば耳にする。「グーグルのクローラーであるGooglebotがそのサイトを一定期間にどれぐらいクロールするかの割り当て枠」という意味合いで使われている言葉だ。

[広告]おすすめ記事

記事執筆/サイト管理者

記事執筆/サイト運営者


名前:白石竜次 Shiraishi Ryuji
肩書:SEOコンサルタント
高校卒業後、調理師を経て数々の職業を経験し、その後IT企業でHTMLおよびSEO対策を学ぶ。
その経験を知識を生かしながら各企業でSEO担当者となりインハウスSEOを行う。
現在ではフリーで様々な企業のSEOコンサルティングを行っている。
2011年11月 「SEO対策<検索上位にヒットする>コレだけ!技(技術評論社)」を出版。
2014年1月「世界一わかりやすいSEO対策 最初に読む本(技術評論社)」を出版。
2014年1月「たった30分でできるSEO検索エンジン最適化(秀和システム)」を出版。
2017年 書籍「DeNAと万引きメディアの大罪(宝島社)」に寄稿。


ストアカ

白石 竜次

元お笑い芸人の初心者・中小企業向けSEOセミナー

SEOコンサルタント問い合わせ

・SEOコンサルのご依頼
・SEOや誹謗中傷対策のご相談
・講演会・セミナーのご依頼

SEOコンサルタント問い合わせ

SEO漫画「ウェブマブ!」

ニョッキーのお笑いオリジナルネタ

-SEO, SEO用語集

Copyright© SEOコンサルタント.com , 2019 All Rights Reserved.