サーバーの負荷に合わせてWordPressを最適化する手順

Question

W3 Total Cacheや他のキャッシングプラグインをインストールする以外に、自分のテーマとサイトができるだけ速く実行されるようにするためにどのようなステップを踏むことができますか。

Answer 1

あなたはNginxにWordPressをインストールすることができます。役立つリソースがいくつかあります。

• nginx互換性プラグイン

• HOWTO：NginxにWordPressをインストールする -

• Slicehostディスカッション

• NginxとWP Super CacheでWordPressを高速化する方法

• nginx + lighttpd + FastCGI + phpのWordPress

• WordPressのフロントエンドプロキシキャッシュとしてのNginx

その最後のリンクからのパフォーマンス情報（これは他のものとは少し異なる設定のようです）。

だから私は可能な限り静的キャッシュへのワードプレスの前にプロキシを置くことにしました。認証されていないトラフィックはすべてnginxファイルキャッシュから直接処理され、6ページ/秒から7000+ページ/秒までのリクエスト（RSSフィードの生成など）が行われます。おお。 Nginxはロギングとgzippingも処理します。バックエンドが重い場合は、必要なときにだけ動的なワードプレスページを提供するようにします。

...

Nginxでは - とても効率的で怖いです。最大の負荷がかかっていても、10〜15メガバイトを超えるRAMとCPUのフラッシュを使用したことは一度もありません。神経節のグラフは嘘をつきません。メモリ要件を半分にし、発信ネットワークのスループットを2倍にし、負荷を完全に平準化しました。これを設定してから基本的に問題はありません。

Answer 2

CSS、画像、JavaScriptなど、各ページビューで再ダウンロードする必要がないものについては、クライアント側の有効期限を設定します。これは、私のサイトの読み込み時間に最大の違いをもたらしました。最速のダウンロードは、起こったことがないダウンロードです...

# BEGIN Expire headers
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 7200 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 2592000 seconds"
  ExpiresByType text/javascript "access plus 2592000 seconds"
  ExpiresByType application/x-javascript "access plus 2592000 seconds"
  ExpiresByType text/html "access plus 7200 seconds"
  ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
  <FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(css)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(js)$">
    Header set Cache-Control "max-age=2592000, private"
  </FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

あなたはあなたが合理的にできるすべてのものを事前にgzipすることができ（7-Zipはこれに良いツールです）そしてあなたが今gzipしたファイルと同じ場所にそれをアップロードすることができます。以下のように、.htaccessを変更してgzipされたファイルを提供します。ここでの注意点は、あなたがものを更新するときには、それらを再gzipすることを忘れないでください。これにより、.htaccessの解析とは別に、CPUのオーバーヘッドが削減されます。

RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]

これは単なる生の答えです。このテーマにはたくさんのバリエーションがあります。私はこれについてブログを書き、 http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ にあるより詳細な記事へのかなりの数の参照を追加しました。それを読みなさい、そしてもっと重要なことに、私が指す参照 - それらは良いリソースです。

頻繁にいじっている場合は、ユーザーはキャッシュを更新する必要があります。

私もとても便利だと思うプラグインは wp-minify です。これに注意することはあなたが各ページのためのcss、JSなどの全部のセットを再ダウンロードしないようにあなたがページ特有のアイテム（連絡フォーム、フロントページスライダーなど）を除外するべきであるということです。ベースラインのCSS、JSなどを縮小、結合、および圧縮するのに適した方法です。httpリクエストを大幅に削減します。 Wp-minifyは、スーパーキャッシュと、上で詳述した有効期限ヘッダーでもうまく機能します。

Firebug（Firefox）などでYslowを使用して、httpリクエストと圧縮されているものと圧縮されていないものを監視します。そこにある有効期限ヘッダーも見てください。あなたはすぐにあなたが改善できるものを見るでしょう。

Answer 3

あなたが本当に必要とするものだけにあなたが走らせるプラグインの数を最小にしなさい。特に、ページでそのコードが使用されていない場合でも、ページが読み込まれるたびにJavaScriptとCSSコードを追加するプラグインに注意してください。

最初から独自のテーマを作成している場合は、特定のページテンプレートまたはビュータイプ（単一の投稿、アーカイブ、カテゴリなど）にのみ必要な機能が必要なときにのみロードされるようにCSSを分割します。

CDNを使用するようにW3TCを設定します（Amazon CloudFront、またはW3TCでサポートされている他のいずれかなど）。

