# コーポレートサイトの表示高速化とエッジ配信の設計メモ | Muscle Industry

> サイトの表示速度や検索適合性を高めるための設計方針、技術スタック、キャッシュ制御、品質検証の流れをまとめます。

Canonical: https://muscleindustry.work/ja/blog/first-post
Language: ja

2026/05/15

# コーポレートサイトの表示高速化とエッジ配信の設計メモ

サイトの表示速度や検索適合性を高めるための設計方針、技術スタック、キャッシュ制御、品質検証の流れをまとめます。

[#performance](https://muscleindustry.work/ja/blog/tags/performance)[#cloudflare](https://muscleindustry.work/ja/blog/tags/cloudflare)[#seo](https://muscleindustry.work/ja/blog/tags/seo)[#typescript](https://muscleindustry.work/ja/blog/tags/typescript)

## 目標とした設計基準

デザインや操作性を損なわずに素早い初回表示と軽快な閲覧体験を得られるコーポレートサイトを目指しました。

設計時の目標指標は次の通りです。

-   Lighthouse Performance 95以上
-   Lighthouse SEO 100
-   TBT（Total Blocking Time） 0ms付近
-   [Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals)（LCP、INP、CLS）の良好な維持、特にCLS 0.1未満（理想は0）
-   ファーストビューから問い合わせやプロダクトへ迷わず移動できる導線

これらは設計上の目標値であり、閲覧環境や通信状況による変動を前提とした指標です。また、LighthouseのスコアやTBTとCore Web Vitalsを同一視せず区別して扱っています。LCPやCLSなどはラボ環境でも測定できますが、検索評価の観点では実ユーザーの測定データが重視されます。

## 外部Webフォント配信の停止とフォント選定

表示遅延の要因になりやすい外部Webフォント配信の見直しを行いました。

日本語Webフォントは手軽に端正な印象を作れる反面、サブセット化してもデータサイズが大きくなりやすく、外部ドメインとのDNS解決やTLS接続のオーバーヘッドが初回描画に影響を与えます。

そこで本サイトでは、日本語の表示をOS標準のシステムフォント（ヒラギノ角ゴ、Yu Gothic、Meiryo等）に委ね、デザインの核となる英数字のみ自己ホストした軽量なLatinサブセットで補う方針を採りました。

外部フォント配信サービスへのリクエストを省くことで、フォント取得に伴う遅延を抑えています。なお、サイト内では機能要件に応じてアクセス解析やセキュリティ検証などの外部通信を必要最小限で維持しており、外部依存をすべて排除したわけではありません。

## 静的HTMLの生成とCloudflare Workersの役割分担

ページ表示のたびにHTMLを組み立てる動的処理を避け、ビルド時にHTMLを事前生成しています。

生成した静的コンテンツはCloudflareの静的配信（Assets）を活用し、画像・CSS・JavaScriptなどの静的アセット（`/assets/*`）は基本的にAssetsから直接配信されます（例外として、mainサイトの `/assets/ffmpeg-core/*` など一部リソースはWorkerを経由してR2から配信します）。

一方、通常ページのHTMLリクエストも、Markdown形式への動的切り替えやレスポンス制御を行うためCloudflare Workersを経由します。静的に生成したHTMLであってもWorkerを経由して配信される構成であり、サイトごとにWorkerを分離してホスト別のビルド成果物を配信しています。

キャッシュ制御とレスポンス設計：

-   ハッシュ付きCSS/JS: 内容ハッシュを含むアセットは長期キャッシュの対象とし、効率的な再利用を図る。固定ファイル名のアセットは一律に長期キャッシュ化せず個別に管理する。
-   HTML: ブラウザ側では再検証を基本としつつ、エッジキャッシュを併用して配信負荷を抑える。
-   Markdown切り替え・APIレスポンス: 状態に応じた正確な返却のため Cache-Control: no-store とし、形式判定のために Vary: Accept を適切に付与する。
-   セキュリティヘッダー（HSTS、CSP、X-Content-Type-Options等）: Assets側およびWorker側の双方で要件に合わせて設定する。

キャッシュ設定を厳密に切り分けることで、コンテンツ更新の反映と配信効率のバランスを取っています。

## ビルド時のSEO設計とメタ情報の付与

表示速度だけでなく、検索エンジンやSNSでの適切な解釈を支えるため、ビルド時に必要なメタ情報をHTMLへ埋め込んでいます。

各ページのHTMLに付与される主なSEO情報は次の通りです。

-   正規化された canonical URL
-   対象言語を指定する hreflang（ja / en / x-default など）
-   各ページ固有の meta description
-   OGP（Open Graph Protocol）および Twitter Card
-   構造化データ（JSON-LD）

構造化データは、mainサイトのトップページに WebSite や ProfessionalService、ブログ記事に BlogPosting、支援メニューに Service などを定義しています。また、sitemap.xml や robots.txt はHTML内ではなく独立した生成物として配置しています。

これらの設定は検索エンジンへの情報伝達を整えるものであり、検索順位や検索結果のリッチリザルト表示枠を保証するものではありません（コンテンツ作成の観点については[Google公式のガイダンス](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)も参照してください）。

## 画像の適切な配信とレイアウト崩れの防止

画像はブランドやプロダクトの理解を深める重要な要素ですが、容量過多や不適切な読み込み順は最大視覚要素の描画遅延（LCPの悪化）やレイアウトシフトを招きます。

画像運用では次の点に配慮しています。

-   用途に適したファイル形式と寸法の画像を用意する
-   ファーストビューの主要画像（LCP対象）は遅延読み込みを適用せず素早く描画し、ページ下部の画像には loading="lazy" を指定する
-   imgタグに width と height を指定して表示領域を事前に確保し、画像読み込みに伴うレイアウトのずれ（CLS）を抑える
-   装飾目的の過度な画像配置を控え、CSSによる軽量な装飾を活用する

## URLの正規化と整合性の確保

末尾スラッシュ（トレイリングスラッシュ）の有無が不統一だと、同一コンテンツに対して複数のURLが認識され、評価の分散やキャッシュの重複を招く可能性があります。

mainサイトでは、Cloudflare Assetsの drop-trailing-slash 設定を活用して末尾スラッシュを除いたURLに統一し、canonical や hreflang、サイトマップの記載と整合させています。なお、この設定はmainサイトにおける統一であり、挙動の異なるアプリ別サイトのURL構成まで一律に変更するものではありません。

## 採用した技術スタック

選定基準は「静的出力を中心とした確実な配信」「簡潔なHTML出力」「Cloudflare環境との親和性」です。

-   言語・ランタイム: TypeScript, Node.js, pnpm
-   HTML構築: Hono, Hono JSX（静的レンダリングエンジンとして活用）
-   インフラ・配信: Cloudflare Workers, Cloudflare Assets, Wrangler
-   スタイリング: Tailwind CSS v4
-   原稿管理: Markdown, gray-matter, marked, Zod
-   バンドラ・ビルド: esbuild
-   テスト・品質管理: Vitest, Biome, Lighthouse CI

不要なクライアント側ランタイムを抑えるため、Hono JSXによる静的HTML生成を活用しています。

記事や支援メニューの原稿はMarkdownで管理し、frontmatterの必須項目や日付形式をZodでバリデーションしています（Zodによる検証は構造や型の形式検査であり、原稿の事実誤認や公開判断のミスをすべて自動で防げるわけではありません）。

クライアント側のJavaScriptは、Cookie同意バナーや問い合わせフォーム、各ツールの対話機能など必要な用途に絞って導入し、esbuildでバンドルしています。

## 品質検証と公開フロー

コードや公開原稿に変更を加えた際は、手動の確認だけに頼らず多層的な検証を行っています。

-   実装や公開原稿の変更時:
    -   quality:ci による検証（audit、format、typecheck、unit、build、Workers tests）
    -   security:osv による脆弱性スキャン
    -   git diff --check による行末の余分な空白などの検査
-   表示やSEOに関わる変更時:
    -   対象ページのローカルブラウザでの表示・動作確認
    -   Lighthouseによる各種指標の計測

通常のリポジトリへのpushだけで自動的にCI/CDや本番環境への反映が走る構成にはせず、ローカルおよび手動で検証を通過したコミットSHAを明示して本番へ公開するフローを採っています。これにより、内部ドキュメントのみの変更と公開対象の成果物を適切に区別して運用できます。

## 実装の要点チェックリスト

静的配信とエッジコンピューティングを組み合わせたサイト構築の要点は次の通りです。

1.  外部フォント依存の見直し: 日本語はOS標準フォントを活かし、英数字のみ軽量サブセットを自己ホスト。
2.  静的生成の活用: 通常ページはビルド時にHTMLとして出力し、配信基盤に配置。
3.  アセットとHTMLのキャッシュ分離: ハッシュ付きCSS/JSは長期キャッシュを適用し、HTMLは再検証を基本とする。
4.  正確なレスポンス制御: 形式切り替え（Markdown等）やAPIは no-store と適切な Vary ヘッダーを設定。
5.  ビルド時のSEOメタ情報付与: canonical、hreflang、meta、JSON-LDをHTMLに埋め込み、サイトマップやrobots.txtは別生成物として管理。
6.  画像の寸法明記と読み込み制御: LCP候補を優先し、下部画像を遅延読み込み。寸法指定でCLSを抑制。
7.  URL正規化の適用: サイト特性に応じてトレイリングスラッシュの扱いを揃え、canonicalと一致させる。
8.  クライアントJSの最小化: 同意管理や問い合わせなど必要な機能に絞って実装。
9.  体系的な検証と公開手順: CIスクリプトや静的解析、Lighthouseを活用し、検証済みの変更を明示的に反映する。

表示速度の向上は特定の設定だけで完結するものではなく、不要な依存を省き、適切なキャッシュと配信経路を組み合わせる地道な設計の積み重ねによって支えられています。