表示速度は自分で測って直せる｜Core Web Vitals改善の3手

「せっかく作ったのに、なんだかサイトが重い気がする」。そう感じているなら、それは気のせいではないかもしれません。表示が遅いページは、内容を読まれる前にそっと閉じられています。

この記事では、表示速度を「感覚」ではなく「数値」で測り、専門知識がなくても自分で直せる最初の3手を、順番にお伝えします。使うのは無料ツールだけです。どこから手をつければ効果が大きいのか、逆にどこはプロに任せた方がいいのかまで、現場目線で整理していきます。

Contents / 目次

1. 結論。表示速度は「3つの数値」を測って直す
2. やり方。測ってから直す具体的な手順
3. 効果。速くなると何が変わるのか
4. よくある失敗と、その回避法
5. 現場の本音。自分でやる範囲と、任せる範囲
6. よくある質問
7. まずは自社サイトの数値を、いっしょに見てみませんか

結論。表示速度は「3つの数値」を測って直す

結論から言います。表示速度の改善でまずやるべきことは、Core Web Vitalsという3つの数値を測り、点数の悪いものから順に直すことです。やみくもに「軽くしよう」とするのではなく、どこが遅いのかを数値で特定してから手を打ちます。

Core Web Vitals（コアウェブバイタル）とは、Googleが定めた「ページの使い心地」を測る3つの指標のことです。ひとことで言うと、表示の速さ・反応の良さ・画面の安定さを数値化したものです。この3つが基準内に収まっていれば、利用者はストレスなくページを見られていると判断できます。

まずは、その3つが何を測っているのかを一覧で見てみましょう。

指標	測っているもの	良好の目安
LCP（最大コンテンツの表示時間）	メイン画像や見出しが表示されるまでの速さ	2.5秒以内
INP（次の描画までの応答時間）	ボタンなどを押したときの反応の良さ	200ミリ秒以内
CLS（累積レイアウトシフト）	読み込み中に画面がガタッとズレない安定さ	0.1以下

補足すると、INPは、それまでのFID（初回入力遅延）に代わって、反応の良さを測る主要な指標として位置づけられています。ボタンを押してから画面が反応するまでのモタつきを測る数値です。「押したのに反応しない」と感じさせないための指標だと考えてください。各指標の正式な定義やしきい値は、Google公式のWeb Vitals（web.dev）にまとまっています。

この3つを踏まえると、最初にやるべき3手は次のように整理できます。順番にも意味があります。

• 1手目。画像を軽くする：LCPを改善する一番の近道。重い画像を軽い形式に変え、必要なサイズに縮める
• 2手目。レイアウトのズレを止める：CLSを改善する。画像や広告の場所を先に確保して、読み込み中に画面が動かないようにする
• 3手目。不要なスクリプトを減らす：INPを改善する。使っていないプラグインや外部タグを整理して、反応を軽くする

この3手は、多くのサイトで効果が大きく、かつ比較的手をつけやすい順番になっています。全部を一度にやろうとせず、上から1つずつ潰していくのが、遠回りに見えて一番の近道です。

やり方。測ってから直す具体的な手順

ここからは、実際に測って直すまでの手順を追っていきます。大事なのは「直す前に必ず測る」ことです。どこが遅いか分からないまま手を動かすと、効果の薄いところに時間をかけてしまうからです。

手順1。PageSpeed Insightsで現状を測る

まずは無料ツールのPageSpeed Insights（ページスピードインサイト）で現状を測ります。Googleが提供している無料の速度診断ツールで、URLを入れるだけで、先ほどの3つの数値と改善提案を出してくれます（2026年7月1日時点）。 使い方はPageSpeed Insightsとは？使い方と活用方法を徹底解説！でも詳しく解説しています。

測るときのポイントは1つだけです。結果画面の上の方に出る「実際のユーザーの環境で計測されたデータ（フィールドデータ）」を最優先で見ること。これは、実際にあなたのサイトを訪れた人たちの体感を集計した数字です。ここが基準内なら、利用者は快適に見られています。

その下に出る「診断（ラボデータ）」は、あくまでツールが仮想環境で1回測った参考値です。改善のヒントとしては役立ちますが、点数に一喜一憂する数字ではありません。この違いを最初に押さえておくと、後で説明する「よくある失敗」を避けられます。

あわせて、スマホ表示の数値を重点的に見てください。スマホから閲覧する人の割合は業種やサイトによって大きく異なりますが、多くのサイトで無視できない比重を占めるためです。

手順2。1手目、画像を軽くする（LCP対策）

画像はページの重さの大部分を占めます。だからLCP改善はここから始めるのが効率的です。やることは次の3つです。

• 形式を変える：JPEGやPNGを、WebPやAVIFといった軽い形式に変換する。見た目はほぼ変わらず容量だけ減る
• サイズを合わせる：表示は横800pxなのに元画像が4000pxのまま、という無駄をなくす。表示サイズに合わせて縮小する
• 読み込む順番を決める：最初に見えるメイン画像は優先的に、画面外の画像は後回し（遅延読み込み）にする

