サーバーの負荷に関してWordPressを最適化する手順は？

W3 Total Cacheまたは別のキャッシュプラグインをインストールする以外に、テーマとサイトをできるだけ速く実行するためにどのような手順を実行できますか。

NginxにWordPressをインストールできます。役立つ多くのリソースがあります。

• nginx互換性プラグイン

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

• スライスホストディスカッション

• NginxとWPスーパーキャッシュを使用してWordPressを高速化する方法

• nginx + lighttpd + FastCGI + php上のWordPress

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

その最後のリンクからのパフォーマンス情報の一部（他とは少し異なる設定のように見えます）：

そこで、できる限り静的キャッシュにワードプレスの前にプロキシを配置することにしました。すべての非認証トラフィックはnginxファイルキャッシュから直接提供され、6ページ/秒から7000+ページ/秒までの一部の要求（RSSフィード生成など）を取得します。おー また、Nginxはロギングとgzip処理も処理し、バックエンドの重いアパッチは、必要なときにのみ動的なワードプレスページを提供するために、ベストを尽くします。

...

nginxでは、非常に効率的で怖いです。最も重い負荷でも、10から15メガバイト以上のRAMとCPUのブリップを使用するのを見たことはありません。神経節のグラフは嘘をつきません。メモリ要件を半分にし、発信ネットワークのスループットを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を変更して、事前に圧縮されたファイルを提供します。ここでの注意点は、物事を更新する場合/それらを再圧縮することを忘れないでください。これにより、.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リクエストと圧縮されているものとされていないものを監視します。そこにある有効期限ヘッダーも見てください。すぐに改善できるものが表示されます。

実行するプラグインの数を、本当に必要なものだけに最小限に抑えます。特に、ページでコードが使用されていない場合でも、ページの読み込みごとにjavascriptとCSSコードを追加するプラグインに注意してください。

独自のテーマを最初から作成する場合は、特定のページテンプレートまたはビュータイプ（シングルポスト、アーカイブ、カテゴリなど）にのみ必要な機能が必要な場合にのみ読み込まれるように、CSSを分解します。

CDNを使用するようにW3TCを構成します（Amazon CloudFront、またはW3TCがサポートするその他のいずれか）。

Minifyオプションが機能するかどうかを確認します（一部のプラグインはうまく圧縮しないjs / cssを生成するため、minify機能をアクティブ化した後にサイトをテストしてください）。

MySQLサーバーを完全に制御できる場合は、query_cacheが有効になっていることを確認してください。MySQLチューニングスクリプトを使用して、データベース構成を最適化する他の方法を見つけます。

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

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

APCのようなオペコードキャッシュを実行していることを確認してください。（さらにいくつかあります。）

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

