株式会社JADEスマートフォン用の表示で見るInfoServicesContactNewsBlog2019-08-06レンダーバジェットとは何か、あるいはなぜ私は心配するのをやめてサーバーサイドレンダリングを愛するようになったか「クロールバジェット」ならぬ、「レンダーバジェット」があり、単純なクライアントサイドレンダリングは、大規模なサイトにおいては、そのサイトの検索可能性に対して大きな障害になり得る。ウェブマスター側でも配慮して、より良いウェブを作っていこう。(英語原本はこちら)。実行し、ウェブページをレンダーすることができるようになったことを告知するもので、当時としては非常に画期的なものだったと言えます。認識されるようになり、ウェブ全体の検索可能性が上がることになりました。クローリングスキームも無事撤廃することができました。(英語原本はこちら)。レンダリングをするボットくんあれから5年。実行しページをレンダーすることは、当たり前と思われるようにさえなってきました。素晴らしい成果であり、個人的にも大変誇らしく思っています。利用してよい時代が来たというわけではありません。レンダリングプロセスがどうなっているのかについての詳しい説明を書きました。いままでこのあたりの詳細は明示的には公開されていなかったので、パブリックを語ることは控えてきましたが、この流れなら言える!ということがあります。今でもなお、大規模なサイトにおいては、そのサイトの検索可能性に対して大きな障害になり得ます。書いた図を見て貰えばわかるのですが、レンダリングは現在、「インデックス登録の際、その前処理として走る」、追加的なステップとして設計されています。図の通り、あるページがレンダリングの必要性があると判断された場合、そのページはコンテンツの情報が必要となる本格的なインデックス登録の前に、まずは「レンダーキュー」に追加されます。「そのコンテンツが何なのかを実際に見る以前に」、「そのコンテンツがどれくらいインデックスにとって重要なのかを確率的に推測する」、という処理を行わなければなりません。レンダリングしていないのに、それをレンダリングするべきなのか否かを事前に判断しなくてはならないのです。これは形式的には、クロールと同じような構造の問題です。発見したすべてのページに関して、実際にそのページが価値あるものなのかを、「クロールを行う前に」判断し、その優先度を決定しなくてはなりません。これが何を意味するか?「クロールバジェット」ならぬ、「レンダーバジェット」がある、ということです。バジェットとは?という記事を書いています。詳しく知りたい方は、ぜひそちらを熟読してもらえればと思います。「サイトの人気度・コンテンツの鮮度・サーバーリソース」をベースにそれを決定している、ということです。クロールにおいて最大のネックとなるのは、クロールされる側のサーバーリソースです。「このサーバーはどれくらいの負荷に耐えられるのか」を常に予測しながら、そのサイトのユーザーにとっての重要性と、更新の頻度とうまくバランスを取る形でクロールバジェットを決定しています。これはかなり洗練されたシステムで、外部からはあまり注目されることはありませんが、クロールチームは本当に素晴らしい仕事をしているのです。サーバーリソースです。新しくクロールする必要のあるリソースは増えますから、レンダーされる側のリソースもある程度重要になってはきます。側でキャッシングして負荷を減らすことが可能です。レンダリングする側は逐一最初から行わなくてはなりません。いえども今のところ持っていないのです。どのページを・いつ・どれくらいレンダーするのか、を決定する必要があります。数」をベースに決定するしかありません。多いサイトに対しては、よりバジェットを多く割り当てる。レンダリングの必要がないサイトには、人気であってもリソースは割り当てない。人気ではないのに、レンダリングが必要なURLが多いサイトには、様子を見ながら少しずつ割り当てる。考えてみれば当たり前のことと思います。完全にクライアントサイドでレンダリングを行うシングルページアプリケーションを新規で作成した場合、レンダーバジェットはどうなるでしょうか。生成していないケースも数多くあるのですが、それをうまくやったとしましょう。その重要性がうまく認識できていません。様子を見ながら少しずつレンダーバジェットを割り当てる、ということになります。インデックスに登録されないままになってしまいます。その人気度が分かっているから、リニューアルしてクライアントサイドレンダリングにしても大丈夫だ、という方もいるかもしれません。レンダーする」、という必要に駆られます。クロールバジェットとレンダーバジェットの両方が問題になり得るのです。その結果、リニューアルの結果がうまくインデックスに登録されるまでに何ヶ月、あるいは一年以上もかかってしまう、という可能性もあります。結論から言えば、やはり、大規模なサイトにおけるクライアントサイドレンダリングは、効率的なインデックス登録という点から見れば非現実的です。そのままクローラに返すこと。とっては追加的な、「余計な」ステップです。検索エンジン側にリソースを使わせて、インデックスが遅くなってしまいます。ユーザーにはクライアントサイド、クローラーにはサーバーサイド、といういわゆるダイナミックレンダリングを行えば、たしかに検索エンジン側の問題は解決しますが、それは、レンダリングのためのサーバーリソースの問題を、そのまま「自社のサーバーで引き受ける」ということに他なりません。返すことがインデックス登録にとってはもっと素早く、かつ正確です。クライアントサイドレンダリングは絶対に行わない方が良い、と断言します。認識能力は素晴らしく、他の検索エンジンとは比べ物にならないほどレベルが高いものです。外部から特定のサイトの詳細を見る立場で分析しても、ある程度の規模のサイトまでは全く問題なく動いています。これからのさらなる進化も大いに期待でき、個人的にはとても楽しみにしています。認識能力は完璧ではありません。完璧でない部分は、ウェブマスターの側でもしっかりとしたサポートが必要です。日々生成されるような大規模サイトにおいては、非常に繊細な配慮が必要になります。レンダリング関連の問題は、その最たるものです。増加に伴い2019年8月に事務所を移転いたします。設立のお知らせ令和元年5月7日、株式会社JADEを設立いたしました。K.K.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。