ワードプレス

WordPressとブラウザのキャッシュ - 不正確な設定が多い

WordPress ブラウザのキャッシュは、しばしばレスポンスの低下を引き起こします。 キャッシュ・ヘッダ が正しく設定されていないか、まったく制御されていない。典型的な設定ミスが304の代わりに200を返すこと、TTLが欠落している理由、WordPressでキャッシュを正しく設定する方法を紹介する。 パフォーマンス トリム。.

中心点

ロングTTL を静的アセットに使用することで、不要なリクエストを防ぐことができます。.
明確な分離 静的パスと動的パスが管理者とログインを保護する。.
一つのシステム 競合するキャッシュ・プラグインを混ぜないでください。.
ヘッダーのチェック DevToolsと304のステータスを持つ。.
サーバー・キャッシング とブラウザのキャッシュを削除します。.

WordPressのブラウザ・キャッシュの仕組み

ブラウザは静的ファイルをローカルに保存するため、再読み込みの手間が省ける。 HTTPリクエスト. .2回目の訪問では、画像、CSS、JSをローカルメモリから読み込み、変更をサーバーに要求するだけです。これにより、データ量が削減され、レスポンスタイムが短縮され、スクロールが即座にレスポンスよく感じられるようになります。液体にある。明確な指示がない場合、ブラウザは毎回完全にリロードされ、インタラクティブになるまでに時間がかかります。キャッシュ・コントロール・ヘッダを正しく設定することで、304バリデーションが可能になり、帯域幅が削減され、PHPとデータベースの負荷が軽減されます。私はこれを一貫して使用している。なぜなら、特に定期的なユーザーは、持続的なキャッシュから最も恩恵を受けるからだ。.

コンフィギュレーションがしばしば失敗する理由

多くのサイトが、とんでもなく短い静的ファイルを配信している。 最高年齢-値を設定します。プラグインによっては、お互いの.htaccessを上書きしたり、矛盾するディレクティブを設定したりします。サイトがしばしば管理パスを不正にマークし、/wp-adminや/wp-login.phpのコンテンツが意図せずキャッシュに残ってしまい、セッションが衝突する。また、最初の呼び出しと繰り返し呼び出される呼び出しの違いもチェックしています。ファーストコール対リターンコール. .バージョン管理なしでクエリ文字列を使用すると、メモリ上に古いファイルが作成され、次のような問題が発生します。 廃れた スタイル.

WPキャッシュ・ヘッダを正しく設定する

で持続時間をコントロールしている。 キャッシュ・コントロール とExpiresを設定し、マルチサーバ環境では曖昧なETagsを避けています。Apacheでは、Expiresに意味のある値を設定し、アセットには „public, max-age “を定義しています。Nginxの場合は、add_headerディレクティブを追加し、コンテンツがパーソナライズされている場合は、HTMLに短い時間か „no-store “を与えるようにしています。また、ロードバランサーやプロキシがこれらの値を一貫して生成しない場合は、ETagヘッダーを無効にします。このようにして、ブラウザに明確な動作を強制し、以下のような事態を回避している。 バリデーション クリックするたびに.

ExpiresActive On
  ExpiresByType image/jpeg "アクセスプラス 1 年"
  ExpiresByType image/png "アクセスプラス 1 年"
  ExpiresByType text/css "アクセス＋1ヶ月"
  ExpiresByType application/javascript "アクセスプラス1ヶ月"


 は次のようになります。
  ヘッダセット Cache-Control "public, max-age=31536000" "expr=%{CONTENT_TYPE} =~ m#^(image/|font/|application/javascript)#"
  ヘッダーセット Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#"
  ヘッダが ETag をアンセットする
</IfModule

# Nginx
location ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {.
    add_header Cache-Control "public, max-age=31536000"；
}
location ~* /(wp-admin|wp-login.php)${。
    add_header Cache-Control "no-store"；
}

日常生活における拡張キャッシュ制御ディレクティブ

max-age„ と “no-store„ に加えて、最新のディレクティブは顕著な安定性を保証します。“immutable„ は、ファイル名が変わらない限りファイルが変更されないことをブラウザに知らせます。“stale-while-revalidate„ は、バックグラウンドで更新している間、期限切れのコピーを配信することを許可します。“stale-if-error „は、Originが一時的にエラーを返した場合、コピーを準備しておきます。「s-maxage」はプロキシ/CDNを対象としており、「max-age」以外の値を取ることができます。また重要なこととして、“public „は共有プロキシでのキャッシュを許可し、“private „はブラウザに制限されます。「no-cache “は „キャッシュしない “という意味ではなく、„キャッシュは許可するが、使用前に再検証する “という意味です。.

