8月17日、NaibaはあるWordPress + WooCommerce B2C ECサイトのPageSpeed Insightsスコア最適化の仕事を受けました。

このサイトは最適化前にGoogle PageSpeed Insightsでテストした結果：

• モバイル端末：約45分
• PC端末：約56分

実際に運用中のWooCommerceサイトとしては、このスコアはまだまだ最適化の余地がかなりあります。

しかし、実際に作業を始めてみると、このサイトの問題は単に„WordPress 高速化プラグイン“をインストールするだけで解決できるものではないことがわかりました。

サーバー環境、WordPress プラグイン、キャッシュ、商用テーマの CSS やフォントの読み込み方法、Elementor のページ構造、Cloudflare の設定に至るまで、ほぼすべての層に最適化できる点があります。

最終的に最適化を完了した後：

• モバイル端末の平均は約60〜70点
• PC端末の平均は安定して90点以上

この記事では、今回のサイト速度最適化のプロセスを完全に記録します。

一、サイト最適化前の基本状況

顧客のサイトは、典型的な WordPress 外贸 B2C 电商架构（外国貿易向け B2C EC サイト）を使用しています：

• WordPress
• WooCommerce
• Elementor
• Blonwe 商用テーマ
• Alibaba Cloud ECS
• 4コア CPU
• 8GB メモリ
• 10 Mbps 公網帯域幅
• Cloudflare CDN

サーバー構成だけを見ると非常に優れていますが、唯一の弱点はサーバーの帯域幅が小さすぎることです。10 Mbps の公網帯域幅では、最大ダウンロード速度はわずか1メガバイト強で、数メガバイトの画像があると2〜3秒待たされることがあります。ただし、Cloudflare CDN を導入しているため、その弱点はそれほど顕著ではありません。

顧客のサーバーは2027年4月まで契約が切れないため、最初からサーバーを変更するようには言えません。WordPress サイトにとって、サーバー性能は一側面に過ぎず、サイト自体の作りやサーバー設定が合理的かどうかもスコアに影響します。

そのため、速度とスコアに影響を与える可能性のあるすべての側面を、一歩ずつ調査する必要があります。

二、最初のステップ：サーバーを宝塔パネルから WP Panel に切り替える

お客様の元のサーバーは宝塔パネルを使用していました。私が最初に行ったことは、サーバーを再インストールし、WordPressサイト開発向けに設計されたものに変更することでした。WP Panel パネル。

WP Panelは、Naibaが長年WordPressサイト構築で培った経験を融合して開発されたサーバー管理パネルであり、一般的なサーバーパネルと比較して、その機能はWordPressに特化しています。

例えば、以下の機能を直接有効にすることができます：

• Nginx FastCGI キャッシュ；
• データベースキャッシュ；
• WordPress関連の最適化；
• WordPressセキュリティ保護ルール。

一般ユーザーにとっては、複雑なNginx設定ファイルを自分で研究する必要はなく、基本的にパネル操作で完了できます。

この記事の公開時点で、お客様のサーバーのWP Panelセキュリティルールは、自動的に数十の悪意のあるIPをブロックしています。

上記のスクリーンショットで404泛滥検出としてブロックされた記録は、基本的にボットがサイトの脆弱性を一括スキャンしているもので、通常は1分間に数十回サーバーのファイルをスキャンし、サーバーのCPU使用率を急上昇させます。サーバーのCPUリソースが常に100%使用されている場合、おそらくボットのスキャンに遭遇している可能性が高いです。

もしあなたもWP Panelパネルへの移行を検討しているなら、以下を参照してください：WordPress サイトを宝塔パネルから WP Panel に移行する方法

注意すべき点：

サーバーパネルを変更しても、PageSpeed スコア。WP Panelへの変更は、純粋にWordPressサイトにより適しているためであり、自動セキュリティルールが悪意のあるリクエストをブロックし、Nginx FastCGIキャッシュとデータベースキャッシュ機能が内蔵され、ワンクリックで有効にできるからです。

このお客様のサイトには、当初キャッシュ最適化プラグインが一切ありませんでした。そのため、NaibaはWP Panelを使用してサーバー側でNginx FastCGIキャッシュ最適化を行いました。

三、ステップ2：WordPressプラグインの簡素化

このサイトは最適化前に、26 個の WordPress プラグイン。

