WooCommerceの高速化の相談は、ほとんど同じ場面から始まります。店舗のオーナーはすでに速いホスティングへ移り、キャッシュプラグインを入れ、画像最適化ツールまで買っています。それでもサイトは遅いままです。そして「WooCommerceはそもそも重いのだ」と結論づけて、そこで諦めてしまいます。

WooCommerceが会社案内のようなサイトより重いのは事実です。どのページもカートを抱えうる以上、その分の負担は避けられません。しかし読み込みに六秒かかる店舗が背負っているのは、その負担ではありません。もっと具体的な何かが起きており、私の経験では、ほぼ必ず四つのうちのどれかです。

要点: 店舗が遅いのは、カートと決済のページをページキャッシュに載せられないから、オプションテーブルが自動読み込みの不要データで肥大しているから、商品クエリが索引のないメタデータテーブルを走査しているから、そして三十個のプラグインがそれぞれ自分のスクリプトを全ページに足しているからです。ホスティングは最初に変えるものではなく、最後に変えるものです。

店舗がブログと違う理由

一つの違いを理解すれば、WooCommerceの性能に関するふるまいの大半が説明できます。

ブログ記事はどの訪問者にも同じ内容なので、一度生成してキャッシュから全員に配ることができます。会社案内のようなサイトが作り方にほとんど関係なく速いのは、そのためです。店舗はすべてのページでそれをできません。カートは個人のものだからです。訪問者が商品を一つ入れた瞬間から、そのページは共有の複製ではなく、その人自身の状態を映さなければなりません。

その結果、カート、決済、アカウントのページはページキャッシュを完全に迂回し、リクエストのたびにPHPとデータベースクエリを実行します。そして、遅さが直接お金に響くのもまさにそのページです。カテゴリーページが遅ければ見ているだけの人を失いますが、決済が遅ければ買う気のある人を失います。

だから「うちのサイトは速いか」という問いはほとんど役に立ちません。役に立つのは「カートに商品を入れてログインしている訪問者にとって、うちのサイトはどれくらい速いか」です。その状態を名指しで計測してください。売上が依存しているのはその状態であり、合成的な速度テストが取りこぼすのも、まさにその状態だからです。

実際に壊れている四つのもの

肥大したオプションテーブル。 WordPressはリクエストのたびに一群のオプションを読み込み、プラグインはそこへ自由に書き足します。アンインストールされたプラグインが自分の行を残していくのは、例外ではなく通例です。古い店舗ではこのテーブルが数十メガバイトの自動読み込みデータにまで育ち、決済ページを含むすべてのページ表示でそれが読まれています。目に見えず、静かに積み重なり、そして得られる効果が最も大きい修正の一つでもあります。まず自動読み込みされるオプションの合計サイズを確認してください。キロバイトではなくメガバイトで測る規模なら、そこに本物の時間が眠っています。

索引のないメタデータへの商品クエリ。 WooCommerceは歴史的に、商品の属性、価格、在庫を、他のあらゆるものと共有する汎用のメタデータテーブルに保存してきました。大きなカタログを絞り込んだり並べ替えたりすることは、そのテーブルを何度も結合することを意味します。商品が数百なら誰も気づきません。数万になると、カテゴリーページと絞り込みページは這うような速さになります。新しいWooCommerceは、まさにこの圧力を和らげるために注文データを専用のテーブルへ移しており、長い注文履歴を持つ店舗でその保存方式を有効にすることは、それ単体でもたいてい価値があります。

プラグインと外部呼び出し

重要経路に載ったプラグインの氾濫。 問題が数そのものであることはまれです。問題は、ほとんどのプラグインが必要な場所だけでなく全ページで自分のCSSとJavaScriptを読み込ませることです。一つのページでしか使わない予約プラグインが、決済ページでも同じ資産を読み込みます。修正の手順は地味です。各プラグインが何を読み込んでいるかを調べ、自分のページ以外では資産を外し、機能を説明できないものは削除する。それだけです。

