PageSpeed Insightsで「効率的なキャッシュ保存期間を使用する」と表示されたら、画像・CSS・JavaScriptなどの静的ファイルが十分にキャッシュされず、再訪問時にも再ダウンロードが発生しているサインです。

LighthouseはCache-Controlのmax-ageなどを見て、長期キャッシュで高速化できる余地を指摘します。

本記事では原因の見分け方から、Apache/Nginx/CDN/WordPress別の具体的な改善手順まで解説します。

「効率的なキャッシュ保存期間を使用する」とは？

「効率的なキャッシュ保存期間を使用する」とは、PageSpeed Insights静的アセット（画像・CSS・JS・フォント等）に対して、ブラウザキャッシュの有効期限（TTL）が短い／未設定で、再訪時に不要な再ダウンロードが発生していると判断したときに出る改善項目です。

具体的にはレスポンスヘッダーの Cache-Control（例：max-age）などを見て、長期キャッシュ（不変の静的ファイルは1年など）を推奨します。

PageSpeed InsightsでURLを分析すると「パフォーマンスの問題を診断する＞インサイト」の箇所に表示されます。

上記画像の赤枠に削減できるサイズが表示され、数字が多いほど改善の余地があるということになります。

青枠が対象となるファイル名で、黄色枠がそれぞれのファイルの削減ができるサイズになります。

キャッシュの有効期間を長くすると、再訪問したユーザーへのページの読み込み速度を向上できます。

といった表記で解説されていて、キャッシュの有効期間の設定によって読み込み速度も改善できるという意味合いになります。

キャッシュの有効期間の設定で読み込みが速くなる理由

キャッシュの有効期間（TTL）を適切に長く設定すると、再訪問時に画像・CSS・JSなどの静的ファイルをネットワークから再取得せず、ブラウザのローカルキャッシュから即座に読み出せるため読み込みが速くなります。

仕組みとしては、初回訪問時にキャッシュが保存されます。

再訪問時には、ネットワークに再度アクセスせずにキャッシュされたファイルを読み込めます。

そのため、読み込み時間が短縮されウェブページの表示速度も速くなる。といった仕組みになります。

さらに有効期限が切れた後でも、差分確認（再検証）だけで済み、未変更なら本体の再ダウンロードを避けられます。

結果として転送量・待ち時間・サーバー負荷が減り、体感速度も改善します。

PageSpeed Insightsが見ている対象のファイル

PageSpeed Insightsの「効率的なキャッシュ保存期間を使用する」が見ている対象は、ページ表示時に取得される“キャッシュ可能なサブリソース（主に静的アセット）”です。

具体的には、再訪時に同じURLで再利用されるはずなのに Cache-ControlのTTLが短い／未設定なものを拾い、URLごとにTTL（キャッシュ有効期間）として一覧表示します。

対象になりやすいファイル例

• CSS
• JavaScript
• 画像
• Webフォント
• アイコン静的JSON

などの静的アセットとなります。

逆に、HTML本体やログイン後に変わる個別ページのような動的性が強いものは、長期キャッシュにすると更新反映の事故が起きるため、運用設計が別になります。

効率的なキャッシュ保存期間を使用するの対象ファイルを探す方法

まずは対象のファイルを確認する方法から解説していきます。

PageSpeed InsightsでURLを計測した後に、「効率的なキャッシュ保存期間を使用する」を開きます。

上記画像の赤枠部分が対象のファイルとなるので、ここのファイル名と黄色枠のキャッシュTTLをメモなどでリストアップしておきましょう。

次に計測した同じURLをDevToolsのネットワークを開きます。（下記画像の赤枠部分）

PageSpeed Insightsでメモしておいたファイルを参照し、クリックします。（上記画像の青枠部分のようにファイル名をクリック）

ヘッダー（黄色枠部分）を開きレスポンスヘッダー内の「cache-control」（緑枠部分）を確認しましょう。

cache-controlの部分で、max-ageの数値がキャッシュ時間にあたります。

max-age=14400となっている場合は、4時間（60秒×60分×4時間）のキャッシュ時間が設定されていることになります。

チェックポイントをまとめると下記となります。

• cache-controlを確認
• max-ageで時間を確認（短すぎたり長すぎないか？）
• no-store / no-cache になっていないか（＝キャッシュを指定していない）

特にキャッシュした方が良いファイルなのに、no-store / no-cachと表示されていないものはキャッシュ設定を検討しましょう。

キャッシュの設定時間の考え方

キャッシュ時間（TTL）は「そのURLの中身がどれだけ変わるか」で決めます。

変わらない静的ファイルは長期（1年）で再訪を高速化し、たまに変わるものは30〜90日でバランスを取り、頻繁に変わるHTML/APIは短期または再検証（no-cache）で更新反映を優先します。

