なぜ telosh.log は DocumentLink でフルページ遷移に寄せたか

Next.js の App Router では、同一アプリ内のリンクを Link で貼ると、クライアント側の遷移（いわゆるソフトナビ）が既定の体験になります。telosh.log では、ナビの多くを DocumentLink（通常の <a href>） に寄せ、フルページ遷移を選んでいます。

結論から：優先したのは「単純さ」と「URL の信頼性」

個人ブログのトラフィック規模では、毎回フルドキュメントを取りに行くコストより、次の価値を上に置きました。

• アドレスバーの URL が、その瞬間の状態を表す（一覧のソートやページ番号もクエリに載せる）
• サーバーが毎回 HTML を組み立てる前提に寄せ、キャッシュや RSC の境界を追いやすい
• テーマ（ダーク／ライト）を Cookie と SSR で一致させる方針と相性がよい（フルリロードでも class="dark" が消えにくい経路に寄せられる）

ソフトナビを使わないと何が起きるか

クリックのたびに ブラウザがドキュメント全体を読み直すので、体感ではページ遷移が「重く」感じることがあります。一方で、ブログの記事読みはそもそもページ単位の集中が主で、SPA 的な画面内差し替えより 読み込み一回で本文が確定している方が安心、という読者も多いです。

URL ファーストの具体例

記事一覧で並び替えやページを変えると、/posts?sort=...&page=... のように クエリに状態を載せます。これにより次が成立しやすくなります。

• リンクをコピーして渡した相手が 同じ並びを見る
• ブックマークしたとき 同じページに戻る
• クローラや SNS のプレビューが その URL の意味を解釈しやすい

トレードオフ（正直なメモ）

• 遷移のたびにリクエストが増える — CDN や静的生成の効き方はルート設計に依存
• 入力フォームの保持など、クライアント状態を跨ぎたい UI には向かない — ブログの主用途では優先度が低い
• 将来、ダッシュボード的な画面を同一リポジトリに足すなら、Link と DocumentLink を併用する判断もありうる

まとめ

telosh.log では **「ブログとしての読みやすさ」と「状態を URL に載せる」**を先に決め、DocumentLink でフル遷移に寄せています。正解ではなく、規模と用途に対する割り切りです。同じ App Router でも、Link 中心の構成と比較材料にしてもらえればうれしいです。