BtoB向けの産業機器メーカーのサイト改善に携わったときの話です。

「ページの読み込みが遅いのは知っているのですが、何から手をつければいいかわからなくて」

先方のマーケティング担当の方がそう言いながら見せてくれたのが、Google PageSpeed Insightsのスコアでした。モバイルで28点、デスクトップでも51点。真っ赤な画面が広がっていました。

聞くと、2年前にリニューアルした際に見た目重視でフルスクリーンの画像を各ページに配置し、スライダー用のjQueryプラグインを3つ、フォームにもう1つ、アクセス解析タグが5種類。WordPressのプラグインは37個。結果、トップページの読み込みに8秒以上かかっていました。

問題は速度だけではありません。GAのデータを見ると、モバイルからの直帰率がデスクトップの1.7倍。問い合わせフォームの到達率はモバイルで2.1%、デスクトップで5.8%。モバイルユーザーがページを見る前に離脱していました。

このケースでは、3ヶ月の改善を経てモバイルスコアは28点から74点に、モバイルのフォーム到達率は2.1%から4.6%に上がりました。売上への直接的なインパクトがある話です。

この記事では、サイト表示速度の改善を「何から始めて、どう優先順位をつけるか」という実務寄りの視点で書いていきます。技術者でなくても判断できるように、背景の考え方を含めて説明します。

そもそもCore Web Vitalsとは何か

表示速度の改善を語るうえで避けられないのが、GoogleのCore Web Vitalsです。2021年にランキング要因に組み込まれてからもう5年が経ちますが、いまだに「聞いたことはあるけれど中身はよく知らない」という方が少なくありません。

Core Web Vitalsは3つの指標で構成されています。

LCP（Largest Contentful Paint）はページの「見た目の速さ」

ページ内でもっとも大きなコンテンツ要素（多くの場合メインビジュアルやヒーロー画像）が表示されるまでの時間です。

  • 良好：2.5秒以内
  • 改善が必要：2.5〜4.0秒
  • 不良：4.0秒超

ユーザーが「このページ、表示されたな」と感じるタイミングに近い指標です。実務的には、LCPがもっとも改善の恩恵が大きい指標になります。ファーストビューの体感速度はLCPでほぼ決まるからです。

INP（Interaction to Next Paint）は操作への「反応速度」

2024年3月にFID（First Input Delay）から正式に置き換わった指標です。ユーザーがボタンをクリックしたり、メニューを開いたりしたときに、画面が反応するまでの時間を測ります。

  • 良好：200ミリ秒以内
  • 改善が必要：200〜500ミリ秒
  • 不良：500ミリ秒超

FIDが「最初のインタラクション」だけを測っていたのに対し、INPはページ全体を通じたインタラクションの応答性を評価します。JavaScriptの処理が重いサイトでは、この数値が一気に悪化します。

CLS（Cumulative Layout Shift）はレイアウトの「ガタつき」

ページの読み込み中にレイアウトがずれる現象を数値化したものです。広告バナーが遅れて読み込まれて本文が押し下げられる、Webフォントが適用されて文字がガクッと動く、といった現象を指します。

  • 良好：0.1以下
  • 改善が必要：0.1〜0.25
  • 不良：0.25超

CLSが高いサイトで実際に起きたトラブルとして、フォーム入力中に上部のバナーが読み込まれてボタンの位置がずれ、ユーザーが「キャンセル」を押してしまうケースがありました。地味ですが実害があります。

この3指標の詳細な定義と測定方法は、Google公式のWeb Vitalsドキュメントに記載されています。

PageSpeed Insightsの読み方と改善優先順位の付け方

速度改善の話をするときは、まずPageSpeed Insightsを回してみることをおすすめしています。無料で使えて、問題の診断と改善の方向性まで教えてくれるツールだからです。

ただ、出てきた結果をどう読むかで、改善のスピードが大きく変わります。

スコアの数字より「診断セクション」を見る

PageSpeed Insightsのスコア（0〜100）は目安にはなりますが、100点を目指す必要はありません。実務上は、モバイルで60点以上・デスクトップで80点以上あれば、ユーザー体験上のクリティカルな問題はほぼ解消されています。

