何を目標にしたか

このサイトでは、見た目を作り込んでも初期表示が重くならない構成を目指しました。

目標は単純です。

  • Lighthouse Performance 95以上
  • SEO 100
  • TBT 0ms付近
  • CLS 0.1未満
  • 問い合わせや相談導線をファーストビューから見つけやすくする

結果として、実装完了時の確認では主要ページでPerformance 99〜100、SEO 100、TBT 0ms付近、CLS 0.1未満を確認できました。

一番効いた判断は「外部依存を減らす」こと

最初に大きく効いたのはGoogle Fontsをやめたことです。

日本語Webフォントは見た目の印象を作りやすい一方で、コーポレートサイトでは初期表示の足を引っ張りやすくなります。そこで日本語はOS標準フォントを使い、英数字だけ自己ホストした軽量なLatin subsetを読み込む構成にしました。

この判断で、外部ドメインへの接続、CSS取得、フォント取得の待ち時間をまとめて減らせます。

静的HTMLを先に作って、Cloudflareに配る

ページはリクエスト時に毎回組み立てるのではなく、ビルド時にHTMLを生成します。

この構成にすると、通常のページ表示ではサーバー側の処理をほぼ挟まず、Cloudflareの静的配信に寄せられます。Workerは問い合わせAPIなど必要な処理に絞り、サイト閲覧そのものはできるだけ静的に返す設計です。

配信ヘッダーも静的配信側に寄せました。

  • /assets/* は public, max-age=31536000, immutable
  • HTMLは s-maxage と stale-while-revalidate でエッジキャッシュ
  • XMLやTXTも適切にキャッシュ
  • セキュリティヘッダーは _headers で適用

アセットファイル名にはハッシュが入るため、CSSやJSは長期キャッシュしても更新事故が起きにくくなります。

SEOは「後付け」ではなくHTML生成時に入れる

高速化だけを見てHTMLを薄くしすぎると、検索エンジンやSNS共有で弱くなります。そこでSEO要素はレンダリング時に全ページへ確実に入れるようにしました。

入れているものは次の通りです。

  • canonical URL
  • ja / en / x-default のhreflang
  • meta description
  • OGP / Twitter Card
  • JSON-LD
  • sitemap.xml
  • robots.txt

Homeには WebSite と ProfessionalService、ブログ詳細には BlogPosting、プロダクト詳細には Service を出しています。

SEOをJavaScript実行後に任せず、最初のHTMLに入れておくことで、速度と検索対応を両立できます。

画像は「必要な場所だけ強く見せる」

デザイン刷新では、オリジナルプロダクトのキービジュアルやキャラクター画像を使っています。ただし、画像を増やすほどLCPは悪化しやすくなります。

そのため、方針は次のようにしました。

  • ファーストビューに必要な画像だけ優先表示
  • それ以外は loading="lazy" を使う
  • WebP化して容量を抑える
  • width / height を明示してレイアウトシフトを抑える
  • 画像を装飾で増やしすぎない

ゲーム画像を使いながらも、コーポレートサイトとしての表示速度を壊さないことを優先しています。

URL設計も速度とSEOに関係する

URLは末尾スラッシュの扱いが揺れると、canonicalと実URLがずれます。Cloudflare Assets側で drop-trailing-slash に寄せ、/ja と /ja/ の扱いが散らばらないようにしました。

小さい設定ですが、キャッシュ、canonical、hreflang、サイトマップの整合性に効きます。

このサイトで使っている技術

技術選定では、表現力よりも「静的に返せること」「HTMLをきれいに出せること」「Cloudflareに素直に乗ること」を優先しました。

使っている主な技術は次の通りです。

  • TypeScript
  • Hono / Hono JSX
  • Cloudflare Workers
  • Cloudflare Assets
  • Wrangler
  • Tailwind CSS v4
  • Markdown
  • gray-matter
  • marked
  • Zod
  • esbuild
  • Vitest
  • Biome
  • Lighthouse CI
  • pnpm

ページのHTMLはHono JSXで組み立てていますが、ユーザーに配るページはビルド時に生成した静的HTMLです。SPAにせず、初回表示で必要なHTML、meta、JSON-LDを最初から返す構成にしています。

Markdownはブログと支援メニューの原稿管理に使っています。frontmatterはgray-matterで読み、本文はmarkedでHTML化し、Zodで必須項目や日付形式を検証します。これにより、記事や支援メニューを増やしてもビルド時に壊れたデータを検出できます。

CSSはTailwind CSS v4で生成し、サイト全体の見た目は通常のCSSとして配信します。クライアント側JavaScriptは最小限にして、同意バナーなど必要なものだけをesbuildで小さく束ねています。

Cloudflare側では、Workersで問い合わせAPIなどの動的処理を受けつつ、通常ページはAssetsから静的に返す構成です。_headers でキャッシュとセキュリティヘッダーを指定し、wrangler.toml でURLの扱いも揃えています。

テストと品質確認は、Vitest、TypeScript、Biome、ビルドチェックを基本にしています。速度に関わる変更をしたときはLighthouse CIで確認します。

この構成の狙いは、Next.jsのような高機能フレームワークを使わずに、コーポレートサイトに必要なSEO、速度、問い合わせ導線、更新性だけを薄く組み合わせることです。

実装後に確認したこと

実装後は、毎回Lighthouseを回すのではなく、変更内容に応じて確認範囲を分けています。

通常のコンテンツ変更では次を確認します。

  • pnpm run build:assets
  • pnpm run typecheck
  • pnpm test
  • ブラウザで対象ページの表示確認
  • コンソールエラー確認

高速化や配信構成に触れたときだけ、LighthouseでPerformance、SEO、CLS、TBTを確認します。

この運用にすると、開発速度を落とさずに品質を保てます。

再現するならこの順番

同じような爆速コーポレートサイトを作るなら、順番はこうです。

  1. 外部フォントを疑う
  2. 静的生成できるページは先にHTML化する
  3. CSS / JS / 画像に長期キャッシュを効かせる
  4. HTMLにはエッジキャッシュを効かせる
  5. SEO要素を最初のHTMLに含める
  6. 画像はWebP化し、サイズを明示する
  7. URL、canonical、hreflang、sitemapを揃える
  8. 技術スタックは静的配信に合うものだけに絞る
  9. Lighthouseは節目で測る

爆速化は特殊なテクニックよりも、重い依存を消し、静的に返せるものを静的に返し、HTMLの品質を落とさないことが大事です。

このサイトでは、その方針で「速いだけ」ではなく、相談導線、SEO、ゲーム紹介の見せ方まで含めたコーポレートサイトとして設計しています。