3つ目の「読み込む順番」は、HTMLの属性で指定できます。ツールの画面ボタンではなくコードで完結するので、そのまま使えます。

<!-- 最初に見えるメイン画像。優先して読み込ませ、幅と高さも指定する -->
<img src="hero.webp" width="1200" height="630" alt="トップの主役画像" fetchpriority="high">

<!-- 画面をスクロールしないと見えない画像は遅延読み込みにする -->
<!-- ［src と width・height は自社の画像に合わせて変更］ -->
<img src="below.webp" width="800" height="600" alt="下部の説明画像" loading="lazy">

手順3。2手目、レイアウトのズレを止める（CLS対策）

読み込み中に、押そうとしたボタンが急に下にズレて別のリンクを踏んでしまう。あの現象がCLSの正体です。防ぐ考え方はシンプルで、「表示される場所を先に確保しておく」ことです。具体策は次の2つです。

• 幅と高さを必ず指定する：すべての画像・動画・広告枠に「幅」と「高さ」を指定する。読み込み前からその分のスペースが空き、後からガクッとズレなくなる（先ほどの画像コードにも width と height を入れているのはこのため）
• Webフォントの表示を安定させる：サイト独自の書体を使っている場合、フォント読み込みの待ち時間に文字が消えたり入れ替わったりするのを、CSSの一行で抑える

/* Webフォントの読み込み中も、まず標準フォントで文字を即表示する。
   これで文字が消える瞬間やズレを抑えられる */
@font-face {
  font-family: "YourFont";
  src: url("/fonts/yourfont.woff2") format("woff2");
  font-display: swap; /* ［この一行を足すのがポイント］ */
}

手順4。3手目、不要なスクリプトを減らす（INP対策）

反応のモタつき（INP）の多くは、裏で動いているJavaScriptの重さが原因です。特に、アクセス解析タグ・チャットツール・SNS埋め込み・広告タグといった外部スクリプトが積み重なると、ボタンの反応が鈍くなります。

まずやるべきは棚卸しです。「本当に今も使っているか」を1つずつ確認し、使っていないプラグインやタグは思い切って外します。増やすより減らす方が、速度には確実に効きます。

手順5。AIに診断結果の読み解きを手伝ってもらう

PageSpeed Insightsの改善提案は、専門用語が多くて読みづらいのが正直なところです。そこで、結果をAIに貼り付けて「何から直すべきか」を整理してもらうと、判断がぐっと楽になります。出発点として、こんな短い指示（たたき台）から始めてみてください。

あなたはWeb表示速度の専門家です。
これからPageSpeed Insightsの診断結果を貼り付けます。
次の3点を、専門用語を使わずに教えてください。
1. 一番効果が大きい改善はどれか
2. 自分たちで直せるものと、制作会社に頼むべきものの区別
3. 直すときの具体的な手順

［ここに「改善できる項目」の文章をコピペ］

あとはAIと会話しながら、自社の状況に合わせて質問を足していけば十分です。ただしAIの回答は最終確認が必要です。実際に直す前に、提案が自社のサイト構成に合っているか、消していい要素かを人の目でチェックしてください。

効果。速くなると何が変わるのか

表示速度を直すと、まず「見られる前に閉じられる」損失が減ります。人は待たされると離れます。速さは、内容を読んでもらうための入場券のようなものだと考えてください。

成果はSEO（検索順位対策）の面でも見込めます。Core Web Vitalsは、Googleがページの使い心地を評価する要素の一つに位置づけています。 ここで補足すると、速くしたからといって順位が直接上がると約束できるものではありません。ただ、遅さが原因で評価を損ねている状態は解消できます。速度改善は「加点」というより、失点を防ぐ土台づくりと捉えるのが実態に近いです。

数値の見方として大事なのが「75パーセンタイル」という考え方です。Googleは、一番速い人でも一番遅い人でもなく、利用者の中で下から数えて75%目にあたる人の体感で合否を判断します（この判定方法はGoogle公式のWeb Vitalsで説明されています）。つまり、大半の利用者が快適かどうかが問われます。一部の高性能な端末で速いだけでは足りない、ということです。

速度改善は一度きりの作業で終わらせず、定期的に測り直して運用課題として回すのがおすすめです。ページを追加すれば重い画像がまた増えます。プラグインを入れれば裏で動くコードが増えます。だから「作って終わり」ではなく、定期的に測る仕組みを持つことが効いてきます。更新体制の作り方は更新されないサイトが招く信用低下と立て直す更新体制の作り方もあわせて参考にしてください。

技術面の後押しも進んでいます。世界規模のCDN（コンテンツ配信網）を提供するFastlyも、Core Web Vitals: How to Improve Your Website Speedという公式ブログで、利用者に近い場所からコンテンツを配信するCDNがLCPやINP、CLSの改善に役立つと説明しています。 自前のサーバーが遅いと感じるなら、こうした配信の仕組みも選択肢に入ります。