重要なのは、スコアの下にある「診断（Diagnostics）」と「改善できる項目（Opportunities）」のセクションです。ここに具体的な改善ポイントが、推定の時間削減効果とともに一覧表示されます。

改善の優先順位はこう付ける

よくある間違いは、上から順番に全部やろうとすることです。限られたリソースで最大の効果を出すには、優先順位が欠かせません。

クライアントの改善案件で使っている判断基準はこの3つです。

判断基準内容
推定削減時間PageSpeed Insightsが表示する「推定節約時間」が大きいものを優先
実装の難易度プラグインの設定変更だけで済むものから着手
ビジネスインパクトファーストビューに影響する改善（LCP関連）を最優先

たとえば「次世代フォーマットでの画像の配信」が推定3.2秒の削減、「使用していないJavaScriptの削除」が推定1.8秒の削減と出ていたら、画像の最適化から手をつけます。同時に「レンダリングを妨げるリソースの除外」が0.4秒で、CSSファイルの読み込み順序を変えるだけなら、工数の少なさから並行して対応します。

全部を一度にやる必要はありません。「LCPに効く施策」「INPに効く施策」「CLSに効く施策」の3カテゴリで分けて、まずLCPから片付けるのが実務上もっとも効率的です。

画像最適化はもっとも効果が大きい改善領域

サイト表示速度の改善において、ROIが一番高いのが画像の最適化です。HTTP Archiveの調査によると、Webページの転送データ量の約半分を画像が占めています。つまり、画像を軽くするだけでページ全体の重さが半分近く改善できる可能性があるということです。

WebPとAVIFへの変換

いまだにJPEGやPNGのまま画像を配信しているサイトは、それだけで損をしています。

フォーマットJPEG比の削減率目安ブラウザ対応率
WebP25〜35%軽量97%以上（2026年時点）
AVIF40〜50%軽量93%以上（2026年時点）

WebPはもう事実上の標準で、対応していないブラウザのほうが珍しい状況です。AVIFはさらに圧縮率が高いですが、エンコードに時間がかかるのと、対応ブラウザがWebPよりわずかに少ない。実務的には、WebPをベースにして、AVIFはCDN側で自動変換する運用がバランスが良いです。

HTMLの<picture>要素を使えば、ブラウザの対応状況に応じて出し分けができます。

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="メインビジュアル" width="1200" height="630">
</picture>

遅延読み込み（Lazy Loading）

ファーストビュー以外の画像は、画面に近づいたときに読み込めば十分です。ブラウザネイティブの遅延読み込みはloading="lazy"属性を付けるだけで実装できます。

<img src="/images/section2.webp" alt="サービス紹介" loading="lazy" width="800" height="450">

注意点がひとつあります。ファーストビューのメインビジュアル（LCPに該当する画像）にはloading="lazy"を付けないでください。LCPの画像を遅延読み込みすると、肝心のファーストビューの表示が逆に遅くなります。LCP画像にはloading="eager"（デフォルト）のまま、かつfetchpriority="high"を指定するのが望ましいです。

<img src="/images/hero.webp" alt="メインビジュアル" fetchpriority="high" width="1200" height="630">

CDNの活用

画像をCDN（Content Delivery Network）経由で配信すると、ユーザーに近いサーバーからの配信でダウンロード時間が短縮されます。中小企業のコーポレートサイトであればCloudflareの無料プランで十分で、WebP自動変換機能もあります。

冒頭の産業機器メーカーの案件では、画像最適化だけでLCPが4.8秒から2.1秒に改善しました。2,400px幅のPNG画像（1枚3〜5MB）をWebPに変換してリサイズしただけで、トップページの転送量が12MBから3.2MBに減っています。

JavaScript/CSSの最適化で見えない重さを削る

画像の次にインパクトが大きいのが、JavaScriptとCSSの最適化です。ここはユーザーの目には直接見えない重さですが、表示速度とINPに大きく影響します。

レンダリングブロックの理解

ブラウザがHTMLを解析してページを表示する過程で、CSSファイルやJavaScriptファイルの読み込みが「壁」になることがあります。これをレンダリングブロックと呼びます。

