あなたのWordPressサイトがとても遅くて物事をスピードアップするための便利なガイドである理由
公開: 2021-08-19この投稿は、これが単なる別の一般的な「WordPressを高速化する方法」の記事ではないことをお知らせすることから始めたいと思いました。
私はすでにウェブ上で見つけられるものを逆流させるつもりはありません。 キャッシュプラグインをインストールし、圧縮を有効にし、css / jsを縮小する必要があるとは言いません…。
結局のところ、あなたはすでにこれらのことを行う方法を知っている必要があります。 そうでない場合は、他の何百ものブログでこの一般的な情報を見つけることができます。
代わりに、この記事には、私が過去1か月ほどで実装したすべてのカスタム/セミカスタムが含まれており、自分のWordPressブログを高速化し、基本的に不正アクセスによってサーバーがダウンするのを防ぎます。
そして、それが「ほとんど知られていない」理由は、これから説明するテクニックが、表示されているトラフィックパターンに応じて、自分のブログに非常に固有のものになるためです。
注:ブログの速度が遅く、Webサイトの高速化の技術的な側面に対処したくない場合は、おそらくWPEngineなどのサービスにサインアップする必要があります。
これらの人はWordPressホスティングを専門としており、ブログができるだけ速く実行されるようにします。 しかし当然、これには代償が伴います。 この投稿が頭に浮かぶ場合は、それらをチェックする必要があります:)
とにかく、私がブログに行ったことをどのように、そしてなぜ行ったかを説明する前に、WordPressとキャッシングに関するいくつかの基本的な概念を理解する必要があります。これについては以下で説明します。
いくつかの興味深いWordPressの事実
WordPressを高速化する方法に関するすべてのガイドラインにすでに従っているとしましょう。 あなたのブログは気難しいと感じています。 Webpagetest.orgは、あなたのブログが地獄のように速いと言っています。 すべてが大丈夫ですか? 必ずしも。
私は自分のブログについてまったく同じように感じていました。 結局のところ、私はほとんどの標準的な高速化プロトコルに従います。 私はプラグインをほとんど実行しておらず、人間の読者の観点から見ると、通常の使用ではブログはかなり速く感じます(広告ネットワークはブログの速度を低下させるので、最後に広告をロードします)。
しかし、その後、CPU使用率のグラフの分析を開始し、トラフィックレベルが低から中程度であるにもかかわらず、サーバーの負荷が高い期間に気付くことがよくありました。 時折、私のサーバーが長期間使用できなくなったり、応答しなくなったりすることさえありました。
これらの統計に注意を払い始めた唯一の理由は、しばらく前にブログと同じサーバーでオンラインストアを運営していたためです。 そして定期的に、店が非常に遅いと顧客に不満を言わせました。 ついに掘り下げたところ、最適化され、完全にキャッシュされたWordPressブログが、サーバーをひざまずかせていることに気づきました。
この話の教訓? 速度テストでブログが高速であることがわかったからといって、必ずしもすべてが良好であるとは限りません。
WordPressと、WP SuperCacheやW3TotalCacheなどのキャッシュプラグインに関するいくつかの面白い事実を知っておく必要があります。
- WordPress404の応答が遅い。 ブログが存在しないページへのアクセスを受信するたびに、貧弱なサーバーはWordPressをロードし、一連のphpコードを実行し、一連のMySQLクエリを実行してから、カスタムWordPress404ページを吐き出す必要があります。 これは非常にリソースを消費するタスクであり、キャッシュは役に立ちません。
- URLにGETパラメータがある場合、キャッシュプラグインはうまく機能しません。 たとえば、以前は、メーリングリストにブラストを送信するたびに、ブログのクロールが遅くなることに気づいていました。 理論的には静的ファイルキャッシュを使用すると、私のサーバーはほぼ無敵になるはずです。
しかし、Aweberは追跡パラメーターをURLに挿入するため、私のファイルはどれもスーパーキャッシュされません。 その結果、WordPressは(すでに存在していても)新しいキャッシュファイルを生成し、それを圧縮して毎回送信する必要があります。 最悪の部分は、これらのキャッシュされたファイルが1回だけ使用されるため、サーバーリソースが無駄になることです。
- 不正アクセスは遅いです。 不正アクセスではデフォルトでWordPressをロードする必要があるため、不正なリクエストでサイトをスパムすることを決定した不正なボットまたはクローラーは、ブログを非常に簡単に削除する可能性があります。
- キャッシュプラグインには、ブログの設定方法にバグや非互換性がある可能性があります。 たとえば、3年間、ログの監視を開始してコードのバグに気付くまで、WPスーパーキャッシュは正しいことをしていると思っていました。 設定方法が原因で、WPスーパーキャッシュがキャッシュを頻繁にフラッシュするという問題が発生しました。
上記の箇条書きで私が言いたいのは、ブログで非標準のアクセスが発生すると、WordPressブログの設定に関係なく、多くのサーバーリソースを消費するということです。 そして、これらのタイプのアクセスが、通常のトラフィックではなく、サーバーをひざまずかせます。
不正アクセスの検出
WordPressブログを最適化するための最初の鍵は、ブログが受信するトラフィックパターンを理解することです。 私は、WordPressユーザーの99%がこれを行わないことに賭けたいと思います。 代わりに、彼らは盲目的にさまざまなプラグインをフォローしてインストールし、すべてが正しく機能していると想定します。 気分が悪くならないでください、私も同じようでした。
したがって、最初のステップは、一体何が起こっているのかを見つけることです。 これを行うには多くの方法がありますが、最も簡単な方法は、プラグインWPSuperCacheが提供するデバッグモードを使用することです。 このモードは何をしますか? 基本的に、アクセスがWordPressによって直接処理されるたびに(リソースを大量に消費します)、WPスーパーキャッシュログに表示されます。 このモードを有効にする方法は次のとおりです。
WPスーパーキャッシュプラグインの[デバッグ]タブで、[デバッグを有効にする]チェックボックスをクリックするだけで準備完了です。
ロギングを有効にしたら、「logfile」リンクをクリックすると、WordPressトラフィックの詳細を示すファイルが表示されます。 以下のテキストのようになります。
15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching
注意すべき重要なことは、このログに何かが表示されると、WordPressが機能しなければならないことを意味するため、それは悪いことです。 また、WordPressはリソースを大量に消費するため、できるだけ少ない作業で実行する必要があります。
ログで何を探すべきか
WPスーパーキャッシュログは、進行中のすべてを教えてくれるので素晴らしいです。 しかし、何を探すべきかを知らない限り、膨大な量の情報は圧倒される可能性があります。 これらのログで注意すべき点は次のとおりです。
- 404エラー–基本的に、これらはブログに存在しないページへのアクセスです。 WordPressによって処理される各404アクセスは、多くのサーバーリソースを消費するため、可能であれば、これらをつぼみに挟みます。
- ワンタイムアクセス–これらは、サーバーに1回だけ使用されるページをキャッシュおよび圧縮させるリクエストです(これについては後で詳しく説明します)。
- 奇妙なトラフィックのバースト–これらは通常、ブログを一度に攻撃するボットです。
- 奇妙なキャッシング動作–キャッシュは必要なときにフラッシュされていますか? すべての状況ですべてが適切にキャッシュされていますか?
ブログのトラフィックを2週間記録した後、以下で説明する多くの非効率性を発見しました。
ボットは私のアーカイブを槌で打っていました
私が最初にしたことは、CPU負荷が高い期間のサーバーログを確認することでした。 次に、これらのまったく同じ期間にスーパーキャッシュログを分析して、面白いビジネスが行われていないかどうかを確認しました。 一日おきかそこらに、ボットのグループがやって来て、私のブログのすべてのアーカイブページを同時に叩くことが判明しました!
これらのアーカイブページはデフォルトではキャッシュされないため、多数の同時アクセスでサーバーの負荷が急上昇し、処理が非常に遅くなります。 そして時々、それは私のサーバーをクラッシュさせることさえしました。
そこで、HTML出力を詳しく調べたところ、WordPressヘッダーの一部としてアーカイブリンクがたくさんあることに気づきました。 したがって、ボットやその他のWebクローラーがやって来て、アーカイブを閲覧しようとします。

