予算内で実現するページスピード改善:最も重要な最適化
予算に優しい戦略でCore Web Vitalsを改善する方法を学びましょう

最も重要な最適化
Core Web Vitalsのコンサルタントとして、私はページスピードのサポートについて様々な依頼を受けます。そしてもちろん、予算が多くないこともあります。そのような場合、私は時間をさらに効率的に使い、実際にCore Web Vitalsを改善する、少ない労力で高い効果が得られる最適化のみを行う必要があります。
最終確認:Arjen Karel (2026年3月)
数字がそれを証明しています。2025 Web Almanacによると、3つのCore Web Vitalsすべてに合格しているモバイルオリジンはわずか48%です。モバイルページの中央値の重さは2.6 MBで、632 KBのJavaScript(そのうち251 KBは未使用)が含まれています。これらは、大きな予算がなくても解決できる問題です。
Table of Contents!
Core Web Vitals TIP: 私のオンコールコンサルタンシー(On-Call Consultancy)は、専門家の助けを得るための最も予算に優しい方法です。2時間のセッション(300ユーロ)をご予約いただければ、あなたのCore Web Vitalsの問題を診断し、最も緊急な問題を修正し、残りの問題に対する明確な戦略を提供します。事前に準備をしてからお話しするため、時間を無駄にしません。
セッションを予約する!
1. まず問題を特定する
予算内でWeb Performanceを最適化する場合、可能な限り効果的に最適化していることを絶対に確信する必要があります。つまり、まず本当の問題が何であるかを知る必要があります。
優れた無料ツールであるPageSpeed Insightsを使用して、CrUXデータを照会できます。CrUXデータはGoogleが使用するデータソースであるため、重要となる唯一のデータソースです。


CrUXスコアの下にLighthouseの監査結果が表示されます。

Lighthouseの監査について明確にしておきましょう!現時点では、私たちはLighthouseを気にしません。なぜなら、LighthouseはCore Web Vitalsを測定しないからです。確かに、Lighthouseは素晴らしいテストツールであり、その提案を自由に探索して構いませんが、私たちは予算が限られているため、Core Web Vitalsに合格することに関心があります。今は合成テスト(synthetic tests)に合格することは気にしません!
CrUXデータに戻りましょう。予算が限られている場合に従うべきいくつかのガイドラインを以下に示します。まさにこの順序でCore Web Vitalsの調査を開始し、まずこれらの問題に集中してください!
- Time to First Byteで不合格となっている場合は、まずそれを修正してください!
- First Contentful Paintで不合格となっている場合は、レンダリングブロックリソースを修正してください(スクリプトを遅延させ、スタイルを最適化します)。
- Largest Contentful Paintで不合格となっている場合は、そのLCPに必要なリソース(フォントや画像など)を優先してください。
- CLSで不合格となっている場合は、すべての画像に幅と高さを追加し、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)は、画像が可視ビューポートに近づくまで読み込まれるべきではないことをブラウザに伝えます。ページに15枚の画像があり、ページの可視部分にあるのが3枚だけである場合、可視ビューポートにない画像に安全にloading="lazy"を追加できます。
これに対処するには2つの方法があります。1つ目は、CMSで遅延読み込みを有効にすることです。これにより、すべての画像に遅延読み込みが追加されます。次に、ドキュメントを参照して、可視状態であり重要な画像の遅延読み込みを削除する方法を確認してください。もう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は一般的な要因であり、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。 WordPress用のAPOは、訪問者がログインしていない場合にページをエッジネットワークにキャッシュする完全なソリューションです。これにより、Time to First Byteを大幅に高速化できます。
- ロスレスおよび非可逆画像最適化。 ProバージョンのCloudflareを使用する主な利点の1つは、画像の最適化です。Cloudflareは画像をWebP形式に変換およびキャッシュし、これらの形式を受け入れる訪問者にのみ配信します。
5. 可能な限りセルフホストする
もう1つのシンプルで効果的な最適化は、静的リソースのセルフホストです。多くのサイトで、静的リソースは外部CDNでホストされています。たとえば、jQueryはhttps://code.jquery.com/に、Bootstrapはhttps://cdn.jsdelivr.netに、フォントはhttps://fonts.googleapis.comにホストされています。その魅力は理解できます。これらのCDNは簡単で高速であると主張していますが、実際にそれらを使用するのは悪い考えであり、サイトを遅くすることになります。
これらの種類のファイルに共有CDNを使用するというアイデアは、ブラウザがWebサイト間でこれらのファイルをまだ共有できていた頃には妥当なものでした。その時代は終わりました。その結果、新しい訪問者は常に静的ファイルをダウンロードする必要があり、ファイルごとに新しいサーバーへの新しい接続が必要になります。そして、これらの新しいサーバーへの新しい接続には、多くの余分な時間がかかる可能性があります。
解決策は、それらのサードパーティファイルをセルフホストすることです。これを行うのは簡単です。ファイルをダウンロードし、サーバーに配置して、このファイルへの参照を変更するだけです。特にフォントについては、Google Fontsをセルフホストする方法を参照してください。
6. スクリプトを遅延させる
ページのheadにあるブロックスクリプトは、大きなボトルネックになる可能性があります。これらのスクリプトは、ページの読み込みを最大20秒も遅らせることがあります!2025 Web Almanacでは、レンダリングブロックリソースの監査に合格したモバイルページはわずか15%であることがわかりました。これは、この問題がいかに広まっているかを示しています。
これらのスクリプトを遅延させることはまったく難しくありません。スクリプトタグにdeferを追加するだけで完了です。可能であれば、これを実行してください!テンプレートを編集し、スクリプトを次のように変更します。
<!-- old blocking script tag --> <script src="script.js"></script> <!-- new deferred script tag --> <script defer src="script.js"></script>
しかし、落とし穴があります!スクリプトタグにdeferを追加すると、あらゆる種類の問題や依存関係のエラーが発生する可能性があります。そして、あなたは予算が限られているため、発生する可能性のあるすべての問題を修正するためにJavaScriptの専門家を雇う手段がないと想定しなければなりません。したがって、スクリプトを遅延させてみて、エラーがないか確認してください(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. パフォーマンスを監視する
これらのすべての最適化は、実際に効果があったかどうかがわからなければ意味がありません。単にLighthouseがラボでどのようにスコア付けするかだけでなく、実際の訪問者がサイトをどのように体験しているかを確認できるように、Real User Monitoring(RUM)を設定してください。ラボスコアはデバッグに役立ちますが、ランキングのためにGoogleが使用するのは実際の訪問者からのフィールドデータです。CoreDashは実際のユーザーからのCore Web Vitalsを追跡し、あなたが現在のどこに位置しているかを正確に教えてくれます。
何が本当に遅いのか、見つけ出します。
フィールドデータでCritical Rendering Pathをマッピング。Lighthouseレポートではなく、優先順位付きの修正リストをお渡しします。
監査を依頼する
