WordPressの表示速度改善｜スマホ61点から99点になった自社サイトの対策と確認

WordPressの表示速度は、原因を調べ、必要な見た目と機能を守って改善します。自社トップではスマホ61点から99点へ。同じ最終版の再測定は94点でした。まずは遅いURLと端末を記録し、設定変更に不安があれば、その段階からご相談いただけます。

WordPressの表示速度改善は、測定と原因の切り分けから

最初にすることは、高速化の設定を増やすことではなく、遅いページと待たされる場面を記録することです。表示されるまで遅いのか、ボタンを押した後が遅いのかで、調べる場所が変わります。

「WordPressだから仕方がない」「サーバーを変えれば全部解決する」とは限りません。WordPress公式の最適化の案内でも、画像やソフトウェアの構成、サーバーなど複数の要因が挙げられています。まず次の順序で、改善の入口を絞ってみてください。

1. 遅いURLと端末を記録する
   トップページ、記事、予約ページなどのURLと、「スマホで初めて開くと遅い」といった状況を書きます。同じサイトでもページによって負荷は違います。
2. PageSpeed Insightsで今の結果を保存する
   スマホとPCを分け、日時とレポートURLを残します。点数だけでなく、主要な内容が出るまでの時間や診断項目も見ます。
3. 変える前に、戻せる準備と確認対象を決める
   設定変更はバックアップと戻す手順を確認してから進めます。メニュー、フォーム、会員ページなど、止められない機能も整理します。
4. 原因に合う対策を一つずつ試す
   同じページ・測定方法で前後を比べ、画像、文字、ボタン、必要な動作が保たれていれば次へ進みます。不具合が出た場合は変更を戻して切り分けます。

自分でできる最初の一歩は、URLを測って結果を保存するところまででも十分です。細かい指標が読めなくても、「どのページで、いつ、何を待つか」が分かれば、調査の手掛かりになります。

自社サイトの改善事例：スマホ61点から99点へ

TAKUMI Web Worksの公開トップページでは、改善前のスマホ61点に対し、改善後に99点を確認しました。同じ最終版の再測定では94点となり、2026年10月26日朝の測定画像ではスマホ99点・PC98点でした。

これは、お客様のサイトの実績ではなく、自社サイトで行った改善事例です。対象はTAKUMI Web Worksのトップページであり、記事や会員ページを含むサイト全体の点数ではありません。

10月26日朝の測定画面：スマホ99点・PC98点

次の2枚は、2026年10月26日10時01分43秒と表示されたレポートのスクリーンショットです。生成した点数画面ではなく、実際の測定画面を載せています。

画像は左右に動かせます。細部は下のリンクから拡大できます。

画像は左右に動かせます。細部は下のリンクから拡大できます。

朝のスマホ画面は、パフォーマンス99・ユーザー補助96・おすすめの方法100・SEO92です。PC画面は、それぞれ98・100・100・92。「99点」はパフォーマンスの項目で、すべての項目が満点という意味ではありません。SEOの点数も、検索順位そのものを示す数字ではありません。

深夜の詳細測定：LCPは8.1秒から2.0秒、再測定2.6秒

改善前後の時間を比較できるのは、次の深夜の記録です。LCPとは、画面内で最も大きな画像や文章のかたまりが表示されるまでの時間です。ページのすべての処理が終わる時間とは区別します。

改善前はテーマ2.0.56、最終版は2.0.64です。深夜のGoogle測定はLighthouse 13.5.0を使い、スマホのMoto G Power・低速4G・初回読み込みを再現した模擬環境でした。PCの最終版は98点、FCP0.8秒・LCP1.1秒です。これらの細かい指標は、朝の画像と同じ測定回の値ではありません。

改善前61点のレポート、改善後99点のレポート、同じ最終版94点の再測定を確認用に残しています。画面表示が変わる場合に備え、日時と元の記録も保管しています。

同じサイトでも点数が変わる。その違いも隠さない

最終版は深夜の測定で94〜99点でした。途中の調整では数値が下がった回もあり、設定を変えるたびに改善が一直線に進んだわけではありません。複数の対策を組み合わせた結果なので、「画像だけで何点上がった」と単独の効果も切り出せません。

また、CLSは改善前0から最終版0.007となっています。これは全指標が一律に良くなったという記録ではありません。点数と時間だけで判断せず、表示の安定や必要な動作を一緒に確認しました。

デザインを保ちながら、実際に行った5つの対策

