1. 概要（Executive Summary）
サイトの表示がモバイルで遅い、あるいはレイアウトが崩れているなら、今この瞬間にも訪問者を入口で追い返しています。オフィスのモニターでは正常に見えるため、問題に気づきにくいだけです。
この記事では3つの疑問に答えます。自社サイトの訪問者は本当にモバイルが多数なのか、Googleは速度をどう評価するのか、そして何から直すべきか。設計原則、速度改善の実務、無料の確認ツールまで、担当者が自分で検証できる水準でまとめました。
コードを理解する必要はありません。制作会社に何を求め、どの基準で納品物を検収すべきか判断できれば十分です。
重要なメッセージ
Googleは2023年にモバイルファーストインデックスへの移行を完了しました。検索順位を決める基準画面はデスクトップではなくモバイルです。それでも検収をオフィスのモニターだけで行う企業は少なくありません。
速度の基準も明確です。LCP 2.5秒、INP 200ミリ秒、CLS 0.1。この3つを満たすことが、Core Web Vitalsにおける「良好なサイト」の公式基準です。
2. トラフィックはすでにモバイルが多数
StatCounterの集計では、世界のWebトラフィックの約60％がモバイルから発生しています。デスクトップが基本でモバイルが例外だった時代は、何年も前に終わりました。
業種によって差はさらに広がります。飲食店、美容室、病院、スクールなど地域の顧客と接する業種では、移動中に手元のスマートフォンで検索が行われます。検索、Instagramのプロフィールリンク、メッセージで共有されたURLからの流入は、ほぼすべてモバイルです。広告を運用した担当者なら、流入レポートでモバイル比率が70％を超える画面をすでに見ているはずです。
2.1 Googleはどの画面でサイトを評価するのか
モバイル画面です。Googleは2016年にモバイルファーストインデックスを発表し、2023年10月に移行完了を宣言しました。現在Googleの検索結果に反映されるのは、スマートフォンクローラーが読み取ったモバイル版です。デスクトップ版の完成度が高くても、モバイルで切れたり隠れたりするコンテンツは評価から外れる可能性があります。
モバイル画面を簡潔にするという理由で、紹介文や詳しい説明を丸ごと削るリニューアルがあります。見た目はすっきりしても、検索エンジンにはコンテンツが消えたサイトと映ります。減らすべきは装飾であって、情報ではありません。
2.2 デスクトップだけで検収してはいけない理由
制作工程の落とし穴はここにあります。発注側も制作側も、通常はオフィスのモニターで確認します。27インチでは完璧だったサイトが、6インチでは文字が極端に小さく、ボタンが重なり、電話ボタンまで3回スクロールしなければ届かないことがあります。
売上を生む顧客は、その6インチ画面からアクセスします。検収基準を「自分のモニターできれいか」から「顧客のスマートフォンで使いやすいか」へ変えることが、モバイルファーストの出発点です。
モバイルファーストインデックスを一文で
Googleはサイトを評価するとき、モバイル版のコンテンツ・構造・速度を基準にするということです。モバイル画面がサイトの公式な成績表です。
サイトを新規公開した直後やリニューアル直後なら、インデックス登録と基本設定から確認しましょう。手順はサイト公開後90日間のSEO設定ガイドにまとめています。
3. Core Web Vitals：Googleが見る速度指標
Googleは「速い」を感覚ではなく3つの数値で判定します。読み込み速度のLCP、応答性のINP、視覚的な安定性のCLSです。これらをまとめてCore Web Vitals（コアウェブバイタル）と呼び、検索順位のシステムにも利用します。
3.1 3つの指標と合格基準
| 指標 | 測定内容 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP （Largest Contentful Paint） | 画面内で最も大きい要素、多くの場合メイン画像が表示されるまでの時間 | 2.5秒以下 | 2.5〜4.0秒 | 4.0秒超 |
| INP （Interaction to Next Paint） | ボタンをタップしてから画面が反応するまでの時間 | 200ミリ秒以下 | 200〜500ミリ秒 | 500ミリ秒超 |
| CLS （Cumulative Layout Shift） | 読み込み中に画面要素が予期せず移動する度合い | 0.1以下 | 0.1〜0.25 | 0.25超 |
判定には実ユーザーデータの75パーセンタイル値を使います。100回の訪問のうち少なくとも75回が基準内に入らなければ「合格」になりません。自分の端末で一度速く表示されただけでは不十分です。INPは2024年3月に従来のFID（First Input Delay）を置き換えました。
CLSという名前は聞き慣れなくても、体験は身近です。記事を読んでボタンを押そうとした瞬間に広告が入り込み、別の場所を押してしまう現象です。画像サイズを事前に指定していないページでよく起こります。
3.2 速度は検索順位をどの程度左右するのか
影響はありますが、コンテンツ品質を逆転させるほどではありません。Googleはページエクスペリエンスを複数あるランキングシグナルの一つとして扱うと説明しています。同程度の品質を持つ文書が競う場合に、速い方が有利になる構造に近いでしょう。
順位以上に怖いのは離脱です。Googleが2016年に公表した調査では、モバイルページの読み込みに3秒以上かかると訪問の53％が中断されました。クリック単価を払って獲得した訪問者が、最初の画面を見る前に離れてしまいます。順位を一つ上げるより、来訪者に残ってもらう方が売上には直接効きます。
サイトの点数は30秒で確認できます
PageSpeed Insights（pagespeed.web.dev）にホームページのURLを入力してください。モバイルスコアと3指標の合否がすぐに表示されます。
この記事を最後まで読む前に一度測定しておくと、後半の改善項目のうち自社に必要なものを判断しやすくなります。
4. モバイルファースト設計の原則
モバイルファーストは「モバイルでも見える」ことではありません。小さい画面から設計し、大きな画面へ拡張する順序のことです。デスクトップ案を先に作って狭めると、どこかが必ず破綻します。狭い画面で成立した構造を広げる方が安全です。
4.1 タッチターゲット：親指で正確に押せるか
マウスポインターはピクセル単位で正確ですが、親指はそうではありません。Google Material Designはタッチ領域を最低48×48dp、Apple Human Interface Guidelinesは44×44ptと推奨しています。ボタン自体の大きさと、ボタン間の余白の両方が必要です。リンクが隣接していれば、どちらかが誤タップされます。
電話番号には必ずtel: リンクを設定してください。番号を覚えて電話アプリに入力させるサイトがまだあります。1回のタップで通話画面が開けば、問い合わせ電話の増加につながります。
4.2 文字サイズと行の長さ
本文は16px以上が基本です。ピンチ操作で拡大しなければ読めない文字は、すでに失敗しています。行間は1.6〜1.8倍、1行は長くしすぎず、十分なコントラストを確保します。白背景に薄いグレー文字を置く流行は、屋外の直射日光では何も読めない画面を作ります。
4.3 ハンバーガーメニューが常に正解とは限らない
すべてのメニューを三本線のアイコンに隠す手法が定番になりましたが、隠れた項目はタップされにくくなります。項目が4〜5個だけなら、無理に隠す必要はありません。上部に表示するか、電話・アクセス・予約など頻繁に使う項目を画面下部の固定バーに出す方が適切です。
10項目を超えるECサイトやコンテンツサイトなど、ハンバーガーメニューが必要な場合もあります。判断基準は一つです。訪問者が最もよく使う行動に1タップで届くか。
4.4 ファーストビューに何を置くか
モバイルのファーストビューは手のひらの小さな領域です。会社沿革や代表挨拶を置く余裕はありません。何をする会社か、どう連絡するか、どこにあるかという訪問目的が、スクロールなしで分かる必要があります。
優先順位を決める簡単な方法は、顧客が電話で最もよく尋ねる3つの質問を書き出すことです。その答えが最初の2画面以内にないなら、配置を見直すべきです。
4.5 レスポンシブとアダプティブ、どちらを選ぶか
結論から言えば、中小企業のサイトにはレスポンシブが適しています。
| 区分 | レスポンシブ | アダプティブ |
|---|---|---|
| 方式 | 一つのページが画面幅に応じて流動的に再配置される | 端末別に別画面またはm.ドメインなど別URLを提供する |
| 管理 | 一つのURL、一つのコンテンツを管理 | バージョン別の二重管理で更新漏れの危険がある |
| SEO | Googleが推奨する方式 | 代替URL設定に不備があるとインデックス問題が起きる |
| 適するケース | ほとんどの企業サイト | モバイル機能が根本的に異なる大規模サービス |
古いサイトには、m.ドメインでモバイル専用ページを別運用しているものがあります。管理コストが倍になりSEO評価も分散するため、リニューアル時に一つのレスポンシブサイトへ統合する方がよいでしょう。全面改修を検討している場合は、サイトリニューアルガイドで手順と確認項目を参照できます。
5. 表示速度改善の実務
何から着手するべきでしょうか。答えは画像です。体感速度の改善は、ほとんどが画像とスクリプトから生まれます。サーバー増強やホスティング移転を考える前に、難易度が低く効果の大きい作業から進めます。
5.1 画像：最も大きく、最も直しやすい問題
遅いサイトの原因は、多くの場合画像です。カメラから出した4000pxの原寸画像をそのまま掲載し、ブラウザが全体をダウンロードしてから小さく表示します。1ページが数十MBになるサイトも珍しくありません。
- WebPへ変換：Googleの開発者向け資料では、同等品質のWebPはJPEGより25〜34％小さくなります。無料変換ツールがあり、WordPressではプラグインで自動化できます。
- 表示サイズに合わせて縮小：400pxで表示する画像なら、高密度画面を考慮しても800px程度で十分です。4000pxの原寸は配信ページに置かないでください。
- 遅延読み込み：
loading="lazy"を付けると、画面外の画像はスクロールが近づくまで読み込まれません。ただしファーストビューのメイン画像には設定しないでください。LCPがかえって遅くなります。 - 幅と高さを指定：widthとheightを指定すれば、ブラウザが画像到着前に領域を確保します。CLSの代表的な原因を解消できます。
5.2 フォント：韓国語フォントは重い
韓国語には組み合わせ可能な文字が11,172字あります。欧文フォントと同じ感覚で全字形を読み込むと、1書体で数MBになります。文字が長く表示されず、後から現れて画面が動く場合、フォントが原因であることが多いです。
- サブセットフォント：使用頻度の高いKS X 1001の2,350字だけを収録したサブセットなら容量を大幅に減らせます。フォント配布サイトやGoogle Fontsでも提供されています。
- WOFF2形式：Webフォントは通常WOFF2一つで足ります。TTFやOTFをそのままWeb配信するのは、未圧縮ファイルを配るのと同じです。
- font-display: swap：Webフォントの読み込み中はシステムフォントで先に表示します。文字が見えない空白画面よりはるかに良い体験です。
5.3 スクリプト：まず使っていないものを削除
チャットウィジェット、古いトラッキングコード、使われていないスライダーライブラリ。こうしたスクリプトが積み重なるとタップへの反応が遅れ、INPが悪化します。高度な最適化を始める前に一覧を作り、不要なものを削除してください。
残すスクリプトにはdefer属性を付け、ページ表示を妨げないようにします。初期画面の描画に不要なコードを待つ理由はありません。
5.4 サーバー側：圧縮とキャッシュ
数行のサーバー設定で終わる改善もあります。gzipまたはBrotli圧縮を有効にするとHTML・CSS・JavaScriptの転送量が大きく減り、Cache-Controlによるブラウザキャッシュを設定すると再訪問時に同じ画像やCSSを再取得しません。自分で変更できなければ、ホスティング会社や制作会社に「gzip圧縮とブラウザキャッシュを設定してください」と依頼できます。
5.5 作業別の効果
| 作業 | 難易度 | 主に改善する指標 |
|---|---|---|
| 画像をWebPへ変換・縮小 | 低 | LCP |
| 画像の遅延読み込み | 低 | LCP |
| 画像のwidth・height指定 | 低 | CLS |
| 韓国語フォントのサブセット + WOFF2 | 中 | LCP、CLS |
| スクリプト整理 + defer | 中 | INP |
| gzip・Brotli圧縮 + キャッシュ | 中 | LCP全般 |
WordPressならプラグインの整理から
プラグインは一つずつCSSとJavaScriptを追加します。20個以上入っているサイトでは、半分が無効だったり、誰も用途を覚えていなかったりします。
一覧を作り、「これを削除すると何が動かなくなるか」を一つずつ確認して整理するだけで点数が上がることがあります。キャッシュプラグインは機能が重なるため一つだけ残してください。複数を同時に使うと競合します。
6. 確認ツールとテスト手順
必要なツールは3つです。PageSpeed Insights、Lighthouse、Google Search Console。すべて無料で、アカウント不要またはGoogleアカウント一つで利用できます。
6.1 PageSpeed Insights：実ユーザーデータまで一度に確認
URLを入力すると2種類の結果が表示されます。上部の実際のユーザー環境での評価は、Chromeユーザーの直近28日間の実測データ（CrUX）であり、Core Web Vitals合否の公式基準です。下部の診断スコアはシミュレーションによるラボデータで、併記される改善項目が実務で役立ちます。必ずモバイルタブを先に見てください。デスクトップの点数は一般に高く出ます。
6.2 Lighthouse：Chromeだけで実行できる
Chrome DevTools（F12）のLighthouseタブから、同じ診断をローカルで実行できます。未公開の開発サイトを調べるときや、修正前後を比較するときに便利です。制作会社にレポートを依頼し、検収資料として使うこともできます。
6.3 Search Console：実際の訪問者を基準に合否を確認
Search ConsoleのCore Web Vitalsレポートは、サイト内のURL群を実ユーザーデータに基づいて「良好」「改善が必要」「不良」に分類し、モバイルとデスクトップを分けて表示します。問題のあるページ群が分かるため、修正の優先順位を決めやすくなります。
以前の「モバイルユーザビリティ」レポートは2023年末に終了しました。レイアウト崩れやタッチ要素の間隔は、Lighthouseと実機テストで確認します。
6.4 ツールより確実なもの：自分のスマートフォン
点数が良くても、実際のスマートフォンで使いにくければ意味がありません。Wi-Fiを切り、LTEでアクセスしてください。顧客の環境はオフィスの高速回線ではなく、地下鉄でつながる電波です。
- 3秒以内に意味のあるファーストビューが表示されるか
- 電話・予約・問い合わせボタンへ親指1回で届くか
- スクロール中に画面がずれたり跳ねたりしないか
- 拡大せずに本文を読めるか
ラボデータとフィールドデータが異なる場合
Lighthouseの点数は良いのに、Search Consoleでは「改善が必要」と出ることがあります。ラボデータは固定条件のシミュレーションで、フィールドデータには低速な端末や地下鉄のLTEも含まれるためです。
結果が異なる場合はフィールドデータを基準にします。Googleが評価に使うのも、顧客が実際に体験するのもこちらです。
7. 結論とチェックリスト
7.1 3文で要約
訪問者の多くはモバイルから入り、Googleもモバイル画面でサイトを評価します。速度にはLCP 2.5秒、INP 200ミリ秒、CLS 0.1という明確な合格線があり、画像・フォント・スクリプトが結果を大きく左右します。設計は小さな画面から始め、大きな画面へ広げる順序が安全です。
7.2 今日確認できる6項目
- 実機テスト：Wi-Fiを切って自分のスマートフォンで開き、3秒以内に意味のある画面が出るか確認する
- 点数測定：PageSpeed InsightsのモバイルタブでCore Web Vitalsの合否を確認し、結果を保存する
- 画像整備：WebP変換、表示サイズへの縮小、適切な遅延読み込み、width・height指定を行う
- フォント整備：韓国語サブセット、WOFF2、
font-display: swapの適用を確認する - タッチ検収：電話・問い合わせを1タップで使えるようにし、ボタン48px以上、本文16px以上を確認する
- 測定習慣：毎月同じ条件で測定して記録する。コンテンツやプラグインが増えるほど速度は必ず後退する
7.3 速度は状態ではなく習慣
一度最適化したサイトも放置すれば再び遅くなります。担当者が原寸のバナー画像を掲載し、マーケティングがトラッキングコードを追加し、プラグイン更新でスクリプトが増えます。だからこそ最後の項目が定期的な測定です。
記録が蓄積すれば、「最近遅くなった気がする」が「3月からLCPが1秒増えた」という事実に変わります。事実があれば、制作会社にも社内チームにも正確な修正を依頼できます。