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

WordPressをNginxにインストールできます.役立つリソースがいくつかあります:

• nginx互換性プラグイン

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

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

• スピードを上げる方法NginxとWPスーパーキャッシュでWordPressをアップ

• nginx + lighttpd + FastCGI +phpのWordPress

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

その最後のリンクからのいくつかのパフォーマンス情報(他のリンクとは少し異なる設定のようです):

それで私はプロキシを前に置くことにしました ワードプレスの静的キャッシュへの できるだけ.認証されていないすべて トラフィックはから直接提供されます nginxファイルキャッシュ、いくつかのリクエストを受け付けます (RSSフィード生成など)6から ページ/秒から7000+ページ/秒. ウーフ. Nginxはロギングと gzipを実行し、より重いバックエンドを残します 彼らが最も得意とすることをするためにアパッチ族:奉仕する ダイナミックワードプレスページ 必要です.

...

nginxの場合–非常に効率的で効率的です 怖い.私はそれがもっと使うのを見たことがありません 10〜15メガのRAMと 私たちの最も重い負荷の下でもCPU.私たちの 神経節のグラフは嘘をつかない:半分にした 私たちのメモリ要件は、私たちの2倍になりました 発信ネットワークのスループットと 負荷を完全に平準化しました.私達 それ以来、基本的に問題はありませんでした これを設定します.

You could install WordPress on Nginx. There are a number of resources to help:

• nginx Compatibility plugin

• HOWTO: Install WordPress On Nginx-

• Slicehost discussion

• How To Speed Up WordPress With Nginx And WP Super Cache

• WordPress on nginx + lighttpd + FastCGI + php

• Nginx as a front-end proxy cache for WordPress

Some performance information from that last link (which appears to be a bit different setup than the others):

So I decided to put a proxy in front of wordpress to static cache as much as possible. ALL non-authenticated traffic is served directly from the nginx file cache, taking some requests (such as RSS feed generation) from 6 pages/second to 7000+ pages/second. Oof. Nginx also handles logging and gzipping, leaving the heavier backend apaches to do what they do best: serve dynamic wordpress pages only when needed.

...

On nginx – it’s so efficient it’s scary. I’ve never seen it use more than 10 to 15 meg of RAM and a blip of CPU, even under our heaviest load. Our ganglia graphs don’t lie: we halved our memory requirements, doubled our outgoing network throughput and completely leveled out our load. We have had basically no problems since we set this up.

ページビューごとに再ダウンロードする必要のない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はこれに適したツールです)＆amp;gzipで圧縮したファイルと同じ場所にアップロードします.以下のように、.htaccessを変更して、事前に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などのセット全体を再ダウンロードしないようにする必要があることです.縮小、結合、＆amp;するのに良い方法です.ベースラインのCSS、JSなどを圧縮します.httpリクエストを大幅に削減します. Wp-minifyは、スーパーキャッシュや、上記で詳しく説明した有効期限ヘッダーでもうまく機能します.

Firebug(Firefox)などでYslowを使用して、httpリクエストと圧縮されているものと圧縮されていないものを監視します.そこにある有効期限ヘッダーも見てください.改善できる点がすぐにわかります.

Set client-side expiries for things like css, images, JavaScript etc which don't need to be redownloaded for each page view. This, by far, made the biggest difference to my site loading times. The fastest download is the download that never happened ...

# 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

You may pre-gzip everything you reasonably can (7-zip is a good tool for this) & upload it in the same place as the file you just gzipped. Change .htaccess to serve the pre-gzipped files, as below. The caveat here is you need to remember to re-gzip them if/when you update things. This cuts out the CPU overhead, apart from parsing .htaccess.

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]

This is just a raw answer. There are a lot of variations on this theme. I blogged about this and added quite a few references to more in-depth articles at http://icanhazdot.net/2010/03/23/some-wordpress-stuff/. Read that and, more importantly, the references I point to - they are good resources.

Be aware that if you tinker often then users will need to refresh their cache.

A plugin I found very useful too is wp-minify. The thing to watch with this one is that you should exclude page-specific items (contact form, front page slider etc) so you're not re-downloading the whole set of css, JS etc for each page. It is a good way to minify, combine & compress your baseline CSS, JS etc. It cuts down on http requests a lot. Wp-minify plays well with supercache and also with expiry headers that I detailed above.

Use Yslow in Firebug (Firefox) or similar to monitor your http requests and what is and isn't compressed. Have a look at expiry headers in there too. You will soon see what you can improve.

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

独自のテーマを最初から作成する場合は、CSSを分解して、特定のページテンプレートまたはビュータイプ(単一の投稿、アーカイブ、カテゴリなど)にのみ必要な機能が必要な場合にのみ読み込まれるようにします.