今回の中心は、必要な見た目と機能を残したまま、ブラウザーが読み込んで表示する順序と量を整理することでした。トップページの画像を一律になくしたり、測定時だけ内容を隠したりする方法は使っていません。

最初に見える部分の表示用ファイルを整理した

ページの色や配置を決めるファイルをCSSと呼びます。今回のトップでは38ファイルを読み込んでいたため、既存の順序を保った4グループへ整理しました。さらに、ページの冒頭を表示するために必要なものを先に用意しています。

ただし、ファイル数を減らすこと自体が目的ではありません。順番を変えると色や配置が崩れることがあるため、必要な表示の規則を残して照合しました。GoogleのLCP改善の解説も、画像などを受け取る時間だけでなく、それを画面に出すまでの待ちを分けて調べる考え方を示しています。

表示サイズに合う軽い画像を用意した

冒頭の見本画像は15ジャンルあり、表示幅に合わせた軽量画像を計30点追加しました。大きな元画像は、拡大して見るときのために残しています。「一覧で見る大きさ」と「細部まで拡大する大きさ」を分けた形です。

写真を小さくしすぎて、制作物の雰囲気が分からなくなっては意味がありません。スマホでの切り抜きや、画像を切り替えたときの表示も確認しています。画質と読み込み量の両方を見て、必要な大きさを選びました。

書体を軽くし、文字の形と幅を確かめた

見出しや本文に使う書体も、表示を待たせる要因になります。今回は、使う文字や表示箇所に合わせて書体のファイルを軽量化・共通化しました。デザイン上の書体を別物へ置き換えた、という対応ではありません。

文字の形だけでなく、文字幅、太さの変化、数字の幅も元と照合しています。幅が変わると、見出しの改行やボタンの収まりに影響するためです。日本語の文字抜けや、急に別の字体へ変わることも避ける必要があります。

ページ下部の描画負荷を調整した

長いトップページでは、まだ見えていない下方の領域まで、最初から描画に時間を使う場合があります。そこで、ブラウザーが画面を描く負担を調整しました。下にある説明や操作を削除したわけではありません。

このような調整では、スクロールした先に必要な内容が出るか、画像の拡大や枠内スクロールが使えるかも確認対象になります。「最初だけ速いけれど、後半は読めない」という状態にしないことが大切です。

既存のアクセス解析が動き始める時期を調整した

アクセス解析の処理は、最初の表示を妨げにくいよう、実行を遅らせました。送信先や送信内容、既存の処理そのものは変えていません。ただし、この作業で実際の問い合わせ増加や解析値の完全一致を確認した、という意味ではありません。

解析、広告、予約などの外部機能は、読み込みを遅らせれば何でもよいわけではありません。計測したい行動や、その場ですぐ必要な操作を整理し、遅らせてよいものを選ぶ必要があります。

WordPressが重い原因を、症状別に見分ける

「重い」を、画面の表示待ち、押した後の反応待ち、管理画面の遅さに分けると、確認先を絞りやすくなります。症状だけで原因を決めつけず、測定や操作で確かめることが前提です。

画像は左右に動かせます。細部は下のリンクから拡大できます。

スマホだけ遅いなら、画面が小さいから軽いとは考えない

スマホ用の見た目でも、裏ではPCと同じ大きな画像や処理を読み込んでいることがあります。今回も、スマホで表示する画像の大きさと、最初に必要な読み込みを見直しました。画面幅だけでなく、通信量と端末が行う処理を見ることが大切です。

「PCでは気にならないが、スマホで最初に開くと待つ」という情報は、そのまま役立ちます。スマホとPCの点数の差だけをそろえるのではなく、実際に困る場面を再現して調べます。

WordPressの管理画面が重い原因は、公開ページと分ける

公開ページの写真を軽くしても、記事の保存や管理画面の一覧が速くなるとは限りません。管理画面には、データの検索や保存、プラグインの管理処理など別の負荷があります。

今回紹介する対策は公開トップ向けで、管理画面を高速化した事例ではありません。管理画面の遅さも相談できますが、対象の操作、発生時刻、直前の更新を確認して、別に原因を調べます。

初回アクセスが遅いときは、2回目だけで良否を決めない

一度受け取ったデータを再利用する仕組みがキャッシュです。2回目はその恩恵を受けて速くなる場合がありますが、初めて訪れた人の待ち時間も大切です。初回と再訪を混ぜて比較せず、どちらの結果かを記録してください。

急に遅くなった場合は、画像の追加、プラグイン更新、外部サービスの導入など、直前に変わったものをメモします。原因が分かる前に更新を取り消したり、データを消したりせず、変化を絞る材料に使います。