chattr -R +A ~/*

〜/ *は「ホームディレクトリの下のファイル」を意味します。必要に応じてそのパスを変更できます。ウェブホストが提供している場合は、cpanelのcronジョブでこれを設定することもできます。

atimeのプロパティに関する詳細については、を参照してくださいこれを。Linuxディスクの読み取りパフォーマンスを大幅に高速化します。

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

私が見るもう一つのことは、プラグインの作成が不十分なことです。プラグインの作成方法を学ぶと、一部のプラグインが非効率的にコーディングされている方法を確認したり、塗りつぶされたり塗りつぶされたりすることのないデータベーステーブルなどの時限爆弾を見つけ、着信接続データなどを保存します。

ここにある他のすべてのソリューションを超えて、ファイルの単一のデータベースと単一のディスクボリューム（NFS経由でマウントされたボリュームなど）にすべて接続する複数のWebノードPCでホストすることにより、ブログのWordPress Webファームを作成することもできます）。そのすべてを実現する方法については、ウルトラモンキーをご覧ください。

私の頭の上のいくつかの答え：

1）可能な場合/実用的な場合は、JavaScriptとCSSを連結することにより、ブラウザーがホストに対して行わなければならないHTTP要求の数を最小限にします。

2）特に共有ホスティングを使用している場合は、サードパーティのCDNに提供する画像/メディアを可能な限りオフロードします。

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

3a）いくつかの主要な投稿をフロントページに完全に表示するテーマと、その他のすべての古い投稿を抜粋として使用してみてください。

WordPressメニューをキャッシュすると、パフォーマンスが向上します。特に、多くのページまたは巨大なメニュー構造がある場合は、これを考慮する必要があります。

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_menusをに置き換えますget_cached_menu。これで、メニューが呼び出されるたびに、Menubuilding全体ではなく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（メニューを直接呼び出します）。

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

最適化のためにトリミングされたデータベースクラスを使用します。メモリ使用量とデータベースアクセス速度を減らすために、独自のコードで良い経験をしました。それに加えて、多くの小さな変更を加えることでデータベース構造自体を最適化できます。

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

トラフィックの多いサイトでは、現在配置されているコンテンツのすべてのMySQLバッファーを調整する必要があります。WordPressのバージョンに関係なく、MySQLレイヤーの構成を計算できます。

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

私見、設定するデータの量を知らずにmy.cnfの適切な設定を計画することはできません。現在のデータセットを運用環境からステージング環境に定期的に読み込み、最適化を実行し、運用サーバーのmy.cnfで構成する数値を取得する必要があります。

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

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

プログレッシブレンダリングは、ページコンテンツが完全に読み込まれる前にユーザーに表示されるため、ページがより速く感じられます。これを行うには、ブロッキングjsがページの一番下にあり、cssが一番上にあることを確認してください。

また、多くのソーシャルメディアボタンを使用する場合は、スクリプトをカスタマイズして、ページが完全に読み込まれた後にiframeに読み込ませることができます。TweetMeMeのtweetボタン（Twitterが独自のretweetボタンをリリースしてから廃止されました）を使ってそれを行う方法に関するチュートリアルを書きましたが、他の共有ボタンに適用できます。

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

誰もまだ言及していないので、LAMPセットアップとともにサーバーのパフォーマンスを向上させる最も重要なステップの1つは、Apacheワーカースレッドとmod_fcgidに切り替えることです。

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

プラグインの速度を遅くするためのガイド

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と（かなり古いが良い）Multi-level Navigation Pluginを遅くする2つのプラグインを見つけました。

WordPressのキャッシュ機能については、W3 Total Cacheプラグインを使用してください。プラグインの設定ページからページキャッシュとデータベースキャッシュを有効にします。キャッシュメカニズムとして「代替PHPキャッシュ（APC / APCu）」を選択してください。サイトの外観や機能を損なう可能性が高いため、W3 Total Cacheで縮小を有効にしないでください。Cloudflareに任せます。

プラグインの残りの機能の設定が完了したら、Webサイト用にCloudflareをセットアップします。「拡張機能」の下のW3合計キャッシュ設定でもCloudflareを有効にしてください。

Cloudflareは、サイトからすべての静的コンテンツ（画像ファイル、CSS、JS、ドキュメントなど）をキャッシュし、グローバルサーバーから訪問者に提供するコンテンツ配信ネットワークです。これにより、ページの読み込み時間が短縮され、サーバーの負荷が軽減されます。Cloudlfareチェックアウトによってキャッシュされるファイルタイプのリストについては、このリストを参照してください。さらに、Cloudflareには無料のプランがあります。

Cloudflareで、キャッシュレベルを標準に設定し、ブラウザーキャッシュの有効期限を少なくとも20時間以上に設定します。Always Online™を有効にして、サーバーがダウンしてもCloudflareがキャッシュからWebサイトの静的ページを提供するようにします。また、それらの自動縮小機能を有効にします（縮小を有効にしないように要求した理由を覚えておいてください。Cloudflareの方が優れているため、W3 Total Cacheです！）次に、Rocket Loader™を自動に設定します。

Rocket Loaderの機能の抜粋を次に示します。

• JavaScriptファイル（サードパーティのリソースも含む）をバンドルすることにより、ネットワークリクエストの数を減らして、ページレンダリングの速度低下を防ぎます。

• 
  ページのコンテンツが
  すぐにロードされるのをブロックしないように、サードパーティのスクリプトを含むスクリプトを非同期的にロードします。

• キャッシュ（最も上の利用可能のlocalStorageを使用して、ローカルスクリプト
  のブラウザやスマートフォン）ので、再フェッチされていない場合を除き
  必要。

詳細はこちらをご覧ください。

WordPressのジェネシスフレームワークへの可能なスイッチは、彼らがなくてきれいなので、場合任意の肥大化。Genesisは、スピードとSEOを念頭に置いて構築されました。私自身もテストしており、PageSpeedスコアは良好でした。また、Genesisを使用している場合は、W3 Total Cache設定でフラグメントキャッシュを有効にすることを忘れないでください。

CloudlfareをCDNとして使用しているため、TingPNGの「Imagify」や「Compress JPEG＆PNG images」などのプラグインを使用して画像を圧縮できます。どちらもWordPress.orgプラグインリポジトリで利用可能な無料のプラグインです。また、Imagifyは強力な非可逆圧縮アルゴリズムをサポートしています。

最後に、「インストール静的リソースからクエリ文字列を削除し、それはCSS＆JSファイルなどの静的リソースからクエリ文字列を削除するように、WordPressのリポジトリからプラグイン」。これは、URLに「？」または「＆」が含まれるリソースが一部のプロキシキャッシングサーバーによってキャッシュされないためです（Cloudflareはプロキシキャッシングサーバーでもあります）。

次に、「Use Google Libraries」プラグインをインストールします。このプラグインを使用すると、WordPressサイトでこれらのファイルをWordPressインストールから直接提供するのではなく、GoogleのAJAX Library API CDNを使用できます。

利点のいくつかは次のとおりです。

• ユーザーがこれらのファイルを既にキャッシュしている可能性が高くなります。
• サーバーから余分な負荷を取り除きます。
• ライブラリの圧縮バージョンを使用します（利用可能な場合）。
• Googleのサーバーは、要求元のブラウザーとHTTP圧縮をネゴシエートするように設定されています。

最後になりましたが、Ruhani Rabin の ' WP-Optimize 'プラグインを使用して、データベースをクリーンアップおよび最適化します。

これにより、WordPressを最適化してサーバーの負荷を軽減することに関する質問にお答えいただければ幸いです。