CDN(Amazon CloudFront、またはW3TCでサポートされているその他のものなど)を使用するようにW3TCを設定します.

最小化オプションが機能するかどうかを確認します(一部のプラグインは、適切に縮小されないjs/cssを生成するため、縮小機能をアクティブ化した後、必ずサイトをテストしてください).

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

何らかの理由でCDNの使用に問題がある場合は、Apacheセットアップでmod_expiresを構成します.画像、CSS、JavaScript、ビデオ、オーディオなどの静的タイプに適した有効期限を設定します.

Minimize the number of plugins you run to only what you really need. Especially be aware of plugins that add javascript and CSS code on every page load, even when that code isn't being used on the page.

If you are creating your own theme from scratch, break your CSS down so that features that are only need for particular page templates or view types (single post, archives, category, etc) are only loaded when needed.

Configure W3TC to use a CDN (like Amazon CloudFront, or any of the others supported by W3TC).

See if the Minify options work for you (some plugins generate js/css that won't minify nicely, so be sure to test your site after activating the minify feature).

If you have full control of your MySQL server, make sure that you have the query_cache turned on. Use a MySQL tuning script to find other ways to optimize your database config.

If using a CDN is problematic for some reason, configure mod_expires in your apache setup. Set expiration times as long as reasonable for static types like images, css, javascript, video, audio, etc.

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

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

Run memcached and use an object cache to reduce the number of database queries. This caches data from the database, rather than pages. Not sure if w3-total-cache already does this.

Make sure you are running an opcode cache like APC. (There are several more available.)

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

 chattr -R +A ~/*
 

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

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

サイトがクモに襲われていることがあります. SpyderSpankerやChennaiCentralなどのツールを使用して、サイトのページランクを上げるのに役立たないスパイダーを除外し、単に速度を落としてから、ランダムに送信することで優れたスパイダー(Google、Bingなど)を抑制できます. HTTP304未変更メッセージ.

私が目にするもう1つのことは、プラグインの記述が不十分なことです.プラグインの作成方法を学ぶと、一部のプラグインが非効率的にコーディングされていることがわかります.また、入力接続データなどを保存する、いっぱいになり、いっぱいになり、クリーンアップされないデータベーステーブルなどの時限爆弾を見つけることもできます.

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

In addition to using a disk caching plugin like wp-cache, put your blog on a host volume that has the "noatime" property set on it. Otherwise, SSH into your host (if your webhost provides that) and routinely run this command on your files every few days:

chattr -R +A ~/*

The ~/* means "my files under my home directory". You can change that path as you see fit. You can also set this up on a cron job in cpanel if your webhost provides that.

For more info about atime property, see this. It speeds up Linux disk read performance greatly.

Sometimes your site is being hammered by spiders. You can use a tool like SpyderSpanker or Chennai Central to filter out spiders who don't help bring more page rank to your site and merely slow it down, and then throttle good spiders (like Google, Bing, etc.) by sending them random HTTP 304 Not Modified messages.

Another thing I see is just poorly written plugins. If you learn how to make plugins, you begin to see how some plugins are inefficiently coded, or even find timebombs, such as a database table that fills and fills and never gets cleaned out, storing things such as incoming connection data.

Beyond all the other solutions here, you can also create a WordPress web farm of your blog by hosting it on several web node PCs that all connect back to one single database and one single disk volume for the files (such as a volume mounted over NFS). Check out Ultra Monkey for how to get that all going.

頭のてっぺんからいくつかの答え:

1)可能な場合/実用的な場合はJavaScriptとCSSを連結して、ブラウザがホストに対して行う必要のあるHTTPリクエストの数を最小限に抑えます.

2)特に共有ホスティングを使用している場合は、サードパーティのCDNに提供する画像/メディアをできるだけ多くオフロードします.

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

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

A few answers off the top of my head:

1) Minimize the number of HTTP requests the browser has to make to your host by concatenating JavaScript and CSS where possible/practical.

2) Offload as much of your image/media serving to 3rd party CDNs as possible, particularly if you're using shared hosting.

3) Try reducing the number of posts you're displaying on the front page in order to cut down on total render time.

3a) Try using a theme that presents a few featured posts in full on the front page and all other, older posts as excerpts.

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_menuを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(メニューを直接呼び出す場合)の両方で機能するように関数を更新しました.

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

Caching the WordPress Menu also gives you a performance boost. Especially if you have a lot of Pages or a giant Menu Structure, this should be considered.

Do it in 2 easy steps. At first, create a function that gets or creates the menu, instead of calling wp_nav_menu directly.

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

    }

}

In your theme, replace the wp_nav_menus with get_cached_menu. Now, everytime the menu is called, you have one Databasequery instead of the whole Menubuilding.

Menus don't change often - but you also have to hook into the wp_update_nav_menu action to delete the old transients.

Do it like this:

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 ); 

}

The Menu will be generated the next time the page is called - and use the cached version until someone updates the menu again.

Updated Version

Thanks @helgatheviking for pointing out a mistake between slugs and IDs. I updated the functions so it works both with theme_position and menu (for a direct call of the menu).

The menus are always saved with the name of the Menu, not the position in the Theme.

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

データベースクラスコードの一部はwordpresstracにありますが、コアにはなりませんでした(チケット#11799および関連).

Use a database class that is trimmed for optimization. We made good experiences with own code to reduce memory usage and database access speed. Next to that, you can optimize the database structure itself by some small changes that do a lot as well.

Part of the database class code can be found in the wordpress trac, it did not made it into core (Ticket #11799 and related).

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

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

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

For a highly trafficked site, you should tune all MySQL buffers for the content that is in place now. Regardless of the version of WordPress, the MySQL layer can have its configuration computed.

In fact, if you have InnoDB data without enabling innodb_file_per_table, you need to cleanup InnoDB by segmenting each table into its own physical tablespace. It is possible to do decent MySQL tuning even if you have a limited hardware. There are many scenarios for doing such InnoDB optimizations.

IMHO, you cannot plan good settings for my.cnf without knowing the amount of data to configure for. You would have to periodically load a current dataset from production into a staging environment, perform optimizations and come away with the numbers to configure in the my.cnf of the production server.

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

you could enable global output compression. this will gzip everything going out automatically if the browser supports it. This drastically reduces the size of files transferred, but does increase your CPU load.

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

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

また、多くのソーシャルメディアボタンを使用する場合は、スクリプトをカスタマイズして、ページが完全に読み込まれた後にiframeに読み込まれるようにすることができます. TweetMeMeのリツイートボタン(Twitterが独自のリツイートボタンをリリースしたため廃止されました)を使用してそれを行う方法についてのチュートリアルを作成しましたが、他の共有ボタンにも適用できます.

サーバーのパフォーマンスについては、静的コンテンツのフロントエンドプロキシとしてNginxを調べ、ApacheがPHPとMySQLの重い処理を処理します.

I recently spoke about this subject at WordCamp Houston. All of the above recommendations are great and the important thing is to make sure all the front end stuff is fully optimized then you can start working on the caching and server performance issues.

Progressive rendering will make your pages feel faster because the user will see the page content before it is fully loaded. To do this make sure any blocking js is at the very bottom of the page and css is at the top.

Also if you use a lot of social media buttons you can customize the scripts to make them load in an iframe after the page is fully loaded. I wrote a tutorial on how to do it with the TweetMeMe re tweet button (now obsolete since Twitter released their own retweet button) but can still be applied to other share buttons.

For server performance look into Nginx as a front end proxy for static content with Apache handling the heavy PHP and MySQL lifting.

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

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

Since nobody mentioned it yet, one of the most important steps to enhance server performance in conjunction with any LAMP setup would be to switch to apache worker thread and mod_fcgid.

This freed up 500MB of memory on my virtual private server.

プラグインの速度低下をチェックするためのガイド

ページの読み込み時間、ページフッターにタイマーを追加します.実際には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 |
 

したがって、プラグインを非アクティブ化した後、ページの応答時間が大幅に増加した場合は、そのプラグインを回避できるかどうかを確認できます.

「大幅な」速度低下を引き起こす2つのプラグインmqtranslate と(かなり古いが良い)マルチレベルナビゲーションプラグイン.

Guide for checking plugin slow down

There's a beautifully simple plugin called Page Load Time, which adds timer to your page footer. Its actually only four lines of code:

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

Then:

1. Create a spreadsheet
2. List out all your active plugins and put them in there
3. Refresh the page three times noting the page load time each turn
4. Go through your plugins one by one deactivating them
5. Repeat step 3
6. Note the order that you deactivated the plugins

Your spreadsheet should look something like

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

So if after deactivating a plugin the page response time increases significanly then you can see if you can avoid that plugin.

I found two plugins that caused 'significant' slow down mqtranslate and (the rather old but good) Multi-level Navigation Plugin.

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

プラグインの残りの機能の構成が完了したら、Webサイト用にCloudflareをセットアップします. 「拡張機能」の下のW3トータルキャッシュ設定でもCloudflareを有効にしていることを確認してください.

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

Cloudflareで、キャッシュレベルを標準に設定し、ブラウザのキャッシュの有効期限を少なくとも20時間以上に設定します. AlwaysOnline™を有効にして、サーバーがダウンした場合でも、CloudflareがWebサイトの静的ページをキャッシュから提供するようにします.また、自動縮小機能を有効にします(縮小を有効にしないように依頼した理由は、W3 Total Cacheですか?Cloudflareの方が優れているためです！)次に、RocketLoader™を自動に設定します.

ロケットローダーの機能の抜粋です:

• JavaScriptをバンドルしてネットワークリクエストの数を減らす ページの速度低下を回避するためのファイル、さらにはサードパーティのリソース レンダリング.

• サードパーティのスクリプトを含むスクリプトを非同期にロードするため、
  ページのコンテンツの読み込みをブロックしないこと
  すぐに.

• スクリプトをローカルにキャッシュする(LocalStorageを使用、ほとんどの場合に利用可能
  ブラウザとスマートフォン)なので、
  を除いて再フェッチされません 必要です.

詳細については、ここ.

可能であれば、WordPressのGenesisフレームワークに切り替えてください.膨満感がなくクリーンであるためです. Genesisは、スピードとSEOを念頭に置いて構築されました.私自身がそれをテストし、PageSpeedスコアは良好でした.また、Genesisを使用している場合は、W3 TotalCache設定でフラグメントキャッシュを有効にすることを忘れないでください.

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

最後に、WordPressリポジトリから「静的リソースからクエリ文字列を削除」プラグインをインストールして、CSSやCSSなどの静的リソースからクエリ文字列を削除します. JSファイル.これは、「?」が付いたリソースが原因です.または「＆amp;」 URL内のは一部のプロキシキャッシングサーバーによってキャッシュされません(Cloudflareはプロキシキャッシングサーバーでもあることに注意してください).

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

いくつかのメリットは次のとおりです.

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

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

これが、サーバーの負荷を軽減するためのWordPressの最適化に関する質問に答えることを願っています.

Stick with the W3 Total Cache plugin for caching functionality in WordPress. Enable page caching and database caching from the plugin's settings page. Make sure you choose 'Alternative PHP Cache (APC / APCu)' as the caching mechanism. Do NOT enable any minification in W3 Total Cache as there are many chances for you to break your site's appearance and/or functionality. We'll leave it to Cloudflare.

Once you're done with configuring the rest of the plugin functionalities, set up Cloudflare for your website. Make sure you enable Cloudflare in the W3 Total Cache settings too under 'Extensions'.

Cloudflare is a Content Delivery Network which caches all the static contents (image files,CSS,JS,documents,etc.,) from your site and serves it to your visitors from their global servers. This can help speed up page load times and reduce the load on your server. For a list of file types that are cached by Cloudlfare checkout this list. Moreover, Cloudflare has a free plan.

In Cloudflare, set caching level to standard and set browser cache expiration to something at least greater than 20 hours. Enable Always Online™ so that even if your server goes down, Cloudflare will serve your website's static pages from their cache. Also enable their auto minify feature (remember why I asked you to not enable minification is W3 Total Cache? Because Cloudflare does it better!) Then set Rocket Loader™ to automatic.

Here's an excerpt of what Rocket Loader does :

• Decreasing the number of network requests by bundling JavaScript files, even third party resources, to avoid slowing down page rendering.

• Asynchronously loading scripts, including third party scripts, so
  that they do not block the content of your page from loading
  immediately.

• Caching scripts locally (using LocalStorage, available on most
  browsers and smart phones) so they aren't re-fetched unless
  necessary.

More information can be found here.

If possible switch to the Genesis framework for WordPress because they are clean without any bloat. Genesis was built with speed and SEO in mind. I myself have tested it and my PageSpeed scores were good. Also if you're using Genesis, then don't forget to enable fragment cache in W3 Total Cache settings.

Since now you're using Cloudlfare as a CDN, you can make use of a plugin like 'Imagify' or 'Compress JPEG & PNG images' by TingPNG to compress your images. Both are free plugins available in the WordPress.org plugin repository. Also, Imagify supports the powerful lossy compression algorithm.

Finally, install 'Remove Query Strings From Static Resources' plugin from the WordPress repository so that it removes the query strings from static resources like CSS & JS files. This is because resources with a “?” or “&” in the URL are not cached by some proxy caching servers (remember, Cloudflare is also a proxy caching server).

Then install 'Use Google Libraries' plugin. This plugin allows your WordPress site to use Google's AJAX Library API CDN rather than serving these files from your WordPress install directly.

Some of the benefits are:

• Increases the chance that a user already has these files cached.
• Takes the extra load off your server.
• Uses compressed versions of the libraries (when available).
• Google's servers are set up to negotiate HTTP compression with the requesting browser.

Last but not the least, use the 'WP-Optimize' plugin by Ruhani Rabin to clean and optimize your database.

Hope this answers your question with regard to optimizing WordPress to reduce server load.