Разгоняем Wordpress

    SEO Digest #5Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

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

    Основные положения


    Ускорение работы любой системы возможно в основном за счет кэширования некоторых (тут стоит подчеркнуть, что именно некоторых, а не всех подряд) часто используемых операций. Все кэширующие мероприятия, в том числе и для Wordpress, можно разбить на несколько основных частей:
    • База данных
    • Компиляция серверных скриптов (PHP)
    • Статические страницы
    • Клиентская составляющая

    Данную проблему можно проиллюстрировать при помощи следующего рисунка
    Кэширующие звенья для Wordpress
    Кэширующие звенья для Wordpress, источник www.arnebrachhold.de

    База данных


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

    Относительно MySQL это сделать довольно просто: достаточно прописать в конфигурационном файле my.cnf (или my.ini) следующие параметры (в случае большого количества оперативной памяти 20M может быть увеличено до любого приемлемого количества):

    query-cache-type=1
    query-cache-size=20M


    Для оптимизации таблиц (что позволит уменьшить время запросов на 20–50%) можно воспользоваться дополнением Optimize DB, которое позволит существенно уменьшить размер таблиц MySQL и улучшить их структуру.

    Компиляция серверных скриптов


    Каждый раз, когда исполняется PHP-скрипт, он заново компилируется в памяти в исполняемый код, что требует значительного времени. Чтобы избежать повторной компиляции одних и тех же скриптов используются такие приложения как APC или eAccelerator, которые сохраняют уже скомпилированный код в памяти и позволяют выполнять значительно (до нескольких десятков раз) быстрее.

    Также данные решения хорошо справляются с большим количеством маленьких файлов, которые подключаются при обработке запроса к странице, снижая издержки при обращении к файловой системе. PHP-движок не загружает каждый раз файлы с диска (или из дискового кэша) — он получает сразу исполняемый код, что значительно быстрее. После оптимизации базы данных (настройки кэширования) это одно из наиболее узких мест (за исключением создания статически страниц вместо динамической их генерации).

    Статические страницы


    Следующим шагом для борьбы с большим временем подготовки страницы на сервере будет полное кэширование создаваемой страницы в один файл или одну запить в оперативной памяти. Для включения внутреннего кэширования на уровне самого Wordpress достаточно раскомментировать (или добавить) в файл wp-config.php следующие строки (предварительно проверив, что wp-content/cache доступна для записи, иначе ничего не получится):
    define( ‘ENABLE_CACHE’, true );
    define('CACHE_EXPIRATION_TIME', 900);


    Более серьезных результатов кэширования можно добиться при помощи дополнения WP-Super-Cache (базирующегося на WP-Cache) или Hyper Cache, которое вообще не будет осуществлять никаких запросов к базе данных для отображения внешних веб-страниц. Однако при этом станет невозможно и учитывать статистику посещений через встроенные в Wordpress методы (только через внешние счетчики или по логам сервера).

    Для Wordpress, установленного на IIS, также лучше всего будет использовать именно WP-Super-Cache вместо IIS Output Caching. Это подробно рассматривается в соответствующей англоязычной заметке, ниже приведено число запросов в секунду при том или ином методе серверного кэширования.

    Производительность кэширования Wordpress для IIS
    Производительность кэширования Wordpress для IIS, источник blogs.iis.net

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

    Клиентская часть



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

    Для ускорения загрузки сайта в самом браузере (а это, по мнению экспертов Yahoo, занимает 95% времени общей загрузки страницы) можно воспользоваться несколькими решениями:
    • Включить сжатие страниц в самом Wordpress. Делается это через «Настройки -> чтение» («WordPress должен упаковывать статьи (gzip), если браузер запросит это»)
    • CSS Compress — дополнение к Wordpress, которое автоматически минимизирует с сжимает CSS-файлы.
    • PHP Speedy позволяет объединить все CSS- и JS-файлы, настроить клиентское кэширование и сжатие текстовых файлов. Это позволяет значительно ускорить загрузку страниц для конечных пользователей (особенно, если это — ваши постоянные посетители). Устанавливается и как плагин, и как отдельное приложение.
    • Web Optimizer устанавливается как отдельное веб-приложение и обладает более широкими возможностями, в частности, автоматическим созданием CSS Sprites (что ускоряет загрузку страниц для пользователей IE) и добавлением всех серверных правил в .htaccess-Файл (что обеспечивает более широкую совместимость и снимает нагрузку с PHP-скриптов на анализ кэширования и осуществление сжатия). Также Web Optimizer позволяет настроить «ненавязчивую» загрузку JavaScript.


    В общем, даже самый обычный блог может быть ускорен в несколько (десятков) раз за считанные минуты. Скорее всего, в ближайшем будущем уже появятся отдельные сборки Wordpress, настроенные на максимальную производительность при использовании любой темы и произвольной посещаемости блога. Сейчас же можно просто воспользоваться вышеприведенными советами и порадоваться за значительное увеличение числа посещений и постоянных читателей.
    Поделиться публикацией

    Комментарии 23

      +3
      Спасибо! Приятно видеть все «первоочередные» приемы в одной статье
        +2
        Понравилось наличие в тегах memcache — наверное единственное, что не упомянуто в заметке :)
          0
          Перекиньте, пожалуйста, обложку журнала налево, так как сливается с рекламным баннером Хабра и… в общем, не самый лучший ракурс.
            0
            Возникают вопросы:
            1. а тестирование не для IIS проводились?
            2. а почему в несколько (десятков) раз за считанные минуты?
              +1
              если есть ссылка на результаты тестирования не под IIS — с удовольствием ее приведу. Просто не нашел при поиске материала на эту тему.
                +1
                просто описываете инструменты, ну да прикольно, возможно я к ним вернусь когда будет необходимость оптимизировать скорость моего блога. а в конце вы говорите что можно увеличить производительность в несколько раз. возникает резонный вопрос: чем докажете? :)
                я не буквоед, просто мне кажется это несколько нелогичным.
                  +1
                  лично я использовал несколько инструментов из вышеуказанных — скорость увеличилась (в 2-3 раза). Очень сильно зависит от характера блога, нагрузки на него и параметров хостинга — насколько вообще можно улучшить ситуацию. Тут цифры могут и на порядок, и на два колебаться.

                  Специально тестирование по модулям кэширования не проводил.
                    0
                    ну вот есть же ваш реальный пример. хоть без цифр, но упомянули бы о нем в статье.
              –1
              Думаю будет полезным описать ещё плагин кэширования: really static.
              _http://wordpress.org/extend/plugins/really-static/

              Всегда было интересно, как такие плагины работают с комментариями. Повился плагин, закэшировали снова?
                0
                в WordPress есть несколько хукок на действия с комментариями, можно просто из кэша удалять соответствующие файлы
                +1
                ну как на самом деле скромно написано. единственное чего коснулись действительно нужного — это оптимизация базы данных, но и то написанно два параметра которые ни к селу ни к городу.

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

                надо было подробнее расписать как оптимизировать mysql сервер для больше кеширования запросов, как увеличить его буфер.

                как правильно сконфигурировать акселератор и хоть поверхностно сравнить их. почему eaccelerator, а не apc или memcache.

                совершенно пропущен мимо ушей вебсервер. отнего тоже зависит ой как много. можно же тюнить сам апач, а на отдачу статики повесить nginx — вот вам ускорение в несколько раз сразу. либо вообще отказаться от апача и полностью перейти на nginx, благо апач не критически нужен вордпрессу и только от лени переписать реврайты под него.

                воощем по серверной настройке — незачет.

                а по клиентской — тут тоже особо америки не открыто. зачем так мучаться сжимая css и js, извращаясь с CSS Compress и PHP Speedy, если они только один раз подгружаются броузером и далее при серфинге по сайту беруться из кеша? ну да, сжатый и оптимизированный css (js) будет весить не 50 килобайт, а 30. только что это даст по сравнению с кучей графики которая напихана в шаблон?

                вообщем, могли бы и сильнее постараться. а так больше похоже на пиар журнала чем полезную статью. угадал? :)

                  0
                  тут тогда надо цикл статей писать, а не основные (=наиболее эффективные) направления указывать
                    0
                    я вас огорчу. но вы написали не наиболее эффективные. отнюдь. ну конечно не считая упоминания что надо включить supercache. а gzip к вашему сведению — жрет процессор когда сжимается… и на сжатие и распаковку тоже нужно время как ни странно. тут двоякая ситуация. если инет быстрый (а он почти у всех уже быстрый) то сжатие лишь притормозит загрузку. а если инет, это модем на 56к — то тут конечно будет заначительный прирост :)
                  0
                  На шареде вам дадут настраивать фронт-энд сервер? Где?)
                    0
                    так вот я и говорю что:

                    *по сути надо было разделить настройку на серверную и клиентскую. не у ввсех есть свой сервер или впс чтобы настроить его. многие на шареде

                    тоесть надо было по идее две статьи. настраиваем максимально сервер. и настраиваем максимально сам вордпресс.
                  0
                  на своем проекте сделал примерно тоже самое месяц назад — нагрузка с 80%-100% упала до 20%-30%
                  единственное я еще установил nginx
                    0
                    1 автор живет в прошлом году. указанных команд
                    define( ‘ENABLE_CACHE’, true );
                    define('CACHE_EXPIRATION_TIME', 900);
                    уже нет начиная с версии 2.5 (точнее т олку от них нет)
                    2 пхп-спиди работает криво. после того как я установил у себя его — весь сайт (на выделенном достаточно мощном сервере с apache+nginx+eaccelerator) просто тупо вис словно его заддосили. время генерации страниц возрастало почему то в несколько раз. помогло только удаление плагина.
                    3 css-компрессоры работают часто криво. на первый взгляд вроде было нормально, но потом полезли глюки в разных браузерах. в итоге плюнул на это и оставил все стили несжатыми (сжимаются они nginx на лету)
                      +1
                      черт, не знал, что я еще не совершеннолетний :)

                      По поводу Speedy — попробуйте Web Optimizer. Хотя ставится не как плагин, а как отдельное приложение, но на порядок мощнее.

                      CSS-комрессоры обычно работаю криво на кривых CSS-файлах :)
                      Скорее всего, там было довольно много настроек, что и как сжимать, но определенная их комбинация «сломала» CSS. По поводу сжатия CSS/JS: gzip — наиболее оптимальный выбор
                      webo.in/articles/habrahabr/11-minifing-javascript/
                      webo.in/articles/habrahabr/07-gzip-all/
                      0
                      Если не полениться, то можно самому собрать все файлы CSS и JS в 1 файл и сжать. Также посмотреть какие плагины подгружают CSS и JS, обычно они через фильтры вешаются в шапку. И если знания позволяют, то сдлеть для себя поправить немного плагин, а стили вынести в глобальный файл со стилями (если оно того стоит). Если вы не так часто меняете темы, то это наверное в плане производительности будет лучше.
                      Я делал прямой перевод вордперсс 2.6.5, тем самым страница генерируется быстрее и блог кушает меньше. Это тоже можно использовать при «разгоне» своего блога.
                        0
                        _http://wordpress.org/extend/plugins/really-static/, а это кто нибудь пробовал, вроде не плохая вещь.
                          +1
                          Плагин Pure PHP Localization позволяет уменьшигть потребляемую wordpress память на 3-4 Мб!!!
                            0
                            спасибо, попробуем

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.