WordPress で効率的なキャッシュ ポリシーを使用してアセットを提供する方法
公開: 2023-11-16
最善を尽くしているにもかかわらず、WordPress サイトがなぜ遅く感じるのか疑問に思ったことはありますか? その秘密は、資産をどのように提供しているかにあるかもしれません。
ブラウザーが画像、CSS、JavaScript などのファイルを効率的に保存および取得できない場合、不必要な遅延が発生し、ユーザー エクスペリエンスが標準以下になる可能性があります。 そのため、サイトを高速化し、シームレスなユーザー エクスペリエンスを提供するには、効率的なキャッシュが必要です。
確かに、キャッシュはテクノロジーの迷路のように感じるかもしれませんが、それを通る簡単な道があると言ったらどうでしょうか?
このガイドでは、WordPress で効率的なキャッシュ ポリシーを使用してアセットを提供するための重要な手順を説明します。
それでは、始めましょう。
- 静的アセットとキャッシュについて
- 「効率的なキャッシュ ポリシーによる静的資産の提供」問題の特定
- 効率的なキャッシュ ポリシーを使用して資産を提供するためのソリューション
- 最適なキャッシュ戦略のヒント
- Cloudways を使用したキャッシュの最適化
静的アセットとキャッシュについて
静的アセットとキャッシュは、サイトのパフォーマンス、読み込み時間、ユーザー エクスペリエンスを向上させるための Web 開発の 2 つの重要な側面です。 実際、キャッシュをクリアすると、サイトのパフォーマンスが即座に向上します。 「 WordPress キャッシュを効果的にクリアする方法」については、ガイドをご覧ください。
静的資産を適切に管理し、効果的なキャッシュ戦略を実装することで、Web サイトはコンテンツをより効率的に配信でき、全体的なユーザー満足度と SEO ランキングに貢献します。
両方をさらに詳しく理解しましょう。
静的資産とは何ですか?
静的アセットは、画像、CSS スタイルシート、JavaScript スクリプトなど、時間が経っても変化しないファイルです。 これらのファイルは Web サイトの視覚的および機能的側面にとって重要であり、サーバーに保存されているとおりにユーザーのブラウザに配信されます。
キャッシングとは何ですか?
キャッシュは、ファイルまたはデータのコピーを一時的な保存場所に保存して、そのデータに対する将来のリクエストをより迅速に処理できるようにするために使用される技術です。
ブログの関連性を保つためにさまざまなタイプのキャッシュ手法を使用できますが、ここでは 2 つのタイプのキャッシュ、つまりページ キャッシュと静的キャッシュについて説明します。
ページ キャッシュと静的アセット キャッシュ
ページ キャッシュには Web ページの完全なレンダリング バージョンの保存が含まれますが、静的アセット キャッシュには画像やスタイルシートなどの個別のファイルが保存されます。
ページ キャッシュはコンテンツが頻繁に変更されない動的サイトには有益ですが、静的アセット キャッシュは読み込み時間とサーバー帯域幅の使用量を削減するためにすべての Web サイトにとって重要です。
ページ キャッシュと静的アセット キャッシュの詳細な比較については、以下の表を確認してください。
ページのキャッシュ | 静的アセットのキャッシュ |
頻繁に変更されない動的コンテンツを提供します。 | 静的な Web サイト コンテンツの読み込み時間と帯域幅を削減します。 |
コンテンツの変更や有効期限の設定に基づいて更新頻度が低くなります。 | ファイルが変更されたとき、またはキャッシュヘッダーに従って更新されます。 |
Web ページ全体を保存します。 | 画像、スタイルシート、スクリプト、フォント、その他の静的ファイルが保存されます。 |
これは、Cache-Control や Expires などのヘッダーによって制御されます。 | これはヘッダーとファイルのバージョン管理によって制御されます。 |
Cloudways WordPress ホスティングで驚異的なスピードを解き放ちましょう!
NGINX、Apache、Memcached、および高度な PHP キャッシュにより最大 300% 高速化された Web サイトのパフォーマンスを体験し、静的アセットを効率的に提供します。
静的アセットをキャッシュ可能にするものは何ですか?
静的アセットは、頻繁に変更されない場合にキャッシュ可能とみなされ、ブラウザまたは CDN によって保存され、複数のページ読み込みで再利用できます。 画像、CSS ファイル、JavaScript ファイル、フォントは、静的アセットの一般的な例です。
アセットをキャッシュ可能にするには、アセットを保存する期間をブラウザに示す、Cache-Control や Expires などの適切な HTTP キャッシュ ヘッダーが必要です。
キャッシュポリシーとは何ですか?
キャッシュ ポリシーは、ブラウザと中間キャッシュが特定のリソースを保存する方法と期間を指示する、HTTP ヘッダーによって定義される一連のルールです。 明確に定義されたキャッシュ ポリシーは、ロード時間、サーバーの負荷、帯域幅の使用量を削減するのに役立ちます。
UX と SEO はキャッシュ ポリシーによってどのような影響を受けますか?
堅牢なキャッシュ ポリシーは、ユーザー エクスペリエンス (UX) と検索エンジン最適化 (SEO) の両方に直接影響します。 効果的なキャッシュによりロード時間が短縮され、よりスムーズで応答性の高いユーザー エクスペリエンスが実現します。 読み込みに時間がかかりすぎるとユーザーがサイトから離れる可能性が高いため、これは非常に重要です。
SEO に関しては、サイトの速度が Google のランキング要因として知られています。 検索エンジンのランキングでは高速な Web サイトが好まれ、可視性が高まり、トラフィックが増加する可能性があります。
サイトでブラウザのキャッシュが有効になっているかどうかを確認する方法
WordPress サイトでブラウザ キャッシュを活用すると、サイトのパフォーマンスが向上するだけでなく、静的資産の問題も解決できます。 サイトでブラウザーのキャッシュが有効になっているかどうかを確認するには、ブラウザー開発者ツールまたは Google の PageSpeed Insights などのオンライン ツールを使用できます。
そのためには:
- ブラウザで右クリック > [検査] を選択します。
- [ネットワーク] タブに移動し、Cache-Control ヘッダーと Expires ヘッダーが適切に設定されているかどうかを確認します。
Google の PageSpeed Insights は、サイトのパフォーマンスを分析し、キャッシュの最適化が必要なアセットを明示的に示す、よりユーザー フレンドリーなインターフェイスを提供します。
「効率的なキャッシュ ポリシーによる静的資産の提供」問題の特定
「効率的なキャッシュ ポリシーによる静的アセットの提供」の問題は、静的リソースが効果的にキャッシュされず、ユーザーの読み込み時間が長くなる場合に Web サイト パフォーマンス ツールで強調表示されます。
問題を特定するには、次の 2 つの主な点を理解する必要があります。
- 1: 問題の原因
- 2: PageSpeed Insights が問題をどのように解釈するか。
問題の原因
問題の主な原因をいくつか紹介します。
キャッシュポリシーの欠如
これは、画像、JavaScript、CSS ファイルなどの Web サイト上の静的アセットが適切なキャッシュ制御ヘッダーで提供されていない場合に発生します。 これらのヘッダーがないと、ブラウザーはこれらのリソースをキャッシュしないため、不要なダウンロードが発生し、再度訪問する人の読み込み時間が長くなります。
短いキャッシュ期間
キャッシュが有効になっている場合でも、キャッシュ期間が非常に短いと、キャッシュをまったく使用しない場合と同様のパフォーマンスの問題が発生する可能性があります。 理想的には、パフォーマンス上の利点を最大限に高めるために、頻繁に変更されない静的アセットのキャッシュ期間を長くする必要があります。
一貫性のないキャッシュ ポリシー
サイトのさまざまな種類のアセットまたはさまざまなページ間でキャッシュ ポリシーに不一致があると、最適ではないキャッシュ動作が発生する可能性があります。つまり、一部のアセットは効率的にキャッシュされ、他のアセットは効率的にキャッシュされません。
ブラウザのキャッシュを利用しない
ブラウザー キャッシュを利用できないということは、ユーザーのブラウザーが、次回のアクセス時に迅速に取得できるように静的アセットのコピーを保存しないことを意味し、Web サイトのパフォーマンスが大幅に低下する可能性があります。
注: ブラウザーのキャッシュを活用して静的アセットを提供する方法を学習してください。
一般的な構成ミス
これには、不正なキャッシュ制御ヘッダー、誤ったサーバー設定、Web サイトの .htaccess ファイルの問題 (Apache サーバーの場合) など、さまざまな問題が含まれる可能性があります。
PageSpeed Insights はこの問題をどのように解釈しますか?
PageSpeed Insights がこの問題をどのように解釈するかは次のとおりです。
- まず、Web サイトから提供される静的アセットのヘッダーを分析します。
- 次に、キャッシュ コントロールと期限切れヘッダーを調べて、各アセットがブラウザーによってキャッシュされる期間を決定します。
- これらのリソースのキャッシュ TTL (Time To Live) が短いか、まったくキャッシュされていないことがツールによって検出された場合、問題にフラグが立てられ、改善のための推奨事項が提供されます。
したがって、原因を突き止めることで、問題を戦略的に解決できます。
効率的なキャッシュ ポリシーを使用して資産を提供するためのソリューション
効率的なキャッシュ ポリシーを使用してアセットを提供できるように、Web アプリケーションのパフォーマンスを向上させる 2 つのアプローチについて説明します。
- 手動によるアプローチ
- プラグインのアプローチ
手動による方法
まず、この問題を手動で修正する方法を見てみましょう。
ステップ 1: 静的アセットを特定する
まず、どの静的アセットがキャッシュ ポリシーなしで、または非効率的なポリシーで提供されているかを特定する必要があります。 これは、次の手順に従って行うことができます。
- Google Pagespeed Insights に移動します。
- URLを入力してください。
- 診断セクションの下で、「効率的なキャッシュ ポリシーを使用して静的アセットを提供する」の下にリソースが表示されます。
- それらを展開して静的アセットを特定します。 私の場合、テストの実行後に 35 個のリソースが見つかりました。
ステップ 2: HTTP ヘッダーを構成する
次に、静的アセットをキャッシュする期間をブラウザーに指示する特定の HTTP ヘッダーを含めるようにサーバーを構成する必要があります。 注目すべき主なヘッダーは Cache-Control と、オプションで Expires です。
サーバーごとに HTTP ヘッダーを異なるように構成する必要があります。
サーバーで Apache が実行されている場合は、.htaccess ファイルに次の行を追加します。
<IfModule mod_expires.c> 有効期限切れアクティブ日 # 画像 ExpiresByType image/jpeg "アクセスプラス 1 年" ExpiresByType image/png "アクセスプラス 1 年" ExpiresByType 画像/GIF「アクセスプラス 1 年」 ExpiresByType 画像/WebP "アクセスプラス 1 年" ExpiresByType image/svg+xml "アクセスプラス 1 年" # フォント ExpiresByType font/ttf "アクセスプラス 1 年" ExpiresByType font/woff "アクセスプラス 1 年" ExpiresByType font/woff2 "アクセスプラス 1 年" # CSS、JavaScript ExpiresByType テキスト/CSS "アクセスプラス 1 か月" ExpiresByType アプリケーション/JavaScript "アクセスプラス 1 か月" # その他 Expiresデフォルト「アクセスプラス2日」 </Ifモジュール> サーバーが Nginx を実行している場合は、サーバー ブロック構成に次の行を追加します。 location ~* \.(jpg|jpeg|png|gif|webp|svg|ttf|woff|woff2|css|js)$ { 有効期限は 1 年です。 add_header キャッシュ コントロール "パブリック、max-age=31536000、不変"; } 場所 ~* \.(zip|pdf)$ { 有効期限は 7 日です。 add_header キャッシュ制御 "public, max-age=604800"; }
ステップ 3: 構成をテストする
サーバー構成を更新した後、サーバーのキャッシュをクリアし (該当する場合)、次の方法で構成をテストする必要があります。
- ブラウザで Web サイトにアクセスします。
- ブラウザの開発者ツールを開きます (右クリック→「検査」)。
- 「ネットワーク」タブに移動します。
- ページをリロードします。
- [ネットワーク] タブで静的アセットをクリックし、ヘッダー セクションで Cache-Control ヘッダーを探します。
ステップ 4: パフォーマンス テストを再実行する
Google PageSpeed Insights、Lighthouse、WebPageTest などのツールを再度使用して、問題が解決されていることを確認し、パフォーマンス スコアの改善を確認します。
- 設定を調整した後、リソースの数は 35 から 29 に減りました。
プラグインメソッド
キャッシュ プラグインを使用すると、「効率的なキャッシュ ポリシーで静的アセットを提供する」問題を簡単に修正できます。 最高の WordPress キャッシュ プラグインのリストをご覧ください。
その方法は次のとおりです…
ブリーズプラグイン
デモンストレーションの目的で、Breeze プラグインを使用します。 Breeze プラグインは Cloudways によって開発されており、すべての Cloudways ユーザーはデフォルトでこのプラグインを入手します。
- まず、プラグインをインストールして有効化します。
- [設定] > [ブラウザ キャッシュを有効にする] に移動します。

