18ポータルでPageSpeed Insights全項目100点を達成した実体験から

ウェブサイトの表示速度は、ユーザー体験とビジネス成果に直結します。私たち京谷商会では、portal-workerという1つのCloudflare Worker上で18のサブドメイン（ポータルサイト）を運用しています。すべてのポータルでPageSpeed Insights全項目100点を達成しました。

この結果は偶然ではありません。WordPressから静的HTML + vanilla JSへの移行、Cloudflare Workersのエッジ配信、そして画像・CSS・JSの徹底的な最適化を組み合わせた結果です。

詳しい技術的な取り組みはPageSpeed Insights全項目100点を全ページタイプで達成した方法にまとめていますが、この記事では表示速度改善の基礎知識と、私たちが実際にたどったプロセスを解説します。

Core Web Vitalsとは

Core Web Vitalsは、Googleが定義した3つのユーザー体験指標です。2021年からランキングシグナルとして使用されており、SEOにも直結します。

LCP（Largest Contentful Paint）

ページの最大コンテンツが表示されるまでの時間です。ファーストビューの主要な画像やテキストブロックの表示時間を測定します。

評価時間
良好2.5秒以下
改善が必要2.5〜4秒
不良4秒以上

私たちのポータルでは、Cloudflare Workersのエッジ配信によりLCPは0.5秒前後を安定して達成しています。サーバーからHTMLが返るまでの時間（TTFB）がsub-100msなので、LCPの大部分はブラウザ側のレンダリング時間だけになります。

LCPを悪化させる主な要因は、大きな画像の遅延読み込み、レンダリングブロックするCSS/JS、そしてサーバー応答の遅さです。特にファーストビューの画像にloading="lazy"を指定してしまうと逆効果になるため、ヒーロー画像にはfetchpriority="high"を指定し、lazyは付けないのがベストプラクティスです。

INP（Interaction to Next Paint）

ユーザーの操作（クリック、タップ、キー入力）に対する応答性を測定します。INPは2024年3月にFID（First Input Delay）に代わってCore Web Vitalsの正式指標となりました。FIDが「最初の操作の遅延」だけを測定していたのに対し、INPはページ全体のライフサイクルを通じた応答性を評価するため、より実態に即した指標です。

評価時間
良好200ms以下
改善が必要200〜500ms
不良500ms以上

静的HTML + vanilla JSの構成では、ReactやVueのような仮想DOMのオーバーヘッドがないため、INPは自然と良好になります。私たちがクライアントサイトを静的HTMLで構築している理由の一つがこれです。

INPが悪化する典型的なパターンとして、長時間メインスレッドをブロックするJavaScript処理があります。対策としては、重い処理をrequestAnimationFrameやsetTimeoutで分割する、Web Workersにオフロードする、といった手法が有効です。

CLS（Cumulative Layout Shift）

ページの読み込み中にレイアウトが意図せずずれる量を測定します。

評価スコア
良好0.1以下
改善が必要0.1〜0.25
不良0.25以上

CLSが悪化する典型的な原因と対策を具体的に見ていきましょう。

サイズ未指定の画像・動画: <img>や<video>にwidth/height属性がないと、読み込み完了時にレイアウトがガタッとずれます。CSSのaspect-ratioプロパティと組み合わせれば、レスポンシブでもレイアウトシフトを完全に防げます。

<img src="hero.webp" width="1200" height="630"
     style="aspect-ratio: 1200/630; width: 100%; height: auto;"
     alt="ヒーロー画像">

遅延読み込みされるWebフォント: 日本語Webフォントは数MBになることがあり、読み込み中にフォールバックフォントとの字幅差でCLSが発生します。font-display: swapに加えて、フォントメトリクスオーバーライド（size-adjust、ascent-override等）を使うとフォールバックとWebフォントの表示サイズを揃えられます。

動的に挿入されるコンテンツ: 広告バナーやクッキー同意バーなど、後から挿入される要素にはあらかじめ表示領域を確保（min-heightの指定）しておくことが重要です。

WordPress時代と静的サイトの比較 — 京谷商会の移行体験

京谷商会では、かつてWordPressでクライアントサイトを運用していました。6つのサブドメインをWordPressから静的HTML + Cloudflare Workersに移行した結果、劇的な変化がありました。