26個のプラグインがあるからといって、サイトが必ず遅いとは限りません。実際の状況に基づいて、そのプラグインがフロントエンドで使用されているか、機能を取捨選択できるか、コードで実装できるか、機能が競合するプラグインがあるかを分析する必要があります。

一部のプラグインは機能が複雑でも、WordPressの管理画面でのみ動作し、フロントエンドの速度への影響は小さいです。逆に、一見シンプルに見えるプラグインでも、各ページに追加のCSS、JavaScript、またはサードパーティのリクエストを読み込む可能性があります。

調査の結果、まずChatway Live Chatこの使用頻度の低いオンラインチャットプラグインを削除しました。この種のプラグインは通常、フロントエンドに多くのJSやCSSファイルを読み込みます。また、中国とアメリカには時差があるため、オンラインチャットの実用性はあまり高くありません。

次に、Google広告やFacebook広告などのコード管理プラグインをクリーンアップし、子テーマのコード挿入方式に直接変更しました。お客様は以前、同じ機能のプラグインを4つインストールしていたため、深刻な機能重複でした。

同時に、Wordfenceファイアウォールプラグインを無効化しました。。

一部のユーザーは驚くかもしれませんが、なぜセキュリティプラグインを無効にするのですか？

Naibaの経験によると、サイトが実際にウイルスに感染した場合、Wordfenceは実際には効果がありません。Naibaは以前、Wordfenceをインストールしてもサイトがウイルスに感染し、ウイルスをスキャンできないケースを直接処理したことがあります。また、WP Panelのセキュリティルールは必要な保護ルールをすでに提供しているため、サイト自体のプラグインやテーマのコードの脆弱性が正確に悪用されない限り、ほとんどのボットはスキャン段階でブロックされます。

また、この種のセキュリティプラグインは機能が多いため、サーバーリソースの消費もかなり大きいです。削除することでサイトはより軽快になります。

もちろん、WP Panel を使用したサイトが絶対にウイルスに感染しないというわけではありません。サイトではクラックされたリソースを使用せず、WP コア、プラグイン、テーマを最新に保ち、複雑なアカウントとパスワードを設定し、WP Panel の既存の保護ルールと組み合わせることで、サイトが攻撃される可能性は比較的低くなります。

四、ステップ3：データベースキャッシュと Nginx FastCGI キャッシュを追加

不要なプラグインを削除した後は、最適化プラグインを追加します。最初はこのサイトには最適化プラグインが一つもなかったので、WP Panel パネルのバックエンドで Nginx FastCGI ページキャッシュを直接有効にし、Redis Object Cache キャッシュも有効にしました。

もちろん、最終的な最適化の後、CSS ファイルを結合するために Autoptimize プラグインをインストールし、JS ファイルの遅延読み込みのために Debloat をインストールしました。

FastCGI キャッシュの役割は何ですか？

WordPress は本質的に動的なプログラムです。

通常、WordPress のページにアクセスするには、おおよそ次の手順が必要です：

ブラウザリクエスト → Nginx → PHP → WordPress → データベース → PHP が HTML を生成 → ブラウザに返す

頻繁に変更されないページの場合、アクセスのたびに PHP とデータベースの一連の処理を毎回実行すると、多くの重複計算が発生します。

FastCGI キャッシュを有効にすると、キャッシュ条件を満たすページに対して、Nginx は以前に生成されたページコンテンツを直接返すことができます。

つまり：

多くのアクセスでは、PHP や WordPress に再度入る必要さえありません。

これは、記事ページ、製品ページ、およびほとんどの訪問者向けページに役立ちます。

ただし、WooCommerce は通常のブログとは異なります。

カート、チェックアウト、ユーザーログイン状態などのページには動的データが存在するため、キャッシュ戦略はサイト全体を単純にキャッシュすることはできません。

WP Panel の設定ファイルはデフォルトで B2C シナリオのキャッシュを考慮しており、ユーザーが手動で処理する必要はありません。

五、本当の主要部分：Blonwe テーマのコード最適化

サーバーとキャッシュの最適化が完了した後、このプロジェクトで本当に面倒な部分が始まります。

顧客のサイトの以前のサイト制作会社が使用していたのはBlonwe 商用テーマ。

確認したところ、テーマの現在のバージョンは最新バージョンと数バージョン離れていましたが、サイトのバックエンドでは正常に更新できませんでした。