内容が変わらないファイル

内容が変わらない静的ファイルは、長期キャッシュが最も効果的です。

重要なのは「中身が変わったらURLも変わる」運用にしておくこと。

たとえばビルドでCSS/JSを style.x234dff.css のようにハッシュ付きへすると、更新時に別URLとして配信され、古いキャッシュが残っても新しいファイルが確実に読み込まれます。

この条件が揃う場合、Cache-Control: max-age=31536000（1年）で配信するのが定石です。

HTMLなど更新頻度が高い

更新頻度が低いもの（たまに変わるが、即時反映が必須ではない）

更新頻度が低いファイルは「速度」と「更新反映」のバランスが重要です。

Chromeの指標では、キャッシュ可能なサブリソースは少なくとも30日（2,592,000秒）以上のキャッシュ有効期間が望ましいとされています。

まずは30日を基準に設定し、更新が月1以下なら60〜90日へ伸ばす、更新が増えるなら短くする、と段階的に調整するのが安全です。

ハッシュ付きURLにできない運用ほど、長期にし過ぎると反映遅れが起きやすい点に注意します。

更新頻度が高いもの（頻繁に変わる／最新性が最優先）

更新頻度が高いコンテンツは、長期キャッシュにすると「更新したのにユーザーに反映されない」事故が起きやすい領域です。

そのため基本は Cache-Control: no-cache（キャッシュは保持するが毎回サーバーに再検証）を選び、ETag や Last-Modified により未変更なら304で返して転送量を抑えます。

これなら最新性を担保しながら、毎回フルダウンロードする無駄も減らせます。

APIなどは用途に応じて5〜10分の短期TTLも現実的です。

キャッシュを設定する方法

キャッシュの設定方法は、サイトや導入しているサービスによって変わります。

基本はサーバーの管理画面等で設定することが多いですが、CDNを導入している場合などはCDNの設定画面で設定します。

サーバー管理画面で設定

最も基本で確実なのは、サーバー（オリジン）が返すレスポンスに Cache-Control を付ける方法です。

HTTPキャッシュは Cache-Control / ETag / Last-Modified などのヘッダーで制御されます。

サーバーのサービスによって設定方法などは異なりますが、基本的にはどの拡張子のファイルをキャッシュするか？と、時間をどのくらいキャッシュするかが設定できるはずです。

詳しくはご契約のサーバーで設定方法を確認しましょう。

CDNを導入している場合の設定

CDNを使っている場合、CDNがオリジンの Cache-Control を尊重するのが基本ですが、CDN側のルールで上書き・増強もできます。

Cloudflareはオリジンの Cache-Control を尊重する（またはルールで上書きする）概念を明確に説明しています。

こちらもサービスによって設定方法が異なるため、サービス毎の設定方法を確認しましょう。

WordPressなどのCMSで設定する場合

WordPressなどCMS側で設定できるケースもあります。

WordPressの場合であれば、キャッシュ系のプラグインで設定できるものもあるようです。

こちらも各サービスの内容に合わせて設定を行ってみましょう。

キャッシュ設定時の注意点

キャッシュは「速くするため」に入れますが、設定を誤ると 更新が反映されない／個人情報が共有キャッシュに残る／CDNとオリジンで指示が競合する などの事故が起きます。

以下は「PageSpeed Insights対策（効率的なキャッシュ保存期間）」と運用安全性を両立するための注意点です。

長期キャッシュにして良いものとダメなものを最初に分ける

長期キャッシュして良いものと、ダメなものを最初に分けておくことで事故を防ぎやすくなります。

長期キャッシュOK

内容が変わらない（またはURLが変わる）静的ファイル（CSS/JS/画像/フォントなど）。

長期キャッシュNG

HTMLやAPIレスポンスなど、更新や個別表示が起きやすいもの（ログイン後ページ、在庫/価格など）。

Lighthouseの監査は、主に静的アセットのTTL不足をURL単位で指摘します。

まず“何に長期TTLを付けるべきか”の棚卸しが最重要です。

長期キャッシュは「キャッシュバスティング（URL変更）」とセット

長期TTL（例：max-age=31536000）を付けたファイルは、同じURLのまま中身を差し替えると、ユーザー側に古い内容が残りやすいです。

対策は、ビルド時に ファイル名にハッシュを付ける（例：app.abc123.js）など、更新時にURLが変わる運用にすること。

これが長期キャッシュの王道です。

no-cacheとno-storeを混同しない

「キャッシュさせたくない＝no-cache」と誤解されがちですが、挙動が違います。

用途に応じて選ばないと、更新反映・体感速度・挙動が崩れるので注意しましょう。

no-cache

保存はしてよいが、使う前に必ず再検証（常に最新性を担保しやすい）。