WordPress時代:

  • PageSpeedスコア: モバイル50〜70点台
  • TTFB: 500ms〜1.5秒（共有サーバー）
  • プラグイン更新・セキュリティパッチの運用負荷
  • テーマの不要なCSS/JSが大量に読み込まれる

静的サイト移行後:

  • PageSpeedスコア: 全項目100点
  • TTFB: sub-100ms（Cloudflare Workersエッジ配信）
  • 運用負荷ほぼゼロ（セキュリティパッチ不要）
  • 必要なCSS/JSだけを読み込む完全なコントロール

この結果はHTTP Archiveのデータとも整合します。2026年現在、モバイルページの中央値は約2.5MBですが、私たちのポータルサイトは1ページあたり100KB前後です。

この移行を通じて実感したのは、「表示速度の改善」は小手先のテクニックではなく、アーキテクチャの選択が最も大きな影響を持つということです。

実践的な最適化手法

1. 画像の最適化

画像はページの総データ量の50%以上を占めることが多く、最も効果の大きい最適化ポイントです。

フォーマットの選択:

  • WebP: JPGより25-35%小さく、透過もサポート。私たちはすべての画像をWebPで配信しています
  • AVIF: WebPよりさらに20-30%小さい次世代フォーマット。2026年現在、Chrome・Firefox・Safariの主要ブラウザすべてが対応済みで、Can I Useによれば全ブラウザの約95%をカバーしています。新規プロジェクトではAVIFを第一候補にする価値があります
  • SVG: アイコンやロゴなどのベクター画像に最適。京谷商会のサイトではアイコン類はすべてSVG

具体的な対策:

  • <img>タグにwidth/height属性を必ず指定（CLS対策）
  • ファーストビュー画像にはfetchpriority="high"を付与し、loading="lazy"は付けない
  • ファーストビュー外の画像には**loading="lazy"**で遅延読み込みを有効化
  • srcsetでレスポンシブ画像を提供
  • 適切な圧縮率で出力（品質80%程度で視覚的な差はほぼなし）

2. CSS/JavaScriptの最適化

京谷商会の実践:

私たちのクライアントサイトではTailwind CSSを使い、PurgeCSSで未使用クラスを自動除去しています。ビルド後のCSSファイルは通常10KB以下。WordPressテーマ時代の200KB超のCSSと比べると20分の1以下です。

JavaScriptについては、vanilla JSで必要最小限のインタラクションだけを実装しています。フレームワークを使わないことで、バンドルサイズはほぼゼロです。

一般的な対策:

  • 不要なCSSを削除（PurgeCSSなどのツールを使用）
  • CSSファイルを圧縮（minify）
  • クリティカルCSSをインライン化
  • JavaScriptはasyncまたはdefer属性で非同期読み込み
  • 不要なライブラリの削除
  • Tree Shakingでバンドルから未使用コードを除去

3. エッジ配信とキャッシュ戦略

Cloudflare Workersの威力:

京谷商会のportal-workerは、ユーザーに最も近いエッジサーバーからHTMLを直接生成・配信します。従来のオリジンサーバーへのリクエストが不要なため、世界中どこからアクセスしてもsub-100msのレスポンスを実現しています。

キャッシュ設定の実例:

Cache-Control: public, max-age=31536000

静的ファイル（CSS、JS、画像）には長めのキャッシュを設定し、ファイル名にハッシュを含めることでキャッシュバスティングを行います。

CDNの活用: CloudflareのCDNを使えば、無料プランでもグローバルなエッジキャッシュが利用できます。私たちもCloudflareの無料プランからスタートしました。

Early Hints（103レスポンス）の活用:

Cloudflare Early Hintsは、サーバーがHTMLを生成している間に、ブラウザへ重要なリソースのプリロードヒントを先行送信する仕組みです。これにより、HTMLの到着を待たずにCSS・フォント・画像の取得を開始でき、LCPが改善します。Cloudflareダッシュボードからワンクリックで有効化できます。

4. フォントの最適化

