【今すぐ見直す】WordPressの表示速度、重いと検索で不利？ 写真1枚で22秒…手元で測り、Core Web VitalsとGoogle公式の文書で確かめた【2026年】

WordPress の記事に、スマホで撮ったような大きな写真を1枚。そのまま貼ったら、表示にどれだけかかるでしょうか。

私たちは、手元の WordPress に 4000×3000・4.3MB の写真を入れ、遅い回線のスマホの条件で、実際に測りました。写真をそのまま貼った記事は、写真が出るまで22.0秒かかりました。同じ写真をエディターの画像ブロックで入れると、1.3秒でした。

講座の【完全版】WordPressのSEO・AIO・LLMO対策、何をすればいい？の「つなぐ・速くする」の章（8章）では、表示の速さの目安（Core Web Vitals）を紹介しました。この回は、表示の速さを、手元で実際に測ります。重いと検索で不利になるのかも、Google の文書で確かめます。

先に結論を書きます。

• Google は、Core Web Vitals をランキングで考慮しています。ただし、良い数字でも上位は保証されません。 「Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」と書いています
• 4.3MB の写真をそのまま貼ると、写真が出るまで22.0秒でした。 手元の WordPress 7.1.4 で、回線 1.6 Mbps・往復 150ms・CPU を4倍遅くしたスマホの条件で、3回とも22.0秒です
• 同じ写真をエディターの画像ブロックで入れると、1.3秒でした。 WordPress が自動で作った縮小版（768×576・33KB）を、ブラウザが選びました。WebP にすると17KB・1.1秒でした
• 自分たちのサイト sorabun.com も測ると、トップは中央値2.8秒で、目安の2.5秒を超えていました。 3回の数字は4.4秒・2.8秒・2.5秒と、測るたびに揺れました
• この記事の数字は、決まった条件で測ったラボの数字です。 実際に見に来た人の数字（フィールドデータ）とは違います。Search Console の Core Web Vitals レポートに出るのは、実際の人の過去28日間の数字です

まずは、あなたのサイトの記事を PageSpeed Insights のスマホで測り、写真がエディターの画像ブロックで入っているかを確かめてください（10章）。

1. Google は、Core Web Vitals をランキングで考慮する

まず、Google の説明です。

Google は、Core Web Vitals を「Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。」と説明しています。読み込みの速さ、押したときの反応の速さ、画面が動かずに読めるか、の3つを、実際に使う人の体験で測るものです。

そして「Core Web Vitals は、その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素です。」と書いています。その前の文では「検索結果でのランキングを上げ、全般的に優れたユーザー エクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。」としています。

3つの目安: 2.5 秒・200 ミリ秒・0.1

目安は3つです。

Google 検索セントラルは、LCP は「ページの読み込み開始から 2.5 秒以内に LCP を実現するようにします。」、INP は「INP を 200 ミリ秒未満に収めるようにします。」、CLS は「CLS スコアを 0.1 未満に収めるようにします。」と書いています。

LCP で言う、いちばん大きな部分とは何でしょうか。web.dev は「LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間を、ユーザーが最初にページに移動したタイミングと比較する形で確認できます。」と説明しています。ビューポートは、画面に見えている範囲のことです。この記事の試験でも、LCP になったのは、記事の中の写真でした。

なお、同じ目安でも、書き方が少し違う文書があります。web.dev の「Web Vitals」は INP を200ミリ秒以下・CLS を0.1以下とし、Search Console ヘルプの表は「良好」を2.5秒以下・200ミリ秒以下・0.1以下としています。この記事は、Google 検索セントラルの書き方（2.5 秒以内・200 ミリ秒未満・0.1 未満）に合わせます。

ただし、良い数字でも上位は保証されない

ただし、Google は、こうも書いています。「Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」

続けて「優れたページ エクスペリエンスには Core Web Vitals スコア以外の要素もあります。」「このスコアは、サイトの全体的なユーザー エクスペリエンスの改善に役立てるためのものなので、SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。」とあります。

