Blog Tips#3 Increase per­form­ance of your WP site — Word­Press のパフォーマンスを極限まで引き上げる方法

この記事は Blog Tips#3 Increase per­form­ance of your WP siteの邦訳である。

先程の記事 では読者の数を増やす事について書いた。今回はパフォーマンスの向上について見ていこうと思う。先日，読者の1人が経験した事だが， Word­Press をバックエンドに使っている際，膨大なページを Word­Press を CMS として使っている時に起こるバックエンドのパフォーマンスの低下に悩んでいた。このような問題に直面しているのはなにも彼(仮にトムとしよう)だけではなく，多くのWPユーザも同じ問題に頭を抱えている。問いを立ててみよう: “このような問題は Word­Press のコアに存在するものなのか，はたまた 時折起こる他の問題によるものなのか?“

答えは単純ではない。Drupal でも，WordPress でも，どの CMS でも，コアそれ自身に起因するものではない，幾多の同じトラブルに直面する。この検証については(各自ががインストールした)WordPressに限定して焦点を当てていくと思う。何故最初に基本的な原因にスポットライトを当てないのか，つまりそれは簡単に無くせるものなのか? あなたが Word­Press で構築したサイトはもしかしてこのようなパフォーマンスの低下に悩まされていないだろうか: 

• MySQL サーバ及び のネットワークコネクションにおける問題
• PHP のメモリ上限
• Apache のログローテンションに関してのトラブル (Apache サーバを使っている場合)
• テンプレートやテーマ内に存在する，壊れた，あるいは劣化した PHP コード
• プラグインの使い過ぎ，あるいはプラグイン内にある，壊れたコード
• あるサードパーティ製のウィジット，または JavaS­cript コード
• Word­Press ダッシュボードに表示させている RSS フィード
• 記事の投稿時における ping­back について

他のも多くの遅延の引き金となる原因がある。しかし，それらの内一つないしそれ以上は上に挙げたものが原因になるであろう。今こそ我々のWPサイトがバックエンドやフロントエンドでの遅延の原因を見極め，どのように回避すればいいのかについてみていこう。

MySQL サーバ及び のネットワークコネクションにおける問題

実際のところ，ホスティング会社が解決できるものであれば読者が手を加えられる部分はほとんどない。ほとんどの場合，原因は一時的なものであり，ホスティングがアップグレード作業をしていたり，ダウンしていたりといった場合である。あまりの多くのコネクションが DB サーバに張られるとパフォーマンスの低下を引き起こす事がある。WordPress のバックエンドは MySQL データベースが要求クェリーに答えられない時に遅延を引き起こす事もある。

解決策:

ホスティング会社がアップグレード作業やダウンタイムがある場合，サポートへコンタクトを取ること。使っている Word­Press のデータベースが他者のサイトと共有していない事を確認する事。もし，ホストのアップグレードや変更が必要な場合はホスティング会社のデータベースの統計情報を考慮する事。単に感じが良いからといってホスティング会社をダラダラと使い続けない事。ただし，貴方の技術的な要求に応えられている場合は除く。

PHP のメモリ上限

Word­Press の心臓部は PHP である。したがって，何かしら PHP がおかしくなった場合，トラブルが起こる事は明らかだ。デフォルト状態のPHPは，扱いにくいものも含めて，考え得る限り全てのモジュールを読み込もうとする。たくさんモジュールを読み込めば読み込むほどメモリが必要になる。読み込むモジュールを何故コントロールしようと思わないのだろうか。多くの機能拡張ファイルを無効化すれば使うメモリを減らすことにつながる。これこそ PHP の設定を最適化するとても良い方法だろう。

解決策:

PHP の設定を最適化し，無用なモジュールを読み込まないようにする事

Apache のログローテンションに関してのトラブル (Apache サーバを使っている場合)

Apache サーバ上で動いている場合に起こる。ログローテーションを行うスクリプトが壊れた場合，サーバのログは肥大化の一途をたどる。詰まる所，サーバは何百メガバイトもの過剰なログファイルを読み込む事により，サーバを不安定にさせる要因になる。

解決策:

サーバのテクニカルサポートへログローテーションのトラブルについて連絡する事。ログディレクトリやログファイルが serv­er writ­able になっている事も確認するように。

テンプレートやテーマ内に存在する，壊れた，あるいは劣化した PHP コード

多くの Word­Press ユーザはさいとが大きくなるにつれこのような原因によるパフォーマンスの低下を経験する。ウェブ上で 幾百もの美しく，そして魅力的な Word­Press のテーマと出会うことだろう。しかし，どのようにしたらバックエンドにかかれているPHPコードが最適化されているのかどうかを知る事が出来るのだろうか? Word­Press は幾つかの基本的なガイドラインや要求をクリアするようテーマに対して求めているが，PHP のコードに関してのチェック項目はない (テーマ一つ一つをチェックしていくのは現実的ではない)。ユーザの観点から立つとテーマ内のあるこーでゃさいてきかされてしかるべきだろう。なぜならコードはサイト全体のフレームワークなのだから。

解決策:

まずは手始めにWP-Cacheプラグイン (Word­Press の最新のバージョンには同梱されている) を使う事をお勧めする。古典的ともいえるキャッシュによる解決策である。WP-Cache はコメントを受信した時などに自動的にアップデートされ，常に最新の状態に保たれるうえ，読み込み時の時間をより削減できる。2つ目には，これはオプションだが，何故バイトコードを節約しようとする度に毎回再コンパイルをしなくてはいけないのか? eAc­cel­er­at­orという機能拡張があり，これは幾許かのディスクスペースを占有するかわりに opcodes を最適化し，再コンパイル済みスクリプトを保存しておく。この機能拡張は最大で5000ミリ秒読み込み時間を削る事が可能である。3つ目は，プラグインはそのままにテーマを基本的なもの，例えば Word­Press のデフォルトのテーマ，へ変えてパフォーマンスのテストをする事。パフォーマンスが低下したら事の原因はテーマはテンプレートではない事になる。

