以前より、多くの方から「重い」とのご指摘のありました、当ブログ「Telmina」。
執筆者である私自身も何とかしたいとは思っているのですが、どうも主因が分からない状況であります。
とは言っても、放置していい問題ではありませんので、まず可能なところからつぶしてゆかねばなりません。
何度も申し上げているように、当ブログは「WordPress」というプログラムにより構築されております。
WordPressには豊富なプラグインが用意されており、それにより機能拡張を簡単におこなうことが出来ます。
しかし、必要性のないプラグインまで有効化することにより、システム全体のパフォーマンスにも影響が出ます。これは単に処理する必要のあるステップ数が増加するだけではなく、データベースへのアクセスも増加するということを意味します[註1] 。
というわけで、まず、不要なプラグインについては無効化し、サーヴァからも除去することにしました。
とは言いましても、実は私のほうでは、すでに不要と判断したプラグインについては逐次無効化してはいます。もっとも、サーヴァに残したきりで撤去してはいませんでしたので、撤去作業が中心となりましたが…。
くせ者なのが、WordPressの古いヴァージョンでは稼働しており、現行ヴァージョンで稼働しなくなったもの、とりわけ他プラグインのフレームワークとして動作していたものです。
そちらについては、一応無効化はしてみたものの、そのままサーヴァから撤去するのも怖いので、とりあえずサーヴァには残しております。しばらくそのままブログの運営を続けてみて、どこにも影響が出ないようでしたら、完全に撤去したいと思います。
しかし、それだけではどうもブログが軽くなったような気がしません。
私はこことは別に「週刊 e217.net」というブログも運営しておりますが、そこの動作はそれほど重くはないのですね。
使用しているプログラムはWordPressの同一ヴァージョン。プラグインもほぼ同一構成です。
もちろん、使用しているレンタル・サーヴァは違いますし、記事数、閲覧数、更新頻度にも大きな違いがあるのですが、それにしてもここ「Telmina」の重さを、それらの差異だけでは説明できません。
以前ここと「週刊 e217.net」の表示速度を計測してくださった方がいらっしゃいますが、それによるとここのほうが3倍近くも表示までに時間がかかっているのだとか。
とりあえず、両者のブログのHTMLコードを見比べてみたところ、どうも「Telmina」のほうでは意味もなくJavaScriptのコードを読み込もうとしている箇所がありました。
実は先ほど申し上げております「他プラグインのフレームワーク」に関係しているのですが、そのプラグインを無効化することにより、HTMLコード内の無駄なJavaScript読み込みの記述も消えました。
そのほか、あまり効果が出ていないと判断される広告もいくつか撤去してみました。
これで少しは軽くなったような気がするのですが、いかがでしょうか？
とはいえ、どうもこれで問題が解決したような気がしません。
実は管理画面の動作も時々重くなります。
もしかしたら、プログラム側ではなくサーヴァ側、とりわけデータベースが、パフォーマンスに影響しているのかも知れません。
不要なデータを削除すればある程度改善されるのかも知れませんが、それ以上のことは、こちら側としては手を出せません…。
サーヴァの移動というのも一つの手ではありますが、これはあくまで最終手段。
出来れば面倒な手続きを踏まずに軽量化してゆきたいのですが…う～ん。
このブログで関連すると思われる他の投稿
4個のコメント
大きく分けて、DB アクセスが重いことと、広告の読み込みが遅いこととの2つだと思われます。前者にひっかかると、画面のレンダリング開始が始まるまでに時間かかります。遅い回線 (PHS とか) の場合は後者の影響が大きく、ページの大半は表示できているのに、読み込みがなかなか完了しないことになります。
DB アクセスは、とりあえず WP-Cache 系統の導入で改善できるかもしれません。それでもダメならば xrea 内でのサーバー移設でしょうか。
広告の重さはもはやゼロベースで考える必要があって、まずすべての広告を撤去してから、1つずつ追加していって、どうなるか確認、でしょうね。携帯電話表示ではほとんど広告がないわけですが、DB アクセスが重くない限り比較的早く表示されますから。
いまんところ、１０秒内外で表示できているようです。
参考までに当方の回線は５０ＭのＡＤＳＬ。
マシンのパワーはXP SP3環境下の
Mobile Pentium 1.6Ghz、メモリ２GB なりです。
外でPHSを使ってつないだらどうなるかは、そのうちやってみるということで。
あと、Ktai Entry を入れていると、その実装の都合上、サイト表示時に WordPress を2回ロードすると同じぐらいの負荷がかかります。外部メールサーバーの確認を別プロセスとして動かしたいため、スタイルシートの表示という形で retrieve.php を呼び出し、retrive.php では wp-config.php を require することで別プロセスとしています。その結果、2倍の負荷になってしまいます。
メールの取り込みを確実にするため、毎回のページ読み込みで retrieve.php を読むようにしていますが、読み取り時間間隔を経過しない限り retrieve.php へのリンクを出さないようにする変更も検討してみます。
皆様、コメントありがとうございます！
返信が遅くなってしまい申し訳ありません。
管理画面上での操作まで重くなる場合もありますので、私としてはこっちが主因なのではとにらんでおります。
あ、私のほうでも、終末あたりにイー・モバイル経由での接続を試してみます。結構重いのよね。
実は、ここの前身の「TSJ付゛録゛Ⅱ」時代に「WP-Cache」を入れて失敗した覚えがあります。具体的にどこでどう失敗したのかはいくつかあって完全には覚えておりませんが、少なくともアクセス解析の精度は目に見えて低下していました。
そのため、ここでもキャッシュ関連のプラグインは当面入れないつもりです。
結局そうしないとダメですかぁ。
実施するとして、早くて今週末でしょうね。
私のところの体感速度もだいたいこの位です。対策前より確かに速くなっています。
ADSLの50メガというのも同様。
ちなみにうちは電電公社が近いです（笑）。
仮にこれが大きくパフォーマンスに影響しているとしても、それなら「週刊 e217.net」も同様に重くなっていなければならず（一応あっちにも「Ktai Entry」は入れている）、「Telmina」の高負荷の主因とは考えにくいです。
メール読み込みの確実性を重視する人もいるでしょうから、可能であればこれについてはオプショナルでいいのではと、個人的には思います。
1個のトラックバック/ピンバック
[...] とりあえず、その1でプラグインのリストラはおこなったのですが、それでも稼働しているプラグインはまだまだ多く、しかも今のブログの機能を維持しながらプラグインだけリストラ [...]
コメントを書く