同じページのよくある質問には、ページ エクスペリエンスがどのくらい大事かへの答えもあります。「Google 検索は、ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています。」「ただし多くの場合、検索語句に一致するヘルプフル コンテンツが多数存在するため、その中で検索結果でのランキングを上げるには、優れたページ エクスペリエンスを実現していることが重要になります。」

つまり、表示速度は大事な要素の1つですが、中身の代わりにはなりません。何を書くか、誰が書いたかが先にあります。書いた人の情報は、講座の第4回WordPressの書いた人が「admin」のまま？で、初期の WordPress を使って確かめました。

この記事では、速くすれば順位が上がる、とは言いません。ただ、写真が出るまで20秒以上かかるページを、読む人が待ってくれるとは限りません。検索のためだけでなく、読む人のために速くする、と考えます。

2. 手元の WordPress に、写真を3通りで入れて測った

では、写真1枚で、どこまで遅くなるのか。手元で測りました。

試し方

• サイト: 公式の zip で入れた WordPress 7.1.4（日本語版）を、手元の PHP 8.3 の簡易サーバーで動かした。テーマは初期の Twenty Twenty-Five
• 写真: 4000×3000・約4.3MB の JPEG。スマホやカメラで撮った写真くらいの大きさにした。中身は Python で作った試験用の絵（空と木のような丸い形に、細かな粒を散らしたもの）で、実在の写真ではない
• 入れ方: WordPress のメディアの取り込みと同じ関数で写真を取り込み、記事を3つ作った。①元の写真の URL を、HTML のブロックで直接貼った（幅と高さは書いた）②エディターの画像ブロックで入れた（大きさは、エディターで入れたときの初めの large）③同じ写真を、WordPress の画像の出力形式を JPEG から WebP に変えて取り込み、画像ブロックで入れた
• 測り方: Playwright と Chrome DevTools Protocol で、スマホの画面（412×823・画素の細かさ1.75倍）・回線 1.6 Mbps・往復 150ms・CPU 4倍遅く・キャッシュなし、の条件で開き、LCP と CLS と読み込んだ量を取った。3回ずつ測り、中央値をとった
• 片付け: 試したあと、試験用の記事と画像（縮小版も）は消した

条件は、Google の測る道具 Lighthouse の、スマホの初期の条件に近づけました。PageSpeed Insights のラボの数字も、この道具で出しています。PageSpeed Insights の説明には「PSI は Lighthouse を使用して、指定された URL をシミュレーションで分析します。」とあります。

ただし、PageSpeed Insights の API は、この作業の環境で使える回数の上限に達していて使えませんでした。そこで、同じ条件に近づけて、自分たちで測りました。PageSpeed Insights で測った数字と、同じではありません。

写真が出るまで、何秒？

ここでクイズです。スマホやカメラで撮ったくらいの、4.3MB の写真を、記事にそのまま貼りました。遅い回線のスマホで開くと、写真が出るまで、何秒かかるでしょうか。

• 2秒
• 8秒
• 22秒

3. 答えは22秒。写真は上から少しずつ

答えは、22秒でした。

ブラウザが画面を描いた時刻つきで画面を撮ると、見出しと文は先に出て、写真の場所は白いままでした。写真は、上から少しずつ描かれていきます。10秒の画面でも、写真の高さの42%で、まだ半分以下。写真が全部出て LCP が記録されたのは、22.0秒でした。3回測って、3回とも22.0秒です（写真の割合は、画面の行ごとに写真が描かれているかを数えたもの。shots/cards.py）。

見出しと文は先に読めても、いちばん大きな写真が出るまでは、LCP は決まりません。目安の2.5秒の、9倍近くです。

4. 同じ写真、入れ方で22秒 → 1.3秒

同じ写真を、3通りで入れて比べました。

画像の量は、ファイルの大きさです（1KB は1024バイト）。ページ全体の量は、ブラウザが実際に受け取った量で、HTML や CSS など、写真のほかに読み込んだものも入っています。