# Apache 2.4 の例 (アセットをさらに強固にキャッシュする)
 の例
  ヘッダセット Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" "expr=%{REQUEST_URI} =~ m#.(css|js|woff2?|png|jpe?g|webp|avif)$#"
  ヘッダセット Cache-Control "no-cache, must-revalidate" "expr=%{CONTENT_TYPE} =~ m#^text/html#"
</IfModule

# Nginx の例 (304/Include リダイレクト)
location ~* .(css|js|woff2?|png|jpe?g|webp|avif)$ { .
    add_header Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" 常に；
}
location ~* .html$ {.
    add_header Cache-Control "no-cache, must-revalidate" 常時；
}

ファイルタイプ別推奨キャッシュ時間

習慣ではなく、変化の頻度に応じて時間を選ぶ。資産経年変化は大きく異なる。画像、ロゴ、アイコンは通常、長い間最新の状態に保たれるが、CSS/JSはより頻繁に更新される。ウェブフォントはめったに変更されないが、一貫したCORSヘッダーを必要とする。HTMLは多くの場合、動的コンテンツのコンテナとして機能するため、更新期間が短いか、再検証されるだけである。APIには明確に定義されたルールが与えられ、クライアントがCORSヘッダを使用して正しく動作できるようにすべきである。 JSON を避ける。.

ファイルの種類	キャッシュ制御の推奨	ヒント
画像 (jpg/png/webp/avif/svg)	公開, max-age=31536000	ファイル・バージョニングによる年次キャッシュの使用
CSS/JS	公開, max-age=2592000	アップデートのためにファイル名にバージョンを付加する
フォント (woff/woff2)	公開, max-age=31536000	Access-Control-Allow-Originを正しく設定する
HTML (ページ)	no-cache, must-revalidate または short max-age	動的コンテンツには細心の注意を
REST API (json)	非公開, max-age=0, 必ず再検証してください。	エンドポイントによって区別する

プラグインとの競合を避ける

私が使うのはせいぜい キャッシュ・プラグイン ホスティングがすでにサーバーレベルでルールを指定しているかどうかを確認してください。W3 Total CacheとWP Super Cacheのような組み合わせは、しばしば重複したディレクティブを作成し、お互いを打ち消し合う。WP Rocketは迅速なセットアップを提供するが、ダイナミックパスとeコマースに対する明確な除外が必要である。いずれにせよ、非論理的なヘッダーを認識するために、保存後に生成された.htaccessをチェックする。そして、チェックアウト、ログイン、パーソナライズされたダッシュボードなどの重要なページが正しいかどうかをテストします。 バイパス.

キャッシュとクッキー：ログインユーザー、WooCommerce、セッション

ログインユーザー用のHTMLをパブリックキャッシュに保存してはいけません。WordPressは以下のようなクッキーを設定します。 ワードプレス_ログイン, WooCommerceの補足 woocommerce_items_in_cart, wp_woocommerce_session_ などがある。その代わりに 変数: クッキー このようなリクエストに対しては、キャッシュを完全にバイパスします。これにより、チェックアウトプロセスが安定し、パーソナライズされたエリアが正しく保たれます。また、クッキーが認識されたときに、より制限的なヘッダーを設定するサーバー側のルールも使用しています。.

# Apache: クッキーを認識してバイパスヘッダを設定する
 に
  SetEnvIfNoCase Cookie "wordpress_logged_in_|woocommerce_items_in_cart|wp_woocommerce_session" has_session
  ヘッダーセット Cache-Control "private, no-store" env=has_session
</IfModule

# Nginx: クッキーベースのバイパス
if ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)"){
    add_header Cache-Control "private, no-store" 常に；
}

多くのキャッシュプラグインはこのためのチェックボックスを提供しています（WooCommerce/Cart/Exclude checkout）。重要: Nonces (_wpnonce（ワプノンス)のフォームとHeartbeat APIが頻繁に変更されます。私は、noncesを含むフロントエンドのHTMLが永久にキャッシュされないか、„no-cache, must-revalidate “で動作するようにしています。.

HTMLの標的治療：個別治療と一般治療

すべてのページが同じではありません。記事、ランディングページ、リーガルページは、短いTTLまたは再検証でキャッシュできることが多い。アーカイブ、検索ページ、ダッシュボード、アカウントエリア、チェックアウトは動的なままです。ページキャッシュが関係する場合、私は次の習慣を守っています：クッキーを使わずにパブリックHTMLのみをキャッシュし、それ以外は「プライベート」または「ノーストア」です。マイクロキャッシュをテストする場合（例：アクセス頻度が高く、パーソナライズされていないページの30～60秒）、クエリパラメータとセッションの厳格な除外を定義する必要があります。WordPressには DONOTCACHEPAGE テンプレートがトリッキーなページに設定できる定数で、私はエラーを避けるために一貫してこれを使用している。.

サーバーサイド・キャッシングを賢く組み合わせる

