プリレンダーとは何か：検索エンジンが見ている最初のHTML
遊びを見つける執筆にClaudeを使用しています。
ブラウザで開くとタイトルも説明文も画像も並んでいるのに、「ページのソースを表示」で見ると、中身がほとんど空の <div id="app"></div> だけだった。そんな場面を考えてみます。画面に見えているものと、サーバーから最初に届いたHTMLが、別のものになっている状態です。 この差が、検索結果の表示やリンクの共有、読み込みの体感速度に関わってきます。プリレンダーは、この差を小さくするための考え方のひとつです。ここでは「いつ、誰がHTMLを組み立てるのか」という時間軸で整理し、ビルド時に作られる静的ページと、表示後に更新される部分の分け方を読み解きます。最後に、気になるサイトを自分で確かめる手順も示します。
この記事の目次
プリレンダーは「誰が、いつ」HTMLを作るかの話です
プリレンダー（事前レンダリング）とは、ページが閲覧される前に、HTMLの中身を作っておく方法です。多くの場合は、公開用ファイルを作る工程（ビルド）の中でページごとのHTMLを書き出します。訪問者が来たときには、できあがったファイルを返すだけです。
比較のために、HTMLを組み立てる時点で三つに分けてみます。
- クライアントレンダリング、HTMLを組み立てる時点：閲覧者のブラウザ内（JavaScript実行後）、最初に届くHTMLの中身：骨組みだけで、本文は空のことが多い
- サーバーレンダリング、HTMLを組み立てる時点：リクエストを受けたとき、サーバー上、最初に届くHTMLの中身：本文を含む
- プリレンダー（静的生成）、HTMLを組み立てる時点：ビルド時、最初に届くHTMLの中身：本文を含む（全員に同じもの）
ここで大事なのは、プリレンダーされたHTMLが「閲覧前に確定している」点です。閲覧者ごとに違う内容は、ビルドの時点では作れません。だからプリレンダーでは、全員に共通の部分を先に作り、閲覧者ごとの部分は表示後に足す、という分担が自然になります。
最初のHTMLと、表示後の更新を分ける
プリレンダーされたページは、届いた時点で本文が入っています。そのあとブラウザがJavaScriptを読み込み、ボタンが動くようになったり、ログイン状態に合わせて表示が変わったりします。この「最初のHTML」と「表示後の更新」の二層構造が、記事の中心になる考え方です。
分け方の基準は、次のように考えると判断しやすくなります。
- 最初のHTMLに入れてよいもの：誰が見ても同じで、公開後にあまり変わらないもの。作品名、紹介文、見出し、説明の本文などです。
- 表示後に更新するもの：閲覧者や時刻で変わるもの。ログイン状態、個人の履歴、いまの設定、最新の件数などです。
検索エンジンとの関係も、この分け方で見えてきます。一般に、検索エンジンのクローラー（ページを巡回して集めるプログラム）は、まず届いたHTMLを読みます。JavaScriptを実行して表示後の状態まで見る仕組みを持つ検索エンジンもありますが、実行は別の段階に回されたり、処理に制約があったりします。リンクを共有したときに出るプレビューのように、最初のHTMLだけを読むものも少なくありません。どこまで読まれるかは検索エンジンやツールで異なり、時期によっても変わります。実際の挙動は、各社の公式ドキュメントで確認してください。
この前提に立つと、検索結果やプレビューに出てほしい情報は最初のHTMLに入れておくのが安全です。表示後の更新に頼ると、読み取られるかどうかが相手の仕組み次第になるからです。
逆に、すべてをプリレンダーすればよいわけでもありません。閲覧者ごとの情報を静的HTMLに焼き込むことはできないので、そこは表示後に埋める設計になります。ビルド後に内容が変わるページは、作り直すタイミングも考える必要があります。
アソバースの確認済み事項から読み取れること
アソバースの案内で確認できる事実から、この二層構造に当てはめられる点を拾ってみます。なお、アソバース自身のサイトがどの方式でHTMLを作っているかは、確認済み事項に含まれていません。その部分は次の節の手順で、読者が自分で確かめられます。
作品はサイトのページとは別の文書として動きます。 ゲームはsandbox付きのiframeで実行され、アップロードされたコードはメインサイトと別のオリジンから配信されます。iframeの中身は、外側のページとは別のHTML文書です。外側のページのソースを見ても、ゲームの画面の中身は並びません。作品の入口は、アップロード作品なら直下の index.html です。作品名や紹介文のようにページ側に載る文章と、ゲームが画面に描く内容は、別の文書として考えるのが基本になります。
閲覧者ごとの状態は、事前には作れません。 ログイン中はクラウドセーブ、作品ごとのプレイ履歴、あとで遊ぶ、好きな作品、作者のフォローが使えます。ゲストの履歴や進行は端末内に保存されます。これらは閲覧者ごとに違う情報なので、ビルド時に作る共通のHTMLには入れられません。「ログインしていれば出る表示」は、表示後に更新される層の役割だと読み取れます。
表示の言語や設定は、あとから切り替わります。 サイトは日本語と英語の表示切り替え、ライト／ダーク、動きを抑える設定に対応しています。公式作品13本も、サイトの言語設定に合わせて表示を切り替えます。ただし、作者が入力した作品名や紹介文は書き換えません。作者が書いた文章は固定の内容で、切り替わるのは画面の案内表示です。前の節の分け方に当てはめると、固定の文章は最初のHTMLに向き、設定に左右される表示は後から更新する層に向きます。実際にどちらで出しているかは、作品を開いて確かめる部分です。
なお、公式作品のカバー画像は生成したアートワークで、ゲーム画面のスクリーンショットではありません。画像は検索エンジンにとって、HTML内の画像の指定と代替テキストを通して見える情報です。その画像が実際のゲーム画面かどうかは、画像自体では判断できません。
自分で確かめる手順：ソース表示と要素の検査を見比べる
気になるページが、最初のHTMLに本文を持っているかどうかは、数分で確かめられます。ここでは作品の一覧や詳細のページなど、見たいページを一つ決めて始めます。
準備するもの
- 確認したいページのURL
- PCのブラウザ（開発者ツールが使えるもの）
- 任意で、コマンドラインの curl（ページを取得するだけのコマンド）
手順
- ページを普通に開き、見える文章を一つ選びます。 作品名や紹介文の一節など、画面に出ている短い文を一つ控えます。
- 「ページのソースを表示」を開きます。 多くのブラウザでは、ページ上で右クリックして選べます。ここに表示されるのは、サーバーから最初に届いたHTMLです。
- ソース内で、控えた文章を検索します。 見つかれば最初のHTMLに入っています。見つからなければ、表示後に作られている可能性が高いと判断します。
- 開発者ツールの「要素（Elements）」タブで、同じ文章を探します。 こちらは表示後のDOM（ブラウザ内で組み立て終わったページの構造）を映します。ソースと要素の内容が大きく違えば、表示後の更新が多いページです。
- JavaScriptを無効にして、再読み込みします。 開発者ツールの設定から無効にできます。文章が残れば、最初のHTMLだけで表示できるページです。
- （任意）curl でURLを取得し、同じ文章を検索します。 ブラウザを介さず、最初に届く内容そのものを見られます。
記録の取り方
文章ごとに「ソースにある／ない」「要素にある／ない」「JS無効で出る／出ない」の三点を、ページ単位で一覧にします。作品名、紹介文、ボタンの文言、ログイン状態の表示など、最低でも4〜5種類の文章を同じ表に並べると、どの層に何があるかが見えてきます。
結果の読み方
- ソースにも要素にもあり、JS無効でも出る：最初のHTMLに入っています。
- ソースになく、要素にはある：表示後の更新で作られています。
- ログイン状態で変わる表示がソースにない：閲覧者ごとの情報を後から埋める設計と読めます。
起こりやすい誤り
- 「要素の検査」を最初のHTMLと取り違えること。要素の検査は表示後の姿です。最初のHTMLは、ソース表示か curl で見ます。
- ログイン中とログアウト中で見比べずに結論を出すこと。個人の状態で変わる部分は、状態を揃えて確認します。
- 読み込みの途中で見てしまうこと。表示後の更新は少し遅れて入るので、落ち着いてから見比べます。
- 言語設定の違いを見落とすこと。表示言語を変えると、画面の案内文が入れ替わる場合があります。
- ページ側とiframeの中を混同すること。ゲームの画面の文字は、外側のページのソースには出ません。
次の行動
まず、よく見るページを一つ選び、ソース表示と要素の検査で、作品名と紹介文がどちらにあるかを見比べてください。作る側の方は、検索やプレビューに出したい文章を、閲覧者ごとに変わる表示と分けて考えると、置き場所を決めやすくなります。検索エンジンごとの読み取り方は変わりうるため、最新の挙動は各社の公式ドキュメントで確認してください。
参考資料
- Google 検索セントラル：JavaScript と検索に関するドキュメント
- MDN Web Docs：SSR、SSG、DOM など用語解説のページ
