WordPressといえば、大人気のCMSです。CMSを利用しているWEBサイトで6割以上のシェアを占めています。
参考：https://w3techs.com/technologies/history_overview/content_management
当社でも利用しているお客様は多く、負荷対策のご相談も多くいただきます。その対応の中で少し気になることが。負荷の原因になるケースの多くが、「404 Not Found」のエラーが多発しているのです。
今回は、WordPressの「404 Not Found」がサーバ負荷の原因になりやすいのか？ということを調べてみました。結論的には、結構な負荷の原因になりえることが分かったので、「404 Not Found」が発生しないサイト作りを心がけましょう。
↓↓ 動画の解説はこちらから！ ↓↓
リンク切れごとの性能比較
応答速度比較
WordPress >> 静的コンテンツ
大前提として、WordPressはサーバ負荷的には重いものとなります。
| ページ | 応答時間 |
|---|---|
| 静的ページ | 15m秒 |
| 動的ページ | 150m秒 |
手元の環境で確認したところ、画像などの静的コンテンツは15m秒程度で応答が返ってくるのに対して、トップページなどの動的コンテンツは150m秒程度の時間がかかっています。その差は約10倍にもなります。
トップ≒固定≒投稿≒404エラー
| ページ | 応答時間 |
|---|---|
| トップ | 151m秒 |
| 固定ページ | 147m秒 |
| 投稿記事 | 159m秒 |
| 404エラーページ | 145m秒 |
WordPressの中でも、トップページ、固定ページ、投稿記事、404エラーページの速度比較をしてみたところ、ほど同等の応答速度ということがわかりました。
確認環境
ちなみに、確認は以下の環境で行っています。
| 環境 | 内容 |
|---|---|
| サーバ | m5.large |
| OS | AmazonLinux2 |
| WordPress | 5.5 |
| テーマ | TwentyTwenty |
| PHP | 7.2 |
| MySQL | 5.7 |
| 備考 | すべてデフォルト状態で確認 |
404エラーの発生パターン
404エラーはいくつかの発生パターンがあります。
| No | 影響 | 404エラー発生パターン |
|---|---|---|
| 1 | 小 | URL打ち間違い |
| 2 | 小 | hrefのリンク切れ |
| 3 | 大 | srcのリンク切れ |
URL打ち間違い
まず最初のパターンは、URLの打ち間違いです。アドレスバーに手打ちでURLを打つ場合に、次のような間違いをすると発生します。
実際に試してみると、このサイトでは、次のようなエラー画面が表示されました。
ptune.jpの404エラー画面
hrefのリンク切れ
hrefのリンク切れは、コンテンツ側の問題です。aタグのリンク切れです。
ユーザーがリンクをクリックすると、URLの打ち間違いの時と同様に404エラー画面へ遷移します。
- 〇：<a href="https://ptune.jp/tech/"
- ×：<a href="https://ptune.jp/tec"
srcのリンク切れ
最後はsrcのリンク切れです。画像やcssなどリソースを取得するためのリンクです。一見すると表示に問題ないケースが多いですが、性能には大きな影響を与えています。
URLの打ち間違いと、hrefのリンク切れはそれほど大きな問題はありませんが、srcのリンク切れは大きな処理負荷を引き起こします。
- 〇：<img src="namidame.jpg"
- ×：<img src="namidamex.jpg"
理由は、一つの画面を表示させるのに、404エラーが発生した分だけのプログラムが動作するからです。
リンク切れの分だけ動的プログラムが動作
その結果、一つのリンク切れがあるだけで処理負荷が増大し、対応可能な同時アクセス数が50%程度も下がってしまいます。
どれくらいの性能低下があるのか
下の図は、トップ画面の限界スループットを調査したものとなります。
一番上の青い線がリンク切れがない場合の限界スループットです。リンク切れがないものと比較して、1つのリンク切れがあると40%程度の性能劣化がみてとれます。2つのリンク切れがあると50%、3つのリンク切れがあると60%の性能劣化が発生しています。
リンク切れごとの性能比較
404.phpで改善するのか？
WordPressの404エラー画面は、テーマ配下の「404.php」でカスタマイズ可能です。実はこのファイルが処理負荷の原因では？と思い調べてみました。結果としては、404.phpが動作する手前で大きな時間がかかっていることがわかりました。
| ページ | 応答時間 |
|---|---|
| デフォルトの404.php | 145m秒 |
| 空ファイルの404.php | 131m秒 |
もちろん、404.phpをカスタマイズしているケースは多くあり、そこで処理負荷が上がっている場合もあります。その場合は、404.phpの改修が効果的かもしれません。しかしながら、WordPress自体の処理負荷が結構な問題になっています。
まとめ
WordPressでは、画像やcssのリンク切れがあるとサーバ負荷が倍増することがわかりました。
サーバが重いので増強しよう？と検討する前に、リンク切れの精査をしてみてはいかがでしょうか？