Prime Cache Pro マニュアル

Prime Cache 使い方ガイド

Prime Cache マニュアル(Pro版)

バージョン 1.10.13 | PHP 7.4+ | WordPress 5.8+ | 要 Prime Cache Free 版 1.10.59 以上
Pro 版は Free 版の全機能に加え、AI スピード診断・AVIF 変換・Critical CSS /未使用 CSS 削除・Cloudflare / Sucuri / Varnish 連携・Persistent Object Cache(APCu / Redis / Memcached)・データベース最適化・YouTube サムネイル置換などの高度な最適化機能を提供します。Free 版の機能や設定についてはFree 版マニュアルをご覧ください。WebP 変換は 1.10.0 から Free に降ろされており、Pro 版を入れると AVIF が上乗せされます。

Pro 版の有効化: Prime Cache Pro は Free 版のアドオンです。まず Free 版プラグイン(prime-cache)をインストール・有効化してから、Pro 版を追加インストールしてください。Prime Cache 管理画面の「ライセンス」タブに、購入後に発行されたライセンスキー(PCPR-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX 形式)を入力して有効化します。有効化後は AVIF 変換・高度な CSS 配信・CDN / Cloudflare / Sucuri / Varnish 連携・Persistent Object Cache・データベース最適化などの Pro 機能が解放されます。Free 側の Prime Cache > Pro Features ページ(1.10.14 で新設)にも、Pro で追加される機能の一覧と推奨サイト像が掲載されています。

はじめに

ライセンス有効化

Prime Cache > ライセンス タブで設定します。

Pro版を使用するにはライセンスキーの有効化が必要です。ライセンスキーは購入後に発行されます。

項目説明
ライセンスキー入力PCPR-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX 形式のキーを入力します。キーはライセンスサーバー(raplsworks.com)に対して検証されます
有効化「有効化」をクリックしてこのサイトにライセンスを登録します。1ライセンスは同時に1サイトで有効化できます
無効化別のサイトに移行する場合に使用します。ライセンスを解放して別のサイトで有効化可能な状態にします
ステータス表示有効(有効期限付き)・無効・期限切れ・無効のいずれかを表示します
自動アップデート有効なライセンスがある場合、WordPress 管理画面からプラグインの自動アップデートを受け取れます

有効化手順:

  1. Prime Cache > ライセンス タブを開きます
  2. ライセンスキー入力欄に PCPR-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX を貼り付けます
  3. 「有効化」ボタンをクリックします
  4. 「有効」ステータスが表示されたら完了です
  5. ページをリロードすると Pro 専用の設定項目が管理画面に表示されます
注意: ライセンスが無効または期限切れの場合でも、既存の Pro 機能設定は保持されますが、新しいアップデートを受け取ることができません。更新(延長)プランの販売はありません。

動作要件

項目最低要件推奨
PHP7.4 以上8.2 以上
WordPress5.8 以上最新安定版
WebP / AVIF 変換GD または Imagick PHP 拡張Imagick(変換品質が高い)
Object Cache (APCu)APCu PHP 拡張APCu 5.x 以上
Object Cache (Redis)phpredis または Predisphpredis + Redis 6.x 以上
Object Cache (Memcached)Memcached または Memcache PHP 拡張Memcached 3.x 以上
Web サーバーApache または NginxApache(.htaccess 最適化フル対応)
HTTPS推奨(HSTS 等に必要)Let’s Encrypt などの有効な SSL 証明書
サーバー拡張の確認: Prime Cache > ツール > システム情報 タブで、GD、Imagick、APCu、Redis、Memcached 拡張の有効状態を一覧で確認できます。

クイックスタート(推奨設定順序)

  1. ライセンス有効化 — ライセンスタブでキーを入力
  2. ページキャッシュ — ページキャッシュタブで有効化し、.htaccess 最適化を有効にする
  3. ファイル最適化 — HTML・CSS・JS の Minify を有効化、サイトを確認しながら Combine/Defer を段階的に有効化
  4. メディア最適化 — Lazy Load を有効化し、WebP 変換と一括最適化を実行
  5. プリロード — キャッシュプリロードとリンクプリフェッチを有効化
  6. データベース最適化 — クリーンアップを実行し、自動スケジュールを設定
  7. Heartbeat 制御 — フロントエンドの Heartbeat を無効化
  8. セキュリティヘッダー — HSTS・X-Frame-Options などを有効化
重要: CSS/JS の Combine、Delay、Critical CSS は設定後にすべてのページを確認してください。テーマやプラグインの組み合わせによっては JavaScript の実行順序に影響することがあります。まず一つずつ有効化し、問題がないことを確認してから次を有効化してください。
プリセットを使う場合: Free 版の ツール タブにある最適化プリセットのうち「自動」と「アグレッシブ」は、Pro 版が有効なときに内容が強化されます。CSS/JS の結合はオフのまま(HTTP/2 以降では効果がなく、不具合の原因になるため)、CSS 配信は「未使用 CSS の削除」+ Critical CSS の自動生成、Google Fonts のセルフホスト、YouTube サムネイル置換、Delay JS の「最大 Delay」(セーフモードはオフ)を有効にし、Local Analytics はオフにします(Google Site Kit や同意モードとの競合を避けるため)。1.9.2 からは「自動」もサーバーの HTTP プロトコルを判定せず、常に結合をオフにします。

ファイル最適化(Pro)

Prime Cache > ファイル最適化 タブで設定します。

HTML・CSS・JavaScript ファイルを最適化し、ページのレンダリングブロックを削減してページ読み込み速度を向上させます。

補足: この章で扱う機能のうち、Defer JavaScript と Delay JavaScript は Free 版に含まれる機能です。Pro 版が追加するのは CSS/JS 結合・Critical CSS・未使用 CSS 削除などです。

CSS 結合

複数の CSS ファイルを1つにまとめて HTTP リクエスト数を削減します。

1.8.4 の新機能: 「小さい CSS のインライン化」が有効で、結合後のスタイルシートがしきい値以内に収まる場合、結合結果は 1 つの <style> ブロックとして HTML に丸ごとインライン化されます。レンダーブロック CSS リクエストがゼロになり、非同期 CSS のような再スタイルの揺れも起きません (Free 1.10.38 が必要)。また、Free 版の「最大 Delay」が有効なリクエストでは JS 結合は自動的にスキップされます (遅延スクリプトのドキュメント順実行を守るため)。

設定デフォルト説明
CSS ファイルの結合無効複数の CSS ファイルを1つにまとめます。HTTP/2 のサーバーでは効果はほとんどありません
モバイルのみ無効CSS/JS の結合をモバイル端末にだけ適用します。モバイル専用キャッシュが必要です
結合を除外する CSS空結合対象から除外するファイルの URL またはパターン(1行に1つ)。テーマ固有の CSS などを除外できます
ヒント: CSS 結合はページ読み込みに必要な HTTP リクエスト数を大幅に削減しますが、条件付き読み込みの CSS(特定のページのみ読み込まれる CSS)は除外リストに追加することを推奨します。WooCommerce などのプラグインが独自に登録する CSS ファイルも必要に応じて除外してください。
結合をオンにしている場合の案内(1.9.2): 以前の「自動」プリセットで結合がオンになったままのサイトには、設定画面に 1 回だけ案内が表示されます。「結合をオフにする」を押すと結合をオフにしてキャッシュをクリアし、「オンのままにする」を押すとそのまま維持します。自動で変更されることはありません。HTTP/1.1 のみで配信しているサイトでは、オンのままでも構いません。
生成ファイルの更新(1.10.12): 結合ファイルと「未使用 CSS の削除」で生成したファイルのファイル名には、プラグインのバージョンが含まれます。プラグインを更新すると次のアクセス時に自動で作り直されるため、手動でキャッシュをクリアする必要はありません。新しいファイル名になるので、サーバー側のキャッシュ(X Accelerator など)が古い内容を返し続けることもありません。Free 版 1.10.59 以上が必要です。

JavaScript 結合

複数の JavaScript ファイルを1つにまとめて HTTP リクエスト数を削減します。

