静的サイトで作れる関連記事と作れない関連記事｜Next.js static exportの限界と割り切り方

関連記事を実装したあと、ふと気になることがありました。

Amazon の「この商品を買った人はこんな商品も買っています」や YouTube の「次の動画」は、見るたびに内容が変わります。自分の閲覧履歴や購買履歴をもとに、その人専用のおすすめが表示されているからです。

一方、私が自分のブログに実装した関連記事は、どの読者が見ても同じ記事が表示されます。

これは「本当の意味での関連記事」と言えるのでしょうか。

静的サイトとは何か

私のブログは Next.js の output: 'export' という設定で動いています。

この設定にすると、ビルド（サイトを公開用に変換する処理）のタイミングで全ページの HTML ファイルが生成され、それをそのままサーバーに置いて配信します。

これを静的サイトと呼びます。

静的サイトの特徴は、ページを表示するときにサーバー側での処理が一切発生しないことです。

ここで「サーバー側」について補足します。ウェブサイトは大きく「サーバー側」と「ブラウザ側」に分かれています。サーバー側とは、インターネットの向こう側にあるコンピュータが行う処理のことです。ブラウザ側とは、読者のパソコンやスマートフォンのブラウザ上で行われる処理のことです。

静的サイトは、あらかじめ作られた HTML ファイルをそのまま返すだけなので、表示が速く、サーバーへの負荷も小さいというメリットがあります。

サーバー側での処理が発生しないということは、ページを表示するたびに何かを判断することができないということです。

具体的には、以下のことができません。

Amazon や YouTube のおすすめは、アクセスのたびにサーバーがユーザーの履歴データを処理して最適な結果を返しています。これはサーバー側での処理があって初めて成立します。静的サイトにはこれができません。

私が実装した関連記事は、ビルド時に決まります。

記事Aのページをビルドするとき、「記事Aのタグと一致する記事」「記事Aと同じカテゴリーの記事」を探して、結果を HTML に書き込みます。この時点で関連記事は確定し、以降は誰がアクセスしても同じ記事が表示されます。

つまり、読者が誰であるかに関係なく、記事の内容だけをもとに選ばれた関連記事です。

Amazon や YouTube のような「あなた専用のおすすめ」とは根本的に違います。

「本当の意味での関連記事ではない」とわかったとき、実装した意味があったのかと少し考えました。

ただ、冷静に考えると、個人ブログに Amazon や YouTube と同じ仕組みを求めることは現実的ではありません。あれは巨大なデータと処理基盤があって初めて成立するものです。

個人ブログの関連記事に必要なのは、「今読んでいる記事と関係がありそうな記事を、次の候補として提示すること」だと割り切りました。

読者が今読んでいる記事のテーマに興味を持っているなら、同じタグを持つ記事も興味を持ってもらえる可能性が高い。それだけで十分に機能します。

割り切りは「何もしない」とは違います。静的サイトのまま、現状の範囲でできる改善はあります。

その中で一番効果が大きいと感じているのが、件数の設定です。

多すぎると読者が選びにくくなり、少なすぎると選択肢が足りません。私は2列×3行の6件に設定しています。最初は5件にしていましたが、2列表示では最後の1件が左列だけに残ってバランスが崩れることに気づいて変更しました。「何件表示するか」という小さな判断にも、レイアウトの制約が直結していました。

記事数が増えてきたとき、この数字が適切かどうかは改めて見直す予定です。

Next.js をサーバーモードに切り替えると、アクセスのたびにサーバー側で処理ができるようになります。

そうなると、以下のことが可能になります。

「よく読まれている関連記事を優先する」という方式は、読者一人ひとりの履歴は使いませんが、多くの読者に読まれた記事を優先するという意味で、現状より一歩進んだ仕組みになります。

ただしこれは、閲覧数データが蓄積されてから意味を持ちます。今すぐ実装しても、データがなければ機能しません。今はまずサイトを構築して、記事をどんどん書いていく段階だと考えています。

静的サイトには明確な限界があります。

しかしその限界を知った上で使うと、できることとできないことが整理されて、余計な迷いがなくなります。

「本当の意味での関連記事は作れないが、読者に次の記事を届けるための仕組みは作れる。」

この割り切りで十分だと今は考えています。