Шаги по оптимизации WordPress в отношении нагрузки на сервер?

Помимо установки W3 Total Cache или другого плагина кеширования, какие шаги я могу предпринять, чтобы убедиться, что моя тема и сайт работают максимально быстро.

Вы можете установить WordPress на Nginx. Есть ряд ресурсов, чтобы помочь:

• Плагин совместимости nginx

• HOWTO: установить WordPress на Nginx -

• Обсуждение Slicehost

• Как ускорить работу WordPress с Nginx и WP Super Cache

• WordPress на nginx + lighttpd + FastCGI + php

• Nginx в качестве внешнего прокси-кеша для WordPress

Некоторая информация о производительности из этой последней ссылки (которая выглядит немного иначе, чем другие):

Поэтому я решил разместить прокси в WordPress перед статическим кешем в максимально возможной степени. ВСЕ неаутентифицированный трафик подается напрямую из файлового кэша nginx, принимая некоторые запросы (например, генерацию RSS-канала) с 6 страниц в секунду до 7000+ страниц в секунду. Уф. Nginx также обрабатывает журналирование и сжатие, оставляя более тяжелые серверные апачи делать то, что у них получается лучше всего: обслуживать динамические страницы WordPress только при необходимости.

...

На nginx - это так эффективно, это страшно. Я никогда не видел, чтобы он использовал более 10-15 мегабайт оперативной памяти и небольшую загрузку процессора даже при самой большой нагрузке. Наши графы ганглиев не лгут: мы вдвое сократили наши требования к памяти, удвоили пропускную способность исходящей сети и полностью нивелировали нашу нагрузку. У нас практически не было проблем с тех пор, как мы это создали.

Задайте срок действия на стороне клиента для таких вещей, как 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

Вы можете предварительно распаковать все, что можете (7-zip - хороший инструмент для этого) и загрузить его в том же месте, что и файл, который вы только что распаковали. Измените .htaccess для обслуживания предварительно сжатых файлов, как показано ниже. Предостережение в том, что вы должны помнить, чтобы повторно сжать их, если / когда вы обновляете вещи. Это сокращает нагрузку на процессор, кроме анализа .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]

Это просто сырой ответ. Есть много вариантов на эту тему. Я написал об этом в блоге и добавил несколько ссылок на более глубокие статьи на http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ . Прочитайте это и, что более важно, ссылки, на которые я указываю, - это хорошие ресурсы.

Имейте в виду, что если вы часто возитесь, пользователям необходимо обновить кеш.

Плагин, который я нашел очень полезным, тоже wp-minify . С этой вещью нужно следить за тем, чтобы исключить элементы, относящиеся к конкретной странице (контактную форму, ползунок главной страницы и т. Д.), Чтобы не перезагружать полный набор CSS, JS и т. Д. Для каждой страницы. Это хороший способ минимизировать, объединить и сжать базовый CSS, JS и т. Д. Он значительно сокращает количество http-запросов. Wp-minify хорошо работает с суперкашем, а также с заголовками истечения, которые я подробно описал выше.

Используйте Yslow в Firebug (Firefox) или аналогичный, чтобы отслеживать ваши http-запросы, а также то, что сжато, а что нет. Взгляните на истечение срока действия заголовков. Скоро вы увидите, что вы можете улучшить.

Сведите к минимуму количество плагинов, которые вы запускаете, к тому, что вам действительно нужно. Особенно следует помнить о плагинах, которые добавляют javascript и CSS-код при каждой загрузке страницы, даже если этот код не используется на странице.

Если вы создаете свою собственную тему с нуля, разбейте свой CSS-код так, чтобы функции, которые нужны только для определенных шаблонов страниц или типов просмотра (отдельный пост, архивы, категории и т. Д.), Загружались только при необходимости.

Настройте W3TC для использования CDN (например, Amazon CloudFront или любой другой, поддерживаемый W3TC).

Посмотрите, подходят ли вам варианты Minify (некоторые плагины генерируют js / css, который не будет хорошо минимизироваться, поэтому не забудьте протестировать свой сайт после активации функции minify).

Если у вас есть полный контроль над сервером MySQL, убедитесь, что у вас включен query_cache. Используйте сценарий настройки MySQL, чтобы найти другие способы оптимизации конфигурации базы данных.

Если по какой-либо причине использование CDN проблематично, настройте mod_expires в настройках apache. Установите время истечения срока действия для статических типов, таких как изображения, CSS, Javascript, видео, аудио и т. Д.

Запустите memcached и используйте кэш объектов, чтобы уменьшить количество запросов к базе данных. Это кэширует данные из базы данных, а не страниц. Не уверен, что w3-total-cache уже делает это.

Убедитесь, что вы используете кэш кода операции, такой как APC . (Есть еще несколько доступных.)

Помимо использования плагина кеширования диска, такого как wp-cache, разместите свой блог на томе хоста, для которого установлено свойство noatime. В противном случае, вставьте SSH в ваш хост (если ваш веб-хостинг это предоставляет) и регулярно запускайте эту команду для ваших файлов каждые несколько дней:

chattr -R +A ~/*

~ / * Означает «мои файлы в моем домашнем каталоге». Вы можете изменить этот путь, как считаете нужным. Вы также можете настроить это для задания cron в cpanel, если ваш веб-хостинг предоставляет это.

Для получения дополнительной информации о собственности atime, посмотрите это . Это значительно повышает производительность чтения с диска Linux.

Иногда ваш сайт забивают пауки. Вы можете использовать такой инструмент, как SpyderSpanker или Chennai Central, чтобы отфильтровать пауков, которые не помогают повысить рейтинг страниц на вашем сайте и просто замедлить его, а затем задушить хороших пауков (таких как Google, Bing и т. Д.), Отправив их случайным образом. HTTP 304 Не модифицированные сообщения.

Еще я вижу плохо написанные плагины. Если вы научитесь создавать плагины, вы начнете видеть, как некоторые плагины неэффективно кодируются, или даже находите бомбы замедленного действия, такие как таблица базы данных, которая заполняется и заполняется и никогда не очищается, храня такие вещи, как данные входящего соединения.

Помимо всех других решений здесь, вы также можете создать веб-ферму WordPress вашего блога, разместив ее на нескольких компьютерах с веб-узлами, которые подключаются к одной базе данных и одному дисковому тому для файлов (например, тому, смонтированному через NFS). ). Посмотрите Ultra Monkey, чтобы узнать, как все это работает.

Несколько ответов из головы:

1) Минимизируйте количество HTTP-запросов, которые браузер должен сделать к вашему хосту, объединяя JavaScript и CSS, где это возможно / практично.

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. Теперь, каждый раз, когда вызывается меню, у вас есть один запрос к базе данных вместо всего меню.

Меню меняются не часто - но вы также должны подключиться к 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 ); 

}

Меню будет сгенерировано при следующем вызове страницы - и используйте кэшированную версию, пока кто-нибудь снова не обновит меню.

Обновленная версия

Спасибо @helgatheviking за указание на ошибку между слизнями и идентификаторами. Я обновил функцию так , она работает как с theme_positionиmenu работали (для прямого вызова меню).

Меню всегда сохраняются с названием меню, а не с позицией в теме.

Используйте класс базы данных, который обрезан для оптимизации. Мы сделали хороший опыт с собственным кодом, чтобы уменьшить использование памяти и скорость доступа к базе данных. Кроме того, вы можете оптимизировать структуру базы данных путем небольших изменений, которые также делают многое.

Часть кода класса базы данных может быть найдена в WordPress Trac , он не превратился в ядро ​​( тикет № 11799 и другие ).

Для сайта с высокой посещаемостью вы должны настроить все буферы MySQL для содержимого, которое сейчас доступно. Независимо от версии WordPress, уровень MySQL можно вычислить .

Фактически, если у вас есть данные InnoDB без включения innodb_file_per_table, вам необходимо очистить InnoDB, сегментируя каждую таблицу в ее собственное физическое табличное пространство . Можно сделать достойную настройку MySQL, даже если у вас ограниченное оборудование . Есть много сценариев для такой оптимизации InnoDB .

ИМХО, вы не можете планировать хорошие настройки для my.cnf, не зная объема данных для настройки. Вам придется периодически загружать текущий набор данных из рабочей среды в промежуточную среду, выполнять оптимизацию и получать номера для настройки в my.cnf рабочего сервера.

Вы можете включить глобальное сжатие вывода . это автоматически распаковывает все, что происходит, если браузер поддерживает это. Это резко уменьшает размер передаваемых файлов, но увеличивает нагрузку на процессор.

Я недавно говорил об этом на WordCamp в Хьюстоне . Все вышеперечисленные рекомендации хороши, и важно убедиться, что весь интерфейс полностью оптимизирован, и вы можете приступить к решению проблем с кэшированием и производительностью сервера.

Прогрессивный рендеринг заставит ваши страницы чувствовать себя быстрее, потому что пользователь увидит содержимое страницы до ее полной загрузки. Для этого убедитесь, что любой блокирующий js находится в самом низу страницы, а css вверху.

Также, если вы используете много кнопок социальных сетей, вы можете настроить скрипты так, чтобы они загружались в iframe после полной загрузки страницы. Я написал учебник о том, как это сделать с помощью кнопки «Твит» TweetMeMe (в настоящее время она устарела, поскольку Twitter выпустил собственную кнопку ретвита), но все же может быть применена к другим кнопкам общего доступа.

Для производительности сервера посмотрите на Nginx в качестве внешнего прокси для статического контента с Apache, обрабатывающего тяжелый PHP и MySQL.

Поскольку никто еще не упомянул об этом, одним из наиболее важных шагов для повышения производительности сервера в сочетании с любой настройкой LAMP будет переключение на рабочий поток apache и mod_fcgid.

Это освободило 500 МБ памяти на моем виртуальном частном сервере.

Руководство по проверке замедления работы плагина

Есть красивый простой плагин под названием Page Load Time , который добавляет таймер в нижний колонтитул вашей страницы. На самом деле всего четыре строки кода:

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

Затем:

1. Создать электронную таблицу
2. Перечислите все ваши активные плагины и поместите их туда
3. Обновите страницу три раза, отмечая время загрузки страницы каждый ход
4. Просмотрите свои плагины один за другим, отключив их
5. Повторите шаг 3
6. Обратите внимание на порядок, в котором вы деактивировали плагины

Ваша таблица должна выглядеть примерно так

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

Поэтому, если после деактивации плагина время отклика страницы значительно возрастает, вы можете увидеть, сможете ли вы избежать этого плагина.

Я нашел два плагина, которые вызывали «значительное» замедление mqtranslate и (довольно старый, но хороший) плагин многоуровневой навигации .

Придерживайтесь плагина W3 Total Cache для функциональности кеширования в WordPress. Включите кэширование страниц и базы данных на странице настроек плагина. Убедитесь, что вы выбрали «Альтернативный PHP Cache (APC / APCu)» в качестве механизма кэширования. НЕ включайте минимизацию в W3 Total Cache, так как у вас есть много шансов нарушить внешний вид и / или функциональность вашего сайта. Мы оставим это Cloudflare.

Закончив настройку остальных функций плагина, настройте Cloudflare для своего сайта. Убедитесь, что вы включили Cloudflare в настройках W3 Total Cache в разделе «Расширения».

Cloudflare - это сеть доставки контента, которая кэширует все статическое содержимое (файлы изображений, CSS, JS, документы и т. Д.) С вашего сайта и предоставляет его посетителям с их глобальных серверов. Это может помочь ускорить загрузку страниц и снизить нагрузку на ваш сервер. Для списка типов файлов, которые кэшируются Cloudlfare, ознакомьтесь с этим списком . Кроме того, у Cloudflare есть бесплатный план.

В Cloudflare установите уровень кэширования на стандартный и установите срок действия кэша браузера как минимум на 20 часов. Включите Always Online ™, чтобы, даже если ваш сервер вышел из строя, Cloudflare будет обслуживать статические страницы вашего сайта из их кэша. Также включите их функцию автоматического минимизации (помните, почему я просил вас не включать минификацию, это W3 Total Cache? Потому что Cloudflare делает это лучше!) Затем установите Rocket Loader ™ на автоматический.

Вот выдержка из того, что делает Rocket Loader:

• Уменьшение количества сетевых запросов путем объединения файлов JavaScript, даже сторонних ресурсов, чтобы избежать замедления рендеринга страниц.

• Асинхронная загрузка сценариев, в том числе сторонних, чтобы
  они не блокировали загрузку содержимого вашей страницы
  сразу.

• Кэширование сценариев локально (с использованием LocalStorage, доступно в большинстве
  браузеров и смартфонов), поэтому они не загружаются повторно без
  необходимости.

Более подробную информацию можно найти здесь .

Если возможно, переключитесь на платформу Genesis для WordPress, потому что они чисты без какого-либо раздувания. Genesis был построен с учетом скорости и SEO. Я сам проверил это, и мои оценки PageSpeed ​​были хорошими. Также, если вы используете Genesis, не забудьте включить кеш фрагментов в настройках W3 Total Cache.

Поскольку теперь вы используете Cloudlfare в качестве CDN, вы можете использовать такой плагин, как « Imagify » или « Сжатие изображений JPEG и PNG». » с помощью TingPNG для сжатия ваших изображений. Оба бесплатные плагины доступны в хранилище плагинов WordPress.org. Кроме того, Imagify поддерживает мощный алгоритм сжатия с потерями.

Наконец, установите плагин « Удалить строки запроса из статических ресурсов » из хранилища WordPress, чтобы он удалял строки запроса из статических ресурсов, таких как файлы CSS и JS. Это связано с тем, что ресурсы с символом «?» Или «&» в URL не кэшируются некоторыми прокси-серверами кэширования (помните, Cloudflare также является прокси-сервером кэширования).

Затем установите « Использовать библиотеки Google плагин ». Этот плагин позволяет вашему сайту WordPress использовать CDN Google AJAX Library API, а не обслуживать эти файлы из вашей установки WordPress напрямую.

Некоторые из преимуществ:

• Увеличивает вероятность того, что у пользователя уже есть эти файлы в кеше.
• Снимает дополнительную нагрузку с вашего сервера.
• Использует сжатые версии библиотек (при их наличии).
• Серверы Google настроены на согласование сжатия HTTP с запрашивающим браузером.

И последнее, но не менее важное: используйте плагин WP-Optimize от Ruhani Rabin для очистки и оптимизации вашей базы данных.

Надеюсь, что это отвечает на ваш вопрос относительно оптимизации WordPress для снижения нагрузки на сервер.