設定デフォルト説明
JavaScript ファイルの結合無効複数の JS ファイルを1つにまとめます。一部のスクリプトが動かなくなる場合があります。HTTP/2 では効果はほとんどありません
結合を除外する JS空結合対象から除外するファイルの URL またはパターン(1行に1つ)
注意: JavaScript 結合は実行順序に依存するスクリプト(jQuery を前提とするスクリプトなど)で問題が起きる場合があります。有効化後は必ずサイト全体を確認し、問題のあるスクリプトは除外リストに追加してください。

Defer JavaScript

JavaScript ファイルに defer 属性を付与し、HTML のパースをブロックしないようにします。

設定デフォルト説明
JS の Defer を有効化無効すべての <script> タグに defer 属性を付与します
Defer を除外する JS空Defer を適用しないスクリプトの URL またはパターン

Defer の動作:

  • スクリプトのダウンロードは並行して行われますが、HTML のパース完了後に実行されます
  • jQuery に依存するインライン <script> は、自動的に DOMContentLoaded でラップされます
  • GTM(Google Tag Manager)や分析スクリプトを Defer することで Core Web Vitals スコアが向上します
ヒント: defer は jQuery 本体にも適用されます。jQuery に依存するインラインスクリプトが表示崩れを起こす場合は、該当スクリプトを除外リストに追加するか、Defer を無効にしてください。Prime Cache は jQuery 依存のインラインスクリプトを自動検出して DOMContentLoaded でラップする仕組みを持っていますが、すべてのケースを網羅できるわけではありません。

Delay JavaScript

ページ読み込み時に JavaScript の実行を遅延させ、ユーザーの最初のインタラクション(スクロール・クリック・タッチ)が発生したときに初めて実行します。特にモバイルでの TTI(Time to Interactive)を大幅に改善します。

設定デフォルト説明
Delay JS を有効化無効JS の実行をユーザーインタラクションまで遅延します。モバイルキャッシュがオンのときは、モバイル専用キャッシュが自動でオンになります
Delay JS セーフモード無効セーフモードを有効にすると、サードパーティ(外部ドメイン)のスクリプトのみ遅延します。自サイトのスクリプトは通常通り実行されます
遅延対象外の JS空遅延させないスクリプトの URL またはパターン(1行に1つ)

Delay JS の仕組み:

  1. ページ HTML 内の <script> タグの type 属性を text/rocketscript に変換します(ブラウザがスクリプトを実行しない)
  2. ページが表示された後、ユーザーが最初にスクロール・クリック・タッチを行うと全スクリプトを復元して実行します
  3. セーフモードでは src に外部ドメインを持つスクリプトのみが遅延対象となります

Delay JS セーフモードの用途:

  • Google Analytics、Facebook Pixel、広告スクリプトなど外部のマーケティングタグを遅延
  • 自サイトの機能スクリプト(決済、フォーム、スライダーなど)は通常通り実行
  • フル Delay で問題が発生するサイトでも安全に PageSpeed スコアを改善できます
注意: Delay JS はモバイル向けの HTML を書き換えるため、ページキャッシュタブの「モバイルキャッシュ」がオンのときは「モバイル専用キャッシュ」が自動でオンになり、書き換えた HTML が PC に配信されることはありません。Free 1.10.41 からは、Delay JS が「モバイルキャッシュ」自体をオンに戻すことはなくなりました。また、チャットウィジェットや決済ボタンなど、即座に表示が必要なスクリプトは必ず除外リストに追加してください。

Critical CSS

ページの「above-the-fold」(初期表示領域)に必要な CSS のみをインラインで埋め込み、残りの CSS を非同期で読み込みます。最初の描画(FCP: First Contentful Paint)を大幅に高速化します。

設定デフォルト説明
Critical CSS の自動生成無効ページごとにファーストビューの Critical CSS を自動抽出します。「CSS の非同期読み込み」方式でのみ適用されます
フォールバッククリティカル CSS空手動で用意した Critical CSS。<head> にインラインで出力されます。入力されている場合は、自動生成の代わりにこの CSS が使われます

どちらも ファイル最適化 タブの「CSS 配信の最適化」カードにあります。Critical CSS の自動生成が働くのは「CSS の非同期読み込み」方式を選んだときだけです。「未使用 CSS の削除」方式では CSS が通常どおり読み込まれるため自動生成は行われず、自動生成をオンにしているとカード内にその旨の注意が表示されます(1.10.0)。

Critical CSS の生成プロセス:

  1. Critical CSS が有効な状態で対象ページに初めてアクセスがあると、バックグラウンドで CSS 解析が実行されます
  2. 解析結果の Critical CSS がデータベースに保存されます
  3. 次回以降のアクセスから、Critical CSS がインライン <style> として <head> に埋め込まれます
  4. 残りの CSS は media="print" と onload パターンで非同期読み込みされます
ヒント: 自動生成された Critical CSS は一般的なビューポートサイズ(1200px × 800px 相当)を基準に生成されます。特殊なレイアウトのページや、JavaScript で動的に表示される要素が多いページでは、手動 Critical CSS の入力も検討してください。Critical CSS の更新は「キャッシュ全削除」時に自動でリセットされます。

Remove Unused CSS

各ページの HTML を解析し、そのページで実際に使用されていない CSS ルールを除去します。CSS ファイルサイズを大幅に削減し、FCP および LCP スコアを改善します。

設定デフォルト説明
CSS 配信の最適化 + 方式「未使用 CSS の削除」無効未使用 CSS の自動除去を有効にします(CSS 配信最適化参照)
使用 CSS セーフリスト空削除してはならない CSS セレクターやパターン(1行に1つ)。JavaScript で動的に追加されるクラスなどを指定します

誤削除を防ぐしくみ:

  • 端末別のキャッシュ(1.9.8): 削除後の CSS はモバイルとデスクトップで別々に生成・保存します。モバイルで先に生成された CSS がデスクトップにも使われ、PC 専用のヘッダーなどのスタイルが消える問題を防ぎます。更新後に一度キャッシュをクリアしてください。
  • 背景画像のルールを残す(1.10.0): background-image: url() を持つルールは、セレクターが解析対象の HTML に見つからなくても削除しません。JavaScript で後からクラスが付くヒーロー画像(LCP 要素)が消えるのを防ぎます。
  • レイアウトを決めるルールを残す(1.10.11): position・transform・display の flex / grid・overflow・clip-path・contain・aspect-ratio などを宣言しているルールは、セレクターが一致しなくても残します。子要素の配置を決める親要素のルールが消えて、検索ボタンがページ上部に飛ぶといった崩れを防ぎます。
  • テーマ・プラグイン別の既定セーフリスト(1.10.11): Avada、Cocoon、SWELL、Elementor、Divi、WooCommerce、Smart Slider 3 を検出すると、それぞれが動的に付けるクラス名の接頭辞を自動で保護します。
  • 空の結果は使わない(1.10.8): 生成結果が空だった場合や書き込みに失敗した場合は、元の <link> をそのまま残します。

ツールタブの「デバッグログを有効化」をオンにすると、生成した CSS ファイルの隣に {hash}.removed.log が作られ、削除したルール(セレクター・プロパティ・行)と保護のために残したルールが記録されます(1.10.11)。「未使用 CSS の削除でレイアウトが崩れた」ときの原因調査に使えます。

注意: JavaScript で動的に付与されるクラス(モーダル、タブ、スライダーなど)は、初期 HTML 解析時に検出されないため、誤って削除される場合があります。そのようなクラスは「使用 CSS セーフリスト」に追加してください。有効化後は JavaScript を有効・無効の両状態でページを確認することを推奨します。

CSS 配信最適化

ファイル最適化 タブの「CSS 配信の最適化」カードで、「CSS 配信の最適化」をオンにしてから方式を選択します。

方式説明推奨シーン
未使用 CSS の削除(デフォルト)未使用 CSS を解析・除去してから配信。CSS は通常どおり読み込まれますCSS ファイルサイズが大きいサイト
CSS の非同期読み込みCSS ファイルを非同期(media="print" onload パターン)で読み込むCritical CSS と組み合わせたい場合
ヒント: 2 つの方式はどちらか一方だけを選べます。「Critical CSS の自動生成」をオンにして「CSS の非同期読み込み」を選ぶと、Critical CSS がインラインで即座に表示され、残りの CSS が非同期で読み込まれます。1.9.1 で、同じカードにあった重複する「Async CSS」チェックボックスを削除しました(保存しても元に戻る不具合があったため)。非同期読み込みはこの方式の選択で指定します。