キャッシュされない外部呼び出し。 送料のリアルタイム取得、税率の照会、通貨換算、外部システムへの在庫確認は、いずれもページ読み込みの内側にネットワークリクエストを置きます。その提供元が遅ければ決済も遅くなり、提供元が落ちれば決済も落ちます。リクエスト経路にあるすべての外部呼び出しには、タイムアウトとキャッシュと代替の動作が必要です。ここを設計せずに連携を足していくと、自分の管理下にない相手の障害が、そのまま自分の売上の障害になります。外部API連携 の解説で、その作り方を扱っています。

効くものを、効く順に

次の順序で進めてください。一つ手を入れるたびに、次の計測が示すものが変わるからです。

ページキャッシュではなくオブジェクトキャッシュ。 ページキャッシュはHTMLのページ全体を配るもので、カートや決済を助けることはできません。永続的なオブジェクトキャッシュはデータベースクエリの結果をメモリに保持し、ページキャッシュが触れられないまさにそのページを速くします。店舗にとっては、たいていこれが単体で最大の改善であり、同時に最も飛ばされがちな段階でもあります。すでに入れてあるキャッシュプラグインが、仕事は終わったという印象を与えてしまうからです。

データベースの手入れ。 期限切れのトランジェントを消し、削除済みの商品や注文が残した孤立メタデータを取り除き、投稿のリビジョンを整理します。何年も営業してきた店舗では、これだけでデータベースのかなりの割合が消えるのが普通です。一度きりの作業ではなく、定期実行として仕組みに組み込んでください。

そのうえでホスティング。 キャッシュとデータベースが整ったあとなら、ホスティングは本当に効いてきます。PHPのバージョン、使えるメモリ、データベースが同じ機械にあるかどうか、他の利用者と資源を取り合う共用ホスティングにいるかどうか。しかし上を直す前にホストを変えることは、問題をより家賃の高い住所へ引っ越させるだけです。

資産は最後。 画像フォーマット、遅延読み込み、スクリプトの遅延実行はやる価値がありますし、多くの解説はそこから始めます。ただしそれらが良くするのは、もともとそれなりの速さで配れていたページの読み込み体験です。一バイト送るまでにPHPの中で四秒を使う決済ページには、ほとんど何もしてくれません。

WooCommerceの高速化は正しい計測から始まる

合成スコアは、どの層よりも店舗オーナーを惑わせます。だから計測は意図をもって行ってください。

ログイン済みで、カートに商品が入った状態を試してください。多くのツールは匿名の訪問者がトップページに来る場面を測りますが、それはサイトの中で最も速い経路であり、決済についてはほとんど何も語りません。

サーバー時間とフロントエンド時間を分けてください。HTMLを作るのにサーバーが三秒使っているなら、どれだけ画像を最適化してもそのページは救えません。最初の一バイトまでの時間が、問題のどちらの半分を抱えているのか、したがって上のどの手が当てはまるのかを教えてくれます。

可能なら、実験室のデータより実地のデータを使ってください。実際の回線と実際の端末を使う実際の訪問者は、データセンターで走らせたテストとは違う絵を描きますし、Core Web Vitalsが評価するのは前者です。指標の読み方はWordPressの性能監査ガイド で、しきい値が実際に何を求めているのかは2026年のCore Web Vitals で扱っています。

最後に、遅いリクエストの最中にデータベースそのものを見てください。一回のページ読み込みで同じクエリが二百回実行されているクエリログは、犯人をその場で特定します。そしてこの型は、商品データをそれぞれ独立に取りに行くプラグインを何本も動かしている店舗で、きわめてよく現れます。

この作業にかかる費用

以下の価格は、中規模の店舗に対する英国の制作会社の典型的な水準です。

具体的な原因を特定し、優先順位のついた修正一覧と前後の計測を伴う性能監査は、おおむね900ポンドから2,500ポンドです。これは診断の依頼であり、単体で買う価値があります。残りの作業が一週間で済むのか一か月かかるのかを、それが教えてくれるからです。

