アプリLPを86本作っても、
共通CSSファイルを1つも
持たない理由
今日、Bonsai Spirit・早起きクエスト・進路診断ナビ・地域助け合い辞典の4本を追加し、p/apps/.reflected.jsonに登録されたアプリは86本になった。この86本のランディングページは、共通CSSファイルを1つも持たない。新しいアプリを作るたびに、系統が近い既存アプリのindex.htmlをapps・tools・privacyの3ファイルまるごとコピーし、文言とURL、海外向けだけアクセントカラー6色を書き換えている。共通コンポーネント化ではなくコピー&書き換えを選んでいるのは、そのほうが壊れにくいという理由からだ。
今日追加した4本も、白紙からではなく既存アプリのコピーから始まった
新規アプリのapps・tools・privacyページは、デザインをゼロから起こすのではなく、系統が近い既存アプリの3ファイルをそのまま複製して作る。今日の4本は次の組み合わせで作成した。
| 新規アプリ | コピー元 | 変更した内容 |
|---|---|---|
| Bonsai Spirit(海外・英語) | Ikebana Flow | 本文・メタデータ全文、アクセントカラー6色(テラコッタ×セージ) |
| 早起きクエスト(国内・クエスト100型) | ボランティアクエスト100 | 本文・メタデータ全文のみ(配色は共通のティール×ブルー) |
| 進路診断ナビ(国内・AI診断型) | Furoshiki Wrap | 本文・メタデータ全文のみ |
| 地域助け合い辞典(国内・辞典型) | ゴミ分別大辞典 | 本文・メタデータ全文のみ |
共通CSSファイルを1つも作らなかった理由
CLAUDE.mdには「外部CSS読み込みゼロ」というルールがある。ここで共有CSSファイルを1つ作ってしまうと、86本のどのページを開いても<link rel="stylesheet">という外部リクエストが1本増える。ページごとに<style>タグへ丸ごとインライン複製すれば、そのページ単体で完結し、リクエスト数はゼロのままになる。
- 共有CSSファイル方式: リクエストは1本増えるが、修正が全ページに一括反映される
- インライン複製方式(採用中): リクエストは増えないが、デザイン変更時は該当ページを1つずつ書き換える必要がある
コピー元を系統ごとに固定しているから、文言のニュアンスまで正しく引き継がれる
コピー元をランダムに選ばず、系統が近いアプリに固定している。海外向けはFuroshiki WrapやIkebana Flowのような「AIマッチング×英語」系から、国内クエスト型はボランティアクエスト100から、国内辞典型はゴミ分別大辞典から複製する。これにより、広告文言や「AIへの送信について」といったプライバシーポリシーの記述まで、そのアプリの実際の仕様(AIを使うか・端末内保存のみか)に沿った状態を保てる。
この方式で本当に壊れていないか、ファイルサイズを実測した
今日追加したBonsai Spiritの3ページを実測すると、apps側の<style>ブロックは2,634バイト、apps・tools・privacyの3ファイル合計は22,708バイトだった。86本×3ページ分のCSSを単純合計すれば重複バイト数はかなりの量になるが、実際に1回の訪問で読み込まれるのは開いた1ページ分だけなので、体感速度には影響しない。
| ファイル | サイズ |
|---|---|
| p/apps/bonsai-spirit/index.html | 9,479 バイト |
| p/tools/bonsai-spirit/index.html | 5,784 バイト |
| p/privacy/bonsai-spirit/index.html | 7,445 バイト |
共通化しない設計は行儀が悪く見えるかもしれないが、ビルドステップを持たない静的サイトでは「1ファイルで完結している」こと自体が、どのページからでも壊れずに配信できる保証になる。86本目にして初めてこの数字を実測し、この運用を続ける根拠を自分の手元で確認できた。
Today's App
Bonsai Spirit - 性格や部屋の雰囲気を伝えるとAIが本物の盆栽の仕立て方を提案するアプリ →
Related
毎日firebase.jsonに足しているrewriteは、実は静的ランディングページには不要だった話 →
← ブログ一覧に戻る