グーグルの大規模な後、私は他のいくつかのウェブマスターが同様の問題を抱えていることに気づきました。
サイトの読み込みの問題が何度も発生する場合、プロキシサーバーIPのヒット数が多く、これらのプロキシがサイトをキャッシュし、それらすべてのアーカイブリンクにヒットしているという理論があります。 サイトが読み込みの問題を引き起こしているときに表示されるIPの多くは、企業、教育、および政府/軍のプロキシIPであり、誰かがサイトにアクセスしたときにコンテンツをプリフェッチしているように見えます。
解決策:ブログのヘッダーコードにphpステートメント「wp_get_archives」が含まれているかどうかを確認し、削除します。 この小さなスニペットを削除した後、私のアーカイブアクセスはすべて消えました。
ボットが存在しないファイルにアクセスしていました
私が気付いた2番目の重要な点は、サーバー上の存在しないファイルにアクセスしているボットがたくさんあることでした。 問題は、ファイルアクセスが発生するたびに、サーバーがWordPressをロードし、一連のPHPコードを実行してから、404ページを発行する必要があることです。
この問題の解決策は、.htaccess(それが何であるかわからない場合はGoogle this)ファイルを編集し、次の行を追加することです。
RewriteCond%{REQUEST_FILENAME}!-f
RewriteCond%{REQUEST_FILENAME}!-d
RewriteCond%{REQUEST_URI}!(robots \ .txt | sitemap \ .xml(\。gz)?)
RewriteCond%{REQUEST_FILENAME} \。(css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | wax | wmv | wmx | avi | bmp | class | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| png | pot | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip)$ [NC]
RewriteRule。* – [L]
これらの行が.htaccessファイルに挿入されると、Webサーバーは最初にファイルが存在するかどうかを確認します。 そうでない場合は、WordPressをロードせずに404応答を発行します。
ボットが存在しなかったURLにアクセスしていました
WordPressの記述方法について不幸なのは、データベースに存在しない記事へのアクセスがある場合、サーバーはWordPressをロードし、一連のPHPコードを実行し、一連のMySQLルックアップを実行してから404応答。
ログを注意深く見ると、WordPressに到達する前に除外できる特定のアクセスパターンに気付くでしょう。
たとえば、たくさんのボットがURLwww.mywifequitherjob.com/some-article/www.facebook.com/like.php/…で私のサイトにアクセスしていることに気づきました。 そして毎回、私のサーバーはWordPressをロードし、404応答を発行します。
そのため、WordPressでこれらのリクエストを処理する代わりに、.htaccessファイルに次の行を追加しました
RewriteCond%{REQUEST_FILENAME}!-f
RewriteCond%{REQUEST_FILENAME}!-d
RewriteCond%{REQUEST_URI} www \ .facebook \ .com / plugins [NC]
RewriteRule。* 404.html [L、R = 404]
上記の行では、WebサーバーでURLで「www.facebook.com/plugins」を検索し、WordPressをロードせずにすぐに404応答を発行しています。 ログを熟読すると、上記のような不正なアクセスが多数見つかります。 それぞれに.htaccessルールを作成すると、これらのアクセスによってサーバーがロードされなくなります。
ボットは私のコメントリンクを槌で打っていました
GETパラメータを持つURLは、キャッシュプラグインによって異なる方法で処理されると言ったのを覚えていますか? 「コメントに返信」パラメータを設定して、記事を叩きのめすボットがたくさんいることを発見しました。
これが発生すると(キャッシュ設定によって異なります)、WordPressが読み込まれ、キャッシュされた/ zipファイルが提供されます。 これはリソースの浪費です。
私のログから取られた例12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.
解決策は、これらのGETパラメーターを持つすべてのボットとクローラーをメインの記事ページにリダイレクトすることです。 .htaccessファイルに追加したコードは次のとおりです。
RewriteCond%{QUERY_STRING} replytocom
RewriteCond%{HTTP_USER_AGENT} ^(。*)(bot | crawl | spider | slurp)[NC]
RewriteRule。* https://mywifequitherjob.com% {REQUEST_URI}? [L]
このコードは、「replytocom」GETパラメーターを探し、WordPressへのアクセスを提示する前に、このパラメーターを最終URLから削除します。
クローラーはスラッシュなしで投稿にアクセスしていました
なぜそうなるのかはわかりませんが、URLの末尾にスラッシュを付けずに、ブログの記事に合法的にアクセスしようとしているように見える多数のWebクローラーに気づきました。
あなたがまたは意識であってもなくてもよいため、http://yourblog.com/article/のように書かれているURLはhttp://yourblog.com/articleのように書かれたURLとは異なります。
その結果、末尾にスラッシュがないURLが検出された場合、WordPressが介入し、一連のPHPコードを実行してから、末尾にスラッシュが付いた記事への301リダイレクトを発行する必要があります。 WordPressを写真から取り出すには、次のルールを.htaccessファイルに挿入するだけです。
#末尾にスラッシュを追加する
RewriteCond%{REQUEST_FILENAME}!-f
RewriteCond%{REQUEST_URI}!(。*)/ $
RewriteCond%{QUERY_STRING}!。* =。*
RewriteRule ^(。*)$ $ 1 / [L、R = 301]
末尾にスラッシュを追加することで、正しいURLへの301リダイレクトを発行してから、WordPressに到達し、CPUリソースを節約します。
WPスーパーキャッシュにバグを見つけました
ほとんどの人とは異なり、public_htmlディレクトリのルートにWordPressブログをインストールしていません。 さらに、私のブログのフロントページも私の「投稿」ページではありません。 ブログを私と同じように構成すると、WPスーパーキャッシュにバグがあり、キャッシュをプリロードしても、すべてのキャッシュファイルが途中で削除される可能性があります。
プラグインの作成者がこの問題を認識しているかどうかはわかりませんが、基本的に、ブログにスパムコメントが発行されるたびに、キャッシュ全体が誤ってフラッシュされることがわかりました。 コメントやトラックバックのスパムを常に受け取るため、キャッシュが常に空になり、キャッシュの効率が大幅に低下していました。
そのため、週末にこの問題のデバッグを行い、最終的に回避策を開発しました。 同じ問題が発生している場合は、お知らせください。修正方法をご紹介します。 ここでの話の教訓は、キャッシングプラグインが正しく機能するとは決して想定しないことです。 あなたはログを見る必要があります!
CPU集中型プラグインを無効にする
上記のすべての手順を実行したとしても、WordPressブログに到達する前にすべての不正アクセスを除外することは不可能です。
したがって、効率的に処理されないヒットを常に受け取ることになります。 それを回避する方法はありません。
ただし、認識しておくべき重要なことは、帯域幅の問題は発生しない可能性が高く、CPUの問題が発生することです。
結果として(そしてこれは直感に反するかもしれませんが)、実際には、ページの「縮小」や「圧縮」など、CPUを集中的に使用するようなことはしたくありません。 最小化と圧縮は、CPU使用率を犠牲にして帯域幅を支援します。
あなたがしたい最後のことは、不正なアクセスを縮小してキャッシュすることです。 実際、GETパラメーターを使用してURLを縮小または圧縮しないことも検討する必要があります。
最も重要なことは、サイトでCPUを集中的に使用するプラグインを実行しないようにすることです。 WP-Engineには、おそらく避けるべきCPU集約型プラグインの素晴らしいリストがあります。
プラグインリストをよく読んでいると、「類似の投稿」プラグインを使用していることに気付きました。 そして、ソースコードを見てみると、プラグインがフルテキストを実行していることに気づき、CPUを大幅に浪費し、スケーラブルではない同様の記事を見つけました。
適切な代替品を見つけるとすぐに、このプラグインは間違いなくゴミ箱に入れられます。
この話の教訓
オンライン速度テストでブログが高速であることがわかったからといって、大規模な計画ではあまり意味がありません。
誤解しないでください。 ページの読み込み速度は検索エンジンと通常の顧客にとって重要ですが、キャッシュをバイパスしてサーバーをひざまずく可能性のある不正アクセスも考慮する必要があります。
したがって、キャッシュやその他の高速化プラグインを盲目的にインストールしないでください。 時間をかけてトラフィックを分析し、WordPressが実行する必要のある作業を最小限に抑えるために、できるだけ多くの.htaccessルールを記述してください。 幸運を!