現在の状況から、以前のサイト制作会社は正規ライセンスを購入していないか、正規版を購入したものの、更新可能なライセンス設定を顧客に引き渡していない可能性があります。。

サイト制作会社に更新を連絡しましたが、Naiba の最適化が完了するまで更新されていませんでした。ふん。

Elementor Pro にも同様の問題があります：

バックエンドではライセンスが表示されていますが、更新できません。

私は正規の Elementor Pro を持っているので（お得に購入）、今回は Elementor Pro を現在利用可能なバージョンに直接更新しました。（なぜ更新するのか？Elementor Pro と無料版は通常同時に更新されるため、バージョンが大きく異なると、機能が使用できなくなったり、互換性の問題が発生する可能性があります）

ただし、Blonwe テーマは直接更新できないため、顧客が現在使用しているバージョンに基づいて最適化するしかありません。

これは、サイト制作会社にサイト制作を依頼する際に確認すべき点でもあります：

网站で使用しているリソースは正版ですか、それともクラック版ですか？サイト納品後、テーマとプラグインのライセンスはお客様に帰属しますか？今後も正常に更新できますか？

サイトを長期的に運営する予定がある場合、特にWooCommerceストアでは、これは非常に重要だと思います。

六、このテーマの最大の落とし穴：フォントをBase64でCSSに書き込む

サーバー、プラグイン、キャッシュをすべて最適化してもスコアが上がらない場合、さらに調査を進めるとテーマのコードに問題があることがわかります。このテーマはフォントファイルをBase64形式で直接CSSファイルに書き込んでいますそのため、LCPスコアを常に低下させています。

この操作は、本来CSSを読み込むだけでよい場所で、フォントファイルも一緒に読み込む必要があることを意味します。本来数十KBのコンテンツが数百KBになり、パフォーマンスの逆最適化です。

私は子テーマを使用して、CSSとフォントファイルを分離しました。これにより、ブラウザはCSSとフォントの読み込みを個別に処理でき、CSSをダウンロードする際に大量のフォントデータを一緒にダウンロードする必要がなくなります。

なぜ子テーマを使用して変更するのですか？

顧客が商用テーマを使用しているためです。

親テーマを直接変更した場合：

wp-content/themes/blonwe/

今後テーマが更新を再開すると、アップグレード時に変更内容がすべて上書きされる可能性があります。

そのため、このようなテーマコードの変更には、子テーマを使用して変更するのが合理的な方法です。

七、Elementorのページ構造を再最適化

テーマコードの他に、このサイトのもう一つの明らかな問題は次のとおりです：

ページ構造が複雑すぎる。

Elementor自体がサイトを遅くするわけではありません。

多くの場合、実際の問題は、非常にシンプルな視覚効果を実現するために、大量の要素を積み重ねていることです：

• Section；
• Container；
• Column；
• Widget；
• ネストされたコンテナ。

ページが何層にも重なると、最終的に生成されるHTML DOMは非常に複雑になります。

ブラウザはより多くのHTMLを解析する必要があるだけでなく、CSSセレクターのマッチング、ページレイアウトの計算、再レンダリングもより複雑になります。

そのため、今回は複雑なページ構造の一部を再簡素化しました。

八、Heroファーストビューモジュールを直接再設計

ホームページのHeroは今回重点的に処理したモジュールの一つです。

元のHero構造は複雑で、実際のテストでもページのファーストビューの読み込みとレイアウトの安定性に影響を与えることがわかりました。

以前のHeroはテーマ標準の要素で設計されていたため調整できず、Elementorの標準機能を直接使用してこのHeroを再設計しました。

この利点は次のとおりです：

• DOM階層が減少する；
• 元の複雑なテーマコンポーネントに依存しなくなる；
• 画像とテキストの構造が制御しやすくなる；
• CSSが管理しやすくなる；
• 後で顧客が自分でコンテンツを変更するのも便利になる。

上の図の左側は元のHero構造で、右側はNaibaがElementor標準要素を使用して再設計したHero構造です。

最初にText Gridという要素はテーマ標準のもので、その上に合計3つのコンテナがありましたが、実際には1つのコンテナだけで十分でした。Naibaが他の2つのコンテナを削除してスコアをテストしましたが、改善は見られませんでした。これはText Gridコンポーネント自体が複雑なため、右側のElementorネイティブ構造設計を採用し、修正後にスコアが明らかに向上しました。