画面のずれ（CLS）は、どの入れ方でも0.001と、ほぼ0でした。元の写真の記事でも、HTML に幅と高さを書いておいたので、写真が届く前に場所が空いていました。違ったのは、読み込む量と、写真が出るまでの時間です。

エディターで入れると、1秒台で出た

エディターで入れた記事は、0.5秒の時点ではまだ真っ白でした。1.0秒で写真が上から出始め、1.5秒の画面では全部出ていました。WebP の記事は、1.0秒の画面で、もう写真が全部出ていました。

画面は、ブラウザが描いた時刻つきで撮ったもので、ある時刻の画面は、その時刻までに描かれた最後の画面です（Chrome DevTools Protocol の Page.startScreencast。LCP を測った3回とは別に、1回ずつ撮りました）。どちらにしても、1秒台で写真まで出ました。

同じ写真なのに、なぜ、ここまで違うのでしょうか。

5. WordPress は、大きさ違いを自動で作る

答えは、WordPress が自動でやっていることにあります。

写真を取り込むと、WordPress は、150×150 の四角から 2048×1536 まで、大きさ違いの縮小版を6つ作りました。元の写真（4000×3000）が大きすぎたので、2560×1920 に縮めた版（ファイル名の後ろに -scaled が付く）も作りました。

そして、記事では、画面に合う大きさを、ブラウザが選びます。幅412のスマホの画面（画素の細かさ1.75倍）では、768×576 の版が選ばれました。4000×3000 の元の写真の、およそ5分の1の幅です。

WordPress が自動で書いた img

エディターで入れた写真を、記事のページの HTML で見ると、WordPress は、次のように書いていました（.../ は、手元の WordPress の画像の置き場所 /wp-content/uploads/2026/10/ までを縮めたもの。改行は、見やすくするために入れました）。

<img fetchpriority="high" decoding="async" width="1024" height="768"
  src=".../speed-test-photo-1024x768.jpg" alt="試験用の写真" class="wp-image-158"
  srcset=".../speed-test-photo-1024x768.jpg 1024w,
          .../speed-test-photo-300x225.jpg 300w,
          .../speed-test-photo-768x576.jpg 768w,
          .../speed-test-photo-1536x1152.jpg 1536w,
          .../speed-test-photo-2048x1536.jpg 2048w"
  sizes="(max-width: 1024px) 100vw, 1024px" />

書いた覚えのないものが、いくつも並んでいます。

src に書かれているのは 1024×768 の版ですが、スマホのブラウザは srcset の一覧から 768×576 の版を選んで読み込みました。

幅と高さが書いてあるので、写真が出る前に場所が空き、読んでいる途中で画面がずれません。web.dev は、画面がずれる原因として「レイアウトのずれの原因としては、サイズが不明な画像や動画、初期のフォールバックよりも大きくまたは小さくレンダリングされるフォント、サイズを動的に変更するサードパーティの広告やウィジェットなどがあります。」と挙げています。

この写真には、先に読むように、という印（fetchpriority="high"）も付いていました。どれも、エディターで写真を入れただけで、WordPress が自動で書いたものです。

6. 数えると、1.3秒・33KB・17KB

数えると、こうなりました。

エディターで入れると、LCP は元のままの、およそ17分の1。読み込んだ写真は、およそ130分の1でした。WebP にすると、同じ 768×576 の版で17KB。JPEG の33KB の約半分になり、LCP は1.1秒でした。

WebP は、いつも小さいとは限らない

ただし、2048×1536 の版では、WebP（361KB）のほうが、JPEG（346KB）より少し大きくなりました。ほかの5つの大きさでは WebP のほうが小さく、この大きさだけ逆でした。

今回の写真は試験用の絵なので、写真によって結果は変わります。WebP にすれば必ず小さくなる、とは言えません。

それに、22秒を1秒台にしたのは、WebP ではなく縮小版でした。JPEG のままでも、エディターで入れれば1.3秒です。WebP は、そのあとの、もう一段です。

7. 元の写真が遅いのは、なぜ？

元の写真が遅いのは、画面に出る大きさに比べて、写真が大きすぎるからです。