Minifyオプションがあなたのために働くかどうかを確認してください（いくつかのプラグインはうまく縮小できないjs/cssを生成するので、minify機能を有効にした後あなたのサイトを必ずテストしてください）。

MySQLサーバーを完全に制御できる場合は、query_cacheがオンになっていることを確認してください。データベースの設定を最適化する他の方法を見つけるには、 MySQL調整スクリプト を使用してください。

何らかの理由でCDNの使用に問題がある場合は、Apacheの設定でmod_expiresを設定してください。画像、CSS、Javascript、ビデオ、オーディオなどの静的な型に有効な限り有効期限を設定します。

Answer 4

memcached を実行し、 オブジェクトキャッシュ を使用してデータベースクエリの数を減らします。これは、ページではなくデータベースからデータをキャッシュします。 w3-total-cacheがすでにこれを実行しているかどうかわからない。

_ apc _ のようなオペコードキャッシュを実行していることを確認してください。 （他にも利用可能なものがいくつかあります。）

Answer 5

Wp-cacheのようなディスクキャッシュプラグインを使用することに加えて、ブログに "noatime"プロパティが設定されているホストボリュームに配置します。それ以外の場合は、ホストにSSH接続し（Webホストから提供されている場合）、数日ごとにファイルに対してこのコマンドを定期的に実行します。

