静的サイトとは何か、やっとわかった話：クライアントサイドレンダリングからAstroへ

本記事は中国語記事の日本語訳です。原文：https://kkuk.dev/posts/understand-static-sites/

クライアントサイドレンダリングで openflomo を作る

AI Coding に触れ始めたばかりの頃、メモアプリ「flomo」に書き溜めたノートをWeb上で公開したいと思い立ちました。コードはすべて Claude に書いてもらう形で進めたのですが、そのときの作業の流れはこんな感じでした。

1. ノートの元データをダウンロード：flomo 公式のエクスポートは HTML 版

単に公開することだけを考えれば、この書き出された HTML をそのまま静的ページとしてホスティングするだけで十分でした。ですが、そこで大人しくしていられないのが私の悪い癖です。「どうせなら本家の flomo に近い画面にしたい」と、わざわざ余計な苦労を買って出て、リビルドすることにしてしまいました。

2. 細部の作り込み

本家の画面とエクスポートされた HTML の違いは、主に次の2点でした。

1. ノートカード内の「タグ」がハイライト表示されず、タグでの絞り込みもできない
2. 左サイドバーにタグ一覧が存在しない

あれこれ試行錯誤しながら手を動かした結果、なんとか下のような画面が出来上がりました。嬉しくてたまらなくなり、すぐに GitHub Pages にデプロイしました。

3. 直面した問題：読み込み速度が遅い

当時、ノートのストックは全部で 2,000 件以上（2k+）ありました。HTML の元ファイルはおよそ 700 KB、JavaScript と CSS のファイルもそれぞれ 600 行を超えています。この状態でページを開くと、ブラウザ上では次のような処理が走っていました。

1. まず index が読み込まれ、そのタイミングで元データ（HTML）と JavaScript、さらに必要に応じて CSS が読み込まれる
2. JavaScript のロジックによって元データがループ処理され、タグの認識や整形、一覧画面の生成、URL などのフォーマットが行われる
3. CSS が読み込まれてレンダリングが完了する

私はコードが書けないので、LCP（Largest Contentful Paint）のパフォーマンス改善スコアのスクショとにらめっこしては、Claude に投げて「なんとかして」と頼み込みました。色々と手を尽くしたおかげで多少の改善は見られたものの、私の直感は「そもそもこのやり方、何かが根本的におかしいんじゃないか……？」と告げていました。

HackerNews と Buzz に出会う

ちょうどその頃 HackerNews を見始めたのですが、なぜこれほど UI が前時代的なのか不思議でなりませんでした。ですが色々と調べてみると、ユーザーたちがこのデザインを支持する理由が分かってきました。

• 最小限必要な HTML と CSS だけで構成され、JavaScript がほぼ使われていないため、極端に通信環境が悪くてもアクセスできる
• 情報密度が高い
• 大量の CSS による余計な装飾がなく、コンテンツに没頭しやすい

そんな中、Owen さんの Buzz 再構築についての記事（ https://www.owenyoung.com/blog/new-buzzing ）を目にしました。そこでようやく気がついたのです。先ほどの openflomo のようなケースこそ、サーバーサイドでレンダリングして静的サイトを生成（ビルド）し、それを GitHub Pages でホスティングするべきだったのだ、と。

クライアントサイドレンダリングとサーバーサイドレンダリング

最もシンプルな Web ページであれば、HTML ファイルが1つあれば成立します。CSS が見た目を整え、JavaScript が動的なロジックを担います。JavaScript がなかったとしても、HTML 単体ですでに完結した1つのページなのです。

しかし、より一般的な Web サイトでは、手元にあるデータから最終的なページの骨格を作り上げるまでに、もうひとつのプロセスが必要になります。たとえばブログなら、Markdown で書いた記事を、一連のスクリプトによって HTML に変換して初めて Web ページになります。

この変換プロセスのことこそが、「ビルド（Build）」です。

そして Web サイトをホスティングする場合、ビルドを行うタイミングには主に次の3つがあります。

1. ローカルでビルドし、コンパイル後のファイルをホスティングする
2. ソースファイルをデプロイする際にビルドする（サーバー側で1度だけビルドが行われ、訪問者はコンパイル済みのファイルを受け取る）
3. クライアント側ですべての元リソースを取得し、その場で一時的にビルドを行う（これでは必然的に、読み込みやレンダリングの速度が遅くなってしまう）

Astro で再構築する

今度は Cursor に手を動かしてもらいながら、Astro を使ってプロジェクトを作り直しました。現在の処理フローは次のようになっています。

1. 新しい flomo のノートデータを取り込む
2. コードをコミットしてプッシュすると、サーバー側でビルドスクリプトが走り、タグやリスト、スタイルなどの処理を行って、最終的な静的サイトのリソースを生成する
3. クライアントがアクセスすると、生成済みの静的サイトを直接読み込む

DevTools でこの読み込み項目を見たとき、かつて一緒に仕事をしてきたエンジニアの同僚たちが「きれいなコードが書けた！」と興奮していたあの気持ちを、初めて自分でも味わうことができました。