no-store

保存自体を禁止（ブラウザ/中継キャッシュとも保存しない）。機密情報向け。

private/public の付け忘れは“個人情報キャッシュ”のリスク

ログイン後のページやユーザー別に内容が変わるレスポンスは、共有キャッシュ（CDNやプロキシ）に載せない設計が必須です。

private の意味を理解せずにCDN前提で public を付けると、最悪ケースで意図しない共有が起きます。

キャッシュ設定の検証手順

キャッシュ設定ができたら、必ず最後に検証して設定が正常にできているか確認を行いましょう。

PageSpeed Insightsの点数などが気になる方もいるかとは思いますが、DevToolsのレスポンスヘッダーの数値で確認するようにします。

チェックポイントをまとめると下記となります。

• cache-controlで設定した数値に反映されているか？
• no-store / no-cache になっていないか

などが問題なければ設定できているかと思います。

以降は、サイトを運用しながら最適なキャッシュ時間を調整していくことをおすすめします。

「効率的なキャッシュ保存期間を使用する」に関するよくある質問

max-ageは結局何秒が正解？

正解は「更新頻度×更新の反映要件」で変わります。

目安として、頻繁に変わるHTMLやAPIは短め（例：1日=86400秒まで）にして再検証中心、週次更新の素材は7日=604800秒、月次レベルなら30日=2592000秒。

内容が変わらない（URLにハッシュ付与などで更新時にURLが変わる）静的資産は1年=31536000秒が定番です。

max-ageは“オリジンが生成してからの経過秒”である点にも注意。

キャッシュを長くしたら更新が反映されない…どうする？

原因の多くは、同じURLのまま中身だけ差し替えていることです。

解決策は「長期キャッシュするなら更新時にURLを変える」運用に寄せること（例：ファイル名にハッシュ、またはクエリでバージョン付与）。

HTMLなど更新を必ず反映したいものは no-cache で“保存は許可しつつ毎回再検証”にすると事故りにくいです。

更新後はDevToolsで実際の Cache-Control が返っているか確認し、CDN/サーバの上書きも疑ってください。

ETagって付けるべき？（期限切れ後の再検証のため）

基本は付けるのがおすすめです。

max-ageで期限が切れた後でも、ETag（またはLast-Modified）があるとブラウザは条件付きリクエストで再検証でき、未変更なら304 Not Modifiedで本文再ダウンロードを避けられます。

結果として転送量と待ち時間が減り、更新がある場合のみ取得する挙動に寄せられます。

ただし、生成コストが高いETag（毎回計算が重い等）や、サーバ間で不整合が出る実装は逆効果なので方式選定は注意。

Cloudflare使ってるけど直らないのはなぜ？

よくあるのは、Cloudflareが「オリジンのCache-Controlを尊重」している（またはルールが競合している）ケースです。

オリジンが no-cache / no-store / 短い max-age を返していると、Cloudflare側で期待したTTLにならないことがあります。

また「Browser Cache TTL」「Edge Cache TTL」「Cache Rules」とオリジンヘッダーの関係で、どれが最終決定になっているかがズレがちです。

まずDevToolsで最終レスポンスヘッダーを確認し、次にCloudflareのルールとオリジン設定のどちらで制御するかを一本化してください。

キャッシュ設定してあるのに、PageSpeed Insightsで指摘される

PageSpeed Insightsは、URLごとにキャッシュ有効期間（TTL）が短い/未設定の静的アセットを列挙して指摘します。

設定したつもりでも

1. 対象拡張子や配信パスが設定から漏れている
2. 別ドメイン（外部タグ/外部CDN）の資産で自分が変えられない
3. CDNやアプリが別のヘッダーで上書きしている
4. HTML等“長期キャッシュ非推奨”に長期TTLを付けて逆に設計が崩れている

が典型です。

指摘一覧のURLを「自社/Cloudflare/外部」に分類し、DevToolsでヘッダーを突合すると最短で潰せます。

「効率的なキャッシュ保存期間を使用する」まとめ

「効率的なキャッシュ保存期間を使用する」は、画像・CSS・JS・フォントなどの静的アセットに適切なTTL（Cache-Control: max-age）を設定し、再訪時の無駄な再ダウンロードを減らして表示を速くする改善です。

まずPageSpeed Insightsで指摘URLを洗い出し、不変（ハッシュ付き）=1年、低頻度=30日目安、高頻度=短期＋再検証に分類。

更新反映はURL変更（キャッシュバスティング）とETag/Last-Modifiedの再検証で担保し、CDN利用時はオリジンとCloudflareの設定競合をDevToolsで最終確認しましょう。

小さな改善の積み重ねが、体感速度と評価を確実に押し上げます。

ぜひ今日から一つずつ試してみてください。