chattr -R +A ~/*

〜/ *は「自分のホームディレクトリの下にある自分のファイル」を意味します。あなたが合うようにあなたはその道を変えることができる。 Webホストから提供されている場合は、これをcpanelのcronジョブに設定することもできます。

Atimeプロパティの詳細については、 this を参照してください。これはLinuxのディスク読み取りパフォーマンスを大幅にスピードアップします。

時にはあなたのサイトがクモに襲われている。 SpyderSpankerやChennai Centralなどのツールを使用して、ページのランクを上げずに速度を落としてスパイダーを排除し、ランダムに送信して（グーグル、ビングなどの）優れたスパイダーを絞り込むことができます。 HTTP 304 Not Modifiedメッセージ。

私が見ているもう一つのことは、単調に書かれていないプラグインです。プラグインの作成方法を学ぶと、一部のプラグインがどのように非効率的にコーディングされているか、あるいはいっぱいになっていっぱいになって消去されることがないデータベーステーブルなど、着信接続データなどを格納するタイムボムを見つけることができます。

ここで他のすべての解決策を越えて、あなたはまたあなたのブログのWordPress Webファームを作成することができます。 ） Ultra Monkey をチェックして、すべてうまくいくようにしてください。

Answer 6

私の頭の上からいくつかの答えがあります。

1）可能な場合/実用的な場合は、JavaScriptとCSSを連結して、ブラウザがホストに送信しなければならないHTTP要求の数を最小限に抑えます。

2）共有ホスティングを使用している場合は特に、できるだけ多くの画像/メディアをサードパーティのCDNに配信してください。

3）合計レンダリング時間を短縮するために、フロントページに表示する投稿数を減らしてみてください。

3a）フロントページにいくつかのおすすめ投稿と、その他の古い投稿を抜粋として表示したテーマを使用してみてください。

Answer 7

WordPressメニューをキャッシュすると、パフォーマンスも向上します。特にあなたがたくさんのPagesや巨大なメニュー構造を持っているなら、これは考慮されるべきです。

2つの簡単なステップでそれをしなさい。最初に、wp_nav_menuを直接呼び出す代わりに、メニューを取得または作成する関数を作成します。

function get_cached_menu( $menuargs ) {

    if ( !isset( $menuargs['menu'] ) ) {

        $theme_locations = get_nav_menu_locations();
        $nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
        $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
        $transient = 'menu_' . $termslug->slug . '_transient';

    } else {

        $transient = 'menu_' . $menuargs['menu'] . '_transient';

    }


    if ( !get_transient( $transient ) ) { // check if the menu is already cached

        $menuargs['echo'] = '0'; // set the output to return
        $this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
        echo $this_menu; // output the menu for this run
        set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved

    } else {

        echo get_transient( $transient ); // just output the cached version

    }

}

テーマで、wp_nav_menuをget_cached_menuに置き換えます。現在、メニューが呼び出されるたびに、メニュー構築全体ではなく1つのDatabasequeryがあります。

メニューはあまり変更されませんが、古いトランジェントを削除するにはwp_update_nav_menuアクションにフックする必要があります。

これを好きですか？

add_action('wp_update_nav_menu', 'my_delete_menu_transients');

function my_delete_menu_transients($nav_menu_selected_id) {

    $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );

    $transient = 'menu_' . $termslug->slug . '_transient';

    delete_transient( $transient ); 

}

次にページが呼び出されたときにメニューが生成されます - そして誰かがメニューを再び更新するまでキャッシュされたバージョンを使用します。

更新版

ナメクジとIDの間違いを指摘してくれてありがとう@helgatheviking。 theme_positionとmenuの両方で動作するように関数を更新しました（メニューを直接呼び出すため）。

メニューは、テーマ内の位置ではなく、常にメニューの名前で保存されます。

Answer 8

最適化のために調整されたデータベースクラスを使用してください。メモリ使用量とデータベースアクセス速度を減らすために、私たちは独自のコードで良い経験をしました。その次に、あなたはデータベース構造自体を最適化することができます。

データベースクラスのコードの一部はwordpressのtracにありますが、コアにはなりませんでした（ チケット＃11799および関連 ）。

Answer 9

トラフィックの多いサイトでは、現在設定されているコンテンツ用にすべてのMySQLバッファを調整する必要があります。 WordPressのバージョンにかかわらず、 MySQLレイヤーはその構成を計算させることができます です。

実際、innodb_file_per_tableを有効にせずにInnoDBデータがある場合、 各テーブルを独自の物理テーブルスペースにセグメント化してInnoDBをクリーンアップする必要があります 。きちんとしたMySQLチューニング あなたが限られたハードウェアを持っている場合でも を行うことは可能です。 そのようなInnoDBの最適化を行うための多くのシナリオ _があります。

私見、あなたが設定するデータの量を知らずにmy.cnfのための良い設定を計画することはできません。現在のデータセットを本番環境からステージング環境に定期的にロードし、最適化を実行し、本番サーバーのmy.cnfで構成するための数値をなくす必要があります。

Answer 10

私は最近この話題について WordCamp Houston で話しました。上記の推奨事項はすべて素晴らしいものです。重要なことは、すべてのフロントエンドのものが完全に最適化されていることを確認してから、キャッシュとサーバーのパフォーマンスの問題に取り組むことです。

プログレッシブレンダリングを使用すると、ページの内容が完全に読み込まれる前にユーザーに表示されるため、ページの表示が速くなります。これを行うには、ブロッキングjsがページの一番下にあり、cssが一番上にあるようにします。

また、ソーシャルメディアのボタンをたくさん使用する場合は、ページが完全に読み込まれた後にスクリプトをカスタマイズしてiframeに読み込ませることができます。私はTweetMeMe re Tweetボタン（Twitterが独自のリツイートボタンをリリースしたため現在は使用されていない）でそれを行う方法についてのチュートリアルを書きましたが、それでも他の共有ボタンに適用できます。

サーバパフォーマンスのために、Apacheが重いPHPとMySQLリフティングを処理する静的コンテンツのフロントエンドプロキシとしてNginxを調べてください。

Answer 11

グローバルな 出力圧縮を有効にできます 。ブラウザがサポートしていれば、これは自動的にすべてをgzipします。これにより転送されるファイルのサイズが劇的に減少しますが、CPUの負荷は増大します。

Answer 12

まだ誰も言及していないので、LAMPの設定と組み合わせてサーバーのパフォーマンスを向上させるための最も重要な手順の1つは、Apacheワーカースレッドとmod_fcgidに切り替えることです。

これで私の仮想プライベートサーバー上の500MBのメモリが解放されました。

Answer 13

プラグインが遅くなるのをチェックするためのガイド

Page Load Time という美しくシンプルなプラグインがあり、これはあなたのページフッターにタイマーを追加します。実際にはわずか4行のコードです。

<?php
function ur_pageload_footer() {
    printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')

その後：

1. スプレッドシートを作成する
2. アクティブなプラグインをすべてリストアップしてそこに入れます
3. 各ターンのページ読み込み時間に注意してページを3回更新する
4. プラグインを1つずつ調べて無効にします
5. ステップ3を繰り返す
6. プラグインを無効にした順番に注意してください。

スプレッドシートは次のようになります。

+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |

そのため、プラグインを無効にした後にページの応答時間が大幅に長くなった場合は、そのプラグインを回避できるかどうかを確認できます。

mqtranslate と（やや古くて良い） マルチレベルナビゲーションプラグイン という2つのプラグインが見つかりました。