Local Google Analytics

Google Analytics の JavaScript ファイル(gtag.js / analytics.js)を自分のサーバーにダウンロードしてローカルから配信します。外部ドメインへの DNS ルックアップと接続を削減し、PageSpeed スコアを改善します。

設定デフォルト説明
Local Analytics を有効化無効Google Analytics スクリプトをローカルにキャッシュして配信します
Tracking ID空Google Analytics のトラッキング ID(例: G-XXXXXXXXXX)
更新間隔24 時間ローカルキャッシュを更新する間隔。Google Analytics スクリプトは頻繁に更新されるため、定期更新が必要です

設定手順:

  1. Prime Cache > ファイル最適化 > Local Analytics セクションを開きます
  2. 「Local Analytics を有効化」をオンにします
  3. Google Analytics のトラッキング ID を入力します
  4. 「設定を保存」をクリックすると、自動的にスクリプトがダウンロードされます
  5. サイトのソースで analytics.js が自サイトのドメインから読み込まれていることを確認します
注意: Google Analytics スクリプトをローカルにキャッシュすると、Google から直接配信される場合と比べてリアルタイム性がわずかに低下する場合があります。また、ローカルキャッシュが古い状態のままだと、Google の仕様変更に追従できないことがあります。更新間隔を適切に設定してください。

Google Fonts 最適化

Prime Cache > ファイル最適化 > Google Fonts セクションで設定します。

Google Fonts の読み込みを最適化し、レンダリングブロックを削減します。

モード説明効果
Combine複数の Google Fonts API リクエストを1つにまとめますHTTP リクエスト削減
Self-hostGoogle Fonts のフォントファイルをサーバーにダウンロードしてローカルから配信します外部リクエスト削減・プライバシー向上
Display Swapフォント読み込み中に代替フォントを表示するため display=swap を追加しますFOIT(Flash of Invisible Text)防止
DisableGoogle Fonts をすべて無効化します外部リクエストを完全に排除

Self-host の動作:

  1. Google Fonts API URL を解析してフォントファイル(.woff2)を取得します
  2. フォントファイルを wp-content/cache/prime-cache/fonts/ に保存します
  3. HTML 内の Google Fonts リンクをローカルの CSS に置き換えます
  4. GDPR 観点からも外部 Google サーバーへのリクエストがなくなります
ヒント: EU の GDPR 対応が必要なサイトでは「Self-host」が最も推奨されます。Google のサーバーへのリクエストが発生しないため、IP アドレスが Google に送信されません。また、PageSpeed の「レンダリングを妨げるリソースの除去」に Google Fonts が含まれている場合は、Self-host を有効化して display=swap を組み合わせると効果的です。

メディア最適化(Pro)

Prime Cache > メディア タブで設定します。

画像を自動的に次世代フォーマットに変換し、ファイルサイズを削減します。変換後の画像は元ファイルと並存し、ブラウザのサポート状況に応じて最適なフォーマットが配信されます。

WebP / AVIF 変換

WebP 変換そのものは Free 版に含まれています(1.10.0 から)。Pro 版を有効化すると、同じ Prime Cache > メディア タブに AVIF 変換のトグルと、AVIF 専用の品質コントロールが追加されます。配信時はブラウザの対応状況に応じて AVIF / WebP /元画像が自動で選択され、Safari など AVIF 非対応のブラウザでも Free 側の WebP にフォールバックします。

設定提供デフォルト説明
WebP 変換を有効化Free無効アップロード時に WebP バリアントを自動生成します(Free 1.10.0 以降)
AVIF 変換を有効化Pro無効アップロード時に AVIF バリアントを自動生成します。WebP よりさらに小さいファイルサイズを実現しますが、変換に時間がかかります

対応変換エンジン:

エンジンWebP 対応AVIF 対応備考
GDPHP 5.4+PHP 8.1+ほとんどのホスティングで利用可能
ImagickImageMagick 6.5+ImageMagick 7.0.25+GD より変換品質が高い
サーバー要件: WebP 変換には GD(PHP 5.4+)または Imagick が必要です。AVIF 変換には GD(PHP 8.1+)または Imagick(ImageMagick 7.0.25+)が必要です。Prime Cache > ツール > システム情報 で対応状況を確認してください。

品質・EXIF・リサイズ設定

Free 版と Pro 版の違い: WebP 変換・EXIF データ削除・アップロード時リサイズ・一括変換は Free 版の機能です。Pro 版はここに AVIF 変換(と AVIF 品質設定)を追加します。
設定デフォルト説明
圧縮モードなしlossy(非可逆)/ lossless(可逆)/ custom(品質指定)から選択
WebP 品質85カスタムモード時の WebP 変換品質(0-100)。80-90 が品質とファイルサイズのバランスが良い
AVIF 品質75カスタムモード時の AVIF 変換品質(0-100)。AVIF は低い値でも高い品質を維持します
元ファイルの品質変更なし元の JPG/PNG ファイルを再圧縮する場合の品質(0-100)
EXIF データを削除無効GPS 情報・撮影日時・カメラ情報などのメタデータを削除します。プライバシー保護とファイルサイズ削減に効果的です
アップロード時にリサイズ無効設定したサイズを超える画像を自動的にリサイズします
最大幅2560(px)リサイズ時の最大横幅。これを超える画像はアップロード時に自動縮小されます
最大高さ2560(px)リサイズ時の最大高さ
ヒント: EXIF データには GPS 座標が含まれることがあります。プライバシー上の理由から、ユーザーが撮影した写真をそのまま公開するサイト(レストランのレビューサイト、フォトギャラリーなど)では EXIF 削除を有効化することを強く推奨します。

一括最適化

既存のメディアライブラリの画像を WebP・AVIF に一括変換します。

一括最適化の実行手順:

  1. Prime Cache > メディア > 一括最適化 セクションを開きます
  2. 変換対象のフォーマット(WebP / AVIF)を選択します
  3. 「一括最適化を開始」をクリックします
  4. AJAX によるプログレスバーが表示され、変換の進行状況をリアルタイムで確認できます
  5. 変換完了後、メディアライブラリの各画像の圧縮率がメディアライブラリ列に表示されます
処理時間について: 大量の画像を一括変換する場合、サーバーの処理能力によっては長時間かかる場合があります。一括変換はバックグラウンドで進行するため、処理中も管理画面の他の操作は続けられます。タイムアウトが発生した場合は、複数回に分けて実行してください。

配信方式

変換後の WebP・AVIF ファイルをブラウザに配信する方式を選択します。

方式説明推奨シーン
.htaccess リライトApache の mod_rewrite を使って、ブラウザが WebP/AVIF をサポートしている場合に自動的に変換ファイルを配信。PHP を経由しないため最速Apache サーバー
picture タグHTML の <img> タグを <picture><source><img> 構造に書き換えて、ブラウザが最適なフォーマットを選択Nginx / CDN 使用時
URL リライトHTML 内の画像 URL を WebP/AVIF の URL に書き換え。ブラウザが非対応の場合は元ファイルへ自動フォールバックシンプルな構成
ヒント: Apache サーバーをご利用の場合は「.htaccess リライト」が最もパフォーマンスが高く、推奨される配信方式です。Nginx や CDN を使用している場合は「picture タグ」方式をお試しください。.htaccess リライトを使用する場合は、Accept ヘッダーを使った条件分岐が .htaccess に自動追記されます。
.htaccess リライトが効かないサーバー: Xserver の X Accelerator、LiteSpeed、nginx のフロント、一部の CDN のように静的ファイルを直接返すサーバーでは、.htaccess のリライトが実行されず、訪問者に変換画像が届きません。診断タブの「WebP / AVIF 配信」で実際に変換画像が配信されているかを確認できます(1.10.11)。「変換されず元画像が配信されています」と表示された場合は「picture タグ」か「URL リライト」に切り替えてください。1.10.11 から、AVIF のリライトルールも元画像が存在する場合にだけ .avif を返します。元画像を削除したときの変換ファイルの削除と、残った孤立ファイルの掃除は Free 版 1.10.58 が行います。