WordPressの速度計測：PageSpeed Insightsの見方

PageSpeed Insightsでは、パフォーマンスの点数、原因を探す診断、実際の利用者のデータを分けて読みます。今回の99点は、一定の条件を再現して調べた結果であり、実利用者全体の評価ではありません。

測定するときに残すのは、点数だけでなくURLと条件

PageSpeed Insightsを開き、調べたい公開ページのURLを入れて分析します。スマホとPCの切り替えを確認し、日時、レポートURL、画面の点数と指標を保存してください。ログインが必要な非公開ページや管理画面を、そのまま外部の測定サービスへ渡すことは避けます。

比較する対象は、同じページ・同じ端末区分にそろえます。トップと記事、スマホとPC、初回と再訪を混ぜると、変更の前後が読み取りにくくなります。僕なら1回の最高点で終わらせず、再測定でどのくらい変動するかも確認します。

Googleの点数の公式解説では、90〜100は良好の区分です。ただし、90点以上なら操作も含めてすべて問題なし、89点ならサイトが使えない、といった合否の線ではありません。

LCP・INP・CLSは、何を確かめる数字か

よく出てくる3つの指標は、次の意味で捉えると分かりやすくなります。基準はGoogleのWeb Vitalsの案内に基づきます。

この良好の目安は、実利用者のデータではスマホとPCを分け、75パーセンタイルの値で判断します。「少なくとも75%の体験が目安に収まるか」を見る考え方です。単発のラボ測定1回で、実利用者のCore Web Vitalsがすべて合格したとは言えません。

FCPは最初の文字や画像などが出るまでの時間、TBTは読み込み中に長い処理で操作を妨げた時間を見る指標です。特に、TBTが0ミリ秒だからINPも0、すべての操作が快適、と読み替えないでください。ボタンを押す、検索する、といった実際の流れも確かめます。

「実際のユーザーのデータがない」と出た場合

データがない表示は、そのページやサイトで公開できるだけの実利用者サンプルが集まっていない場合などに出ます。アクセスがゼロ、サイトに問題がある、計測が失敗した、と一律には判断できません。

GoogleのPageSpeed Insightsの説明では、実利用者の情報と、原因調査に使える模擬測定を区別しています。実利用者データがない段階でも、診断結果と実際の操作をもとに改善を始められます。十分なデータがある場合は、その傾向も合わせて判断します。

高速化プラグインやサーバー変更の前に守ること

高速化プラグインを追加したり、サーバーを変えたりする前に、現在の対策と、壊してはいけない動作を整理します。速くなったかだけでなく、必要な見た目・操作・情報の扱いが保たれたかまでを確認対象にします。

画像は左右に動かせます。細部は下のリンクから拡大できます。

すでにある高速化と重ねない

サーバー、テーマ、プラグインのそれぞれに、キャッシュや画像の遅延読み込みが備わっている場合があります。何が有効かを調べず同じ処理を重ねると、どの設定が効いているか分かりにくくなります。まず既存の役割と対象ページを確認します。

キャッシュは便利ですが、利用者ごとに内容が違う会員ページや、予約状況などを同じ扱いにはできません。個別の情報を共有キャッシュへ保存すると、別の人に見える危険があります。MDNのキャッシュ解説でも、個人向けの内容と共有キャッシュの区別が説明されています。速度のために公開範囲を広げないことが前提です。

「全部遅らせる」「全部削る」を避ける

画面の下にある画像の読み込みを後に回す方法は役立ちますが、最初に見せたい大きな画像まで遅らせると、かえって表示を待つ原因になります。Googleの画像の遅延読み込みの案内も、この区別を示しています。

ボタンやフォームを動かす処理を一律に遅らせる、必要な画像まで消す、といった変更も慎重に判断します。点数が上がっても、予約を進められない、問い合わせ先へ行けない状態では、使いやすさを改善したことにはなりません。

今回の自社サイトで確認したこと、まだ試していないこと

今回の速度改善では、公開画面の320・390・768・1440px幅で横はみ出しがないこと、共通メニューと相談フォームを開けること、サービス・料金・FAQへの移動を確認しました。制作事例の画像拡大や、PCとスマホの見本を表示する枠のスクロールも確認しています。

一方で、実機のiPhone・Safari、実際の相談送信とメール到達、契約の一連の操作は、この改修では試験していません。確認済みの画面操作と、これらの未試験範囲を分けて記録しています。「全端末、全機能を確認済み」とは案内しません。