これがNaibaがElementorチュートリアルの中で、Elementor拡張機能をあまり多くインストールしないことを推奨する理由です。初心者が自分でサイトを作る際に実現できない効果をプラグインで組み合わせ、最終的に1つのページで複数のElementor拡張機能を使用し、ページが肥大化し、最後にElementorが遅いと非難することになります。

単純なファーストビューを実現するために、10数層のDOMと大量のJavaScriptが必要なら、後でCSSを圧縮したりJSを遅延させたりしても、本質的には初期の構造問題を補っているに過ぎません。

九、マーキーモジュールを純粋なコード実装に変更

サイトにはもう1つマーキー切り替えモジュールがあります。

元の実装方法も同様に複雑でした。

この種の機能は、実際には大規模なElementorウィジェットやテーマコンポーネントを必要としないため、最終的に単純なコード実装に変更しました。

WordPressのページデザインでは、通常2つの方向性の間でトレードオフを行います：

顧客が今後頻繁に変更するコンテンツ：

できるだけElementorを使用します。

基本的に変更せず、機能が非常に単純な効果：

少量のHTML / CSS / JavaScriptで実装することを検討できます。

これにより、メンテナンスが容易になり、不要なフロントエンドリソースを削減できます。

すべてを自分でコードを書くべきではなく、すべてをElementorに詰め込むべきでもありません。現在のAIは非常に優れており、単純な効果はAIを利用してHTMLコードを生成し、それをElementorページに挿入できます。プラグインに頼る必要はありません。プラグインは、1つの機能のために複数の不要なリソースを導入することになり、最終的にページの読み込みが遅くなります。

十、Cloudflareの設定ミスもWooCommerceに影響を与える

ここまでで最適化効果はほぼ限界に達しており、PC版は安定して90点以上を維持しています。モバイル版でさらにスコアを上げるには、ホームページのすべてのデザインを大幅に変更する必要があり、根本的には軽量なテーマに変更する必要がありますが、これは明らかに大規模な変更であり、現在の状況には適合しません。

ただし、最後のチェックで、Naibaはゲスト状態のサイトではコンソールエラーがない一方、ログインユーザーのコンソールで503エラーが10数件発生していることを発見しました。これらはすべてJSエラーです。

最初はプラグインを無効にしたことが原因のバグだと思いましたが、プラグインを復元しても問題は解決しませんでした。

最適化のどこかに問題があると思い、テストサーバーで最適化前のバックアップデータを復元しましたが、問題は解決しませんでした。

実際のJSファイルを確認すると、実際に存在していました。

したがって、この問題は私たちの最適化によって生じたものではなく、最初から存在していたものです。

最終的に調査したところ、お客様のCloudflare設定に問題があることが判明しました。

ユーザー自身が設定したのか、以前のサイト制作会社が設定したのかは不明ですが、Cloudflareの推奨設定を無差別にすべて有効にしたことが、今回の503エラーの原因でした。

Cloudflareの設定を再調整した後、関連する503エラーは解消されました。

これが、Naibaが一般的にWordPressの速度最適化を引き受けたがらない理由でもあります。完全なWebサイトのアクセス経路は長すぎるため、サイトを自分で制作したものでなければ、どの段階に問題が潜んでいるかわかりません。どの層の設定に異常があっても、最終的には„WordPressサイトが遅い“という形で現れる可能性があります。

十一、最終的なPageSpeed Insightsの最適化結果

すべての最適化が完了した後、再度Google PageSpeed Insightsでテストしました。

最終的なスコアはおおよそ以下の通りです：

PageSpeed Insightsのラボテストのスコアは毎回変動する可能性があるため、複数回テストを実施しました。複数回のテストの平均結果は、PCでは90点以上、モバイルでは60点台から70点台の間で変動し、サイト全体のスコアは最適化前と比較して明らかに向上しました。

十二、今回の最適化で実際に効果があったのは何か？

今回のWordPressサイトのPageSpeed Insightsスコア最適化で効果があったのは、特定の一点ではなく、複数の修正の組み合わせでした。

1. サーバー実行環境

宝塔パネルから、WordPressの使用シナリオに特化したWP Panelに切り替え、キャッシュも設定しました。

2. 不要なプラグインの削除

単にプラグインの数を減らすのではなく、使用していないプラグインや重複する機能を削除しました。

3. FastCGIとデータベースキャッシュ