ウェブフォントは表示速度に大きく影響します。特に日本語フォントはファイルサイズが大きいため注意が必要です。

  • font-display: swapでFOIT（Flash of Invisible Text）を防止
  • 使用する文字のサブセットのみ読み込む（日本語フォントでは特に重要。Google Fontsは自動サブセット配信に対応）
  • preloadでフォントファイルを事前読み込み
  • size-adjustプロパティでフォールバックフォントとWebフォントのサイズ差を調整し、CLS発生を抑制

5. サーバーレスポンスの改善

TTFB（Time To First Byte）の短縮:

京谷商会ではHono on Cloudflare Workersで全APIを構築しています。Honoの軽量なルーティングとCloudflare Workersのエッジ実行により、APIレスポンスもsub-100msです。

  • D1（SQLite）のクエリ最適化 — インデックス設計が重要
  • HTTP/2の有効化（Cloudflareが自動対応）
  • HTTP/3（QUIC）の活用 — Cloudflareではダッシュボードで有効化するだけで、TLSハンドシェイクの短縮とパケットロス耐性が向上します
  • SSL/TLSの最適化

6. ページナビゲーションの高速化 — Speculation Rules API

Speculation Rules APIは、ユーザーが次にクリックしそうなページを事前にプリレンダリングする仕組みです。Chromeで利用可能で、リンクホバー時に遷移先ページを裏で事前読み込みすることで、ページ遷移をほぼ瞬時に感じさせることができます。

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/articles/*" },
    "eagerness": "moderate"
  }]
}
</script>

京谷商会のポータルサイトでは、記事一覧ページで読者が次に読みそうな記事をmoderate設定でプリレンダリングしており、体感的なページ遷移速度が大幅に向上しています。

測定ツール — 改善の第一歩は現状把握

表示速度を改善するには、まず正確な測定から始めましょう。

ツール用途特徴
[PageSpeed Insights](https://pagespeed.web.dev/)総合スコア確認ラボデータ+フィールドデータの両方を表示
[Chrome DevTools Lighthouse](https://developer.chrome.com/docs/lighthouse/overview)詳細なパフォーマンス分析ローカル環境でも測定可。改善提案が具体的
[WebPageTest](https://www.webpagetest.org/)詳細な読み込み分析ウォーターフォール表示で読み込み順序を可視化
Chrome DevTools Performanceランタイム分析INP悪化の原因特定に最適。Main Threadの処理を詳細に追跡

PageSpeed Insightsの「フィールドデータ」は実際のユーザーの測定データ（CrUXレポート）に基づいており、ラボデータだけでは見えない実環境の問題を把握できます。

改善の優先順位 — 私たちが実際にたどった順序

すべてを一度に改善する必要はありません。京谷商会が実際にたどった優先順位を紹介します。

  1. PageSpeed Insightsで現状を測定 — まず数字を把握する
  2. アーキテクチャを見直す — WordPressが本当に必要か検討する
  3. 画像の最適化 — WebP・AVIF変換だけで大幅改善
  4. 不要なJavaScriptの削除 — 使っていないプラグイン・ライブラリを排除
  5. CDNの導入 — Cloudflare無料プランで十分な効果
  6. キャッシュヘッダーの設定 — 適切なCache-Controlで再訪問を高速化
  7. CSSの最適化 — PurgeCSSで未使用スタイルを除去

特にステップ2のアーキテクチャ見直しが最もインパクトが大きかったです。WordPressから静的サイトへの移行だけで、スコアが50点台から90点台に跳ね上がりました。

まとめ

ウェブサイトの表示速度改善は、一度の対策で完了するものではなく、継続的な取り組みが重要です。しかし、私たち京谷商会の経験から言えるのは、最も効果的なのはアーキテクチャレベルの判断だということです。

静的HTML + Cloudflare Workersという構成は、中小企業のウェブサイトにとって最適解の一つです。WordPressの運用負荷から解放され、PageSpeed全項目100点を維持しながら、18のポータルサイトを1つのWorkerで効率的に運用しています。

まずはPageSpeed Insightsで現状のスコアを確認し、最もインパクトの大きい画像最適化から始めましょう。APIの基本やGit/GitHubの使い方も合わせて学ぶことで、npm run deploy一発で本番反映できる効率的な開発フローが構築できます。