個別のご依頼では、サイトの用途に合わせて必要な試験を決めます。フォーム送信や予約・決済を試す場合は、宛先やテスト環境、実際の送信・課金が起きない方法を先に確認します。

変更前に、戻し方まで決めておく

設定やコードを触る前に、対象ファイルとデータの保全、検証場所、問題が出たときの戻し方を決めます。変更前後の測定と動作を残せば、「どこまで進めると問題が出たか」を追いやすくなります。

途中で表示が崩れた、フォームが開かなくなった場合は、そのまま別の設定を重ねず、直前の変更へ戻して確認します。セキュリティ対策やアクセス制限を外して点数を上げる方法は選びません。

記事や制作事例を増やした後も、速度を保つには

追加する画像や機能の重さを確認し、更新後にも代表ページを測ることが大切です。一度の最適化で、将来も同じ点数が続くとは約束できません。

今回の対策は、一時的にキャッシュが温まった状態だけを狙ったものではなく、読み込み方、画像、書体を見直すものです。通常の制作事例追加で最適化が解除される設計にはしていません。一覧を12件ごとに分けることや、下方の画像を後から読むことでも、負荷が増えにくいようにしています。

それでも、大きな画像や動画、外部ツールを追加すれば、そのページで受け取るデータや処理は増えます。記事本文に測定画像や図解をたくさん載せる場合も同じです。画像の寸法と容量、最初に見せる必要があるかを確認してから追加します。

テーマやプラグインの更新後は、適用状態も確かめる

今回の最適化は、確認済みのファイル構成を対象にしています。構成が変わったときには、表示崩れを避けるため、一部が通常の読み込み方へ戻る場合があります。そのときは、新しい構成を確認し、必要に応じて最適化用ファイルの作り直しや再調整を行います。

これは、将来の変更へ完全自動で追いつき、永久に同じ点数を保つ仕組みではありません。安全に通常表示へ戻ることと、高速化が続いていることは別なので、更新後に画面と測定結果を確認します。

• 画像を追加したら、実際に使う大きさと容量を確認する。
• 外部機能を追加したら、必要なページと動き始める時期を確認する。
• テーマやプラグインを更新したら、代表ページと主要操作を確かめる。
• 以前の結果と違ったら、日時・変更内容・測定結果をそろえて原因を調べる。

自動監視や継続保守が今回の改善に含まれている、という案内ではありません。ご依頼時に、作業後の報告、再確認が必要になる変更、公開後に対応する範囲を決めておくと、運営を続けやすくなります。

表示速度改善でよくある質問

表示が遅いサイトの改善を相談するときは

初回は、サイトのURLと「どの場面が遅いか」を教えていただければ、相談を始められます。専門用語で原因を説明したり、改善方法を決めてから依頼したりする必要はありません。

「スマホでトップを開くと写真が出るまで待つ」「記事は読めるが、メニューが反応するまで遅い」「高速化を試したら表示が崩れた」といった伝え方で大丈夫です。結果があれば、PageSpeed Insightsの画面やレポートURLも参考になります。

お見積もりでは、調査と作業、確認の範囲をそろえる

画像の調整が中心なのか、テーマの読み込み処理まで直すのか、会員機能やサーバー側の調査も必要かで、作業範囲は変わります。調べるページ、変更する場所、動作確認、問題が出たときの戻し方、作業後の報告をそろえて検討します。

費用や納期は、サイトの状態とご希望を確認してからご案内します。「どのサイトでも何点まで上げる」「一定の料金で全部直す」というお約束はしていません。調査で分かること、追加の確認が必要なこと、今回は対応しない範囲も分けてお伝えします。

ご希望の予算や上限を添えていただければ、希望内容の全体がその範囲で可能か、難しい場合はどこまでできるか、優先順位・別の方法・段階的な実施でどう組み直せるかを整理してお返しします。同じ内容を無条件に値下げするのではなく、必要な品質と安全を守って範囲を検討します。

バックアップや移行時の保全、必要な試験、セキュリティやアクセシビリティの確認は、予算のために省かない方針です。最初に一番困っているページから進めるなど、無理のない始め方も一緒に考えられます。

情報確認日：2026年10月26日。自社事例の測定対象は公開トップページです。本文の測定結果は記載日時の記録で、現在や将来の点数を保証するものではありません。測定条件の解説はGoogleのPageSpeed Insights資料、安全な改善の考え方はWordPress公式の最適化資料を参照しています。