• 元の写真は、4000×3000・4.3MB。 スマホやカメラで撮った写真くらいの大きさです
• スマホの画面には、幅352px で出るだけ。 試験の記事の写真は、画面の上で幅352px（画素の細かさ1.75倍で、約616画素ぶん）でした
• HTML で直接貼ると、縮小版が使われない。 元の写真の URL を書くと、ブラウザは、その1枚を丸ごと読み込みます

WordPress は、取り込んだ元の写真も、そのままサーバーに残しています。その URL を HTML で直接書いたり、元の大きさの画像のアドレスを貼ったりすると、WordPress の縮小版の仕組み（srcset）は使われません。幅352px で出すために、4000×3000 の写真をまるごと読み込むことになります。

逆に言えば、今回の条件では、WordPress の標準のやり方（エディターの画像ブロック）で入れるだけで、写真の大きさの問題は避けられました。

ただし、テーマやプラグインによって、写真の出し方は変わります。あなたのサイトでは、記事の写真を1枚選び、ページのソースで、その img に srcset と width・height が付いているかを確かめてください。

8. 自分たちのサイトも、同じ条件で測った

では、自分たちのサイトはどうか。sorabun.com の3ページを、同じ条件で、3回ずつ測りました。

無料のサイト診断のページは0.9秒、コラムの記事は1.9秒でした。トップは、中央値で2.8秒と、目安の2.5秒を超えていました。3回の数字は4.4秒・2.8秒・2.5秒。表では2.5秒と書いた回も、2,532ミリ秒で、わずかに2.5秒を超えています。

CLS は、3ページとも0.1未満でした。無料のサイト診断の0.08は、目安に近い数字です。

この数字は、この作業の環境から、プロキシ（あいだに入る中継のサーバー）を通して測ったものです。実際に見に来た人の回線や端末とは違います。

自分たちのサイトで分かったこと

分かったことは3つです。

• トップは、目安の2.5秒を超えた。 LCP になったのは、いちばん上の画像（WebP）でした
• どのページも、文字（フォント）のデータを約119KB 読み込んでいた。 Google Fonts の文字のデータです。無料のサイト診断のページでは、読み込んだ量137KB のうち、119KB が文字のデータでした
• 測るたびに、数字は揺れる。 同じトップのページで、4.4秒から2.5秒まで揺れました。1回の数字で決めず、何回か測るか、実際に見に来た人の数字を見ます

トップの画像や文字の読み込み方は、これから見直す候補です。

9. ラボの数字と、実際の人の数字は違う

ここまでの数字は、どんな数字なのでしょうか。

PageSpeed Insights の説明には「PSI では、ページのラボデータとフィールド データを確認できます。」とあります。

ラボデータについては「ラボデータは、制御された環境で収集されるため、問題のデバッグに役立ちます。」「ただし、実際のボトルネックを捕らえていないおそれがあります。」。フィールドデータについては「フィールド データは実際のユーザー エクスペリエンスをそのまま把握するのに役立ちますが、使用できる指標セットが限られます。」と書いています。

よくある質問でも「ラボデータは、一連の固定されたネットワーク条件で 1 台の端末でページ読み込みをシミュレートしたデータです。」と説明しています。

今回の私たちの数字も、このラボの数字です。回線 1.6 Mbps・往復 150ms・CPU 4倍遅く・画面 412×823 に絞った条件で測りました。実際に見に来る人には、もっと速い回線の人も、もっと遅い端末の人もいます。22秒という数字も、この遅めの条件での数字です。

web.dev も「ラボでの測定は優れたエクスペリエンスを提供するために不可欠ですが、フィールドでの測定の代わりにはなりません。」「全体像を正確に把握できるのは、フィールドでの測定だけです。」と書いています。

なお、INP は、実際に押したり触ったりした操作への反応を測るものです。今回のように、開いて待つだけの測り方では、測っていません。web.dev の「Web Vitals」の表でも、ラボの道具の Lighthouse は、INP の代わりに TBT という別の数字を使う、とされています。