簡単に言うと、ブラウザが「このCSSを全部読み込まないと画面を描画できない」「このJavaScriptを実行し終わるまで次に進めない」という状態です。

対策は主に3つあります。

1つ目はCSSのインライン化（Critical CSS）です。ファーストビューの描画に必要なCSSだけを<head>内に直接書き、残りは非同期で読み込みます。

<head>
  <style>
    /* ファーストビューに必要な最小限のCSS */
    body { margin: 0; font-family: sans-serif; }
    .hero { width: 100%; height: 60vh; }
  </style>
  <link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

2つ目はJavaScriptのdeferとasyncです。<script>タグにそのまま外部ファイルを指定すると、HTMLの解析が止まります。deferを付ければHTMLの解析完了後に実行され、asyncを付ければダウンロードと並行して解析が進みます。

<!-- 推奨：deferでHTMLの解析を止めない -->
<script src="/js/main.js" defer></script>

<!-- アクセス解析など、他のスクリプトに依存しないもの -->
<script src="/js/analytics.js" async></script>

3つ目は不要なJavaScriptの削除です。ここが一番効きます。PageSpeed Insightsの「使用していないJavaScript」の項目を確認し、本当に必要かどうかを1つずつ精査します。

冒頭の産業機器メーカーの案件では、以下のように整理しました。

項目対応削減効果
jQuery（3つのスライダープラグイン用）プラグインをCSS+バニラJSのスライダーに置き換え、jQuery自体を削除約87KB削減
未使用のソーシャルシェアボタンJSSNSシェア機能は使っていなかったため削除約42KB削減
古いポリフィル（ES5互換用）IE対応不要のためすべて削除約35KB削減

合計で約164KBのJavaScriptを削減しました。これだけでモバイルのINPが380msから170msに改善しています。

CSSの最適化

CSSも同じ考え方です。Chrome DevToolsの「Coverage」タブで未使用CSSの割合を確認し、PurgeCSSなどのツールで自動削除します。リニューアルを繰り返したサイトではCSSの未使用率が70%を超えていることもあり、削除だけでファイルサイズが4分の1になったケースもあります。

WordPress特有の速度改善施策

日本のBtoB企業のコーポレートサイトではWordPressのシェアが圧倒的に高い。W3Techsのデータでは、CMSを使っているサイトのうち約62%がWordPressです。そこで、WordPressに特化した改善施策も書いておきます。

プラグインの断捨離

WordPressサイトが遅くなる最大の原因は、たいていプラグインの入れすぎです。

クライアントのサイトを診るとき、まず最初にやるのがプラグイン一覧の棚卸しです。有効化されているが実際には使っていないプラグインが5〜10個見つかることは珍しくありません。使っていないプラグインを無効化・削除し、同じ機能の重複がないか確認し（SEOプラグインが2つ入っているケースなど）、Query Monitorで各プラグインの処理時間を可視化して原因を特定する。この3ステップで十分です。

キャッシュプラグインの導入

WordPressは動的にページを生成するCMSなので、アクセスのたびにPHPの処理とデータベースへの問い合わせが走ります。キャッシュプラグインを入れると、一度生成したHTMLを保存しておき、次回以降はそれを返すだけになります。サーバーの処理時間が大きく短縮されます。

代表的なキャッシュプラグインの比較です。

プラグイン特徴費用
WP Super Cacheシンプルで設定が簡単。Automattic公式。初心者向け無料
W3 Total Cache細かい設定が可能。CDN連携に強い無料（Pro版あり）
WP Rocket設定がほぼ不要で効果が高い。CSS/JSの最適化機能も内蔵有料（年$59〜）

BtoBのコーポレートサイトで設定にあまり時間をかけたくない場合は、WP Rocketが一番手離れが良いです。有効化するだけで遅延読み込み、CSS/JSの圧縮、キャッシュ生成まで自動でやってくれます。

テーマ設定と画像の自動最適化

SWELLやLightningなど国産テーマを使っている場合でも、使っていないテーマ機能が裏で動いていることがあります。たとえばSWELLのGoogleフォント読み込み機能を「読み込まない」に設定するだけでWebフォント分だけ軽くなります。

