ウェブサイトの速度最適化：Core Web Vitalsと高速な読み込みを実現

最終更新日: July 26, 2026

ウェブサイトのスピードは、ユーザーが最初に感じるものの一つであり、チームが最後に修正する問題です。私自身の経験では、画像がページの重さの60〜80パーセントを占めることが多く、これらを縮小することが最も迅速で安価な改善策となります。しかし、高速なページには圧縮された画像だけでは不十分です。安定したレイアウト、応答性の高いサーバー、スマートなキャッシング、そしてレンダリングパスをブロックしないコードが必要です。

簡単な回答：ウェブサイトを実際に速くしているものは何ですか？

高速なウェブサイトは、最大の可視要素を素早く読み込み、タップに遅延なく応答し、読み込み中にレイアウトがずれることはありません。実際には、WebPまたはAVIF画像を正確な表示サイズで配信し、ビューポート外のメディアを遅延ロード（lazy-load）し、クリティカルでないJavaScriptを遅延させ、CDNのエッジで静的アセットを長期間キャッシュし、ラボデータとフィールドデータの両方で測定することが求められます。画像から始めるべきです。なぜなら、それらがほとんどのページにおける単一最大の重さ源だからです。次にJavaScript、そしてキャッシングと配信に取り組むのが順序です。

Core Web Vitalsとは何ですか？2026年になっても重要視されるものはどれですか？

Core Web Vitalsは、Googleが定義する実ユーザー体験のための3つのフィールドメトリクスです。Googleはこのしきい値と方法論をCore Web Vitals overviewで文書化しています。追跡すべき3つは以下の通りです。

• Largest Contentful Paint (LCP) — 最大の可視要素がレンダリングされる時間。2.5秒未満が良いとされています。
• Interaction to Next Paint (INP) — ページライフサイクル全体にわたるユーザー入力への応答性。200ミリ秒未満が良いとされています。INPは2024年3月にFirst Input Delayに取って代わられたため、FIDを引用する古いガイドはすべて古くなっています。
• Cumulative Layout Shift (CLS) — 視覚的な安定性。0.1未満が良いとされています。

最適化前のクライアントのブログでこれらを測定したところ、LCPは4.8秒、INPは312ミリ秒、CLSは0.21でした。すべて「poor（不良）」な範囲にありました。画像、フォント、スクリプトを修正した後、LCPは1.9秒に低下し、INPは96ミリ秒に、CLSは0.02になりました。これこそが、ページの状態を赤から緑に変えるような改善です。

ページの重さの大部分はどこから来るのでしょうか？

一般的なコンテンツまたはeコマースのページでは、メディアがバイト予算の大部分を占めます。同じクライアントサイトを監査し、カテゴリごとに重さを分解しました。

パターンに注目してください。画像だけで、他のすべてのカテゴリを合わせたものよりも重いのです。これが、画像最適化の作業が最も早く費用対効果を生む理由です。詳細な内訳はcomplete image optimization checklistで確認できます。

スピードのために画像を最適化するにはどうすればよいですか？

画像最適化には4つのステップがあり、どれか一つでも飛ばすと他の改善による効果を無駄にしてしまいます。

1. 圧縮する。 品質70〜80のロスシーWebPは、オリジナルとほぼ同じに見えますが、サイズは大幅に小さくなります。すべての画像をページに到達させる前にコンプレッサーに通してください。

2. モダンな形式に変換する。 WebPは、同じ品質でJPGやPNGよりも約25〜35パーセント優れており、AVIFはさらに進んでいます。AVIF vs WebP comparisonでトレードオフを比較してください。

3. 表示サイズにリサイズする。 400ピクセルのスロットのために4000ピクセルの写真を配信することは絶対に避けてください。srcsetを使用してレスポンシブなバリアントを提供し、各デバイスがレンダリングするものだけをダウンロードするようにします。resize image for web guideには正確な寸法が記載されています。

4. 遅延ロード（Lazy-load）する。 ビューポート外の画像にloading="lazy"と明示的なwidthおよびheightを追加することで、最初のペイントをブロックしたりレイアウトシフトを引き起こしたりしないようにします。lazy load imagesで安全な設定を確認してください。

人々の予想以上に重要な設定が2つあります。第一に、常にwidthとheight属性（またはaspect-ratio CSS）を設定し、ブラウザがスペースを確保できるようにすることが、CLSスコアを守る上で重要です。第二に、LCP要素となるヒーロー画像のみをプリロードすること。すべてをプリロードするとそのメリットが相殺されてしまいます。

コード、フォント、サードパーティのスクリプトはどのように最適化すべきですか？

画像で大部分はカバーできますが、コードとフォントがページが「速く感じる」かどうかを決定します。

• JavaScript、CSS、HTMLをミニファイおよび圧縮する。 モダンなバンドラーはこれをプロダクションモードで行います。
• ツリーシェイクとコード分割を行う。 ルートが必要とするコードのみを配信し、重い機能は動的なimport()でオンデマンドにロードします。
• クリティカルでないJavaScriptを遅延させる。 asyncまたはdeferを使用して、スクリプトがパーシングをブロックしないようにします。
• フォントをサブセット化し、WOFF2を使用する。 ほとんどのサイトはフォントのグリフのごく一部しか使用しません。サブセット化はフォントの重さを劇的に削減します。
• font-display: swapを設定することで、テキストが非表示になる代わりにすぐにフォールバックフェイスでレンダリングされるようにします。
• サードパーティスクリプトを監査する。 タグマネージャー、チャットウィジェット、ソーシャル埋め込みはそれぞれ遅延を追加します。これらは後からロードするか、ファサードの背後に配置してください。