よくある失敗と、その回避法

速度改善は、進め方を間違えると時間だけ溶けていきます。現場でよく見かける失敗を3つ挙げて、それぞれの防ぎ方をお伝えします。

失敗1。スコア100点を目的にしてしまう

PageSpeed Insightsの点数を100点に近づけること自体がゴールになってしまうケースです。こうなると、体感にほとんど影響しない細かな指摘まで直そうとして、労力の割に成果が出ません。あるあるなのが、100点を狙って必要な機能まで削り、かえって使いにくいサイトになってしまうパターンです。

防ぐには、目的を「点数」ではなく「利用者がストレスなく目的を達成できること」に置き直します。フィールドデータの3指標が良好の範囲に入っていれば、そこから先の1点2点は追わなくて構いません。

失敗2。ラボデータだけを見て満足する

ツールがその場で1回測ったラボデータの改善だけに集中し、実際の利用者データ（フィールドデータ）が変わっていない、という失敗です。手元では速くなったのに、Search Consoleの評価が改善しない、という食い違いが起きます。

これが起きるのは、開発者の高速な回線・端末で測っているからです。回避するには、判断の軸を必ずフィールドデータに置くこと。Google Search Consoleのウェブに関する主な指標レポート（Google公式ヘルプ）を使えば、実際の利用者データでどのページ群が「不良」なのかをまとめて確認できます。 使い方は検索流入を増やすならここから！Googleサーチコンソール徹底活用術で解説しています。

失敗3。根本原因を特定せず、場当たりで対策する

「遅いらしいから、とりあえず高速化プラグインを入れる」「キャッシュ設定をいじる」と、原因を突き止めないまま手を打つ失敗です。運が悪いと、プラグイン同士がぶつかって表示が崩れたり、別のところが遅くなったりします。

防ぐ順番は決まっています。次の4ステップを、上から1つずつ回してください。

1. まず測る
2. 一番点数の悪い指標を特定する
3. その指標の原因（画像・レイアウト・スクリプトのどれか）に絞って直す
4. 直したらまた測る

この「測る→直す→測る」を1手ずつ回すことが肝心です。複数の対策を同時にやると、どれが効いたのか分からなくなるので、一度に一つが鉄則です。

高速化系のプラグインは、設定を強くしすぎるとデザインや動的な機能が壊れることがあります。導入したら、必ずスマホとパソコンの両方で表示崩れがないか確認してから公開してください。

現場の本音。自分でやる範囲と、任せる範囲

ここまで「自分で直せる」とお伝えしてきましたが、率直に言うと、全部を自力でやり切れるとは限りません。どこまで自分でやり、どこからプロに任せるか。その線引きを、現場で見えてきた本音でお話しします。

まず、自分でやって効果が出やすいのは「画像の軽量化」と「使っていないプラグイン・タグの整理」です。この2つはリスクが低く、成果も体感しやすい。逆に、サーバーの応答速度・JavaScriptの分割・テーマの構造そのものに手を入れる領域は、無理に自分でやらない方が安全です。一歩間違えるとサイト全体が表示されなくなるからです。

見落としがちなコストの話もしておきます。速度改善は、着手そのものより「原因の切り分け」に時間を取られます。プラグインを一つ止めては測り、を繰り返すと、半日は平気で溶けます。

人件費に換算すると、外注した方が結果的に安く早い、というケースは珍しくありません。ここは「自分の時間をいくらと見るか」で判断が変わります。

もう一つ、正直に伝えておきたいのがフィールドデータのタイムラグです。フィールドデータは、実際の利用者の環境を集計したGoogleのChrome UX Report（CrUX）を基にしており、直近28日間のデータを集計する仕組みです。そのため、直してもすぐには数値が動きません。

「昨日直したのに変わらない」と焦って余計な改修を重ねる人がいますが、それは早すぎるだけです。改修後の効果判定は、少し待ってから見る前提で計画を立ててください。

制作会社に頼むときの注意点も一つ。「速くします」とだけ言う相手には、必ず「どの指標を、どの数値まで、フィールドデータで改善するのか」を聞いてください。ラボデータの点数だけを見せて「速くなりました」と報告する会社もあります。判断の軸が実際の利用者データにあるかどうかが、信頼できるパートナーの見分け方です。AIで内製化を進める場合の限界と任せ所についてはVibe codingのサイトが3か月後に詰む前の更新設計も参考になります。

よくある質問

まずは自社サイトの数値を、いっしょに見てみませんか

ここまで読んで、測り方は分かったけれど「原因の切り分けや、テーマ側の改修まで自分でやり切るのは不安」と感じた方も多いと思います。そんなときは、コレットラボのAIで作るサイト制作・運用改善の伴走支援にご相談ください。無理な売り込みはしません。まずは現状の数値を一緒に見て、どこから直すと効果が大きいかを整理するだけでも大丈夫です。AI業務システム化の詳細はこちらからお気軽にお問い合わせください。