パフォーマンス9分で読めます

コーポレートサイトの表示速度を改善する実務手順 — Core Web Vitalsの直し方

LCP・CLS・INPの3指標を軸に、コーポレートサイトの表示速度を実際に改善するための計測・原因特定・修正の手順を、現場の優先順位とあわせて解説します。

#パフォーマンス#Core Web Vitals#LCP#画像最適化#フロントエンド

「サイトが重い」という相談は、コーポレートサイトの改修依頼で最も多いものの一つです。ただ、体感の遅さを感覚のまま直そうとすると、効果の薄い箇所に時間を使ってしまいがちです。Googleが定義するCore Web Vitalsを共通のものさしにすれば、どこを直せば体感とSEOの両方に効くかを、根拠を持って判断できます。この記事では計測から修正までの実務手順を、優先順位とあわせて整理します。

まず3つの指標の意味を正しく押さえる

Core Web Vitalsは表示速度を3つの観点で数値化したものです。それぞれが「ユーザーが感じる別々のストレス」に対応しているため、ひとくくりに『速くする』のではなく、どの体験を直すのかを意識して取り組みます。

  • LCP(Largest Contentful Paint): 最も大きな要素が表示されるまでの時間。2.5秒以内が良好の目安。ファーストビューの主要画像や見出しが対象になりやすい。
  • CLS(Cumulative Layout Shift): 表示中にレイアウトがガタつく量。0.1以下が目安。画像のサイズ未指定や後から差し込まれる広告・バナーが主因。
  • INP(Interaction to Next Paint): クリックや入力への反応の速さ。200ミリ秒以内が目安。重いJavaScriptがメインスレッドを占有すると悪化する。

FIDではなくINP

2024年3月にCore Web Vitalsの応答性指標はFIDからINPへ置き換わりました。古い記事のままFID対策をしても評価されません。現在はINPを前提に施策を組みます。

計測は『ラボ』と『フィールド』を分けて見る

計測ツールには大きく2種類あります。手元で再現実験するラボデータと、実際の訪問者の体験を集めたフィールドデータです。改善の判断材料としては、最終的にフィールドデータが正解になります。

  • Lighthouse / PageSpeed Insights: 1回の読み込みを分析するラボ計測。原因の切り分けと修正中の確認に向く。
  • Chrome UX Report(CrUX) / Search Consoleのウェブに関する主な指標: 実ユーザーの28日間の分布を見るフィールド計測。施策が本当に効いたかの最終判断に使う。
  • Chrome DevToolsのPerformanceパネル: INPやロングタスクの原因を、実行されたスクリプト単位まで掘り下げる。

順番としては、PageSpeed Insightsで全体像と改善余地の大きい項目を把握し、DevToolsで原因のコードを特定し、修正後はSearch Consoleで実ユーザーの数値が改善するかを数週間かけて確認する、という流れが堅実です。

効果が大きい順に直す

1. 画像 — 多くのサイトで最大のボトルネック

コーポレートサイトで最初に効くのはほぼ画像です。撮影したままの数MBのJPEGがファーストビューに置かれているだけで、LCPは簡単に4秒を超えます。WebP/AVIFへの変換、適切な幅へのリサイズ、width/height属性の明示(CLS対策)、ファーストビュー外の遅延読み込みを徹底するだけで、体感は大きく変わります。

  • 次世代フォーマット(WebP・AVIF)に変換し、容量を半分以下に。
  • 表示サイズの2倍を超える巨大画像を配信しない。レスポンシブにsrcsetで出し分ける。
  • imgにwidth・heightまたはaspect-ratioを必ず指定し、読み込み中の場所取りでガタつきを防ぐ。
  • ファーストビューの主役画像はpriority読み込み、それ以外はloading=lazyで後回しにする。

2. JavaScript — INPと総読み込み時間に直結

アニメーションや計測タグを足し続けた結果、初期表示に不要なスクリプトまで先頭で読み込んでいるサイトは多いものです。使っていないライブラリの削除、サードパーティタグの遅延読み込み、コード分割によって、メインスレッドの占有時間を減らせばINPが改善します。タグマネージャ経由のタグも、本当に全ページで即時に必要かを見直す価値があります。

3. フォントとサーバー応答

Webフォントはfont-display: swapで本文の表示をブロックしないようにし、必要な字種のみ読み込みます。サーバー側ではキャッシュ(CDN・ブラウザキャッシュ)の設定、gzip/Brotli圧縮、TTFB(最初のバイトが返るまでの時間)の短縮が効きます。動的生成のページが多いサイトでは、静的化やキャッシュ層の追加でTTFBが大きく下がることがあります。

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

表示速度は、新しいバナーやタグを足すたびに少しずつ劣化します。一度直して終わりにせず、リリース前にLighthouseで確認する、四半期ごとにSearch Consoleの指標を見る、といった運用に組み込むことが、長期的にはもっとも効果的です。プランタンでは計測から原因特定、修正、運用への組み込みまでを一貫してご支援しています。

公開: 2026年6月9日 / 執筆: プランタン

Contact

この記事のテーマについて相談する

「自社の場合はどう進めればいいか」という具体的なご相談も歓迎です。Webサイト制作・システム開発・保守運用まで、手を動かす技術者が直接お話を伺います。