Search Console は、実際の人の28日間

フィールドデータは、どこで見るか。Search Console の Core Web Vitals レポートです。

Search Console ヘルプは「Core Web Vitals では、実際の使用状況データ（フィールド データとも呼ばれます）に基づくページのパフォーマンスを確認できます。」と書いています。

• 過去28日間の、75% の読み込みの数字。 たとえば LCP は「過去 28 日間の 75% のページ リクエストにおいて、Largest Contentful Paint（最大テキスト ブロックまたは画像のレンダリング）にかかった最大時間です。」
• URL を3つに分ける。 「低速」「改善が必要」「良好」です。似たページは、まとめて（URL グループとして）出ます
• インデックスに登録されている URL だけ。 「このレポートに表示されるのはインデックスに登録されている URL のみです。」

見に来る人が少ないサイトでは、データが出ないことがあります。Search Console ヘルプは、「データがありません」と出るのは、プロパティがまだ新しいか、CrUX レポート（Chrome の実際の利用者から集めたデータ）で使えるデータが足りないときだ、と説明しています。そのときは、PageSpeed Insights のラボの数字で、大きな問題が無いかを確かめます。

直したあとも、レポートの数字は、すぐには変わりません。直したことを確かめる手続きも、28日間かけて見ます。「[トラッキングを開始] をクリックすると、28 日間のモニタリング セッションが開始され、サイトでこの問題が実際に発生するかどうかをチェックできます。」

記事が検索に出ていない（インデックスに登録されていない）ときは、このレポートにも出てきません。検索に出ない原因の確かめ方は、講座の第1回WordPressが検索に出ない原因、手元で14通り試したら7つで試しました。

10. 今日やること（5つ）

1. 写真は、エディターの画像ブロックで入れる。 WordPress が縮小版を作り、画面に合う大きさをブラウザが選びます。幅と高さも、自動で書かれます
2. 元の写真の URL を、HTML で直接貼らない。 4000×3000 の写真を、スマホの幅352px のために丸ごと読み込むことになります。すでに貼ってある記事は、画像ブロックで入れ直します
3. 写真は WebP で入れる。 WordPress は WebP の画像も扱えます。今回は 768×576 の版で、33KB が17KB になりました。ただし、大きい版では JPEG より大きくなることもありました
4. PageSpeed Insights で、スマホを測る。 パソコンではなく、スマホの数字を見ます。数字は揺れるので、1回で決めず、何回か測ります
5. Search Console の Core Web Vitals レポートで、「低速」の URL が無いかを見る。 実際に見に来た人の、過去28日間の数字です。データが出ないときは、PageSpeed Insights のラボの数字で確かめます

画像に幅と高さが書かれているかは、URL を入れるだけの無料のサイト診断（45項目）でも確かめられます。点数は目安として、直すきっかけにしてください。

Sorabun で書く記事なら

Sorabun の「表示速度」の画面では、Google の PageSpeed Insights で、スマホで開いたときの速さを記事ごとに測り、点数の低い順（遅い順）に並べます。点数・LCP・CLS が出て、実際の読者のデータ（フィールドデータ）がある記事は、その数字を優先して出します。INP は、実際の読者のデータがある記事だけに出ます。記事ごとに、主な原因と、できることも並びます。毎日5記事ずつ自動で測る設定もあります（初めはオフ）。

最初の画像を速く出す設定もあります。記事のページでは、アイキャッチを最優先で読ませます（fetchpriority="high"。初めからオン。テーマがアイキャッチを WordPress の標準の関数で出しているときに効きます）。大きさの書かれていない本文の画像に、幅と高さを書く設定もあります（初めはオフ）。

そして、Sorabun が作るアイキャッチや図解は、WebP にして保存します（幅が1600px を超えるときは、1600px に縮めます）。サーバーが WebP を書けないときや、WebP にするとかえって大きくなるときは、元の形式のまま保存します。前からある JPEG・PNG の画像に WebP の複製を作り、表示のときに差し替える設定もあります（初めはオフ。元の画像はそのまま残します）。