ブラウザのキャッシュはクライアントで終わるが、私はサーバーにページ、オブジェクト、オペコードのキャッシュを持たせている。 負荷ピーク. .ページキャッシュは、PHPが起動する前に静的なHTMLを提供します。RedisやMemcachedは、繰り返されるリクエストのデータベースクエリを減らし、TTFBを顕著に減らします。OPcacheはコンパイル済みのPHPバイトコードフラグメントを提供し、実行時間を短縮します。最終的に重要なのは、サーバーのキャッシュとブラウザーのキャッシュがきれいに接続され、2回目の訪問が多かれ少なかれ成功することです。 インスタント の作品だ。.

サプライズなしのCDN統合

CDNは独自のTTLロジックを使用し、„s-maxage “に反応します。そのため、私はブラウザ用の „max-age “とEdge用の „s-maxage “を明確に区別しています。デプロイメントが保留中の場合は、„Cache Everything “をグローバルに破棄するのではなく、対象を絞ったパージをトリガーします。重要：EdgeでHTMLをキャッシュするのは、クッキーが関係していない場合だけにしてください。そうしないと、エッジのキャッシュがパーソナライズされたレスポンスを共有するため、正しくないステートが作成される。アセットについては、私は長いTTLを設定し、ファイル名のバージョニングに依存している。CDNはクエリー文字列を無視することができる。ヘッダーの正規化（余計な „Vary “値や一貫性のある „Content-Type “を使用しない）は、キャッシュキーの肥大化を防ぐ。.

ステップバイステップ：クリーンインストール

私はまずプラグインを使い、CSS、JS、画像、フォントのブラウザ・キャッシングを有効にしてから、次のようにする。 htaccess を確定します。そして、静的アセットにはmax-ageを高く設定し、HTMLには短い時間かno-cacheルールを提供する。複数のサーバーが関係している場合はETagsを無効にし、Last-Modifiedプラス304に頼ります。その後、重要なページが静的コピーとしてすぐに利用できるようにプリロードを開始します。最後に、ショップ、ログイン、管理者のパスをチェックし、プライベートコンテンツが バッファメモリ 土地だ。.

CLIとヘッダーチェックによる実践的な診断

DevToolsは必須だが、私はCLIテストをより深く行う。A curl -I はダウンロードなしのヘッダーを示し、ダウンロードありは -H 私は条件をシミュレートする。例えば、再検証が本当に304を返すかどうか、プロキシ/CDNから „Age “が増加するかどうか、クッキーがキャッシュをオフにするかどうかをチェックする。.

# 表示ヘッダ
curl -I https://example.com/style.css

#の再検証をシミュレートする（If-Modified-Since）
curl -I -H "If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT" https://example.com/style.css

クッキーを使った#テスト（強制的にバイパスする必要がある）
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/

私は、アセットには長い「キャッシュ制御」値、理想的には「不変」であることを確認する。HTMLは „no-cache “か短いTTLが必要だ。それでも304ではなく200が返ってくる場合は、ETags/Last-Modifiedを無効にするリダイレクトが行われていることが多い。また、Nginxの „add_header “はデフォルトでは200レスポンスにしか適用されません。„always “では304と301/302のヘッダーも設定します。.

ヘッダーのテストと検証

DevToolsを開き、ページを一度リロードし、キャッシュをクリアしてリロードすると、304対304が表示される。 200 を観察する。ネットワークパネルで、キャッシュコントロール、年齢、ETag/last modified、レスポンスサイズをチェックする。再バリデーションの代わりに直帰がまだある場合は、リダイレクト、クッキー、クエリー文字列の競合をチェックする。厄介なケースでは、ヘッダーの落とし穴に関するこの記事が役に立つ：キャッシュヘッダの妨害. .ルールの変更はしばしば無言で行われるため、プラグインを更新するたびにチェックを繰り返す。パス.

バージョニング、CDN、キャッシュの破壊

を吊るす。 バージョン をファイル名（style.css?ver=23ではなくstyle.23.css）に変更することで、ブラウザが長いキャッシュを保持しながらも、新しいコンテンツを即座に読み込むことができます。CDNは静的ファイルをグローバルに配信し、エッジPoPに独自のTTLを設定し、RTTを大幅に短縮します。重要：パーソナライズが必要ない場合のみCDNでHTMLをキャッシュする。デプロイ時にバージョン番号を自動的に変更し、ユーザーが古いスクリプトに引っかかることがないようにしている。このようにして、ハードブラウザのTTLとセキュアな キャッシュ・バスト.

WordPressのビルドにおけるクリーンなバージョン管理

最も信頼できるのは、ファイル名にハッシュを書き込むビルドパイプラインだ（例えば. app.9f3c.css).WordPressは、このファイルを正確に読み込みます。ブラウザは、「immutable」のおかげで、このファイルを1年間保持できます。もしファイル名を変更できない場合は、バージョン番号をファイルの日付から動的に設定します。これにより、クエリー文字列は正しく信頼できるものになります。.