よくある修正の実装、つまりオブジェクトキャッシュ、データベースの掃除、プラグイン資産の点検、外部呼び出しのキャッシュ化は、どれだけ溜め込んできたかによって2,000ポンドから6,000ポンドになるのが普通です。

さらに深い作業は、それが本当に開発だから費用も上がります。大きなカタログを索引付きの保存方式へ移す、メタデータを走査する絞り込みの仕組みを作り直す、遅いプラグインを目的を絞った独自実装で置き換えるといった仕事は、6,000ポンドから20,000ポンドの間に収まるのが一般的です。

これらのどれよりも大切な数字は、遅さがあなたにいくら払わせているかです。決済の離脱は読み込み時間とともに測定できるほど増えるので、それなりの売上がある店舗なら、決済ページ一枚の話だけで監査の費用は正当化できます。

スコアではなく店舗を直す

MecanikはWordPress開発サービス の一環としてWooCommerceの高速化を引き受けており、トップページではなくログイン済みの決済経路を測ることから始めます。店舗が実際にお金を落としているのは、そこだからです。

ホストの変更を勧める前に、自動読み込みのオプション、注文の保存方式、クエリの型、外部呼び出しを確認します。そして改善が主張ではなく検証可能なものになるよう、前と後の両方の計測をお渡しします。設定の問題ではなく、店舗がプラットフォームを卒業してしまったから遅いのであれば、それもはっきりお伝えします。その境目がどこにあるのかは、Shopifyとカスタム開発の比較 で扱っています。成長そのものの段取りを考えている段階なら、ECビジネスの拡大 が周辺の判断を整理します。

URLと、店舗が抱えている商品数と注文数のおおよその規模をお送りください。上の四つの原因のうち、どれに当たっている可能性が最も高いかをお伝えします。

関連記事: WordPressがハッキングされた：駆除と復旧の手順 、英国でEコマースビジネスをスケールする方法：2026年最新のデータベース高速化とEdge活用ガイド手順 、Drupal開発者の採用：単価、スキル、見極め方 、2026年英国のウェブサイト制作費用はいくら？ 。

よくある質問

キャッシュプラグインを入れてもWooCommerceが遅いのはなぜですか。 ページキャッシュはカート、決済、アカウントのページには適用できません。それらのページは訪問者それぞれの状態を映さなければならないからです。これらはリクエストのたびにPHPとデータベースクエリを実行するため、速くするにはページキャッシュではなくオブジェクトキャッシュとデータベースの作業が必要になります。

ホスティングを良くすればWooCommerceの性能は直りますか。 部分的にしか直らず、最初の一手にすべきではありません。オプションテーブルが肥大し、クエリに索引がなく、プラグインが至る所で資産を読み込んでいるなら、良いホスティングは同じ問題を少しだけ速く、より高い費用で動かすだけです。まずキャッシュとデータベースを直し、そのうえでホスティングを見直してください。

WooCommerceでプラグインは何個から多すぎますか。 数そのものより、それぞれが何を読み込むかのほうが重要です。自分のページでしか資産を読み込まない行儀の良いプラグイン二十個は、サイト全体にスクリプトを流し込む八個より害が小さいのです。各プラグインが決済ページに何を足しているかを点検し、目的を誰も言えないものは削除してください。

WooCommerceの高速化にはいくらかかりますか。 優先順位のついた修正一覧を伴う診断的な監査は、一般に900ポンドから2,500ポンドです。オブジェクトキャッシュ、データベースの掃除、資産の点検といったよくある修正の実装は2,000ポンドから6,000ポンドが普通で、カタログや絞り込みの作り直しは6,000ポンドから20,000ポンドに達することがあります。

WooCommerceの性能はどう計測するのが正しいですか。 匿名でトップページを開くのではなく、カートに商品を入れたログイン済みの訪問者として試してください。サーバーの応答時間とフロントエンドの描画を分けて、どちらの半分が遅いのかを見ます。そして実験室のスコアだけに頼らず、実際の訪問者から得られる実地のデータを使ってください。