# WordPress高速化：実装ガイド URL: https://noonwp.com/ja/journal/wordpress-kousoku-ka Type: blog Locale: ja Published: 2026-09-29 Updated: 2026-09-29 --- > 実践的なWordPress高速化ガイド。測定から始まり、サーバー応答速度、ページキャッシュ、ヒーロー画像最適化、CSS/JavaScript最適化、プラグイン最適化へと進みます。 WordPress サイトの wordpress 高速化 を実装的に進める方法です。測定を最初に行い、実際の効果の順に改善を進めてください：サーバー応答時間とページキャッシュ、次に重いヒーロー画像、その次にレンダリング阻害の CSS と JavaScript、最後にデータベースとプラグイン負荷。遅いサイトのほとんどは、その全部ではなく2～3つの要因が制限しています。PageSpeed Insights であなたの最も遅いテンプレートを実行して、Largest Contentful Paint (LCP) 要素をメモし、この一覧を下へ進みながら、その数値が緑に変わるまで改善を続けてください。 ## 測定がなければ最適化は迷信である 速度改善を測定なしに始めるのは迷信です。プラグインに手を付ける前に、あなたの最も遅いテンプレート（通常は大きなヒーロー画像を持つ記事か、WooCommerce商品ページ）で3つの数値を記録してください：Largest Contentful Paint、Interaction to Next Paint、Time to First Byte です。モバイル設定でテストしてください。なぜなら、そこが「私のマシンでは速い」と「顧客の訪問者にとって実際に速い」の差が顕著に表れるからです。 ターゲットは公式に発表されています。伝承ではありません。[Google の web.dev ガイド LCP に関するセクション](https://web.dev/articles/lcp)は、2.5秒以下を実訪問の75パーセンタイルで良好と見なしています。INP は 200 ミリ秒未満、レイアウトシフトは 0.1 未満が目標です。これを付箋に書いてスクリーンの横に貼ってください。 Lighthouse のようなラボツールは再現可能なベンチマークをくれます。Chrome User Experience Report からのフィールドデータは、訪問者が実際に経験した内容を教えてくれます。この2つが食い違う場合、フィールドデータを信頼し、ラボ実行を原因追求に使ってください。 余談：この改善順序は WordPress 6.5 以降に有効です。古いインストールはその前にもっと多く改善すべきことがあります。 ## サーバーを最初に修正：ホスティング、PHP、Time to First Byte すべてのフロントエンドのトリックはファーストレスポンスの上に立っています。HTML が到着するのに 1.5 秒かかるなら、どんな画像圧縮も LCP を救えません。Time to First Byte は弱いホスト、古い PHP バージョン、リクエストのたびに一から再構築されるページを露呈させます。 3つのことを順に確認してください。現在サポートされている PHP バージョンを実行してください。各リリースは前のものより確実に安いです。ホストが永続的なオブジェクトキャッシュ（Redis または Memcached）を提供していることを確認してください。これにより、オプション、メニュー、クエリの繰り返されたデータベース読み込みが削除されます。そしてプラン自体を見てください：100人の隣人がいる共有サーバーは、トラフィックスパイクのまさにその時点であなたを絞ります。 多くのクライアントサイトを管理する場合、ここはマネージドホスティングが手数料を稼ぐ場所です。ホスティング、キャッシング、パフォーマンスターゲットをバンドルするプラットフォームは、推測の全カテゴリーを削除します。[10Web](https://10web.io) は Google Cloud で WordPress をホストし、最初から PageSpeed スコア 90 以上を目指す例の1つです。これは、専任の運用担当者がいない小さなエージェンシーにとって合理的なデフォルトです。 キャッシングを有効にする前に、大きなプランを購入したいという誘惑をスキップしてください。キャッシュされていないページを提供するためにハードウェアをアップグレードするのは、同じ無駄な作業をより速く行うために多く払うことです。 ## ページキャッシュを有効にして、実際にヒットしていることを確認する WordPress は訪問者が要求するたびに PHP と MySQL を使ってそれぞれのページを構築します。ページキャッシュは完成した HTML を保存し、その代わりにそのファイルを提供します。ブログ、企業サイト、ポートフォリオなど、ほぼ読み取り専用のサイトでは、この単一の変更は TTFB を秒からミリ秒の数十に移すことが多いです。 1つのページキャッシュレイヤーを選んで、その1つだけにしてください。ホストレベルキャッシュ、キャッシングプラグイン、CDN キャッシュをどれがリクエストを提供するかを知らずに積み重ねるのは、午後全体をキャッシュの古さをデバッグするのに費やす方法です。何をインストールする前に、ホストが既に何を提供しているのかを聞いてください。 そしてキャッシュがヒットしていることを確認してください。ブラウザのネットワークパネルを開き、公開ページを2回リロードし、レスポンスヘッダーを読んでください。ほとんどのキャッシュはヒットまたはミスを通知し、多くが年齢値を追加します。常にミスしか見ない場合、キャッシュはクッキー、クエリ文字列、またはログイン状態によってバイパスされており、「最適化」は飾りです。 オンラインストアは特別なケアが必要です。カート、チェックアウト、アカウントページは決してキャッシュされてはいけません。WooCommerce サイトは通常、これらの除外を知っているキャッシングプラグインに依存しています。除外を間違えるとお客様は互いのカートを見ることになり、これは遅いページより悪い問題です。 ## ヒーロー画像を縮小する：LCP の常連犯 ほとんどの遅い WordPress ページでは、LCP 要素は画像です：ヒーロー、フィーチャー画像、またはフルワイドバナーです。これにより、画像の重さが単一の最も一般的な失敗スコアの原因になります。カメラから直接エクスポートされた 4000 ピクセルの JPEG が 1200 ピクセルの列に表示されている場合、レイアウトが使える複数倍のバイト数を送信します。 ![Digital scale weighing a stack of paper against a single printed photograph, a metaphor for image weight](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/50469b-img1.webp) 画像パイプラインをこの順序で処理してください： - レイアウトが実際に表示する最大サイズにリサイズしてください。デザイナーがエクスポートしたサイズではなく。 - WebP または AVIF を提供してください。どちらも WordPress コアが数リリースずっと処理しています。 - 1つの大きなファイルをハードコーディングする代わりに、コアが反応型の `srcset` バリエーションを生成するようにしてください。 - ヒーロー画像を遅延読み込みしないでください。コアは WordPress 6.3 以来、最初のコンテンツ画像の遅延読み込みをスキップし、それに `fetchpriority="high"` を追加しているため、あなたのテーマやプラグインがそれをやり直していないことを確認してください。 - すべての画像に明示的な幅と高さを与えてください。ブラウザが領域を予約でき、レイアウトシフトはゼロに近くなります。 折り目の下では、遅延読み込みは正しく無料です。折り目の上では、それは自分で引き起こす遅延であり、「すべてを遅延読み込みする」プラグインをインストール後に最も多く表れる誤りです。 電子商取引では、重さはしばしば商品写真から来ます。一貫した、正しくサイズされたビジュアルをソースで作成することは、後で50の過度にサイズされたファイルを圧縮するより安いです。AI 商品写真プラットフォームの Klayn は1つの商品写真を複数のシーンに変え、メディアライブラリに到着する前にサイズを計画できます。 ## レンダリング阻害 CSS と JavaScript をソースで削除する サーバーとヒーロー画像がソートされたら、次の遅延はブラウザが描画する前にダウンロードして実行しなければならないものです。ヘッド内のすべてのスタイルシートはレンダリングをブロックします。すべての同期スクリプトはパースをブロックします。ページビルダーと汎用テーマがこれをやる習慣的な犯人です。なぜなら、ページが使うかどうか関係なくすべての機能のスタイルとスクリプトを送付するからです。 ブロックテーマはここに構造的な利点があります。コアはそのブロックがページに表示される場合のみ、ブロックのスタイルをロードします。従って、シンプルな投稿は Query Loop や Gallery の代金を払いません。これが、リーンな Full Site Editing テーマがバンドルされたスライダーとバンドルされたアイコンフォントを持つレガシーテーマより前に開始する理由の1つです。クラシックページビルダーはギャップを閉じられますが、使わないモジュールを無効化した場合だけです。 ![Server rack cables with green status lights in a clean data center aisle](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/098a03-img2.webp) Divi は公平なテストケースです。Divi 5 はより最新のアーキテクチャ上で再構築され、数百のモジュールを送付しており、これはまさにその理由が Dynamic CSS や Critical CSS のようなパフォーマンス設定が提供するサイトでの慎重な検討に値する理由です。 実用的なステップ、リスク順で： - 非クリティカル JavaScript を遅延させ、可能な限りインタラクション後に第三者スクリプト（チャットウィジェット、分析、タグマネージャー）をロードしてください。 - 折り目の上のコンテンツ用にクリティカル CSS をインラインしてください。残りは非同期にロードしてください。キャッシュツールがそれをサポートする場合。 - フォントを自己ホストし、サブセットし、テキストがフォント読み込み中に表示されるように `font-display: swap` を使用してください。 - すべてのページで大きなスクリプトを読み込み、1つで使用される機能のためのプラグインを削除または置き換えてください。 - 各変更後にテスト。積極的な JavaScript 遅延化は、破壊されたメニューまたは破壊されたチェックアウトボタンの第1の原因です。 ## プラグインスタックを整理し、データベースを呼吸させる プラグイン数は悪いメトリックです。重要なのは各プラグインがフロントエンドで何をロードするか、そしてそれがすべてのリクエストで何をするかです。重いクエリを持つ 1 つの悪く書かれたプラグインは、30 の行儀の良いプラグインよりコストがかかります。Query Monitor をステージング コピーで使用して、遅いクエリ、それをトリガーしたプラグイン、および各プラグインがエンキューするスクリプトを確認してください。 その後、options テーブルを見てください。年前に削除されたプラグインは背後に行をしばしば残し、自動読み込みのためにマークされています。つまり WordPress はすべてのリクエストでそれらをメモリに読み込みます。Site Health は自動読み込みオプションが大体 800 KB に達するとフラグを付け始めます。その警告が見える場合、最大の行を監査し、もう実行しないプラグインからの残された物を掃除してください。 投稿リビジョン、有効期限切れのトランシェント、孤立したメタデータは時間とともに重みを加えますが、これをメンテナンスとして扱ってください。最初にバックアップし、ステージング上でクリーンアップを実行し、再度測定してください。ゲインはしばしば小さなサイトでは控えめで、年の注文とセッションを持つストアで有意です。 ![Craftsman workbench with a plumb line, calipers and a brass hourglass laid out in order](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/a80ad0-img3.webp) ## CDN と投機的読み込みで最後の一歩を進める Content Delivery Network は静的ファイル、そしてしばしばキャッシュされた HTML でも、訪問者に近い場所から提供します。アラビア語言語のサイトのように、湾岸と北アフリカから読まれながらオリジンサーバーがヨーロッパに座っているような分散した視聴者にとって、節約された遅延は化粧的ではありません。距離はコストであり、CDN はそれを短くする最も安い方法です。 WordPress 6.8 は何も費用がないものを追加しました：投機的読み込みです。これは Speculation Rules API を使用して、訪問者がクリックを開始すると、ページを先読みします。次のナビゲーションがほぼ瞬間的に感じられます。コアチームは、以前のプラグインバージョンを使用するサイトが、[WordPress 6.8 投機的読み込みデベロッパーノート](https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/)で説明されているように、中央値で約1.9% だけ LCP パスレートを改善したことを報告しています。サイトごとに小さいですし、設定は不要です。 コアはプリティパーマリンクを持つサイト上のログアウト訪問者のためにそれを有効にします。プラグインが GET リクエストで状態を変更するアクション URL を使用する場合、`wp_speculation_rules_href_exclude_paths` フィルターを使用してそれらのパスを除外してから設定をより積極的にしてください。デフォルトのままカートとアナリティクスを確認するまでです。 ## チューニングをいつ停止するか、最初に実行する修正はどれか より多くの WordPress チューニングがそれが返すより多くのコストである時点があります。小さなショップがキャッシング除外、プラグイン競合、ホスティングアップグレードとの毎月の戦いに費やす場合、正直な質問はスタックが事業に適合するかどうかです。WiziShop のようなホストプラットフォームはいくらかの柔軟性を取引しますが、その速度は他の誰かの仕事である店で、それは保守時間に請求する時間に対してプライシングする価値があります。 コンテンツサイト、エージェンシー、RTL プロジェクトの場合、WordPress は正しいツールのままであり、上記のすべてはやる価値があります。要点は各クライアントがラインのどちらの側に座るかを知ることです。 最も遅いテンプレートで今日ベースラインを実行してください。TTFB が 800 ミリ秒を超える場合は、ホスティング、PHP、キャッシングから始めてください。TTFB は健康的でもある LCP が失敗する場合は、ウォーターフォールを開いて LCP 要素（通常はヒーロー画像）を見つけてください。その両方が合格で相互作用が重い場合は、JavaScript とプラグインスタックを見てください。これら3つのうち、あなたの最悪のページはどれが失敗しますか？ ## FAQ ### WordPress高速化の最初のステップは何ですか？ まず、PageSpeed Insights でサイトを測定し、Largest Contentful Paint (LCP)、Interaction to Next Paint (INP)、Time to First Byte (TTFB) の3つの指標を記録してください。その後、この記事の優先順位に従って改善を進めます。 ### ページキャッシュとプラグインキャッシュの違いは何ですか？ ページキャッシュは完成した HTML をファイルとして保存し、次回の訪問者に直接配信します。プラグインキャッシュはプラグイン自体の出力をキャッシュします。ページキャッシュのみを使用し、複数のレイヤーを重ねないでください。 ### ヒーロー画像の最適なサイズは？ 実際にレイアウトが表示する最大幅にリサイズしてください。WebP または AVIF 形式を使用し、WordPress のレスポンシブ srcset を活用します。最初のコンテンツ画像の遅延読み込みはスキップし、fetchpriority="high" を使用してください。 ### プラグインを削除する前に確認すべきことは何ですか？ Query Monitor を使用して、各プラグインが実行するクエリとロードするスクリプトを確認してください。WordPress 6.5 以降の環境で、本当に削除しても問題ないプラグインを特定します。ステージング環境で最初にテストしてください。 ### WordPress 6.8 の投機的読み込みはどのような効果がありますか？ 投機的読み込みは先読み API を使用して、訪問者がクリックする前にページを事前にロードします。実装サイトは LCP パスレート中央値で約 1.9% の改善を報告しています。デフォルトで有効で、設定は不要です。 ### CDN を導入するのに最適なタイミングは？ CDN は、サーバー応答、キャッシング、ヒーロー画像最適化を済ませた後で導入してください。特に複数地域に分散した訪問者がいる場合に効果的です。