重複するPHP処理とデータベースリクエストを削減しました。

4. テーマコード

不適切なCSSやフォントの読み込み方法を処理しました。

5. Elementorのページ構造

不要なネストや複雑なDOMを削減しました。

6. パフォーマンスの低いモジュールの再構築

例えば、Hero はパッチを当て続けるのではなく、直接再設計する。

7. シンプルな機能はシンプルに実装する

マーキーなど複雑なコンポーネントを必要としない効果は、軽量なコードで実装する。

8. Cloudflare を調査する

CDN 設定による WooCommerce リクエストの異常を解決する。

これらの工程のうちどれか一つでも欠けると、最終的な効果が損なわれる可能性がある。

十三、WordPress の速度最適化は PageSpeed スコアだけを見てはいけない

最後に Naiba は自分の見解を改めて述べる。

PageSpeed Insights のスコアは重要だが、WordPress サイトの速度最適化のすべてではない。

見栄えのするテスト数値を得るために、非常に過激な方法を使うことができる。例えば：

• 大量の JavaScript を遅延させる；
• CSS を削除する；
• サードパーティのスクリプトを強制的に遅延させる；
• すべてのページをキャッシュする。

さらに簡単に、サイトのトップページにテキストのみを置けば、簡単にダブル満点を取ることができる。

しかし、過度に過激な最適化は以下の問題を引き起こす可能性がある：

• WooCommerce のカート追加が機能しない；
• チェックアウトページの異常；
• ログインユーザーが誤ったキャッシュを表示する；
• Elementor のアニメーションが動作しない；
• ページの最初のクリックが反応しない；

それならテストスコアがどんなに高くても意味がない。

特に B2C の EC サイトでは、まず以下を保証する必要がある：

商品の閲覧、カートへの追加、ユーザーログイン、チェックアウトのフローが正常であること。

その上で、可能な限りパフォーマンスを最適化する。

PageSpeed Insights のスコアについて、Naiba は、低すぎるほどでなければ合格ラインを超え、海外のユーザーに実機テストを依頼してサイトの表示速度が遅くないことを確認できれば、重点をサイト運営に置くべきであり、PageSpeed Insights のスコア最適化に置くべきではないと考えている。

十四、„プラグインを一つインストールすれば100点“という迷信を信じない

WordPress の速度最適化や PageSpeed Insights のスコア向上をネットで検索すると、WP Rocket という有料プラグインを勧められることが多いだろう。

Naiba も以前 WP Rocket でサイトを最適化したことがあるが、効果は確かに良かった。しかし、他の無料プラグインでは達成できないというわけではない。ただ、WP Rocket の方が使い方が簡単だということだ。

しかし、以下のような場合：

WooCommerce + Elementor + 商業テーマ

この組み合わせは、実際のウェブサイトは通常もっと複雑で、今回のクライアントのウェブサイトはその典型的な例です：

サーバーキャッシュはその一部に過ぎず、実際に時間がかかったのはむしろ次の点です：

• 商業テーマ；
• フォント；
• CSS；
• Elementor；
• ページ構造；
• Cloudflare。

したがって、WordPress サイトの PageSpeed スコアが低い場合、まず次のことを明確にすることをお勧めします：

一体何がサイトを遅くしているのか？

そして問題に応じて最適化します。

スコアが低いからといって、次の„高速化プラグイン“をインストールし続けるのではなく。

まとめ

今回の WooCommerce サイト最適化前の PageSpeed Insights はおおよそ次のとおりでした：

モバイル 45 点、デスクトップ 56 点。

サーバー環境、WordPress プラグイン、FastCGI キャッシュ、データベースキャッシュ、テーマ CSS とフォント、Elementor ページ構造、Hero モジュール、Cloudflare などの一連の最適化を経て：

モバイルは平均 60〜70 点、デスクトップは平均 90 点以上に達することができます。

Naiba は、今回のサイト最適化の実践プロセスを通じて、あなたに理解していただきたいと思います。WordPress サイトの速度最適化は、本質的に問題を調査するプロセスです。

サーバーにはサーバーの問題、プラグインにはプラグインの問題、テーマにはテーマの問題、ページデザインにもページデザインの問題がある可能性があります。

真のボトルネックを見つけ、これらの問題を一つずつ解決することは、いわゆる WordPress 高速化プラグインをインストールし続けるよりも効果的です。