これで問題は解決するはずです。 Breeze プラグインの設定について詳しくは、このガイドをご覧ください。
W3 トータル キャッシュ プラグイン
上で説明したように、ほとんどのキャッシュ プラグインでは静的アセットを提供できます。 W3 Total Cache プラグインを使用して静的アセットを提供する方法は次のとおりです。
- W3 Total Cache プラグインをダウンロードしてアクティブ化します。
- [設定] > [ブラウザ キャッシュ] に移動します。
- CSS と JS、HTML と XML の各要素について、有効期限ヘッダーにチェックマークを付け、有効期限ヘッダーの有効期間を 31536000 秒に設定します。
また、追加情報については、ガイド「 WordPress W3 Total Cache Plugin を使用してウェブサイトを高速化する方法」を参照してください。
最適なキャッシュ戦略のヒント
「効率的なキャッシュ ポリシーで静的アセットを提供する」問題を簡単に解決する方法についてはすでに説明しましたが、そもそもこの問題を防ぐには最適なキャッシュ ポリシーが必要です。
ここでは、キャッシュ戦略を最適化するためのヒントをいくつか紹介します。
効果的なホスティングプロバイダーを使用する
ホスティング プロバイダーの選択は、最適なキャッシュ戦略を設定する上で重要な役割を果たします。 堅牢なホスティング プロバイダーを持っている場合は、キャッシュ戦略を設定するために特別な努力をする必要がない場合があります。 ホスティングプロバイダーがキャッシュのほとんどの部分を処理します。
SSD を使用し、主な利用者の近くにデータセンターがあり、サーバー レベルで組み込みのキャッシュ メカニズムを提供するホスティング プロバイダーを選択する必要があります。 さらに、トラフィックの急増時にリソースを簡単にアップグレードできるようにし、HTTP/2 または HTTP/3 のサポートを提供する必要があります。
Cloudways マネージド ホスティングで WordPress サイトを強化しましょう!
高度なキャッシュ、SSDテクノロジー、Cloudflare Enterprise CDNによる驚異的なスピードと揺るぎない信頼性を体験してください。
コンテンツ配信ネットワーク (CDN) の採用
CDN を使用すると、「静的資産の提供」の問題も解決できます。 ユーザーに最も近い場所からコンテンツを配信するには、世界中の幅広いサーバー ネットワークを備えた CDN を選択する必要があります。
さらに、オリジンサーバーのキャッシュヘッダーを尊重するように CDN が構成されていることを確認するか、CDN レベルで適切なキャッシュ ポリシーを設定する必要があります。
Cloudflare CDN を使用している場合は、ページルールをいじってこの問題を解決できます。
- Cloudflareダッシュボードに移動します
- 「キャッシュ」>「構成」を選択します
- ブラウザのキャッシュ TTL を 1 年に設定します。
Cloudways ユーザーの場合は、ワンクリックで Cloudflare Enterprise アドオンを有効にし、キャッシュ オプションを有効にして「静的アセットの提供」問題を解決できます。
Cloudways 上の Cloudflare のワンクリック統合を活用すると、Web サイトのパフォーマンスとセキュリティを簡単に強化できます。 Cloudflareを有効にすることで、「効率的なキャッシュポリシーで静的アセットを提供する」問題に対処でき、Webサイトの静的コンテンツがユーザーに迅速かつ効率的に配信されるようになります。
Cloudway 上の Cloudflare でスピードとセキュリティを最大化しましょう!
CloudflareのエッジキャッシュとArgoスマートルーティングを活用して、読み込み時間を短縮し、ワンクリックでサイトのセキュリティを強化します。
サードパーティのコードの遅延
ご存知のとおり、ロード時間の遅さ、ひいては静的資産の問題の真の原因はサードパーティのコードです。
したがって、サードパーティのコードを遅らせる必要があります。 それは次のようにして行うことができます。
- async または defer 属性、または必須ではないスクリプトを使用して、メイン スレッドがブロックされるのを防ぎます。 これは、スクリプト タグに async 属性と deferring 属性を追加するだけで実行できます。
- async 属性を追加するには、HTML ファイルの script タグの下に次の行を配置します。
<script async src="path-to-your-script.js"></script>
- Defer 属性を追加するには、HTML ファイルの script タグの下に次の行を追加します。
<script defer src="path-to-your-script.js"></script>
- async 属性と defer 属性を適切に使用すると、Web サイトの読み込みパフォーマンスを最適化し、ユーザーに高速でスムーズなエクスペリエンスを提供できます。
フォントと分析をローカルでホストする
外部フォントを使用すると、Web サイトの速度が低下し、静的アセットの問題に直面する可能性があります。 これを防ぐには、外部のフォント プロバイダーに依存するのではなく、サーバーからフォントを直接ダウンロードして提供します。 これをする、
- まず、Google Fontsからフォントファイルをダウンロードします。
- フォントをサーバーにアップロードします。 それにはFTPを使用できます。 フォント ファイルをリモート サイトにドラッグ アンド ドロップします。
- @font-face ルールを定義する CSS ファイルを作成して、フォントの表示方法を指定します。
f
ont-family: 'あなたのフォント名'; src: url('/フォントディレクトリへのパス/フォントファイル.woff2') format('woff2'), url('/フォントディレクトリへのパス/フォントファイル.woff') format('woff'), url('/フォント ディレクトリへのパス/フォント ファイル.ttf') format('truetype'), url('/フォントディレクトリへのパス/フォントファイル.otf') format('opentype'); フォントの太さ: 通常; フォントスタイル: 通常; }
- 「YourFontName」をフォントの名前に置き換え、/path-to-your-font-directory/your-font-file をフォント ファイルの実際のパスとファイル名に置き換えます。
- 次に、フォント ファイルを提供するように Web サーバーを設定します。
- Apache を使用している場合は、これらの行を .htaccess ファイルに追加します。
AddType フォント/woff2 .woff2 AddType フォント/woff .woff AddType フォント/ttf .ttf AddType フォント/otf .otf
- Nginx を使用している場合は、これらのファイルをサーバー ブロックに追加します。
場所 ~* \.(ttf|otf|woff|woff2)$ { add_header アクセス制御許可オリジン *; }
- 上で作成した CSS ファイルを HTML ドキュメントに含めます。 これを行うには、HTML の <head> セクションに CSS ファイルへのリンクを追加します。
<link rel="stylesheet" href="/path-to-your-css-directory/your-font-stylesheet.css">
- 以上です。
Cloudflare機能の無効化
Cloudflare の一部の機能は、Web サイトへの負荷を高め、読み込み時間を増加させる可能性があります。 静的資産の問題を回避するには、それらを無効にする必要があります。 また、Cloudflare ページルールを設定して、さまざまな種類のコンテンツのキャッシュを最適化します。
- Cloudflareダッシュボードの「速度」タブに移動します。
- ここで、必要に応じて Rocket Loader のオンとオフを切り替えることができます。
Cloudways を使用したキャッシュの最適化
Cloudways で Web サイトをホストするとき、すでにキャッシュの最適化にサインアップしていることをご存知ですか?
その方法を知りたいですか?
Cloudways がホストする WordPress サイトでは、Varnish は Cloudways プラットフォーム インターフェイスを通じて有効になり、ユーザーはサーバーで Varnish をオンに切り替えるだけで済みます。 Varnish をアクティブにすると、リバース プロキシとして機能し、受信 HTTP リクエストをインターセプトします。
画像、CSS、JavaScript ファイルなどの静的アセットの場合、Varnish はサーバー上の WordPress アプリケーションに到達する前にキャッシュをチェックします。 アセットがキャッシュされており、設定された Time To Live (TTL) に基づいて有効期限が切れていない場合、このアセットはユーザーに直接提供され、WordPress がページを生成する必要がなくなります。
これにより、Web サーバーがこれらのファイルを最初から提供する必要がなくなるため、サーバーの負荷が大幅に軽減され、応答時間が短縮され、エンド ユーザーのエクスペリエンスが高速化されます。 コンテンツがキャッシュにない場合、または期限切れの場合、Varnish はサーバーから新しいコンテンツを取得し、キャッシュして提供し、後続のリクエストがキャッシュから提供されるようにします。
ワニスを有効にするには、次の手順に従います。
- サーバー設定 > サービスの管理に移動します
- 「ワニスを有効にする」をクリックします。
さらに、WordPress サイトで Varnish を手動で設定したい場合は、「 WordPress on Varnish 」に関する詳細ガイドを参照してください。
注: また、動的アセットと静的アセットの両方を提供するには、「 WordPress サイトに Redis をインストールして構成する方法」も確認してください。
まとめ
効率的なキャッシュ ポリシーを使用して静的アセットを提供することは、WordPress Web サイトのパフォーマンスとユーザー エクスペリエンスを向上させるために非常に重要です。 このガイドでは、キャッシュの重要性を説明し、キャッシュ ポリシーを構成するための実行可能な手順を示し、静的アセットの速度を確実に最適化するためのベスト プラクティスを強調しました。
さらに詳しい情報が必要な場合は、お気軽にお問い合わせください。
よくある質問
Q)ブラウザのキャッシュは安全ですか?
A) はい、ブラウザーのキャッシュはユーザーのデバイスに静的資産を保存するため、一般に安全です。 ただし、適切なキャッシュ検証と有効期限ポリシーを実装して、ユーザーが古いコンテンツや安全でない可能性のあるコンテンツを受信しないようにすることが重要です。
Q)ブラウザ キャッシュとサーバー キャッシュの違いと利点は何ですか?
A) ブラウザ キャッシュは静的アセットをユーザーのデバイスに保存し、繰り返しアクセスする際の読み込み時間を短縮します。一方、サーバー キャッシュは Web ページまたはその他のコンテンツをサーバーに保存し、すべてのユーザーへのコンテンツ配信を高速化します。 どちらの方法もパフォーマンスを向上させますが、コンテンツ配信の異なる段階で動作します。
Q)追加のパフォーマンス向上戦略とは何ですか?
A) キャッシュ以外の戦略には、画像の最適化、CSS および JavaScript ファイルの縮小、リソースの遅延読み込み、コンテンツ配信ネットワーク (CDN) の利用による遅延の削減と読み込み時間の改善などがあります。