フォルダー対象設定

画像変換の対象フォルダーを詳細に設定します。

設定デフォルト説明
対象フォルダーuploads変換対象に含めるフォルダー(uploads / themes / plugins / カスタムパス)
除外フォルダー空変換対象から除外するフォルダーの相対パス(1行に1つ)
除外ファイル空変換対象から除外する特定のファイル URL(1行に1つ)
ヒント: SVG、GIF(アニメーション)、アイコンフォントの画像などは除外フォルダーに追加してください。また、外部 CDN から配信されている画像は変換対象に含まれないため、設定する必要はありません。

メディアライブラリ圧縮列

WordPress のメディアライブラリに「Prime Cache」列が追加され、各画像の変換状況と圧縮率が表示されます。

表示内容説明
圧縮率元ファイルと比較した WebP/AVIF の削減率(例: -65%)
変換済みフォーマットWebP / AVIF の変換状況(済み / 未変換 / 非対応)
再変換ボタン個別の画像を手動で再変換するボタン

YouTube サムネイル置換

YouTube の <iframe> 埋め込みを軽量なサムネイル画像に置き換えます。訪問者がサムネイルをクリックしたときに初めて YouTube iframe を読み込むため、YouTube 関連のリソース(約 500 KB)を初期読み込みから排除できます。

設定デフォルト説明
YouTube サムネイル置換を有効化無効YouTube iframe をサムネイル画像に置き換えます
ヒント: YouTube 動画を多数埋め込んでいるサイトでは、この機能を有効にするだけで PageSpeed スコアが大幅に向上します。サムネイルにはプレイボタンのオーバーレイが自動追加されるため、訪問者は直感的に動画だと認識できます。

CDN 連携

Prime Cache > CDN タブで設定します。

CDN(コンテンツデリバリーネットワーク)を活用して静的アセットの配信を高速化します。

CDN URL 書き換え

静的ファイル(CSS、JS、画像、フォントなど)の URL を CDN の URL に書き換えます。CDN プルゾーンと組み合わせて使用します。