よくある質問

まとめ

• Core Web Vitals は、Google のランキングで考慮される。ただし、良い数字でも上位の保証ではない
• 元の写真（4.3MB）をそのまま貼ると、遅いスマホの条件で、写真が出るまで22.0秒
• エディターの画像ブロックで入れれば、WordPress が縮小版を作ってブラウザが選び、1.3秒
• WebP で、768×576 の版は約半分（33KB → 17KB）。ただし、大きい版では逆のこともある
• スマホで測る。数字は揺れるので、1回で決めない。ラボの数字と、実際の人の数字（Search Console・過去28日間）を分けて見る

出典（2026年10月31日に確認）

測った結果は、2026年10月31日（日本時間）に、手元の WordPress 7.1.4（初期のテーマ Twenty Twenty-Five）と sorabun.com で、私たちが測ったものです（コンテンツ/page-speed-2026/shots/speed_test.mjs・strip_test.mjs・site_speed.mjs、結果は shots/data/speed-test.json・strip.json・site-speed.json・srcset-example.html）。試験用の写真は Python で作った絵で、実在の写真ではありません。試したあと、試験用の記事と画像は消しました。数字は決まった条件で測ったラボの数字で、実際に見に来た人の数字（フィールドデータ）とは違います。web.dev と「PageSpeed Insights について」の日本語は、Google が AI で翻訳したものです。

• Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」（最終更新 2025年12月18日） https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja
• Google 検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」（最終更新 2026年9月25日） https://developers.google.com/search/docs/appearance/page-experience?hl=ja
• Google「PageSpeed Insights について」（最終更新 2025年7月25日） https://developers.google.com/speed/docs/insights/v5/about?hl=ja
• Search Console ヘルプ「Core Web Vitals レポート」 https://support.google.com/webmasters/answer/9205520?hl=ja
• web.dev「Web Vitals」（最終更新 2024年10月31日） https://web.dev/articles/vitals?hl=ja
• web.dev「Largest Contentful Paint（LCP）」（最終更新 2025年3月20日） https://web.dev/articles/lcp?hl=ja
• web.dev「Cumulative Layout Shift（CLS）」（最終更新 2023年4月12日） https://web.dev/articles/cls?hl=ja

関連するコラム

SEO・AI検索2026年10月28日 【完全版】WordPressのSEO・AIO・LLMO対策、何をすればいい？ Google公式の文書と実験で全部確かめた【2026年】 WordPressのSEO・AIO・LLMO対策を、Google公式の文書と実験で全部確かめた完全版。AIに引用される特別な対策は要らない（Google）。初期設定のチェック1つでサイトマップが消える実験、何も入れていないWordPressに足りない10項目、FAQの表示の終了、llms.txt、E-E-A-T、構造化データ、AI検索に出たかの測り方、今日やること10個まで。 SEO・AI検索2026年10月30日 【今すぐ見直す】WordPressが検索に出ない原因、手元で14通り試したら7つ。パーマリンクを変えると古いURLは404？ Search Consoleの理由とGoogle公式で確かめた【2026年】 手元のWordPress 7.1.4で、検索に出なくなる原因を14通り起こした。下書き・非公開・ゴミ箱は404、パーマリンクの形を変えると古いURLも404、メンテナンス中は503。Search Consoleの理由15種類との対応、自動でやる正常なこと4つ、今日やる確かめ方5つまで。 SEO・AI検索2026年10月30日 【実際に試した】WordPressの書いた人が「admin」のまま？ E-E-A-Tの「誰が」を初期のWordPressで確かめたら、略歴はどこにも出なかった。Google公式の書き方【2026年】 手元のWordPress 7.1.4（初期のテーマ）では、書いた人の名前はadmin、略歴はどこにも出ず、構造化データは0個。表示名・投稿者の略歴ブロック・運営者情報など5つ足してGoogleの「誰が」の3つの問いに答えた手順と、構造化データの著者の書き方、署名欄にAIと書かない理由。

コラムの一覧へ