サイト表示速度を劇的改善｜Core Web Vitals最適化の実践手順
※この記事はオンラインサロンの内容を元に作成しています。
美しいデザインのサイトを作ったのに、表示が重くてユーザーが離脱する。そんな残念な状況は珍しくない。Core Web Vitalsは、ページ速度を数値化し、検索順位に直接影響を与える指標だ。「写真いっぱい使ったりすると、リッチなページでお客さん、ユーザー満足するんですけど、Googleの評価は低いねみたいなことが起こりうる」と伊藤が指摘するように、見た目と速度の両立は難しい。しかし画像最適化、JavaScript最適化、キャッシュ活用という3つの施策で、サイトスピードは劇的に改善できる。本記事では、LCP・CLS・INPの基準値から具体的な改善手順まで、実践的なノウハウを解説する。
- PageSpeed Insightsで「改善が必要」と表示され、何から手をつければいいか分からない方
- 画像が多いサイトを運営しており、表示速度が遅いことに悩んでいるサイト運営者
- Core Web Vitalsの基準値を満たして検索順位を上げたい実践者
こちらの関連記事も併せてご覧ください。「SEOの戦略」を総論的に解説しています。
目次
Core Web Vitalsの3指標とサイトスピードの重要性
LCP（Largest Contentful Paint）｜2.5秒以内が目標
LCPは、ページの一番大きなコンテンツが表示されるまでの時間を測定する指標だ。「一番多いのは、やっぱり一番最初にある大きなきれいなグラフィック、画像が評価されるケースが多い」と伊藤が指摘するように、多くの場合、ファーストビューのヒーロー画像やメインビジュアルが対象になる。
基準値は2.5秒以内が「良好」、2.5秒から4秒が「改善が必要」、4秒以上が「不良」とされる。ユーザーは3秒待てない。4秒かかれば、半数近くが離脱する。読み込み時間が1秒増えるごとに、直帰率は約7%上昇するというデータもある。LCPの改善は、ユーザー体験の向上に直結する。
主に評価される要素は、画像、動画、テキストブロック、背景画像だ。特に、ページ上部の大きな画像がLCPの対象になることが多い。高解像度の写真を無圧縮でアップロードしていないか。ファイルサイズが5MBを超えていないか。まずは現状を確認することが第一歩だ。
CLS（Cumulative Layout Shift）｜0.1以下が目標
CLSは、レイアウトシフトの度合いを数値化した指標だ。「要するに、うざさの度合いを数値化した指標になります。なので、これが高いと詐欺みたいなページだねっていう評価になるわけです」と伊藤は表現する。
具体的には、ページを読んでいる最中に、突然広告が表示されて、読んでいた位置がずれる。ボタンをクリックしようとした瞬間に、レイアウトが変わって、別のボタンを押してしまう。こうした体験は、ユーザーにストレスを与える。Googleは、このストレスを数値化し、評価に組み込んでいる。
基準値は0.1以下が「良好」、0.1から0.25が「改善が必要」、0.25以上が「不良」だ。原因として多いのは、サイズ指定のない画像、動的に挿入される広告、Webフォントの読み込み、非同期で読み込まれるコンテンツだ。これらが突然表示されることで、既存のコンテンツが押し下げられ、レイアウトがずれる。
対策の基本は、すべての要素に事前にスペースを確保することだ。画像にはwidth属性とheight属性を指定する。広告枠にはmin-heightを設定する。Webフォントにはfont-display: swapを使う。これだけで、CLSは大幅に改善される。
INP（Interaction to Next Paint）｜200ms以内が目標
INPは、ユーザーがアクションを起こしたときに、次の描画までどれくらい時間がかかるかを測定する指標だ。ボタンをクリックした。フォームに入力した。メニューを開いた。こうしたインタラクションに対して、サイトが素早く反応するかを評価する。
基準値は200ms以内が「良好」、200msから500msが「改善が必要」、500ms以上が「不良」だ。200msは、人間が「瞬時に反応した」と感じる時間だ。500msを超えると、「遅い」と感じ始める。1秒以上かかれば、「動いていないのでは」と不安になる。
INPに最も影響するのは、JavaScriptの実行時間だ。重いスクリプトが実行中は、ブラウザは他の処理を待たされる。ユーザーがボタンをクリックしても、スクリプトの実行が終わるまで反応できない。これがINPの悪化につながる。
対策は、JavaScriptの最適化だ。不要なプラグインを削除する。スクリプトを遅延読み込みにする。長時間実行されるタスクを分割する。50ms以上かかる処理は、分割して実行する。これによって、ブラウザは他の処理を挟み込めるようになり、INPが改善される。
測定方法と改善の優先順位
Core Web Vitalsを測定する方法は、主に3つある。一つ目はPageSpeed Insightsだ。URLを入力するだけで、モバイルとデスクトップの両方のスコアが表示される。0から49が「不良」、50から89が「改善が必要」、90から100が「良好」だ。具体的な改善提案も表示されるため、何から手をつければいいかが分かる。
二つ目は、Chrome Developer Toolsだ。「このGoogle ChromeのDeveloper Toolsを開いていただいて、そうするとパフォーマンスというデータがあるので、これをリロードしていただくと、先ほどの3大指標が出る」と伊藤が実演したように、リアルタイムでのパフォーマンス確認ができる。Lighthouseタブを開き、「レポートを生成」ボタンを押すだけだ。
三つ目は、サーチコンソールのCore Web Vitalsレポートだ。サイト全体のページを「不良」「改善が必要」「良好」の3つに分類して表示する。どのページに問題があるかを一覧で確認できるため、優先順位をつけやすい。
改善の優先順位は、「不良」から始める。「改善が必要」は後回しでもいい。まず赤信号を黄色にする。それから黄色を緑にする。一度にすべてを完璧にしようとせず、段階的に改善していくことが、継続可能な最適化につながる。
この項のまとめ
- LCPは2.5秒以内が目標。ヒーロー画像が主な評価対象で、1秒遅れるごとに直帰率7%上昇
- CLSは0.1以下が目標。レイアウトのずれが「うざさ」として数値化され、画像や広告のサイズ指定で改善
- INPは200ms以内が目標。JavaScriptの実行時間が影響し、50ms以上の処理は分割が必要
- 測定はPageSpeed Insights、Chrome Developer Tools、サーチコンソールの3つで実施
- 改善は「不良」から優先的に対処し、段階的に進めることが継続可能な最適化の鍵
LCP改善の3つの優先施策
画像圧縮と次世代フォーマット（WebP）への変換
LCPを改善する最も効果的な方法は、画像最適化だ。「画像をいかに最適化できるかっていうところですね」と伊藤が述べたように、これがすべての起点になる。大きな画像ファイルは、読み込みに時間がかかる。5MBの画像なら、モバイル回線では10秒以上かかることもある。これではユーザーは待てない。
まず画像圧縮から始める。JPEGやPNGの画像を、画質を保ったまま圧縮する。TinyPNGやImageOptimといったツールを使えば、50%から70%のファイルサイズ削減が可能だ。見た目はほとんど変わらない。しかしファイルサイズは半分以下になる。これだけで、読み込み時間は大幅に短縮される。
次に、次世代フォーマットへの変換だ。WebPは、JPEGと比較して25%から35%小さいファイルサイズで、同等の画質を実現する。Google が開発したフォーマットで、現在はほとんどのブラウザが対応している。変換は簡単だ。オンラインツールやWordPressプラグイン（EWWW Image Optimizer、WebP Expressなど）を使えば、既存の画像を一括変換できる。
目標は、1枚あたり100KB以下だ。ヒーロー画像でも、200KB以内に収める。これを超える場合は、さらに圧縮するか、画像のサイズ自体を小さくする。4000px幅の画像は不要だ。表示サイズが1200pxなら、1200pxで十分だ。余計な解像度は、読み込み時間を無駄に増やすだけだ。
画像の遅延読み込み（Lazy Load）実装
画像の遅延読み込みは、ファーストビュー外の画像を後から読み込む技術だ。ページを開いた瞬間に、すべての画像を読み込む必要はない。ユーザーがスクロールして、画像が見える位置に来たときに初めて読み込む。これによって、初期の読み込み時間が大幅に短縮される。
実装は驚くほど簡単だ。HTMLのimg タグに、loading=”lazy”という属性を追加するだけだ。例えば、<img src="image.jpg" loading="lazy">とする。これだけで、ブラウザが自動的に遅延読み込みを行う。JavaScriptのライブラリは不要だ。
ただし、注意点がある。ファーストビューの画像には、loading=”lazy”を使ってはいけない。ファーストビューの画像は、すぐに読み込む必要がある。遅延読み込みにすると、逆にLCPが悪化する。ファーストビュー外の画像だけに適用する。具体的には、スクロールしないと見えない位置の画像が対象だ。
WordPressを使っているなら、バージョン5.5以降は標準で対応している。特別な設定は不要だ。自動的に、適切な画像にloading=”lazy”が追加される。古いバージョンを使っている場合は、アップデートするか、プラグインを使う。Lazy Load by WP Rocketなどが有効だ。
CDNとキャッシュの活用
画像を最適化しても、サーバーからの配信が遅ければ意味がない。ここで威力を発揮するのが、CDN（Content Delivery Network）だ。CDNは、世界中にサーバーを持ち、ユーザーに最も近いサーバーから画像を配信する。日本のユーザーには日本のサーバーから、アメリカのユーザーにはアメリカのサーバーから配信する。物理的な距離が近いほど、配信は速い。
Cloudflareは、無料で使える代表的なCDNだ。設定は少し複雑だが、一度設定すれば、すべての画像が自動的にCDN経由で配信される。表示速度は体感できるほど改善される。特に、海外からのアクセスが多いサイトでは効果が大きい。
次にキャッシュだ。キャッシュは、一度読み込んだデータを保存し、次回以降は保存したデータを使う技術だ。毎回サーバーから取得する必要がなくなる。WordPressなら、キャッシュプラグインの導入が必須だ。WP RocketやLiteSpeed Cacheが代表的だ。設定は簡単で、インストールして有効化するだけで、基本的なキャッシュが機能する。
さらに、サーバー応答時間（TTFB：Time To First Byte）の短縮も重要だ。サーバーがリクエストを受けてから、最初のデータを返すまでの時間だ。これが遅いと、いくら画像を最適化しても効果は限定的だ。共有サーバーを使っているなら、専用サーバーやVPSへの移行を検討する。データベースクエリの最適化も効果的だ。不要なプラグインを削除し、データベースを軽量化する。
LCP改善の3つの施策は、画像圧縮、遅延読み込み、CDN・キャッシュだ。この順番で実施する。まず画像を軽くする。次に不要な画像の読み込みを遅らせる。最後に配信を高速化する。この3つで、LCPは劇的に改善される。
この項のまとめ
- 画像圧縮で50-70%削減可能。WebP変換でJPEG比25-35%小さく、目標は1枚100KB以下
- loading="lazy"属性でファーストビュー外の画像を遅延読み込み。WordPress5.5以降は標準対応
- CDN（Cloudflare等）で地理的に近いサーバーから配信し、キャッシュプラグインで読み込み高速化
- サーバー応答時間（TTFB）短縮も重要。共有サーバーからVPSへの移行やデータベース最適化が効果的
- 画像圧縮→遅延読み込み→CDN・キャッシュの順で実施することで、LCPが劇的に改善される
CLS・INP改善の実践テクニック
画像と広告にサイズ属性を指定してCLS対策
CLSを改善する最も確実な方法は、すべての画像にwidth属性とheight属性を指定することだ。画像がロードされる前に、ブラウザはその領域を確保できる。画像が表示されても、周りのコンテンツは動かない。レイアウトシフトが発生しない。
具体的には、<img src="image.jpg" width="800" height="600">という形で記述する。実際の表示サイズと異なっていても問題ない。CSSで縮小すればいい。重要なのは、アスペクト比を保つことだ。800×600なら、4:3の比率だ。この比率さえ維持すれば、レスポンシブデザインでも正しく表示される。
広告枠も同様だ。Google AdSenseやアフィリエイトバナーは、読み込みに時間がかかる。広告が表示される瞬間、コンテンツが押し下げられる。これを防ぐには、広告が入る場所に事前にスペースを確保する。CSSでmin-heightを設定する。例えば、min-height: 250px;とすれば、広告が表示される前から250pxの高さが確保される。広告が表示されても、レイアウトは崩れない。
Webフォントも要注意だ。フォントの読み込み中、テキストが一瞬見えなくなる（FOIT：Flash of Invisible Text）か、別のフォントで表示されてから切り替わる（FOUT：Flash of Unstyled Text）。どちらもレイアウトシフトの原因になる。対策は、CSSにfont-display: swap;を追加することだ。これによって、フォントの読み込みを待たずにシステムフォントでテキストを表示し、フォントが読み込まれたら切り替える。テキストは常に表示され、ユーザーは待たされない。
動的コンテンツも同様だ。JavaScriptで後から挿入される要素は、事前に領域を確保する。スケルトンスクリーンと呼ばれる手法が効果的だ。コンテンツの形だけを先に表示し、実際のコンテンツが読み込まれたら置き換える。ユーザーは待っている間も、何かが表示されていると感じる。突然コンテンツが出現して驚くことはない。
JavaScriptの最適化でINP改善
INPを改善するには、JavaScriptの最適化が不可欠だ。まず不要なスクリプトを削除する。使っていないプラグインはないか。実は機能していないスクリプトはないか。Chrome Developer ToolsのCoverageタブを使えば、未使用のコードを検出できる。赤く表示された部分は、読み込まれているが実行されていないコードだ。これを削除するだけで、読み込み時間が短縮される。
次に、スクリプトの遅延読み込みだ。すべてのスクリプトを最初に読み込む必要はない。重要でないスクリプトは、defer属性やasync属性を使って遅延させる。deferは、HTMLの解析が終わってから実行する。asyncは、ダウンロード完了次第すぐに実行する。どちらもHTMLの解析をブロックしないため、ページの表示が速くなる。
さらに、JavaScriptの分割とコード最小化だ。1つの巨大なファイルより、複数の小さなファイルのほうが効率的だ。必要な部分だけを読み込める。Webpack や Rollup といったバンドラーを使えば、コードを自動的に分割し、不要な部分を削除（Tree Shaking）できる。ミニファイ（圧縮）も自動化できる。空白や改行、コメントを削除し、ファイルサイズを30%から50%削減できる。
長時間実行タスクの分割も重要だ。50ms以上かかる処理は、ブラウザが他の処理を実行できない。ユーザーがボタンをクリックしても、反応しない。これがINPの悪化につながる。対策は、処理を分割することだ。一度に100個のアイテムを処理するのではなく、10個ずつ10回に分けて処理する。間にrequestIdleCallbackを挟めば、ブラウザは他の処理を実行できる。ユーザーのアクションにも即座に反応できる。
CSSとHTMLの軽量化
CSSの最適化も見逃せない。複数のCSSファイルがあるなら、1つに統合する。HTTPリクエストの回数が減り、読み込みが速くなる。ミニファイも忘れずに。空白や改行を削除し、ファイルサイズを削減する。
未使用CSSの削除も効果的だ。PurgeCSSというツールを使えば、実際に使われているCSSだけを抽出できる。フレームワーク（BootstrapやTailwind CSS）を使っている場合、大量の未使用CSSが含まれている。これを削除するだけで、CSSファイルは半分以下になることもある。
クリティカルCSS（重要CSS）のインライン化も検討する。ファーストビューの表示に必要な最小限のCSSだけを、HTMLの<head>内に直接記述する。外部CSSファイルの読み込みを待たずに、ページが表示される。残りのCSSは非同期で読み込む。これによって、ファーストビューの表示速度が劇的に向上する。
HTMLの構造最適化も忘れてはならない。DOM要素数が多すぎると、ブラウザのレンダリングに時間がかかる。不要なdivタグを削除する。ネストを浅くする。目安として、DOM要素数は1500個以内に収める。これを超えると、パフォーマンスに影響が出始める。
CLS・INP・CSS最適化は、一見地味な作業だ。しかし、これらの積み重ねが、ユーザー体験を大きく改善する。一つずつ、確実に実施していくことが重要だ。
この項のまとめ
- 画像にwidth・height属性、広告枠にmin-height設定でCLS対策。font-display: swapでWebフォント最適化
- 未使用JavaScriptを削除し、defer/async属性で遅延読み込み。50ms以上の処理は分割してINP改善
- CSSを統合・ミニファイし、未使用CSS削除でファイルサイズ半減。クリティカルCSSのインライン化でファーストビュー高速化
- DOM要素数を1500個以内に削減し、不要なdivタグとネストを整理してレンダリング時間短縮
- 地道な最適化の積み重ねが、ユーザー体験の大幅改善につながる
WordPress高速化の必須設定
高速化プラグインの導入と設定
WordPressでサイトスピードを改善するなら、高速化プラグインの導入が最優先だ。代表的なのは、WP RocketとLiteSpeed Cacheの2つである。WP Rocketは有料だが、設定が簡単で初心者でも扱いやすい。LiteSpeed Cacheは無料だが、LiteSpeedサーバーでの使用が推奨される。どちらも、キャッシュ、画像最適化、CSS・JavaScript最適化を統合的に行える。
キャッシュ設定の最適化が、これらのプラグインの核心だ。ページキャッシュを有効にすれば、訪問者がページを開くたびにWordPressがデータベースにアクセスする必要がなくなる。事前に生成されたHTMLファイルを表示するだけなので、表示速度が劇的に向上する。ブラウザキャッシュも忘れずに設定する。画像やCSSファイルをユーザーのブラウザに保存し、2回目以降の訪問時に再利用する。
画像最適化との連携も重要だ。多くの高速化プラグインは、画像の自動圧縮や遅延読み込みの機能を内蔵している。WP Rocketなら、設定画面で「画像の遅延読み込み」にチェックを入れるだけだ。わざわざ別のプラグインを入れる必要はない。機能が重複すると、逆にサイトが重くなる。
データベース最適化機能も活用する。WordPressを長く使っていると、リビジョン、下書き、スパムコメント、トランジェントといった不要なデータが蓄積される。これがデータベースを肥大化させ、クエリの実行時間を遅くする。高速化プラグインには、これらを一括削除する機能がある。月に一度、データベースをクリーンアップする習慣をつける。
不要なプラグインの削除と軽量テーマへの移行
WordPressが重くなる最大の原因は、プラグインの入れすぎだ。便利だからと次々にプラグインを追加していると、気づけば20個、30個になっている。それぞれのプラグインがJavaScriptやCSSを読み込み、データベースにクエリを発行する。これが積み重なると、サイトは確実に遅くなる。
使用頻度の低いプラグインを精査する。本当に必要か。代替手段はないか。例えば、お問い合わせフォームのプラグインを2つ入れていないか。SNSシェアボタンのプラグインが3つもないか。機能が重複しているものは、1つに絞る。理想は、プラグイン数を10個以内に抑えることだ。
テーマも重要だ。多機能なテーマは便利だが、その分重い。ページビルダーを内蔵したテーマは、特に注意が必要だ。使わない機能まで読み込まれ、サイトが遅くなる。軽量テーマへの移行を検討する。GeneratePressやAstraは、高速で知られるテーマだ。シンプルな構造で、必要な機能だけを追加できる。
移行は簡単ではない。デザインが変わってしまうからだ。しかし、デザインとスピードの両立が難しいなら、スピードを優先すべきだ。「写真いっぱい使ったりすると、リッチなページでお客さん、ユーザー満足するんですけど、Googleの評価は低い」と伊藤が指摘したように、見た目だけを追求してはいけない。ユーザーは美しいページを見たいのではない。求めている情報を、素早く得たいだけだ。
データベースの定期メンテナンスも忘れてはならない。リビジョンは記事の履歴だが、何十個も保存する必要はない。最新の5個だけ残し、古いものは削除する。下書きやゴミ箱の記事も、定期的に完全削除する。トランジェントは一時的なデータだが、期限切れのものが残っていることがある。WP-OptimizeやWP-Sweepといったプラグインを使えば、これらを一括削除できる。
モバイル最適化の重要性
現在、検索の過半数はスマートフォンから行われる。Googleもモバイルファーストインデックスを採用している。つまり、モバイル版のサイトを基準に評価する。モバイルでの表示速度が遅ければ、検索順位は上がらない。
PageSpeed Insightsを開くと、モバイルとデスクトップの両方のスコアが表示される。多くの場合、モバイルのスコアのほうが低い。通信速度が遅く、処理能力も限られているからだ。モバイルでのスコアを優先的に改善する。デスクトップで90点でも、モバイルで50点なら意味がない。
レスポンシブ画像の実装も必須だ。デスクトップ用の2000px幅の画像を、スマートフォンで表示する必要はない。画面幅は375pxしかない。srcset属性を使えば、デバイスに応じて最適なサイズの画像を配信できる。例えば、<img src="image-800.jpg" srcset="image-400.jpg 400w, image-800.jpg 800w, image-1600.jpg 1600w">とすれば、スマートフォンには400px幅、タブレットには800px幅、デスクトップには1600px幅の画像が表示される。
タップ領域の最小サイズも重要だ。ボタンやリンクは、最低でも48px×48pxの大きさが必要だ。それより小さいと、指でタップしにくい。隣のボタンを誤ってタップしてしまう。これはユーザー体験を著しく損なう。サーチコンソールのモバイルユーザビリティレポートで、「クリック可能な要素が近すぎる」という警告が出たら、すぐに修正する。
WordPressの高速化は、プラグイン選定、不要な要素の削除、モバイル最適化の3つが柱だ。どれか1つではなく、3つすべてを実施する。そうして初めて、体感できる改善が得られる。
この項のまとめ
- WP RocketやLiteSpeed Cacheでキャッシュ・画像最適化・CSS/JS最適化を統合管理。月1回のデータベースクリーンアップも重要
- プラグインは10個以内に抑え、機能重複を排除。GeneratePressやAstraなど軽量テーマへの移行を検討
- モバイルファーストインデックスのため、モバイルスコアを優先改善。デスクトップ90点でもモバイル50点なら不十分
- srcset属性でレスポンシブ画像を実装し、デバイスごとに最適サイズを配信。タップ領域は48px×48px以上確保
- プラグイン選定・不要要素削除・モバイル最適化の3つを同時実施して、体感できる改善を実現
効果測定とPDCAサイクル
改善前後のデータ比較
サイトスピードの改善施策を実施したら、必ず効果を測定する。感覚ではなく、数値で判断する。主な指標は3つだ。PageSpeed Insightsのスコア、サーチコンソールのCore Web Vitalsレポート、そして実際のユーザー行動だ。
PageSpeed Insightsのスコアは、最も分かりやすい指標だ。改善前に一度測定し、スクリーンショットを保存しておく。改善後、再度測定する。スコアが20点、30点と上がれば、施策は成功だ。特に、「不良」から「改善が必要」へ、「改善が必要」から「良好」へと分類が変われば、大きな進歩だ。ただし、スコアは毎回多少変動する。一度の測定で判断せず、3回測定して平均を取る。
サーチコンソールのCore Web Vitalsレポートは、より実際的なデータを提供する。これは実際のユーザーの体験データだ。PageSpeed Insightsは理論値だが、サーチコンソールは現実値だ。「不良URL」の数が減り、「良好URL」の数が増えれば、改善は成功している。ただし、データの反映には28日間かかる。すぐに結果を求めず、1ヶ月後に確認する。
直帰率と滞在時間の変化も重要だ。サイトスピードが改善されれば、ユーザーはページを離れにくくなる。直帰率が下がり、滞在時間が伸びる。Google Analytics 4でこれらの指標を確認する。改善前の1ヶ月と、改善後の1ヶ月を比較する。直帰率が5%下がれば、明確な改善だ。滞在時間が10秒伸びれば、ユーザーはより多くのコンテンツを読んでいる。
検索順位への影響は、最も時間がかかる。サイトスピードを改善しても、すぐに順位が上がるわけではない。Googleが再評価するまで、数週間から数ヶ月かかる。サーチコンソールの検索パフォーマンスレポートで、平均掲載順位の推移を追跡する。3ヶ月後、半年後と長期的に観察する。じわじわと順位が上がっていれば、効果が出ている証拠だ。
継続的なモニタリング体制
サイトスピードは、一度改善したら終わりではない。時間とともに劣化する。新しいプラグインを追加すれば遅くなる。画像をたくさんアップロードすれば重くなる。だからこそ、継続的なモニタリングが必要だ。
月次でのスコア確認を習慣化する。毎月第一月曜日など、日を決めてPageSpeed Insightsを実行する。スコアをスプレッドシートに記録する。前月と比較して、悪化していないか確認する。悪化していれば、原因を特定し、対処する。
新規ページ公開時のチェックも必須だ。新しい記事を公開したら、そのページのスコアを確認する。画像が多すぎないか。動画を埋め込んでいないか。重い要素があれば、公開前に最適化する。後から直すより、最初から正しく作るほうが効率的だ。
プラグイン更新後の検証も重要だ。プラグインをアップデートすると、予期しない問題が発生することがある。新しい機能が追加され、スクリプトが増え、サイトが重くなる。アップデート後は必ずスコアを確認する。明らかに悪化していれば、プラグインを元のバージョンに戻すか、別のプラグインに切り替える。
Chrome拡張機能「Web Vitals」を使えば、常時監視できる。ブラウザにインストールすると、訪問したページのCore Web Vitalsがリアルタイムで表示される。自分のサイトを見るたびに、LCP、CLS、INPの値が確認できる。異常値が出たら、すぐに気づける。競合サイトのスコアも確認できるため、ベンチマークとしても使える。
実例から学ぶ改善効果
「今、お手伝いしてるサイトでJSON-LDコードを7月に入れた結果、3カ月でサイトのアクセスは3倍になりました」と伊藤が紹介した実例は、技術的な改善の効果を如実に示している。構造化データの実装だけで3倍だ。サイトスピードの改善も、同様の効果が期待できる。
サイトスピード改善と検索順位には、明確な相関関係がある。Googleの調査では、読み込み時間が1秒から3秒に増えると、直帰率が32%増加する。3秒から5秒なら90%増加する。つまり、遅いサイトはユーザーに見放される。Googleもそれを検索順位に反映する。
逆に、サイトスピードを改善すれば、ユーザーは滞在する。ページを読み、他のページも見る。これがエンゲージメント時間を伸ばし、Googleの評価を高める。結果として、検索順位が上がる。アクセスが増える。この好循環が生まれる。
ただし、ユーザー体験向上が最終目標だ。検索順位を上げるためにサイトスピードを改善するのではない。ユーザーに快適な体験を提供するために改善する。その結果として、検索順位が上がる。この順番を間違えてはいけない。
一つずつ地道に改善する重要性を、伊藤は繰り返し強調している。完璧なサイトを目指す必要はない。今日、画像を1枚圧縮する。明日、不要なプラグインを1つ削除する。来週、キャッシュプラグインを導入する。この小さな積み重ねが、数ヶ月後には大きな差を生む。焦らず、着実に進める。それがサイトスピード改善の王道だ。
この項のまとめ
- 改善前後をPageSpeed Insights、サーチコンソール、直帰率・滞在時間で数値比較。検索順位への影響は3〜6ヶ月の長期観察が必要
- 月次スコア確認、新規ページ公開時チェック、プラグイン更新後検証を習慣化。Chrome拡張「Web Vitals」で常時監視
- 構造化データ実装で3ヶ月でアクセス3倍の実例あり。読み込み時間1秒→3秒で直帰率32%増加というデータも存在
- ユーザー体験向上が最終目標であり、検索順位向上は結果。この順番を間違えない
- 完璧を目指さず、一つずつ地道に改善する。小さな積み重ねが数ヶ月後に大きな差を生む
こちらの関連記事も併せてご覧ください。「SEOの戦略」を総論的に解説しています。
編集後記
デザインと速度の両立は難しい。美しい写真をたくさん使いたい。リッチなアニメーションで目を引きたい。しかし伊藤が「写真いっぱい使ったりすると、リッチなページでお客さん、ユーザーは満足するんですけど、Googleの評価は低いねみたいなことが起こりうる」と指摘したように、見た目だけを追求すれば、サイトは重くなる。ユーザーは離脱する。検索順位も下がる。セミナーでH氏だけがサイトスピードをチェックしていた。他の参加者は、誰もチェックしていなかった。これが現実だ。技術的な改善は地味で、面倒で、つい後回しにしてしまう。しかし、一つずつ実施すれば、必ず結果は出る。今日から始めよう。まず1枚の画像を圧縮してみる。それだけでいい。完璧を目指さず、改善を積み重ねる。それがサイトスピード最適化の本質だ。
講師紹介
株式会社ボンセレ 代表取締役
伊藤 祐介（いとう ゆうすけ）
❖ プロフィール
東京出身の“氷河期世代”。
身長182cm、見た目は大きめ、中身は細かめ。
公務員からスタートし、フレンチレストラン、築地魚河岸、ワインショップなど、業種も業界も超えて現場を経験。のちに広告代理店、EC支援、WEB制作へと軸足を移し、現在は複数企業のWEB戦略を支援。実務と現場視点に根ざした教育者です。
❖ 専門領域
WEBマーケティング／EC戦略立案
コンテンツ企画・制作
広告運用（SNS／検索）
顧客接点の設計とCRM支援
❖ 教育観・講義スタンス
「右腕は、育てることができる」。
人は“経験”だけでは変わりません。
変化するのは、思考のプロセスを鍛えたとき。
私は現場から、企画・広告・制作・接客・分析まで、すべての工程を実践してきました。だからこそ、「考えて動ける右腕」を育てるには、手を動かし、振り返り、問い直す場が必要だと考えています。
❖ 右腕育成にかける思い
「社長の想いを言語化し、現場に翻訳する存在」が右腕です。
単なるWEB人材ではなく、“経営を理解し、支える人材”を育てたい。
ひとつの強みを見つけ、自分にしかできない貢献の形を築く――
それが、このプログラムのゴールです。
❖ 私のルーツ
仮説実験授業（板倉聖宣 提唱）
科学的な思考法とディスカッションベースの学びに影響を受ける。プログラミングとの出会い
高校時代にBasicからスタート。VBAでの業務改善からWEB制作へ。
❖ 好きなこと
食べること・飲むこと・考えること。
最近のブームは激辛料理（ブートジョロキア）。