プラグインの使い過ぎ，あるいはプラグイン内にある，壊れたコード

Word­Press が遅延する二番目の原因と思われる。上に上げた問題と同様，壊れたPHPコードや劣化したMySQLクェリーによって引き起こされる。しかし，大本の原因はプラグインそれ自身のファイル内にある。

解決策:

プラグインを使わずに簡単に実現できる機能ならばプラグインを使わない事。欲しいプラグインのみを使い，また出来る事なら使っていないプラグインをディレクトリから削除する事。今一度，プラグインを一旦全部無効化し，ブラウザキャッシュをクリアしよう。プラグインをひとつ有効化し，ブラウザのキャッシュをもう一度削除した後，WordPress の動作がもたつかないかパフォーマンスをチェックしよう。この作業を Word­Press の動作がもたつくまでまたは必要なプラグインが全て有効化されるまで続けよう。詳しくは次の blog tips で取り上げるが，遅延または劣化したMySQLのクェリを見つける方法である。

あるサードパーティ製のウィジット，または JavaS­cript コード

まったくもって奇妙だが，ランダムで発生する。つまり，違う読者が違うタイプのサードパーティ製スクリプトやウィジットでサイトのもたつきを経験するのだ。ランダムに起こるのに，何故私が原因は問題のあるコードにあるのかというと，ほとんどの場合，このトラブルはスクリプトやウィジットを取り除く事で解決しているため，そいつらが原因に違いないと思っている 😛

解決策:

サードパーティー製のスクリプトやウィジットのほとんどに共通している事に，新しいバージョンの Word­Press に起こっている (理由は不明だが)し —どこでもスナッププレビューができる MyB­lo­g­log ウィジット (Myb­lo­g­lo­gの­JavaS­cript版) は手動でJavaScript版ではないコードをテンプレートに貼り付けると驚く事に鈍重さが解決され，また，広告ネットワークのJavaScriptのコード (私が経験したものでは，幾つかの広告ネットワークが提供する広告用のスクリプトはサイトを完全にダウンさせた)，他30–40ほどのスクリプト—。サイトのスマートな動作は必要なスクリプトだけを使い続ける事でもたらされる (可能であれば­JavaS­criptではないコードを貼る事)。

Word­Press ダッシュボードに表示させている RSS フィード

記事やテンプレートの編集をしている時や Word­Press へのログインに時間がかかると思った時，この動作の散漫さの根源は Word­Press のダッシュボードだと感じた事だろう。ダッシュボードは管理画面の “ホーム“ であり，あなたが書いた最新の記事へのリンクや投稿されているコメント，そしてあなたのサイトをリンクしているサイトからの訪問者をリストしている。不幸な事に，ダッシュボードは幾十もの Word­Press に関連した RSS フィードをも表示している。よく30秒やそこらページをロードする時間が余計にかかる程度ならまあいいアイデアだが，新しい情報や重要な情報を引っ張ってくる事は稀である。この余計な時間を削減する方法は2つある:
-

1. ダッシュボーどーページ(index.php)の読み込みを完全に止める事。サイドバーにある “ログイン“リンクは例外であるが，このリンクも単に /wp-admin/post.php としても良い。これですぐ読み込める投稿画面へ行けるし，また，この方法なら管理画面のどのページへもリンクできる。必要とあらばダッシュボードへも。
2. ごく普通にログイン機能を使いたいというならAngsuman’s Dash­board hack をインストールするといい。このプラグインはダッシュボードの RSS セクションを他のもっと有用なリンクへ置き換える事が出来る。

記事の投稿時における ping­back について

これもランダムな原因で Word­Press の投稿，特に編集画面の，インターフェイスに起こる遅延である。実際の投稿プロセスは即座に終了するが，遅延は2つのネットワークの状況によって引き起こされる:

• Word­Press は記事内にある，リンクを張った URI 各々に ping­back を試みる。しょっちゅう Word­Press のブログをリンクしているのなら，実際，非常に有用な機能の一面であるが，時間を浪費するものでもある。経験則だが，pingback をブログではないサイトへ送ろうと試みた場合，あなたのサイトにそれほど軽くはないレスポンスの低下をもたらす。あなたの書いた記事と関係のない記事へのトラックバックに40–45病も費やす事のないよう，デフォルトのトラックバックのようなプラグインを使わないよう祈るだけである。
• Word­Press は Ping-O-Mat­ic をあなたの記事を検索サイトへ登録する手段として用いている。非常にいい方法だが，場合によってはこれも遅延の原因となる。ほとんどあり得ないが， Ping-O-Mat­ic が遅延の原因になる。この可能性も排除したい場合， rpc.pingomatic.com を オプション→執筆 にあるアップデートサービスから削除するといい。Ping-O-Matic に変わるサーバを加えても良いだろう。lPing-O-Mat­icに代わるピンサーバのリストを挙げておくので参考にしてほしい。

これまで見てきたように，WordPress の遅延のケースのほとんどは Word­Press とはまったく関係しないものである。ホンの少し手を加え，トリックを使えば十分に回避できるものばかりである。

from Blog Tips#3 Increase per­form­ance of your WP site