画像については、EWWW Image Optimizerで、アップロード時の自動WebP変換と圧縮が可能です。過去画像の一括変換もできるので、既存サイトの改善にも有効です。

表示速度がCVR・SEOに与える影響を数字で見る

「速くしたほうがいいのはわかるけれど、どれくらいビジネスに効くのか」という質問をよく受けます。ここは数字で答えます。

CVR（コンバージョン率）への影響

Googleが公開した調査データによると、モバイルページの読み込み時間が1秒から3秒に増えると直帰率が32%上昇し、1秒から5秒では直帰率が90%上昇します。

Deloitteが小売業のサイトで実施した調査では、ページの読み込み速度が0.1秒改善するだけで、コンバージョン率が8.4%向上し、平均注文額が9.2%増加したという結果が出ています。

BtoBの文脈でも、表示速度とフォーム完了率の相関は明確です。冒頭の産業機器メーカーの事例では、モバイルのPageSpeedスコアを28点から74点に改善した結果、フォーム到達率が2.1%から4.6%に向上しました。到達率が2倍以上になったわけです。

SEOへの影響

GoogleはCore Web Vitalsをランキング要因として使っていることを公式に明言しています。

ただし、表示速度だけで順位が大きく変わるわけではありません。コンテンツの質や被リンクなど、他のランキング要因のほうがウエイトは大きい。Googleのジョン・ミューラー氏も「Core Web Vitalsはタイブレーカー的な役割」という趣旨の発言をしています。

とはいえ、同じくらいの品質のコンテンツが競合しているとき、表示速度の差が順位の差になります。特にBtoBのニッチなキーワードでは競合コンテンツの質が拮抗しやすいので、表示速度が最後のひと押しになるケースは少なくありません。

加えて、2023年以降Googleはすべてのサイトをモバイルファーストインデックスで評価しています。デスクトップで90点でもモバイルで30点なら、SEO上はモバイルの30点で評価されている。改善の優先度はモバイルが先です。

実務での改善ステップ

最後に、実際の改善手順をまとめます。クライアント案件で使っている進め方です。

ステップ内容目安期間
1. 現状計測PageSpeed Insights（モバイル/デスクトップ）、Search Consoleの「ウェブに関する主な指標」、GAの直帰率・CVR差分を確認1日
2. 優先順位付け改善項目を推定削減時間順に並べ、実装難易度を3段階で評価。「効果大×実装簡単」から着手1〜2日
3. 画像最適化WebP変換、リサイズ、遅延読み込み、CDN導入。効果が大きくリスクが低いので最初にやる1〜2週間
4. JS/CSS整理不要スクリプト削除、defer/async設定、Critical CSSインライン化、未使用CSS削除2〜3週間
5. インフラ最適化キャッシュ設定、CDN調整、TTFB確認とサーバープラン見直し1週間
6. CLS対策画像にwidth/height明示、font-display: swap設定、サードパーティウィジェットのシフト対策1週間
7. 効果測定PageSpeed再計測、GAで2〜4週間モニタリング、Search ConsoleでCore Web Vitals反映を確認継続

全体で1〜2ヶ月が目安です。サイト規模や問題の深さによって前後しますが、画像最適化だけでも先にやる価値はあります。

改善は一度で終わりではない

表示速度の改善は、一度やったら完了というものではありません。

コンテンツの追加、プラグインのアップデート、新しいマーケティングタグの導入。サイトは生き物なので、放っておくとまた遅くなります。四半期に一度はPageSpeed Insightsを回して、スコアが落ちていないか確認する習慣をつけることをおすすめします。

とはいえ、社内にWeb担当者がいない企業にとっては、ここに書いた内容を全部自前で対応するのは現実的ではないかもしれません。「診断はできたけれど実装はどうすれば」「どこまでプラグインで対応できて、どこからテーマの修正が必要なのか判断できない」という声は日常的にいただきます。

株式会社ティーラでは、PageSpeed Insightsの診断から改善施策の優先順位付け、実装、効果測定までを一貫して対応しています。「まずは自社サイトの速度診断だけでも」という段階からご相談いただくケースも多いです。

サイトの表示速度を改善したい方は、お気軽にお問い合わせください。

参考文献