コンテンツにスキップ 
このガイドでは、ロード時間、SEO、ユーザビリティが目に見えて改善されるように、WordPressのパフォーマンス監査を計画、測定、実施する方法をステップごとに説明します。明確な目標を設定し、LCP、FID、CLS などのメトリクスを使用して作業し、ステージングと バックアップ より。
中心点
最も重要な成功要因を簡単に要約し、私が監査で最初に取り組むレバーを強調する。 スピード そして安定性だ。
- 目標 テストを開始する前に、完全なバックアップを作成してください。
- 指標 (LCP、FID、CLS）、ボトルネックを特定し、優先順位をつける。
- ホスティング そして、私がコードを微調整する前に、インフラストラクチャー。
- キャッシング画像、コード、データベースを体系的に合理化。
- モニタリング そして継続的に改善を確認する。
準備：目標設定とクリーン・バックアップ
明確な目標値がないと細かい作業に没頭してしまうので、私はスタート前に測定可能な主要数値を定義し、最も重要なものに優先順位をつけている。 結果.例えば、スタートページでは、最初のバイトまでの時間を200ミリ秒以下、LCPを2.5秒以下に計画している。さらに、いつでも変更をロールバックできるように、ページ全体を保存する。 バックアップ データベースとアップロードも含めて。私はまず、ステージング環境で変更をテストし、実トラフィックが影響を受けないようにします。こうしてリスクを最小限に抑え、ステージングで明らかに速くなったものだけをリリースします。
パフォーマンス・テスト：メトリクスを理解し、きれいに測定する
私は、実際のデータに基づいて決断できるように、再現性のあるラボやフィールドのデータから始める。 データ をサポートしている。概要については、PageSpeedレポート、GTmetrix、Pingdom、さらにChromeのLighthouseとサーバーログを使ってレスポンスタイムをチェックしている。最初のチェックで、スクリプトのブロック、最適化されていない画像、非効率的なクエリなどが見つかり、変更後に2回目のチェックを行うと効果が確認できます。より詳細なインプットのために、私は特に以下にアクセスする。 ページスピードの洞察テンプレートごとの主なボトルネックがすぐにわかるからです。私は以下の表を目標廊下として使い、各ページタイプごとに調整している：
| 指標 | 目標値 | ヒント |
|---|---|---|
| 充電時間（完了） | < 2 s | スタートページとトップランディングページに優先順位をつける。 |
| ラージ・コンテントフル・ペイント（LCP） | < 2,5 s | ヒーロー画像、タイトルブロック、大きな要素を高速化。 |
| ファースト・インプット・ディレイ（FID） | < 100 ms | インタラクションを高速化し、JSの負荷を軽減する。 |
| 累積レイアウトシフト（CLS） | < 0,1 | メディアと広告の固定サイズを設定します。 |
インフラとホスティング：基本的な速度の確保
プラグインを分解する前に、サーバーの場所、PHPのバージョン、オブジェクトキャッシュ、HTTP/2またはHTTP/3のサポートをチェックする。 ベース を設定します。最新のプラットフォーム、NVMeストレージ、キャッシング・レイヤーを備えた高速プロバイダーは、コードの最適化の手間を省きます。独自に比較した結果、webhoster.deは強力なパフォーマンス、優れたセキュリティ、レスポンスの良いサポートでテストの勝者であることが証明された。ホストを変更できない場合、私は少なくともOPcacheと最新のPHPバージョンをセットアップする。また、I/Oや同時処理などの制限で速度が低下していないか、負荷がかかっている状態で監視し、速度が低下している場合は関税やアーキテクチャを調整する。 定員 は十分ではない。
画像とメディア：サイズダウン、効果アップ
大きなファイルは定番なので、画像を最新のフォーマットに変換し、実際に使用するサイズに縮小する。 幅.ShortPixelやSmushのようなツールは、目に見える品質の低下なしにキロバイトを節約する。私は、LCPが低下するように、ヒーロー要素を優先し、正しく設定されたプリロードで読み込みます。動画の埋め込みは必要な場合のみとし、サムネイルとクリックによる読み込みを使用することで、開始時の重さを低く抑えている。アイコンはSVGスプライトにまとめる。 レンダリング時間 をプレスする。
キャッシングとCDN：繰り返し利用されるコンテンツのための高速な方法
ページキャッシュとオブジェクトキャッシュを使えば、WordPressがダイナミックパーツを生成する頻度が減り、サーバーの動作が減るため、1回の呼び出しあたりの計算時間が大幅に短縮される。 スピード.CDNは、静的アセットを地理的に訪問者の近くに配信し、特に国際的なトラフィックでの待ち時間を短縮します。厄介なケースのために、私は動的なブロックを未変更としてマークし、キャッシュがそれらをより長く保持し、例外を最小限に抑えることができるようにしています。更新後にキャッシュを無効にするための一連のルールは、ページ全体を常に再生成することなく、古い出力を防ぎます。一般的なメソッドの概要が知りたい場合は、この ワードプレスのパフォーマンス 私が監査で優先させるテクニックをまとめた。
コードとデータベース：バラストを減らす
私はCSSとJavaScriptを最小化し、ファイルを慎重に組み合わせ、スクリプトを遅延させてロードすることで、重要な 内容 が最初に現れます。同時に、使っていないプラグインやテーマも削除しています。すべての拡張機能にはエントリーやフック、オートローダーのチェックが必要だからです。データベースでは、古いリビジョン、スパムコメント、期限切れのトランジェントを削除しています。大きなオプションテーブルについては、定期的にwp_optionsのオートロードフィールドをチェックして、ページ呼び出しのたびに不要なバラストがロードされないようにしています。 データベースの最適化 これをチェックリストとして使う。最後に、クエリ・モニターでメインクエリがより無駄なく実行されているか、また、クエリ・モニターでメインクエリがより無駄なく実行されているかどうかを再度測定する。 TTFB が減少する。
機能テストとユーザーエクスペリエンス：迅速でエラーフリー
フォームがハングアップしたり、メニューが消えたりしても、パフォーマンスにはほとんど影響はない。 エラー.デスクトップとモバイルデバイスのフォーム、検索、買い物かご、ログイン、コメントなどのプロセスをチェックします。煩わしいポップアップを最小限に抑え、きれいなフォーカスジャンプを設定し、キーボード操作の安全性を確保することで、誰もスピードを落とさないようにします。メディア、広告、埋め込み用のサイズを定義し、CSSトランジションを控えめに使用することで、CLSを介して視覚的な安定性をテストしています。こうすることで、摩擦なくスピードが上がり コンバージョン 高い。
パフォーマンス要因としてのセキュリティ：クリーンで最新
安全でないプラグイン、マルウェア、不正なパーミッションは、サーバーに負荷をかけ、ページを使用不能にする可能性があります。 クリーン.コア、テーマ、エクステンションを迅速にアップデートし、古い管理者を削除し、MFAで強力なパスワードを使用しています。セキュリティスキャンを定期的に実行し、不審なファイルやcronjobを早期に検出します。最新の証明書とHSTSはブラウザの警告を減らし、時間のかかる不必要なリダイレクトを防ぎます。バックアップをバージョン管理し、暗号化し、復元をテストする。 レジリエンス は依然として圧力下にある。
モバイルの最適化：小さな画面、高速
ヒットの半分以上がスマートフォンからのものなので、タップターゲット、フォント、画像サイズ、インタラクションブロックをまずスマートフォン用に最適化します。 モバイル.重要なコンテンツが早い段階で見えるようにし、画面外のスクリプトがインタラクションを妨げないようにする。重要度の低いCSSルールを再読み込みする一方で、折り返しより上のコンテンツのために重要なCSSからバラストを取り除く。メディアクエリを実用的に設定し、デバイスの幅が一貫して読み込まれ、レイアウトのジャンプがないようにする。最終的には、モバイルとデスクトップの指標を比較し、最大の効果を狙います。 リフト.
モニタリングと継続的改善：継続は力なり
なぜなら、コンテンツやプラグイン、トラフィックパターンを変更するたびに、監査対象が変わってしまうからだ。 所在地.そのため、LCP、CLS、FID、可用性、サーバーリソースの監視を設定し、閾値に達するとアラートを発するようにしています。リリース後の定期的なミニ監査により、訪問者が損失に気づく前にパフォーマンスを軌道に乗せることができます。私はデプロイメントを簡潔に文書化し、測定ポイントにリンクさせることで、スパイクの原因を即座に突き止められるようにしています。また、各ページのタイプごとにアップタイムチェックとシンセティックテストを行っています。 優先順位 より良い。
リソースヒントとWebフォント：レンダリングの優先順位を正しく設定する
多くのミリ秒は、正しい操作によって得られる。 優先順位 を使っています。重要なホスト（CDNやフォントドメインなど）にはpreconnectを設定し、セカンダリソースにはdns-prefetchを使用しています。LCP要素をfetchpriority="high "でマークし、非可視画像をfetchpriority="low "で読み込む。折り返し上のCSSやヒーロー画像のような重要なアセットは特にプリロードし、すべてを無差別にプリロードすることはありません。そして ウェブフォント 私はWOFF2に設定し、font-display:swap/optionalを有効にし、可能であればファイルを自分でホストして、ヘッダーのキャッシュ、圧縮、再バリデーションが自分のコントロール下にあるようにしています。サブセット（必要な文字のみ）と可変フォントはキロバイトを節約し、きれいに定義されたフォールバックスタックはFOIT/FOUTを最小限に抑えます。フォントとアイコンについては、長いTTLを割り当て、アセットをイミュータブルとしてマークすることで、繰り返し呼び出しをスピードアップしている。
サードパーティのスクリプト利益を最大化し、負荷を最小化
外部 タグ アナリティクス、チャット、A/Bテストなどは、しばしば秘密のブレーキブロックとなる。私は、すべてのサードパーティプロバイダのインベントリを取り、重複を削除し、明確な目的を持つものだけをロードします。必要のないスクリプトは非同期で統合し、同意やインタラクションの後ろに移動させ（例えば、「チャットを開く」をクリックした後のみ）、分析のサンプリングレートを下げます。メインスレッドの負荷を減らすために、iframe（マップなど）を遅延的にロードし、サンドボックス属性を設定します。ウォーターフォールビューでは、どのドメインに多くのブロック時間がかかっているかをチェックし、プレコネクトを設定するのは、それが明らかに役立つ場合のみにしている。こうすることで 相互作用 ブレーキをかける
交流速度：FIDからINPまで考える
FIDに加え、今日、私が特に注目しているのは、次のことだ。 インピー-これはセッションで最も長いインタラクションを示す。私の目標は、75パーセンタイルで200ミリ秒以下です。これを達成するために、メインスレッドでの長いタスクを減らし、バンドルを分割し、コード分割を使い、ページが本当に必要とするロジックだけをロードする。可能な限りイベントハンドラをパッシブとしてマークし、スクロールとリサイズのリスナーを解放します。高価な計算（フィルターやフォーマットなど）はウェブワーカーに移すか、クリティカルパス外のrequestIdleCallbackで実行する。重いフロントエンドフレームワークの水素化を制限し、サーバーサイドレンダリングを優先します、 インタラクティブ ブロック。
WooCommerceと動的ページ：パーソナライズにもかかわらずキャッシュ
ショップはしばしばwc-ajax=get_refreshed_fragmentsとパーソナライズされたに苦しんでいる。 エレメント.買い物かごの参照がないページではカートフラグメントを非アクティブにし、イベントに基づいてカウンターの更新をトリガーしています。全ページキャッシュのために、関連するクッキーに従ってVaryルールを使用し、パーソナライズされたエリアをAjax/ESIを介して「リーク」させ、残りはキャッシュされたままにします。定期的にセッションと期限切れカートを整理し、適切なインデックスで検索とフィルター機能をサポートし、テーブルスキャンが行われないようにしています。商品ページやカテゴリーページでは TTFB 高価な価格/在庫ロジックをキャッシュまたは事前計算することで、低価格を実現。
サーバーの微調整：PHP-FPM、圧縮、HTTPの詳細
高負荷時、クリーン チューニング 顕著な空気。PHP-FPMの場合は、リクエストがキューで終わらないように、 pm、pm.max_children、プロセスリザーブをCPU/RAMの装備に合わせて調整する。OPcache（memory_consumption、interned_strings_buffer、max_accelerated_files）は、コードベース全体に十分なスペースがあるように調整した。プロトコル側では、BrotliかGzipを有効にし、静的アセットには賢明なキャッシュコントロールヘッダー（public、max-age、immutable）を設定し、アップストリームが正しくバージョン管理されている場合はETagsを避ける。TLS 1.3、HTTP/2またはHTTP/3、そしてオプションで103のearly hintsを使えば、セットアップをスピードアップできる。 ボトルネック が見える。
データベースを深める：インデックス、オートロード、クーロン
通常の片付け作業に加え、私は次のようなことも行っている。 インデックスwp_postmetaでmeta_keyとmeta_valueの組み合わせのように）定期的にフィルタリングや結合を行う。私はwp_optionsを無駄のないものに保ち、オートロード量を制限します。トランジェントとクーロンイベントのオーファンエントリーをチェックし、WP-Cronを実際のシステムクーロンに切り替え、負荷時のレイテンシーを減らしています。すべてのテーブルをInnoDBで実行し、バッファプールを最適化し、問題のあるクエリの再発を防ぐために低速クエリログを監視しています。 ディフューズ.WooCommerceでは、セッション、注文ポストメタ、レポートを注視しています。
ビルド・プロセス、予算、デプロイメント
Iアンカー 業績予算 (LCP、バンドルサイズ、リクエスト数など)をビルドプロセスで直接確認できます。最新のバンドルは、コード分割、ツリーシェイキング、クリティカルなCSS抽出を提供します。本番環境ではソースマップをオフにし、クリーンキャッシュのためにハッシュ付きのアセットを提供します。CIでは、Lighthouse/Labの値をチェックし、定義された制限を超えるデプロイメントをブロックする。フィーチャーフラグを使って変更をロールアウトし、ブルーグリーン/カナリア戦略を使って実際のトラフィック下で小規模に効果をテストしています。リリースごとにモニタリングの測定ポイントを設定し、次のことができるようにしている。 減少 必要であればロールバックで対応する。
測定方法を研ぎ澄ます：現実的なプロファイルと評価
信頼できる決断を下すために、私は現実的なテストを行っている。 プロフィール (4G/Good-3GのミッドレンジAndroid）で、数回にわたって測定する。フィールド・データでは、平均値よりも大多数のユーザーを反映しているため、私は75パーセンタイルを基準にしています。PerformanceObserverを介したRUM測定は、ページタイプとデバイスごとにLCP/INP/CLSを追跡するのに役立ちます。私は地域とテンプレートでセグメント化し、特定のピーク（キャンペーン、リリース）に注意し、ラボとフィールドのデータを意識的に区別しています。こうすることで、各測定が最も効果的なところに行き着くのです。 レバー を持っています。
ボットとクローラー：負荷を減らし、実ユーザーを優先する
意外に多い トラフィック はボットから来ています。404ページを積極的にキャッシュし、wp-loginとxmlrpcへのリクエストを制限し、レート制限を設定し、明らかな悪質ボットをブロックしています。キャッシュが断片化しないように、同じコンテンツを配信するパラメータバリアントを規制するルールを使っている。検索ページでは、深いページ分割を制限し、クローラーが無限のフィルターループを引き起こすのを防いでいる。こうすることで、本当の訪問者と 変換 予約済みだ。
要約：私はこう進める
WordPressのパフォーマンス監査は、明確な目標、バックアップ、再現可能な測定値から始めます。 リスクポイント コントロールする。ホスティング、キャッシング、イメージウェイトの最適化を最初に行う。次にコードとデータベースに取り組み、バラストを取り除き、アセットを最小限に抑え、重要なレンダリングフェーズを短縮します。そして、機能テスト、セキュリティ、モバイル・ユーザビリティに直接取り組みます。なぜなら、テンポは信頼性が高く、同時に使いやすくなければならないからです。最後に、モニタリングとミニ監査を行い、改善を恒久的なものにし、負荷がかかってもサイトが使い続けられるようにします。 速い が残っている。