設定デフォルト説明
CDN URL 書き換えを有効化無効静的アセットの URL を CDN URL に書き換えます
CDN URL空CDN のプルゾーン URL(例: https://cdn.example.com)
対象ファイルタイプcss, js, png, jpg, webp, avif, gif, svg, woff2CDN から配信するファイルタイプ
除外パス空CDN URL 書き換えから除外するパス(1行に1つ)

設定手順:

  1. CDN サービス(BunnyCDN、Cloudflare R2、KeyCDN など)でプルゾーンを作成します
  2. プルゾーンのオリジンに自サイトの URL を設定します
  3. Prime Cache の「CDN URL」にプルゾーンの URL を入力します
  4. 「CDN URL 書き換えを有効化」をオンにします
  5. サイトのソースで静的アセットが CDN URL から配信されていることを確認します

ドメインシャーディング

複数の CDN ドメインを設定し、静的アセットの配信を分散させます。HTTP/1.1 環境でブラウザの同時接続数制限を回避するのに効果的です。

設定デフォルト説明
追加 CDN URL空CDN の追加ドメイン(例: https://cdn2.example.com)。CDN URL と合わせて最大4ドメインまで設定可能
HTTP/2 環境について: HTTP/2 では1つの接続で複数のリクエストを並列処理できるため、ドメインシャーディングの効果は限定的です。HTTP/2 対応サーバーを使用している場合はシャーディングを設定しなくても問題ありません。

Cloudflare 連携

Cloudflare のキャッシュを Prime Cache と同期します。コンテンツを更新したときに Cloudflare のキャッシュも自動的にパージされます。

設定デフォルト説明
Cloudflare 連携を有効化無効Cloudflare API 連携を有効にします
API トークン空Cloudflare API トークン。「Cache Purge」権限が必要です
Zone ID空Cloudflare ダッシュボードの右側に表示される Zone ID
ゾーン全体パージ有効キャッシュ全削除時に Cloudflare ゾーン全体をパージします
URL 別パージ有効特定の投稿・固定ページ更新時にその URL のキャッシュのみをパージします

Cloudflare API トークンの作成手順:

  1. Cloudflare API トークンページにアクセスします
  2. 「トークンを作成」をクリックします
  3. 「カスタムトークン」を選択します
  4. 権限に「ゾーン – キャッシュのパージ – 編集」を追加します
  5. ゾーンリソースに対象のドメインを設定します
  6. 「概要を続ける」→「トークンを作成する」をクリックします
  7. 表示されたトークンをコピーして Prime Cache に貼り付けます
ヒント: Cloudflare のキャッシュレベルを「Standard」以上に設定すると、HTML もキャッシュされます。WordPress の投稿を更新したときに Cloudflare キャッシュが自動パージされるため、訪問者に常に最新のコンテンツが表示されます。

Sucuri 連携

Sucuri WAF(Web Application Firewall)のキャッシュを Prime Cache と同期します。

設定デフォルト説明
Sucuri 連携を有効化無効Sucuri API 連携を有効にします
Sucuri API キー空Sucuri ダッシュボードから取得した API キー
Sucuri API シークレット空Sucuri ダッシュボードから取得した API シークレット

Varnish 連携

Varnish Cache サーバーに HTTP PURGE リクエストを送信してキャッシュを削除します。

設定デフォルト説明
Varnish 連携を有効化無効Varnish PURGE リクエストを有効にします
Varnish サーバー IP127.0.0.1Varnish サーバーの IP アドレス
Varnish ポート6081Varnish が待ち受けるポート番号
正規表現パージ無効正規表現で複数 URL を一括パージします(Varnish の設定でサポートが必要)
注意: Varnish PURGE が正常に動作するには、Varnish の VCL で PURGE メソッドを許可する設定が必要です。ご利用のホスティング会社の Varnish 設定ドキュメントをご確認ください。

プリロード(Pro 全機能)

Prime Cache > プリロード タブで設定します。

キャッシュを事前に生成し、ユーザーが次に訪問するページをブラウザに先読みさせて、ナビゲーションを瞬時に体験させます。

キャッシュプリロード

バックグラウンドクローラーがサイトを巡回し、キャッシュファイルを事前に生成します。訪問者がページにアクセスしたとき、生成済みのキャッシュがすぐに配信されます。

設定デフォルト説明
キャッシュプリロードを有効化無効バックグラウンドクローラーを有効にします
モバイルキャッシュプリロード無効デスクトップに加えてモバイル向けのキャッシュも事前生成します。モバイル別キャッシュが有効な場合に有効化してください
プリロード間隔500(ms)クローラーが各ページを取得する間隔。値が小さいと高速ですが、サーバー負荷が増加します
同時リクエスト数3同時に処理するプリロードリクエスト数
Vary Cookie との関係: Vary Cookie(後述)が有効な場合、プリロードはデフォルトバリアント(Cookie なし状態)のみを生成します。Cookie 別の異なるキャッシュバリアントは、実際の訪問者が初めてアクセスしたときに生成されます。

サイトマッププリロード

XML サイトマップに記載された URL をすべてプリロード対象として使用します。サイト全体のキャッシュを効率的に生成できます。

設定デフォルト説明
サイトマッププリロードを有効化無効サイトマップの URL をプリロード対象に含めます
サイトマップ URL空(自動検出)手動でサイトマップ URL を指定する場合に入力します。空の場合は WordPress の標準サイトマップを使用します

JavaScript を使用して、訪問者がホバーまたはビューポートに入ったリンクをプリフェッチ(先読み)します。

設定デフォルト説明
リンクプリフェッチを有効化無効JavaScript ベースのリンクプリフェッチを有効にします
プリフェッチモードhoverhover(ホバー時)/ viewport(画面内のリンク)から選択
ホバー遅延65(ms)ホバーモード時にプリフェッチを開始するまでの遅延時間。誤ったプリフェッチを防ぎます
除外セレクター空プリフェッチ対象から除外するリンクの CSS セレクター
ヒント: ホバーモードは訪問者がリンクに近づいた時(クリックの約 65ms 前)にプリフェッチを開始します。これにより、クリックされたときにはすでにページがバックグラウンドで読み込まれており、遷移が体感的に瞬時になります。ビューポートモードは画面内のすべてのリンクをプリフェッチするため、サーバー負荷が高くなる可能性があります。

Speculation Rules API

Chrome 109+ で対応した新しいブラウザ API を使用して、訪問者が遷移しそうなページを事前にレンダリング(プリレンダリング)します。対応ブラウザでは遷移が仮想的に即座になります。非対応ブラウザはルールを無視します。

設定デフォルト説明
Speculation Rules を有効化無効Speculation Rules API によるプリレンダリングを有効にします
モードprerenderprefetch(先読みのみ)/ prerender(完全なプリレンダリング)
Eagernessmoderateconservative(ホバー時)/ moderate(中間)/ eager(即時)
対応ブラウザ: Speculation Rules API は Chrome 109+ / Edge 109+ で対応しています(2026年5月時点)。Safari や Firefox は対応していませんが、これらのブラウザはルールを単純に無視するため、副作用はありません。

フォントプリロード

サイトで使用されている Web フォントを自動検出し、<link rel="preload"> タグを追加します。フォントの読み込みを優先させることで、FOUT(Flash of Unstyled Text)を軽減します。

設定デフォルト説明
フォントプリロードを有効化無効CSS から @font-face フォントを自動検出してプリロードします
最大プリロード数4プリロードするフォントファイルの最大数。多すぎると帯域幅を消費します

LCP 最適化

ページの LCP(Largest Contentful Paint)要素を最適化して描画を高速化します。

設定デフォルト説明
LCP 最適化を有効化無効LCP 画像の fetchpriority="high" 付与と <link rel="preload"> の自動追加を有効にします
LCP 画像を手動指定空自動検出に頼らず、LCP 画像の URL を手動で指定します
最初の N 枚の画像を除外3Lazy Load の対象から最初の N 枚を除外し、fetchpriority="high" を付与します。これにより LCP 画像が優先的に読み込まれます
ヒント: Core Web Vitals の LCP スコアを改善するには、ヒーロー画像(ファーストビューの大きな画像)に fetchpriority="high" を付与することが最も効果的です。LCP 最適化を有効にするだけで、自動検出された LCP 画像に適切な属性が付与されます。

CSS の背景画像にも対応(1.10.0): ファーストビューの最大要素が CSS の background-image で描かれている場合(Avada・Divi・Elementor のヒーローによくある構成)、<img> タグがないため、ブラウザはスタイルシートを読み込んで解析するまで画像を見つけられません。LCP 最適化は、インラインの style 属性やページ自身のスタイルシートからその背景画像を見つけ、<link rel="preload" as="image" fetchpriority="high"> を早い位置に追加します。対象は同じオリジンの画像だけです。フィルター prime_cache_lcp_background_preload で無効にできます。

DNS Prefetch / Preconnect

外部ドメインへの DNS ルックアップ・TCP 接続・TLS ハンドシェイクを事前に行い、外部リソースの読み込みを高速化します。

設定デフォルト説明
DNS Prefetch を有効化無効外部ドメインの DNS 解決を事前に行います。リソースの読み込み遅延を削減します
DNS Prefetch ドメイン空(自動検出)手動で DNS Prefetch を追加するドメイン(1行に1つ)。空の場合はページ内の外部リソースから自動検出します
Preconnect を有効化無効外部ドメインとの TCP 接続と TLS ハンドシェイクを事前に確立します。DNS Prefetch より効果的ですが、接続維持のコストがかかります
Preconnect ドメイン空(自動検出)手動で Preconnect を追加するドメイン(1行に1つ)
最大 Preconnect 数4自動検出時の最大 Preconnect 数。セルフドメインは自動除外されます
ヒント: Google Fonts、Google Analytics、Facebook、YouTube など、頻繁に使用する外部サービスのドメインを Preconnect に追加すると効果的です。Preconnect 数は多すぎると逆効果になることがあるため、デフォルトの上限(4)を維持することを推奨します。

手動リソースプリロード

特定のリソース(画像、フォント、スクリプト、スタイルシートなど)を手動で <link rel="preload"> に追加します。

設定説明
リソース URLプリロードするリソースのフルパスまたは URL
リソースタイプimage / font / script / style / fetch。空の場合は拡張子から自動判定

設定例:

リソース URL: /wp-content/themes/my-theme/fonts/custom-font.woff2
リソースタイプ: font

リソース URL: /wp-content/themes/my-theme/images/hero.jpg
リソースタイプ: image

オブジェクトキャッシュ

Prime Cache > オブジェクトキャッシュ タブで設定します。

WordPress のデータベースクエリ結果をメモリに保持する永続的オブジェクトキャッシュを設定します。データベースへのクエリ数を削減し、特にクエリの多いサイト(WooCommerce、BuddyPress など)でページ生成時間を大幅に短縮します。

APCu / Redis / Memcached

バックエンド特徴必要な拡張推奨シーン
APCuPHP プロセスのメモリを共有。設定が最も簡単。サーバー再起動でキャッシュがクリアapcu PHP 拡張単一サーバー・小〜中規模サイト
Redis高速なインメモリデータストア。再起動でもキャッシュが持続。クラスター対応redis(PhpRedis)PHP 拡張大規模サイト・複数サーバー
Memcached分散メモリキャッシュ。複数サーバー間でのキャッシュ共有が可能memcached(PECL)PHP 拡張分散環境・レガシーシステム

有効化の手順:

  1. Prime Cache > オブジェクトキャッシュ タブを開きます。
  2. 各バックエンドのカードに「有効」「利用可能」「未検出」のいずれかが表示されます。PHP 拡張がない場合、ボタンは「PHP 拡張が必要です」と表示され押せません。
  3. 使いたいバックエンドのカードで「有効化」をクリックすると、wp-content/object-cache.php ドロップインが設置されます。
  4. 画面上部の状態表示が「オブジェクトキャッシュ: APCU で有効」のように変われば完了です。止める場合は「無効化」をクリックします。

状態表示:

表示意味
オブジェクトキャッシュ: %s で有効選択したバックエンドで動作しています。
オブジェクトキャッシュ: 無効オブジェクトキャッシュを使っていません。
オブジェクトキャッシュ: 外部プラグインが管理中別のプラグインの object-cache.php が設置されています。
オブジェクトキャッシュ: 設置済みですが動作していませんドロップインは設置されていますが、バックエンドを読み込めていません(PHP 拡張が無効、またはサイト移転でパスが解決できないなど)。WordPress は内部キャッシュで動いています。バックエンドをいったん無効化して有効化し直すと修復できます(Pro 1.9.6)。

「設置済みですが動作していません」の状態になると、ダッシュボード・プラグイン画面・Prime Cache 画面にも通知が表示され、ドロップインが再び動作すると自動で消えます(Pro 1.10.2)。なお 1.9.7 から、サイトの移転やステージングへの複製でドロップインに書き込まれた絶対パスが見つからない場合も、wp-content/plugins/prime-cache-pro/ からバックエンドを読み込むようになりました(反映にはバックエンドの有効化し直しが必要です)。

Redis の接続設定(wp-config.php の定数):

Redis の接続先は管理画面ではなく wp-config.php の定数で指定します。定義しない場合は次のデフォルト値で接続します。

定数デフォルト説明
WP_REDIS_HOST127.0.0.1Redis サーバーのホスト名または IP アドレス
WP_REDIS_PORT6379Redis サーバーのポート番号
WP_REDIS_PASSWORD空Redis 認証パスワード(設定されている場合)
WP_REDIS_DATABASE0使用する Redis データベース番号
WP_REDIS_TIMEOUT1(秒)接続タイムアウト
WP_REDIS_PREFIXサイト固有の値(自動)キーのプレフィックス。未定義の場合は、同じサーバー上の他のサイトと衝突しないサイト固有の値が自動で使われます
WP_REDIS_MAXTTL0(無制限)キャッシュの最大保持秒数

Memcached の接続設定(wp-config.php の定数):

定数デフォルト説明
WP_MEMCACHED_SERVERSarray( '127.0.0.1:11211' )接続する Memcached サーバー(ホスト:ポート の配列)
WP_MEMCACHED_MAXTTL0(無制限)キャッシュの最大保持秒数。Memcached はキーを列挙できないため、確実にメモリを回収したい場合に上限を設定します(Pro 1.9.5)

autoload オプションと「alloptions」の除外

WordPress は autoload(自動読み込み)設定のオプションをすべて「alloptions」という 1 つのオブジェクトにまとめ、リクエストごとに読み込み、オプションが更新されるたびに保存し直します。これが大きくなると、永続オブジェクトキャッシュを有効にしたとたんにサイト全体が極端に遅くなることがあります(実例: autoload 約 3.9 MB で 1 クリック 20 秒以上)。

  • autoload の警告(Pro 1.10.2): autoload オプションの合計が 1 MB を超えるとオブジェクトキャッシュタブに警告が、3 MB を超えると強い警告が表示され、サイズの大きいオプションが一覧されます。計測のみで、オプションを変更することはありません。
  • 継続監視(Pro 1.10.5): autoload のサイズを毎日計測し、3 MB を超えるとダッシュボード・プラグイン画面・Prime Cache 画面に通知を表示します。「autoload オプションを確認」でタブを開き、「閉じる」で非表示にできます。閉じた後はさらに 1 MB 増えたときにだけ再表示されます。ページ表示時に計測を行うことはありません。
  • 「alloptions」をオブジェクトキャッシュから除外(Pro 1.10.4): バックエンドが動作中のときに表示されるカードです。「オンにする」を押すと、alloptions だけをリクエストごとにデータベースから 1 回読み込み、それ以外のキーは引き続きキャッシュします。初期状態はオフで、autoload が大きいサイトにだけ推奨します。オンにする前に、診断タブの「alloptions のフラッシュ後読み込み自己テスト」が「成功」になっていることを確認してください。

動作上の注意

  • キャッシュのクリアでメモリを解放(Pro 1.9.5): 以前はキャッシュのクリア時に古いデータがメモリに残り、APCu では共有メモリが埋まって逆に遅くなることがありました。現在は APCu・Redis とも、このサイトのキーだけを実際に削除します(同じサーバーの他サイトのデータには触れません)。
  • 保存に失敗した値を残さない(Pro 1.9.4 / 1.9.9 / 1.10.10): メモリ不足などでバックエンドが書き込みを拒否した場合も、古い値が読み出され続けないようにしています。1.10.10 で APCu のキーの形式を変更したため、更新後に一度キャッシュをクリアしてください。
  • ログイン情報は APCu に置かない(Pro 1.10.7): 複数の独立した PHP プロセスでサイトを動かすサーバーでは、APCu の内容がプロセス間で共有されず、管理画面でランダムにログイン画面へ戻されることがありました。このため APCu 使用時は、アカウントとセッションのグループ(user_meta、users、userlogins、useremail、userslugs)をキャッシュせずデータベースから読み込みます。APCu がすべてのプロセスで共有されていることが確実なサーバーでは、wp-config.php に PRIME_CACHE_OC_PERSIST_USER_GROUPS を定義するとキャッシュ対象に戻せます。Redis と Memcached は対象外です。
  • APCu が本当にプロセス間で共有されているかは、診断タブの「Cross-process consistency」で確認できます。
注意: オブジェクトキャッシュを有効にすると wp-content/object-cache.php が作成されます。他のキャッシュプラグインの object-cache.php が既にある場合は「外部プラグインが管理中」と表示され、Prime Cache からは切り替えられません。先にそのプラグインのオブジェクトキャッシュを無効にしてください。

診断

Prime Cache > 診断 タブ(Pro 1.10.3 以降)で確認します。サポートに問い合わせる際に最初に聞かれる情報を 1 画面にまとめた、読み取り専用の画面です。設定を変更することはありません。

カード表示内容
環境PHP バージョンと SAPI、WordPress バージョン、サーバーソフトウェア
キャッシュドロップインオブジェクトキャッシュの状態、「書き込み・読み込みの往復テスト」、「Cross-process consistency」、object-cache.php / advanced-cache.php の有無、WP_CACHE の状態
APCuAPCu 使用時のみ。メモリ使用量、キャッシュ件数、ヒット率、追い出し(evictions)の回数。メモリ使用率が 90% を超えるか追い出しが起きている場合は、apc.shm_size を増やすよう案内します
WebP / AVIF 配信画像の配信方式が .htaccess の「rewrite」のときのみ。変換済み画像を 1 枚ループバックで取得し、実際に変換画像が配信されているかを確かめます(Pro 1.10.11)
autoload オプションautoload オプションの合計サイズと大きいオプションの上位、「alloptions」除外の状態、「alloptions のフラッシュ後読み込み自己テスト」の結果(Pro 1.10.4)
  • 書き込み・読み込みの往復テスト: 同じリクエスト内で値を書き込んで読み戻せるかを確かめます。「有効」と表示されているのに値を保存できていないバックエンドを見つけられます。
  • Cross-process consistency(Pro 1.10.7): 書き込んだプロセスとは別のプロセスから値が見えるかを、数分かけてバックグラウンドで計測します。計測中は「Measuring」、共有されていれば「Shared」、共有されていなければ「Not shared between processes」と表示されます。「Not shared」の場合は Redis か Memcached に切り替えるか、オブジェクトキャッシュをオフにしてページキャッシュだけを使ってください。この項目は現在、日本語訳のない英語表記で表示されます。
  • WebP / AVIF 配信のループバックテスト: 「変換されず元画像が配信されています」と表示された場合、Xserver の X Accelerator、LiteSpeed、nginx のフロント、一部の CDN のように静的ファイルを直接返すサーバーが .htaccess のリライトを実行していないため、訪問者に変換画像が届いていません。画像の配信方式を「picture タグ」か「URL リライト」に切り替えてください。

データベース最適化

Prime Cache > データベース タブで設定します。

WordPress データベースの肥大化を防ぎ、クエリのパフォーマンスを維持するためのクリーンアップ機能です。クリーンアップ実行前に各項目の件数が表示されます。

クリーンアップ項目

項目説明推奨頻度
投稿リビジョン投稿・固定ページの編集履歴を削除します。wp_posts テーブルが肥大化している主要な原因です月次
自動下書きWordPress が自動保存した未公開の下書きを削除します月次
ゴミ箱内の投稿ゴミ箱に入れた投稿・固定ページを完全削除します月次
スパムコメントスパムとしてマークされたコメントを削除します週次
ゴミ箱内のコメントゴミ箱に入れたコメントを完全削除します月次
期限切れトランジェントwp_options テーブルの期限切れ一時データを削除します週次
すべてのトランジェント期限内のものも含めてすべてのトランジェントを削除します。プラグインが多いサイトで肥大化していることが多いです月次(注意して使用)
テーブル最適化断片化したデータベーステーブルに OPTIMIZE TABLE を実行します。削除後の断片化を解消してクエリを高速化します月次

一括クリーンアップの実行手順:

  1. Prime Cache > データベース タブを開きます
  2. 各項目のチェックボックスを選択します。件数が右側に表示されます
  3. 「クリーンアップを実行」をクリックします
  4. 確認ダイアログが表示されます。「OK」をクリックして実行します
  5. 完了後、削除された件数がレポートとして表示されます
注意: クリーンアップ前に必ずデータベースのバックアップを取ってください。特に「すべてのトランジェント」は、一部のプラグインの設定や API トークンがトランジェントに保存されている場合があり、削除するとプラグインの動作に影響することがあります。

自動スケジュール

WP-Cron を使ってデータベースクリーンアップを定期的に自動実行します。

設定デフォルト説明
自動クリーンアップを有効化無効スケジュールに従って自動クリーンアップを実行します
実行頻度monthlydaily(毎日)/ weekly(週次)/ monthly(月次)
自動クリーンアップ対象投稿リビジョン、自動下書き、期限切れトランジェント自動実行する項目をチェックボックスで選択します
ヒント: 自動クリーンアップは WP-Cron で実行されます。サイトへのアクセスが少ない場合は WP-Cron が実行されないことがあります。確実に実行したい場合は、サーバーの cron でWP-Cron を定期的にトリガーする設定を追加することを推奨します。

Heartbeat API 制御

Prime Cache > パフォーマンスツール > Heartbeat API セクションで設定します。

WordPress の Heartbeat API は定期的に管理画面と通信し、自動保存、ログイン状態の確認、プラグイン更新通知などに使用されます。フロントエンドでの Heartbeat はサーバー負荷の原因となるため、適切に制御することを推奨します。

場所別・モード設定

場所設定キーデフォルト推奨設定
フロントエンドheartbeat_frontend有効無効(フロントエンドでは Heartbeat は不要です)
管理画面ダッシュボードheartbeat_admin有効頻度を下げる(15-60秒)
投稿エディターheartbeat_editor有効有効または頻度を下げる(自動保存に必要)

各場所で選択できるモード:

モード説明
Allow(有効)WordPress のデフォルト設定で Heartbeat を動作させます
Reduce(頻度を下げる)Heartbeat の実行間隔を指定した秒数に変更します(15-300秒)。標準は15秒です
Disable(無効)Heartbeat を完全に無効化します。フロントエンドでの推奨設定です
設定デフォルト説明
カスタム間隔(秒)60「Reduce」モード時の実行間隔。15-300秒の範囲で指定します
推奨設定: フロントエンドの Heartbeat を「無効」に設定するだけで、サーバーへの定期的な ajax リクエストが排除され、サーバー負荷が軽減されます。投稿エディターの Heartbeat を「無効」にすると自動保存が機能しなくなるため、注意してください。

セキュリティヘッダー

Prime Cache > ツール > セキュリティヘッダー セクションで設定します。

HTTP レスポンスヘッダーにセキュリティ関連のヘッダーを追加します。ブラウザに対してセキュリティポリシーを指示することで、さまざまな攻撃を防御します。

HSTS・各種セキュリティヘッダー

ヘッダーデフォルト説明
HSTS(HTTP Strict Transport Security)無効ブラウザに HTTPS 接続のみを使用するよう指示します。max-age で有効期間(秒)を指定します。HTTPS サイトのみで有効化してください
HSTS max-age31536000(1年)HSTS ポリシーの有効期間(秒)。includeSubDomains と preload オプションも設定できます
X-Content-Type-Options無効nosniff を設定して、ブラウザが MIME タイプを自動判定しないよう指示します。MIME スニッフィング攻撃を防ぎます
X-Frame-Options無効サイトを <iframe> に埋め込むことを制限します。クリックジャッキング攻撃を防ぎます。DENY(完全禁止)または SAMEORIGIN(同一オリジンのみ許可)を選択できます
X-XSS-Protection無効ブラウザの XSS フィルターを有効にします。1; mode=block を設定すると、XSS 攻撃が検出された場合にページの読み込みをブロックします
Referrer-Policy無効リンクをクリックしたときにリファラー情報をどの程度共有するかを制御します。strict-origin-when-cross-origin が一般的に推奨されます
Permissions-Policy無効カメラ・マイク・位置情報などのブラウザ機能へのアクセスを制限します。使用しない機能を明示的に無効化できます

推奨設定例:

HSTS: 有効
  max-age: 31536000
  includeSubDomains: はい
  preload: いいえ(HSTS preload リストへの登録を別途申請した場合のみ「はい」)

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN
  (自サイト内で iframe を使用している場合は SAMEORIGIN、完全に禁止する場合は DENY)

X-XSS-Protection: 1; mode=block

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy: camera=(), microphone=(), geolocation=()
  (サイトで使用しない機能を空の許可リストで禁止)
注意: HSTS を有効にすると、ブラウザは指定された max-age の期間中、サイトへの HTTP アクセスを自動的に HTTPS にリダイレクトします。SSL 証明書に問題が発生した場合でも訪問者がアクセスできなくなる可能性があります。本番環境で設定する前に、SSL 証明書が正常に機能していることを確認してください。

高度なキャッシュ設定

Vary Cookie キャッシュ

Prime Cache > ページキャッシュ > キャッシュ制御 セクションで設定します。

Cookie の値に応じて異なるキャッシュバリアントを生成します。ログイン状態や言語設定、会員グループなど、Cookie によってページの表示内容が変わる場合に使用します。

設定デフォルト説明
Vary Cookie を有効化無効指定した Cookie の値別に異なるキャッシュを生成します
対象 Cookie 名空バリアント生成に使用する Cookie 名(1行に1つ)

使用例:

例1: 言語切り替えに対応
  対象 Cookie: lang
  → lang=ja のユーザーと lang=en のユーザーに別のキャッシュを配信

例2: 会員ランク別に表示内容を変える
  対象 Cookie: membership_level
  → 一般会員と プレミアム会員に別のキャッシュを配信
注意: Vary Cookie を有効にすると Cookie の組み合わせ数だけキャッシュバリアントが生成されます。Cookie の取り得る値が多い場合、ストレージ使用量が大幅に増加します。また、プリロードはデフォルトバリアント(Cookie なし)のみ対応します。Cookie 別バリアントは実際の訪問者が最初にアクセスしたときに生成されます。

クエリ文字列キャッシュ

Prime Cache > ページキャッシュ > キャッシュ制御 セクションで設定します。

通常、クエリ文字列(?key=value)が付いた URL はキャッシュ対象外となります。クエリ文字列キャッシュを有効にすることで、特定のクエリ文字列を含む URL もキャッシュ対象にできます。

設定デフォルト説明
クエリ文字列をキャッシュ無効クエリ文字列付きの URL をキャッシュします
キャッシュ対象クエリ文字列空キャッシュ対象とするクエリパラメーター名(1行に1つ)。指定した名前以外のクエリ文字列はキャッシュ対象外のまま

404 ページキャッシュ

存在しない URL へのアクセスで表示される 404 ページをキャッシュします。大量の 404 リクエストがある場合のサーバー負荷を大幅に削減できます。

設定デフォルト説明
404 ページをキャッシュ無効404 Not Found レスポンスをキャッシュします
404 キャッシュの有効期間3600(秒)404 キャッシュの TTL。通常のキャッシュと同じ期間に設定することを推奨します
ヒント: スパムボットや古いリンクからの大量の 404 アクセスがある場合、404 ページキャッシュを有効にするとサーバーが WordPress を起動せずに 404 ページを返せるため、負荷が大幅に削減されます。

ドロップインモードのワンクリック有効化

Pro 版 1.9.0 以降。ページキャッシュが有効で、wp-config.php の WP_CACHE がまだ true になっていない場合、Prime Cache の設定画面に案内が表示され、「ドロップインモードを有効化 ( wp-config.php を編集 )」ボタンで define( 'WP_CACHE', true ); を追加できます(false と定義されている場合は true に書き換えます)。これにより、WordPress 本体の読み込み前にキャッシュを返すドロップインモードになります。

  • 編集前に、日時付きのバックアップを wp-config.php と同じ場所に保存します。
  • 該当行だけを書き換え、内容を検証してから保存します。検証やバックアップに失敗した場合、ファイルは変更しません。
  • マルチサイトでは表示されません。wp-config.php に書き込めない場合は、手動で追加するよう案内します(手順は Free 版マニュアルを参照)。
  • 有効なライセンスが必要です。Free 版だけの場合は、手動の手順のみが表示されます。

サーバー側キャッシュの検出

Pro 版 1.10.0 以降。Xserver の X Accelerator、LiteSpeed、Kinsta、SiteGround、WP Engine、nginx のマイクロキャッシュ、CDN のエッジキャッシュなど、サーバー側のページキャッシュが Prime Cache の前段にある場合、Prime Cache のパージが届かず、最適化前の古いページが配信され続けることがあります。Prime Cache 設定画面は、サイト自身のレスポンスヘッダーからこの層を検出すると「サーバーレベルのページキャッシュ (…) を検出しました」という案内を表示します。サーバー側のキャッシュを止めて Prime Cache に任せるか、Prime Cache のページキャッシュを止めてサーバー側に任せるか、どちらかに役割を分けてください。案内は表示のみで、設定は変更しません。「閉じる」で非表示にできます。Cloudflare と Varnish は、Pro の連携機能で管理している場合は対象外です。

高度なパージトリガー

Prime Cache は以下のイベントで自動的にキャッシュをパージします。

イベントパージ範囲
投稿の公開・更新・削除・ゴミ箱移動該当投稿ページ + アーカイブ・カテゴリーページ
コメントの投稿・承認・編集・削除コメントが付いた投稿ページ
タームの作成・編集・削除タームアーカイブページ
テーマ切り替え・テーマの更新全キャッシュ
パーマリンク構造変更全キャッシュ
プラグインの有効化・無効化・更新全キャッシュ
カスタマイザー保存全キャッシュ
ウィジェット更新全キャッシュ
ナビゲーションメニュー更新全キャッシュ
WordPress コア更新全キャッシュ
プラグイン・テーマ更新時のパージは Free 版 1.10.57 以降。各トリガーは Free 版の「自動パージ」タブで個別にオン/オフできます
ユーザープロフィール更新全キャッシュ

常時パージ URL の設定:

投稿更新時に合わせて常にパージしたい URL(ホームページ、人気記事ページなど)を設定できます。

設定説明
常時パージ URL投稿パージ時に合わせてキャッシュを削除する URL(1行に1つ)。サイト内の相対パスで指定します

AI 相談

Prime Cache > AI 相談 タブで設定します(Pro 版 1.8.0 以降)。

サイトの環境と公開トップページの構造を計測し、AI が遅さの原因を日本語で説明して、優先順位付きの対策プランを提示します。推奨設定はワンクリックで適用でき、環境に即した追加質問にも答えます。

完全オプトイン・BYOK 方式です。有効化して診断を実行するまで、外部へは一切送信しません。AI の利用料はお客様がご用意いただく API キー側で課金され、診断データが Rapls Works を経由することはありません。

AI プロバイダーとモデル

次のいずれかを選択します。API キーはこのサイトに保存され、選択したプロバイダーだけに送信されます。プロバイダーごとにキーを個別保存するため、切り替えても各キーが保持されます。

プロバイダーAPI キー主なモデル(プルダウン選択)
Anthropic (Claude)必要Claude Opus 4.8 / Sonnet 5 / Haiku 4.5
OpenAI必要GPT-5.2 系 / o4
OpenRouter必要Claude / GPT / Gemini / DeepSeek / Llama など
Google Gemini必要Gemini 2.5 Pro / 2.5 Flash / 2.0 Flash
WordPress AI コネクター(実験的)不要WordPress 本体に設定済みの AI(AI Services プラグイン等)を利用

一覧にないモデルは「カスタム」を選んで正確なモデル名を入力できます。設定後は「接続テスト」ボタンで、キー・モデル・接続が有効かを事前に確認できます。

スピード診断の使い方

  1. AI 相談を有効化にチェックを入れ、データ送信に同意します。
  2. プロバイダーとモデルを選び、API キーを入力して保存、接続テストで確認します。
  3. AI 診断を実行を押します(20〜60 秒)。
  4. 結果として、総括・所見(重要度付き)・推奨設定・判断が必要な対応が表示されます。
  5. 推奨設定は適用ボタンでワンクリック反映(キャッシュは自動削除)。反映後はモバイルで 1 ページ表示してから PageSpeed Insights 等で再計測してください。

安全性: AI が提案する設定変更は、あらかじめ定めた許可リスト(キーと値の型・範囲)で二重に検証されます。認証情報・パージルールなど許可外の項目は変更できず、既知の危険な値(例: Nginx 環境での rewrite 画像配信)は自動的に破棄されます。訪問者のデータが分析対象に含まれることはありません。

追加質問チャット

診断結果とサイト環境を文脈として、環境に即した質問に答えます。例:「このサーバーで wp-config.php を編集するには?」。なお AI は案内のみを行い、AI の回答によって wp-config.php が書き換えられることはありません(ドロップインモードの有効化は、ワンクリック有効化のボタンから行えます)。

よくある質問

FAQ

Q: Pro版は Free版なしでインストールできますか?

A: いいえ。Prime Cache Pro は Free版のアドオンです。まず Free版(prime-cache)をインストール・有効化してから、Pro版をインストールしてください。Free版がない状態では Pro版は動作しません。

Q: ライセンスは複数のサイトで使用できますか?

A: 1ライセンスにつき1サイトで使用できます。複数サイトに導入する場合は、それぞれのサイト用にライセンスを購入してください。サイトを移行する場合は、旧サイトでライセンスを「無効化」してから新サイトで「有効化」してください。

Q: WebP 変換が機能しない場合はどうすればよいですか?

A: Prime Cache > ツール > システム情報 で GD または Imagick の PHP 拡張が有効になっているか確認してください。両方とも無効の場合は、ホスティング会社に PHP 拡張のインストールを依頼してください。共有ホスティングでは PHP 7.4 以上で GD が利用可能な場合がほとんどです。

Q: CSS/JS 結合後にサイトの表示が崩れた場合はどうすればよいですか?

A: まず管理画面の管理バーから「キャッシュを全削除」を実行してください。それでも問題が解決しない場合は、「除外する CSS/JS」に問題のファイルを追加してください。ブラウザの開発者ツール(F12)でコンソールエラーを確認すると、問題の原因を特定しやすくなります。

Q: Delay JS でページの一部が動作しなくなった場合は?

A: 問題のあるスクリプトを「遅延対象外の JS」に追加するか、「Delay JS セーフモード」を有効にしてください。セーフモードでは外部スクリプトのみを遅延するため、自サイトのスクリプトは即座に実行されます。

Q: Cloudflare と Prime Cache の両方を使用する場合の設定は?

A: Cloudflare の「キャッシュルール」でサイトの HTML をキャッシュする設定にし、Prime Cache の Cloudflare 連携を有効にします。投稿を更新すると、Prime Cache が WordPress のキャッシュと Cloudflare のキャッシュを両方パージします。Cloudflare の「開発モード」を使用してキャッシュを一時的に無効化しながら設定を確認することを推奨します。

Q: Redis を使用する場合、何か追加の設定が必要ですか?

A: サーバーに Redis がインストールされ、PHP の redis(PhpRedis)拡張が利用可能であれば、オブジェクトキャッシュタブの Redis カードで「有効化」を押すだけで使用できます。Redis が同じサーバーの 127.0.0.1:6379 以外にある場合や、管理された Redis サービス(AWS ElastiCache、Upstash など)を使う場合は、wp-config.php に WP_REDIS_HOST・WP_REDIS_PORT、必要に応じて WP_REDIS_PASSWORD を定義してください(接続設定参照)。

Q: データベース最適化の「すべてのトランジェント削除」は安全ですか?

A: 一部のプラグインは API レスポンスや設定をトランジェントにキャッシュしています。「すべてのトランジェント削除」を実行すると、これらのキャッシュが削除され、次のアクセス時に再生成されます。通常は問題ありませんが、削除後に問題が発生した場合は、各プラグインのキャッシュを再生成してください。安全のため、初回は「期限切れトランジェント」のみ削除することを推奨します。

Q: Speculation Rules API はすべてのブラウザで動作しますか?

A: いいえ。Chrome 109+ と Edge 109+ でのみ対応しています。Safari や Firefox はルールを無視するだけで、副作用はありません。したがって、対応ブラウザのユーザーのみが恩恵を受けます。

Q: セキュリティヘッダーを設定すると既存の iframe 埋め込みに影響しますか?

A: X-Frame-Options を DENY に設定すると、自サイトのページが他サイトの iframe に埋め込まれなくなります。また、自サイト内の iframe 埋め込みも制限される場合があります。SAMEORIGIN を使用すると、同一オリジン(同じドメイン)からの埋め込みは許可されます。YouTube などの外部の iframe 埋め込みは、この設定の影響を受けません(X-Frame-Options はサイト自身を保護するためのヘッダーです)。

Q: AVIF 変換は WebP より優れていますか?

A: AVIF は WebP よりも圧縮率が高く、同じ品質でより小さいファイルサイズを実現できます。ただし、変換にかかる時間が WebP より長く、サーバーへの負荷も高くなります。また、AVIF の変換には ImageMagick 7.0.25+ または PHP 8.1+ の GD が必要です。ブラウザの対応状況は WebP よりやや劣りますが(Chrome、Firefox、Safari 16+ で対応)、将来的な標準フォーマットです。

タイトルとURLをコピーしました