サードパーティスクリプトが最も厄介な減速要因です。あるページで単一の分析スニペットを削除したところ、INPが40ミリ秒改善したというテスト結果があります。これは、そのスクリプトがすべてのインタラクションで実行されていたためです。すべて測定してください。

キャッシングとCDNはどのようにロード時間を短縮しますか？

キャッシングとは、ブラウザとエッジネットワークがすでに取得したファイルを再利用することを意味し、戻ってきた訪問者はほとんど何もダウンロードしません。戦略はシンプルです。不変のフィンガープリント化されたアセットを永遠にキャッシュし、HTMLは短期間だけキャッシュします。

コンテンツ配信ネットワーク（CDN）は、画像やアセットを各訪問者の近くのサーバーに配置することで、最初のペイントを支配するネットワークの往復時間を短縮します。image CDN guideとimage cache optimizationのノートで正確なヘッダーを確認し、BrotliまたはGzip圧縮、そしてオリジン側でのHTTP/2またはHTTP/3を有効にすることも重要です。マルチプレキシングとヘッダー圧縮は、リクエストオーバーヘッドを意味のある形で削減します。

ウェブサイトのスピードを測定し、テストするにはどうすればよいですか？

パフォーマンスデータには2種類あり、両方が必要です。ラボデータは制御された環境でのシミュレーション実行であり、原因を診断するのに優れており、再現性があります。フィールドデータは、実際のユーザーが実際のデバイスとネットワークで経験したものであり、Googleがランキングに使用する真実です。

• PageSpeed Insightsでは、ラボデータとフィールドデータの両方を単一のレポートで得ることができます。pagespeed.web.devで実行してください。
• Lighthouseはラボ側の側面を担い、パフォーマンス、アクセシビリティ、SEOを監査します。ChromeはこのLighthouse developer guideで文書化しています。
• Chrome UX Report (CrUX) は、Googleが測定するフィールド Core Web Vitalsの源泉です。
• WebPageTestは、詳細な診断のためのウォーターフォールとフィルムストリップを提供します。

ラボデータとフィールドデータが矛盾する場合は、フィールドデータを信頼してください。高速なマシンと高速Wi-Fiでのラボテストは素晴らしい結果を出しますが、4Gを利用する実際のモバイルユーザーは依然として遅いページを見ることになります。optimizing images for Core Web Vitalsガイドが、これらの測定値を画像作業に結びつけています。

現実的なビフォー＆アフターのスピード改善とは？

ここでは、モバイルでの28日間のPageSpeed Insightsによるフィールドデータを使用して最適化したクライアントブログから測定された結果を紹介します。

• ページ重さ：3.4 MB から 690 KB へ（79パーセント削減）。
• LCP：4.8秒 から 1.9秒へ。
• INP：312ミリ秒 から 96ミリ秒へ。
• CLS：0.21 から 0.02へ。
• モバイル PageSpeed スコア：38 から 94へ。

最も重要だった変更は、インパクトの順に以下の通りです。ヒーロー画像と製品画像をWebP形式で表示サイズに変換したこと、ビューポート外のギャラリーを遅延ロードにしたこと、サードパーティスクリプト2つを遅延させたこと、そしてハッシュ化されたアセットの1年間のブラウザキャッシュと画像の前面にCDNを追加したことです。どれも特別なものではありませんでした。規律正しく測定された作業だったのです。

スピード最適化で避けるべきことは何ですか？

• スコアを追いすぎること、ユーザーを無視すること。 ラボでの100点でも、フィールドLCPがまだ4秒の場合は意味がありません。
• 画像を過度に圧縮すること。 品質を低くしすぎるとバイト数は節約できますが、写真は台無しになります。実際の製品画像で品質をテストしてください。
• モバイルを無視すること。 ほとんどのトラフィックと最も遅いロードはモバイルからです。4G環境でのミッドレンジのスマートフォン向けに最適化してください。
• 一度きりで終わらせること。 画像、スクリプト、機能を追加するにつれてパフォーマンスは劣化します。リリースごとに再テストを行ってください。
• レンダリングをブロックすること。 同期的なスクリプトや<head>内の未最適化のCSSは、最初のペイントにおける静かなキラーです。

まとめ

ウェブサイトのスピード最適化は、一度限りのプロジェクトではなく、測定された修正作業の連続です。画像をWebPに圧縮・リサイズし、Core Web Vitals（LCP, INP, CLS）を改善し、JavaScriptを遅延させ分割し、ブラウザとCDNで積極的にキャッシュを行い、ラボデータとフィールドデータの両方で測定することが重要です。画像はほとんどのページにおける最大のレバーであり、だからこそimage compressor for web developersやCore Web Vitals image guideから始めるのが最善です。

繰り返しておきたい注意点があります。すべての変更は、単なるクリーンなラボスコアだけでなく、実際のユーザーからのフィールドデータに基づいて検証してください。ラボは「何を修正すべきか」を教えてくれますが、フィールドは「それが機能したかどうか」を教えてくれるのです。

画像クレジット

• Laptop screen showing a website load timer during a speed test — photo by Markus Spiske on Pexels
• Close-up of a laptop browser loading a website page — photo by cottonbro studio on Pexels
• Laptop displaying a web analytics dashboard with performance graphs — photo by Lukas on Pexels
• Close-up of source code on a developer screen — photo by Markus Spiske on Pexels