ここは僕の冷蔵庫。後はあれして食べるだけ。

I love the frozen FOOD.

wordpressのテーマ作成をしたり、プラグインを沢山インストールをしていると、wordpressが遅くなる現象に見舞われます。

  • プラグインを入れたら遅くなった
  • テーマを改変したら遅くなった

そんな場合は、だいたい察しはつくものですが、「おおまかな状況」しかわかりえません。だんだん遅くなってきた場合は、もう何がなんだかでしょう。
wordpress速度改善」という記事にも書きましたが、結構、改善ポイントってあるもんです。が、原因が分からないというのは、ほんとつらいもの。
そんな場合、みなさんはどう対処してますか?自身でロギングロジックいれてスペックを計測してますか?

Degug-barによる計測

そんなとき、便利なのがDebug-barというプラグインです。

どこで、だれが、とろいのか

がわかりますよ。
DBなのか、初期化処理なのかわかりますよ。

インストール

下記の順番でプラグインをインストールしましょ。2つ入れます。

  1. Debug-bar
  2. Debug-bar-extender

プラグインをインストールし有効かするとわかりますが、右上に
debug-bar
が出てきます。

DEBUGボタン

まず、計測したいページに飛んでください。TOP画面でも、管理画面でもどこでも大丈夫です。ここだと思ったら、右上のDEBUGボタンを押してください。


こんな画面が出てきます。

DBスペック

最初に出てくるのは、DBのスペックです(左側のメニューでQueriesが選択されてます)。その画面を出すのに必要なDBへのSQL本数、トータル秒数(青丸のところ)がわかります。
TOTAL QUERY TIMEは、DB処理のトータル時間。

11ミリ秒(1000ミリ秒が1秒です)

と表示されてますので、DB処理は全くボトルネックになってません。
尚、個別の処理結果は、右下に出てきます。トータル秒数がかさんでいるときは、ここの一覧をみてください。現状でいうと、#1になっている(一番遅い)処理は、0.6msと書いてあります。その左をみると、Jetpackというキーワードが目につきますね。

このブログのDB処理で一番遅いのは、Jetpack関連で、0.6ミリ秒かかってるよ

ということです。

処理スペック

次に、処理単位のスペックです。左のメニューで Profiler を選択します。


見るポイントは2つです。

  1. TOTAL EXECUTION TIME
  2. すべての処理に使われた時間
  3. 個別処理スペック(一覧)
  4. 処理単体の時間

TOTAL EXECUTION TIMEで、まずは「全体のスペック」を確認してみてください。489.24ミリ秒です。0.5秒以下ですので、私的には全然OK。
Jetpackなどをがっつり入れていると、ここが2000ミリ秒とか超えます。。。DBのスペックはいいんですが、処理単体では結構つらい計測結果が出てくる場合ありますね。。

例えば、ここの秒数がかさんでいる場合、その下の一覧をみてみてください。
1から始まる一覧になってます。見るところは2つ。

  • 緑色の丸の箇所
  • 処理名
  • 赤い丸の箇所
  • 処理にかかった時間

この一覧でいうと、「Debug-barが一番遅いぞ」って警告もらってます。普段はプラグインを有効にしてませんので、まあ、これが遅くてもいいかな。
遅い項目が一覧で見つかったら、この「処理名」とそのあとに続くスクリプト名を参考に、「遅い原因をつめていく」感じになります。

遅い原因の詳細をつかむ

上記で「だいたいの目安」がつかみ終わったら、詳細を突き止める準備にかかります。
ここからは、少しハードルが高くなります。
今までは、プラグインだけで済みましたが、ここからは、実際のコードに「罠掛け」することになります。テーマ作成やプラグイン作成をしたことがない方は、辛いかもしれません。前節までで、「悪い原因」が大まかにわかりましたので、該当プラグインを停止するか、妥協するか検討するといいかもしれません。

特定開始

では、実際にはじめます。
前節までは、「スペックが遅くなっているだいたいの場所」がつかめました。ここでは、場所の特定にかかります。
さて、特定方法ですが、先ほどの「処理スペック」の一覧のような、「処理秒数」を計測するという手法をとります。前節とは異なり、自分の好きな箇所の「処理秒数」が計測できるので、「悪い原因が特定しやすくなる」という形です。

計測方法

特定するために、下記のようなソースコードを、プラグインなり、テーマなりに入れ込みます。

Debug_Bar_Extender::instance()->start( "チェック1 開始" )
:
~処理~
:
Debug_Bar_Extender::instance()->checkpoint( "計測ポイント1" )
:
~処理~
:
Debug_Bar_Extender::instance()->checkpoint( "計測ポイント2" )
:
~処理~
:
Debug_Bar_Extender::instance()->end( "チェック1 終了" )

上記コードを入れると、下記の内容が把握できます。

  • チェック1から計測ポイント1までの処理時間
  • チェック1から計測ポイント2までの処理時間
  • チェック1からチェック1終了までの処理時間

画面右上のDEBUGボタンを押せば、先ほどと同じように上記計測結果が出てきますよ。

地味な作業ですが、これで、問題となっているコードが把握できます。
是非ともトライしてみてください。

対策を考える

上記で「問題が把握」できましたと。じゃあ、対策をどうしようという話ですよね。

テーマが悪さしている

ご自身が作ったテーマであれば、ご自身で膿を取り除きましょう。DBで遅延を招いていると思えば、DBにかかわるものを最小限に抑えるというのも大事です。コンテンツを多量に検索かけているなら、少し抑えるよう検討しましょう。あいまいな検索を行っているのであれば、できるだけ具体的にしましょう。SQL文を改善できるのであれば、そこを検討するのも良いかもしれません。また、DB側をチューニングするのもいいかもです。
フリーのテーマを利用している場合は、対処は3つです。

  • テーマの設定をみる(設定が無い場合は諦める)
  • 他のテーマを探す
  • 妥協する

テーマの中には、「テーマの設定」ができるものがあります。余分な機能を削減できる場合もありますので、そこをチューニングしてみてください。設定が無い場合は、どうしようもないですね。
その場合は、他のテーマを探すか、現状で妥協するかです。

プラグインが悪さをしている

私の経験から言うと、速度遅延の原因は、プラグインという落ちが多いです。

プラグイン単体で動かすと快適なのに、他と組み合わせると・・・

という場合もありますよね。

そんな場合は、

  • プラグインの設定をかえる(設定が無い場合は諦める)
  • 他のプラグインを探す
  • プラグインを使うのをやめる
  • 妥協する

を検討ください。
JetpackやSNS系のプラグインは、設定を変えると劇的に早くなる場合があります。
他サイトから情報をひいてくるようなプラグインは、気を付けましょう。

サーバが遅いだけの場合も

色々原因を探ったら

単純に、サーバーが遅いだけ

という場合もあります。。
非情に残念ですが、これは、もうどうしようもないですよね。。。
その場合は、サーバを変更するか、ご契約情報を見直し、スペックがいいものに変更いただくかする必要があるかと思います。
wordpressをあきらめるってのも、手です!

原因が分からない

上記方法で、「原因がない」という場合もあります。上記はサーバー側のスペック計測ですので、ブラウザ側のところは把握できてません。

html/css/javascript、コンテンツ量

などの原因がある場合は、分からないということです。
そんな方は、「wordpress速度改善」という記事も用意してますので、そちらを参考にしてみてください。

参考

参考記事


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


*