限られた予算でのページ速度改善：最も重要な最適化
予算を抑えた戦略でCore Web Vitalsを改善する方法を解説します
最も重要な最適化
Core Web Vitalsのコンサルタントとして、ページ速度改善に関するさまざまな依頼を受けます。もちろん、十分な予算がない場合もあります。その場合は時間を最大限に効率化し、実際にCore Web Vitalsを改善できる、効果が高く工数が少ない最適化だけに絞る必要があります。
最終レビュー：Arjen Karel（2026年3月）
数字を見れば明らかです。2025 Web Almanacによると、モバイルのオリジンでCore Web Vitalsの3つの指標すべてに合格しているのはわずか48%です。モバイルページの中央値は容量が2.6 MBあり、そのうちJavaScriptが632 KB（うち251 KBは未使用）を占めています。多額の予算をかけなくても、これらの問題は解決できます。
Table of Contents!
Core Web Vitalsのヒント：専門家によるサポートを最も手頃な費用で受けるなら、私のOn-Call Consultancyが最適です。2時間のセッション（€300）を予約していただければ、Core Web Vitalsの課題を診断し、最も緊急度の高い問題を修正した上で、残りの対策に向けた明確な方針をお伝えします。事前に準備してからセッションに臨むため、時間を無駄にすることはありません。
セッションを予約する
1. まず問題を特定する
限られた予算でWebパフォーマンスを最適化する場合、可能な限り効率的に進める必要があります。つまり、まずは本当の問題が何であるかを把握しなければなりません。
CrUXデータの確認には、優れた無料ツールであるPageSpeed Insightsを利用できます。Googleが実際に使用しているのはCrUXデータだけです。したがって、重視すべきデータソースもこれしかありません。
CrUXスコアの下には、Lighthouseの監査結果が表示されます。
Lighthouseの監査について、はっきり言っておきます。現時点ではLighthouseを気にする必要はありません。なぜでしょうか？Core Web Vitalsを計測していないからです。もちろん、Lighthouseは素晴らしいテストツールですし、提案内容を調べるのは自由です。しかし予算が限られている以上、重要なのはCore Web Vitalsに合格することです。今はシンセティックテストの合格など気にしている場合ではありません！
CrUXデータの話に戻りましょう。予算が限られている場合は、以下の指針に従ってください。Core Web Vitalsは必ず次の順番で調査し、まずこれらの問題に集中してください！
- Time to First Byteが不合格なら、まずそれを修正してください！
- First Contentful Paintが不合格なら、render blockingリソースを解消してください（スクリプトを遅延させ、スタイルを最適化）
- Largest Contentful Paintが不合格なら、そのLCPに必要なリソース（フォントや画像など）の優先順位を上げてください
- CLSが不合格なら、すべての画像にwidthとheightを追加し、CSSトランジションを見つけて削除し、後からレンダリングされる要素（広告や商品フィルターなど）の表示スペースを確保してください
- Interaction to Next Paintが不合格なら、不適切なタイミングでJavaScriptを実行しすぎている可能性が高いです。不要なスクリプトやプラグインを削除し、CoreDashのようなRUMツールを使って最も遅いスクリプトを特定してください
2. 画像を最適化する
2025 Web Almanacによると、モバイルページの中央値では画像が911 KBを占めています。これはページ総容量の3分の1以上にあたります。さらに、WebPなら同等の画質のままファイルサイズを小さくできるにもかかわらず、LCP画像の57%はいまだにJPG形式で配信されています。予算が限られている場合、画像の最適化は最小の工数で最大の効果を得られる施策です。
無料で画像をWebPに変換する
画像をWebPのような、より新しく高速でモダンな形式に変換できる無料のツール、ソリューション、プラグインは数多くあります。たとえばWordPressなら、無料で優れたWebP Expressをおすすめします。
lazy loadingを実装する
lazy loadingは、画像が表示viewportに入る直前まで読み込まないようブラウザに伝えます。ページ内に画像が15枚あり、ファーストビューにあるのが3枚だけなら、表示viewport外の画像には問題なく loading="lazy" を追加できます。
これには2つの対処法があります。1つ目は、CMSでlazy loadingを有効にすることです。これによりすべての画像にlazy loadingが適用されます。その上で、ドキュメントを確認して、ファーストビューに表示される重要な画像からlazy loadingを解除してください。もう1つの方法は、ファーストビュー外（below-the-fold）の画像に手動で loading="lazy" を追加することです。詳しい手順は、画面外の画像を遅延読み込みする方法を参照してください。
<img loading="lazy" src="image.jpg" width="800" height="600">
画像のfetchpriorityを設定する
画像タグに fetchpriority="high" を追加することで、その画像が他の画像よりも重要であり、最優先でダウンロードすべきであることをブラウザに伝えられます。画像のプリロードや103 Early Hintsなど、ほかにも優れた手法はありますが、fetchpriorityの設定はシンプルで素早く、効果的です！ページ内で最も重要な画像を特定し、テンプレートを編集して、その画像に fetchpriority="high" を追加するだけです：
<img fetchpriority="high" src="image.jpg" width="800" height="600">
3. ブラウザキャッシュを修正する
格安のホスティングを利用している場合、Webサーバーが最適に設定されていない可能性が高いです。私が頻繁に目にするミスの1つが、不適切なブラウザキャッシュ設定です。適切なキャッシュヘッダーがないと、再訪した訪問者が同じ画像、スクリプト、スタイルシートを何度もダウンロードすることになります。これは帯域の無駄であり、時間の無駄でもあります。
WebサーバーとしてApacheを使用している場合は、Webサイトのルートディレクトリに .htaccess というファイルを作成し、以下の行を追加するだけです：
<FilesMatch "\.(ico|pdf|jpg|jpeg|png|webp|gif|css|js|woff|woff2)$">
<IfModule mod_headers.c>
Header set Cache-Control "max-age=172800, public, must-revalidate"
</IfModule>
</FilesMatch> .htaccess ファイルを編集するついでに、GZIP圧縮も有効化しておきましょう。これにより、テキストベースのリソース（HTML、CSS、JavaScript）が圧縮されてからブラウザに送信されます。ほとんどのサイトでは、転送サイズを60〜80%削減できます。
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/css text/javascript AddOutputFilterByType DEFLATE application/javascript application/json </IfModule>
NGINXなど別のWebサーバーを使用している場合は、ホスティング会社に連絡し、この記事を案内してください！
4. Cloudflareを検討する（無料プランでも効果あり）
Cloudflareは無料プランであっても、重要なパフォーマンス機能の多くを提供してくれます。格安ホスティングを利用している場合、DNSをCloudflareに切り替えることは、最小の工数で最大の効果を得られる変更の1つです。詳しい設定手順については、Cloudflare完全設定ガイドを参照してください。
無料プランの場合
- 高速なDNS。 CloudflareのDNSサーバーは無料で利用でき、格安ホスティング業者のDNSサーバーよりもほぼ確実に高速です。2025 Web AlmanacのCrUXデータによると、モバイルのオリジンで良好なTTFBを記録しているのはわずか44%です。DNSの遅さはTTFB悪化の一般的な原因ですが、Cloudflareに切り替えることで即座に解決できます。
- HTTP/3とBrotli。 Cloudflareは最新のプロトコルと最速の圧縮方式を採用しています。詳しい説明は省きますが、これだけでネットワーク速度が少なくとも10%向上することは確実です。
- 安定したブラウザキャッシュ。 静的リソースのキャッシュにおいて、Cloudflareには確かな実績があります。初期設定（デフォルト）のままでも、現在の環境より優れている可能性が高いでしょう。
- 静的リソースのエッジキャッシュ。 Cloudflareは画像、スクリプト、CSSファイルなどの静的リソースをキャッシュし、エッジネットワークからエンドユーザーに直接配信します。これにより、オリジンサーバーへのラウンドトリップ（往復通信）が不要になります。
- Rocket Loader。 Rocket Loaderはスクリプトの読み込みを遅延させ、それに伴って生じる問題に対処します。やや強引な手法ではありますが、スクリプトを手動で遅延読み込みできない場合、Largest Contentful Paintなどの描画指標を改善できる可能性が高いです。注意：Rocket Loaderは非推奨のブラウザAPIを使用しているため、PageSpeed Insightsで警告されることがあります。その警告が表示された場合は、代わりにスクリプトを手動で遅延させることを検討してください。
Proプランの場合
無料のCloudflareプランを目にしたとき、私が真っ先に言うことの1つが「Proプランにアップグレードしましょう！」です。もし月額25ドルを支払う余裕があり、サイトの高速化に投資できるなら、前向きに検討すべきです。
- すべての無料プラン機能。 当然ながら、Proプランには無料プランの全機能が含まれています。
- WordPress向けCloudflare APO。 APO for WordPressは、未ログインの訪問者に対してページをエッジネットワーク上にキャッシュする包括的なソリューションです。これにより、Time to First Byteを劇的に短縮できます。
- 可逆・非可逆の画像最適化。 CloudflareのProプランを利用する大きな利点の1つが、画像の最適化機能です。Cloudflareは画像をWebP形式に変換してキャッシュし、その形式に対応している訪問者にのみ配信します。
5. 可能な限りセルフホストする
もう1つのシンプルで効果的な最適化は、静的リソースのセルフホストです。多くのサイトでは、静的リソースが外部CDNに配置されています。たとえばjQueryは https://code.jquery.com/、Bootstrapは https://cdn.jsdelivr.net、フォントは https://fonts.googleapis.com でホストされています。手軽で速そうに見える魅力は分かりますが、それらの利用は実際には悪手であり、サイトを遅くします。
異なるWebサイト間でブラウザがファイルを共有できた時代には、共有CDNの利用は理にかなっていました。しかし、その時代は終わりました。現在では、新規の訪問者は毎回必ず静的ファイルをダウンロードする必要があり、ファイルごとに新しいサーバーへの新規接続が必要になります。そして、これらの新しいサーバーへの新規接続には、多くの余分な時間がかかります。
解決策は、そうしたサードパーティファイルをセルフホストすることです。やり方は簡単です。ファイルをダウンロードして自社サーバーに配置し、そのファイルへの参照先を変更するだけです。特にフォントについては、Google Fontsをセルフホストする方法を参照してください。
6. スクリプトの読み込みを遅延させる
ページのhead内にあるブロッキングスクリプトは、大きなボトルネックになり得ます。こうしたスクリプトのせいで、ページの読み込みが最大20秒も遅れることがあります！2025 Web Almanacの調査では、render blockingリソースの監査に合格したモバイルページはわずか15%でした。この問題がいかに広く蔓延しているかが分かります。
これらのスクリプトを遅延させるのは、まったく難しくありません。scriptタグに defer を追加するだけで完了です。可能であれば、ぜひ実行してください！テンプレートを編集し、scriptタグを次のように変更します：
<!-- old blocking script tag --> <script src="script.js"></script> <!-- new deferred script tag --> <script defer src="script.js"></script>
ただし、落とし穴もあります！scriptタグにdeferを追加すると、さまざまな不具合や依存関係のエラーが発生することがあります。予算が限られている以上、発生し得るあらゆる問題を修正するためにJavaScriptのエキスパートを雇う余裕はないはずです。そのため、まずはスクリプトをdeferしてみて、エラーが出ないか確認してください（Chromeで Ctrl+Shift+I を押し、コンソールタブを確認します）。テスト後に問題が起きなければ、非常に幸運な数少ない人の1人です！もし問題が発生した場合は、次のいずれかの解決策を試してください。全容を把握したい場合は、JavaScriptを遅延読み込みする16の方法を参照してください。
Rocket Loaderを使用する
前述のとおり、Cloudflareの無料プランでもRocket Loaderを利用できます。これにより、ページ上のすべてのスクリプトが遅延読み込みされます。決して完璧ではありませんが、大半のケースでは十分にうまく機能します。
プラグインを使用する
CMSベースのサイトの多くには、充実したプラグインリポジトリがあります。JavaScriptを遅延読み込みし、それに伴う複雑な問題を解決してくれるプラグインが数多く提供されています。
7. フォントを最適化する
Webフォントは、低予算サイトにおいて見落とされがちなパフォーマンスコストです。2025 Web Almanacによると、ページの中央値で122 KBのフォントファイルが読み込まれています。フォントをGoogle Fontsから読み込んでいる場合、初回アクセスのたびに余計なDNSルックアップとTCP接続が発生します。
無料でできる2つの解決策：
- フォントをセルフホストする。 フォントファイルをダウンロードして自社サーバーに配置し、そこから読み込みます。これにより、fonts.googleapis.com や fonts.gstatic.com への接続オーバーヘッドがなくなります。
- font-display: swap を追加する。 これにより、Webフォントのダウンロード中も、ブラウザは即座にfallbackフォントでテキストを表示するようになります。訪問者はコンテンツをより早く確認でき、テキストが見えなくなる問題（不可視テキスト）を防げます。詳しい戦略は、Webフォント読み込み時の不可視テキストの修正方法を参照してください。
8. キャッシュ、キャッシュ、キャッシュ
予算が限られており、ホスティングに多額の費用をかけられない場合、キャッシュはWebサイトを高速化する最も効果的な方法の1つです。特に、遅いTime to First Byteの改善に絶大な効果を発揮します。キャッシュは複数のレイヤーで実施できます。
クライアントサイドキャッシュ： 可能な限り多くの静的リソースをキャッシュするよう、Webサーバーを設定してブラウザに指示を出します。これによりサーバーの負荷が軽減されます（セクション3の .htaccess の例を参照してください）。
オブジェクトキャッシュ： 複雑なデータベースクエリの結果など、再生成の計算コストが高いデータを保存するために使用します。ホスティング業者に依頼して、RedisやMemcachedを導入してもらいましょう。
フルページキャッシュ： CMSを使用しているなら、フルページキャッシュを導入すべきです。WordPressの場合、WP Fastest Cache や WP Core Web Vitals が優れた選択肢になります。
9. 戦略的にホスティングを選ぶ
ホスティングに関しては、複数社を比較検討する価値があります。最も高価なホストが常に最速であるとは限りません。基本的には、使っているCMSに最適化されたホスティングプランを選ぶべきです。何でも屋の汎用サーバーは、どれも中途半端になりがちだからです。最低条件として、PHP 8以上、HTTP/2、SSDストレージを備えたホスティングを探してください。こうした基本を押さえた優れたWordPressホストなら、一般的な共有サーバーをいつでも凌駕します。
10. パフォーマンスをモニタリングする
実際に効果があったのかを確認できなければ、これらの最適化はすべて無意味です。Real User Monitoringを設定し、Lighthouseによるラボ環境でのスコアだけでなく、実際の訪問者がサイトをどう体験しているかを把握できるようにしてください。ラボスコアはデバッグに役立ちますが、Googleがランキング評価に使用するのは実際の訪問者によるfield dataです。CoreDashは実際のユーザーのCore Web Vitalsを追跡し、現状の正確な数値を把握できるようにします。