// functions.php (filemtimeによるフォールバックバージョニング)
add_action('wp_enqueue_scripts', function () {
    $css = get_stylesheet_directory() .'/dist/style.css'；
    $ver = file_exists($css) ?filemtime($css) : null；
    wp_enqueue_style('theme', get_stylesheet_directory_uri() .'/dist/style.css', [], $ver)；
});

重要：ファイル名にバージョンが含まれている場合、„immutable “が設定されている可能性があります。もしクエリー文字列しか使わないのであれば、ブラウザは更新が確実に届くように再検証できるはずです。また、CDNが不必要に多くの亜種を保存しないように、ビルドツールが古いファイルをクリーンアップするようにします。.

ウェブフォントをキャッシュし、正しく読み込む

ウェブフォントには、長いTTL、正しいCORSヘッダー、オプションのプリロードが必要です。 レイアウトジャンプ が表示されない。同じドメインにwoff2ファイルを置くか、Access-Control-Allow-Originをきれいに設定する。さらに、フォントの読み込み中にテキストがすぐに表示されるように、font-display: swapを定義します。フォントの読み込み時間を最適化したい場合は、こちらに役立つヒントがあります：ウェブフォントの読み込みを高速化. .クリーンなキャッシュヘッダーとCDNへのプレコネクトにより、FOUT/FOITを著しく短縮し、一貫した レンダリング-結果.

フォント、CORS、Varyを正しく調整する

他のOriginからのフォントにはCORSが必要です。私は アクセス制御-許可-オリジン (例えば、独自ドメインや „*“での公開など）。 バリエーション：オリジン, キャッシュキーを膨張させる。フォントに推奨： public, max-age=31536000, immutable. .プリロードはファーストペイントを向上させるが、TTLは変更しない - プリロードとハードキャッシュは互いに補完し合う。また、圧縮配信(br/ジージップ) a Vary: Accept-Encoding はプロキシが正しく分離するために必要である。.

典型的なエラーパターンと迅速な解決策

更新後に古いコードが表示された場合は バージョニング をファイル名に追加する。ブラウザが毎回完全にリロードされる場合、ヘッダーが矛盾する指示を設定しているか、プロキシが途中でそれらを削除している。チェックアウトがキャンセルされた場合、サイトがセッション側のページやAPIレスポンスをキャッシュしている可能性があります。管理者のパスがキャッシュに紛れ込んでいる場合、wp-adminとログインの除外が欠けているか、プラグインがグローバルにキャッシュしている。私は、ステップバイステップの無効化、ヘッダーの統合、重要なパスの除外、そして最終的に304ステータスの効果によってこれを解決している。 確認する.

見落としがちなディテールが大きな違いを生む

Nginx add_header を „always “に設定しないと、304/リダイレクトには適用されません。私は一貫して „always “を設定しています。.
期限切れ対キャッシュ制御： „Cache-Control “が優先され、„Expires “は古いクライアントのための予備となる。重複、矛盾する情報は避けましょう。.
マルチサーバー設定におけるETag： 一貫性のないETagsは304を破壊する。私はETagsを無効にするか、弱いバリデータを使って „Last-Modified “に依存している。.
最低限に変える： „「Vary: Accept-Encoding “は圧縮のために必須で、„Vary: Cookie “はエッジキャッシュを肥大化させる。.
SVGとMIMEタイプ： 正しい image/svg+xml を設定し、長いTTLを与え、重要なアイコンにはインラインSVGを考慮する。.
リダイレクトチェーンを避ける： 各301/302はバリデーターを失い、カスケードなしでクリーンなURLを強制的に200にすることができる。.
プライオリティ／プリロードを的を絞って使用する： fetchpriority="high" キャッシングはリピーターに効果的である。.
REST-APIを区別する： 公開され、めったに変更されないJSONは、短時間キャッシュすることができる。トークン/クッキーを持つエンドポイントは、厳密に „プライベート “である。.

簡単にまとめると

私は明確なものを頼りにしている。 ルールアセットには長いTTL、HTMLレスポンスは短いか再検証、バージョニング、そして単一のキャッシュ・プラグイン。それから、ブラウザのキャッシュとページ、オブジェクト、オペコードのキャッシュを組み合わせて、サーバーの負荷を減らす。DevToolsをチェックし、304を探し、ヘッダーをチェックし、リダイレクトやクッキーとの競合を排除する。実践的なテストでは、最初の呼び出しと繰り返される呼び出しの測定値を比較し、顕著な改善に焦点を当てる。これらのステップに従えば、WordPressを信頼できるレベルのブラウザ・キャッシュにすることができます。 スピード そしてユーザーと検索エンジンを満足させる。.