Большая оптимизация толстого WordPress. Ускоряем блог в 3 раза.

Каждый, кто имел дело с WordPress знает, насколько он прожорлив. Непомерное потребление этой платформой системных ресурсов и постоянные тормоза заставляют многих веб-мастеров переходить на другие CMS. Та же проблема встала и передо мной, кода я начал понемногу “нагружать” блог всякими полезными плагинами, графикой и прочей ресурсоемкой снедью. Но, так вышло, что у нас с этой платформой  очень давние и теплые отношения и менять ее я не хочу. Возможно, это глупо, да. Но это привычка. А привычки управляют нами намного сильнее, чем нам порой кажется. Итак, передо мной встал вопрос об оптимизации блога на WordPress.

Что я сделал? Мм, погуглил, конечно. Нашел несколько десятков подобных статей. Большая часть или устарела или оказалась откровенной халтурой, но, тем не менее, по кусочкам собралось некоторое кол-во методов, которые было решено протестировать и результаты опубликовать здесь. Итак, начнем.

1. Снимаем показания.

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

Первый. Показывает время загрузки страницы, css-файлов и графики. Имитирует обычное посещение пользователем.

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

Итак, в нашем functions.php прописываем(можно в самом конце):

<?php function usage() {
printf((‘%d / %s’), get_num_queries(), timer_stop(0, 3));
if ( function_exists(‘memory_get_usage’) ) echo ‘ / ‘
. round(memory_get_usage()/1024/1024, 2) . ‘mb ‘;
}
add_action(‘admin_footer_text’, ‘usage’); ?>

Далее, в footer.php добавляем строку:

<small><?php usage(); ?></small>

Все, теперь в футере у нас будет отображаться строка вида:

кол-во запросов/время генерации страницы/потребляемая память.

Итак, вот, что мы имеем вначале(кликабле):

Счетчик:

21 / 5.167 / 18.04mb

Все, замерять у нас есть чем, теперь переходим непосредственно к оптимизации.

2. Локализация.

Замена оригинального файла локализации на lite-версию оказался одним из самых эффективных методов.

О чем это я? В wordpress вся локализация хранится в специальном .mo файле, довольно приличных размеров. При обращении пользователя к сайту WP обращается к этому файлу и получает оттуда локализованную версию текстов. Проблема в том, что в этом файле хранится еще и локализация для админки, которой обычный пользователь не видит. Собственно, она и занимает большую часть этого файла. Из-за этого на подгрузку локализации расходуется приличное время.

Суть в том, чтобы заменить стандартный файл локализации на более легкий и этим уменьшить время  загрузки страниц. Итак, качаем у Лекактуса файл с “облегченной” локализацией и копируем его в wp-content/languages/. Далее, в wp-config.php вместо

define (‘WPLANG’, ‘ru_RU’);

прописываем

if (strpos($_SERVER['REQUEST_URI'], ‘wp-admin’)) define (‘WPLANG’, ‘ru_RU’); else define (‘WPLANG’, ‘ru_RU_lite’);

Готово. Смотрим на счетчик:

21 / 3.816 / 13.27mb

Мы видим существенный прирост скорости и уменьшение расходуемой памяти. Отличный результат.

3. Ставим запрет на обновление WordPress.

Суть в том, чтобы, как видно из заголовка, запретить Вордпрессу запрашивать обновления для ядра и плагинов. Тема стара, давно гуляет по сети, было написано несколько плагинов, но смысла в них – ноль ибо все, что нужно сделать – это закомментировать несколько строк. Итак, открываем файл update.php(лежит в wp-includes) и закомментируем следующие строки(ставим перед ними символ “#”):

#add_action( ‘admin_init’, ‘_maybe_update_core’ );

#add_action( ‘wp_version_check’, ‘wp_version_check’ );

#add_action( ‘load-plugins.php’, ‘wp_update_plugins’ );

#add_action( ‘load-update.php’, ‘wp_update_plugins’ );

#add_action( ‘load-update-core.php’, ‘wp_update_plugins’ );

#add_action( ‘admin_init’, ‘_maybe_update_plugins’ );

#add_action( ‘wp_update_plugins’, ‘wp_update_plugins’ );

#add_action( ‘load-themes.php’, ‘wp_update_themes’ );

#add_action( ‘load-update.php’, ‘wp_update_themes’ );

#add_action( ‘admin_init’, ‘_maybe_update_themes’ );

#add_action( ‘wp_update_themes’, ‘wp_update_themes’ );

Указанные строки актуальны для WordPress 2.9.2, в ранних версиях строк меньше. Думаю, соориентируетесь. Готово. Смотрим счетчик:

21 / 3.762 / 13.21mb

Как видим, прироста практически нет. Способ оказался малоэффективным.

4. Оптимизация шаблона. Чистим код.

Одним из самых распространенных способов ускорения WP является чистка шаблона от лишних запросов к БД. Что ж, попробуем. Открываем header.php. Формат содержимого и кодировка:

content=”<?php bloginfo(‘html_type’); ?>“; charset=”<?php bloginfo(‘charset’); ?>“

Заменяем на:

content=”text/html“; charset=”UTF-8“

Меняем title(может отличаться, в зависимости от шаблона):

<title><?php bloginfo(‘name’); ?> <?php if ( is_single() ) { ?> &raquo; Blog Archive <?php } ?> <?php wp_title(); ?></title>

заменяем  на:

<title>Название_вашего_сайта <?php if ( is_single() ) { ?> &raquo; Blog Archive <?php } ?> <?php wp_title(); ?></title>

Далее, информация о версии WP:

<meta name=”generator” content=”WordPress <?php bloginfo(‘version’); ?>“

заменяем на:

<meta name=”generator” content=”WordPress 2.9.2(ставите вашу версию)“

Keywords:

<meta name=”keywords” content=”<?php bloginfo(‘description’); ?>” />

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

Далее, description:

<meta name=”description” content=”<?php bloginfo(‘description’); ?>” />

Меняем на:

<meta name=”description” content=”ваше_описание” />

Путь к css:

<link rel=”stylesheet” href=”<?php bloginfo(‘stylesheet_url’); ?>” type=”text/css” media=”screen” />

Прописываем :

<link rel=”stylesheet” href=”/wp-content/themes/название_шаблона/style.css” type=”text/css” media=”screen” />

Только смотрите, чтобы style.css был расположен именно в корне папки с шаблоном. Если он расположен глубже – указывайте полный путь. Адрес RSS-ленты:

<link rel=”alternate” type=”application/rss+xml” title=”<?php bloginfo(‘name’); ?> RSS Feed” href=”<?php bloginfo(‘rss2_url’); ?>” />

Прописываем:

<link rel=”alternate” type=”application/rss+xml” title=”Подписаться на RSS” href=”ссылка_на_вашу_RSS” />

Пингбэки:

<link rel=”pingback” href=”<?php bloginfo(‘pingback_url’); ?>” />

Пишем:

<link rel=”pingback” href=”http://адрес_сайта/xmlrpc.php” />

Вроде все. Кол-во запросов, разумеется, в зависимости от шаблона может отличаться, но вышеперчисленные функции должны быть в любом шаблоне. Сделали. Смотрим на счетчик:

21 / 3.602 / 13.22mb

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

5.1. Серверная часть. Расширения zlib и eaccelerator.

Для начала немного теории: Расширение zlib отвечает за компрессию php-кода. Он передается пользователю в сжатом варианте, декомпрессия происходит непосредственно перед выводом информации на экран. Вследствие этого старинца грузится заметно быстрее.

Расширение eaccelerator представляет собой оптимизатор кэш-памяти для динамического содержимого. Кэширует скомпилированный php-код, за счет чего ресурсы на повторную комплияцию не тратятся.

Оба расширения являются стандартными для большинства хостингов, но могут быть отключены. Как узнать? Можно написать в саппорт. Или можно узнать самим. Создаем файл, например check.php, в него помещаем такую строку:

<?php phpinfo(); ?>

Сохраняем, заливаем в корень сайта, запускаем. Для тех, кто в танке: прописываем в адресной строке адрес вида “http://ваш_сайт/check.php”. Видим длинную простыню текста, ищем блоки zlib и eaccelerator ссоответственно, в первом должна быть строка

ZLib Support: enabled

а во втором

Caching Enabled: true

Optimizer Enabled: true

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

Если eaccelerator включается без вмешательства в код, то zlib нам придется активировать ручками. Открывает header.php и в самом начале, перед всем содержимым прописываем такие строки:

<?php
ini_set(‘zlib.output_compression’, ‘On’);
ini_set(‘zlib.output_compression_level’, ‘1’);
?>

Сохарняем и заливаем на хостинг. Окей, расширения включили, смотрим на счетчик:

21 / 3.052 / 13.1mb

Ну, полсекунды – какой-никакой, а результат. Хотя, конечно, не ахти.

5.2. Серверная часть. Используем nginx.

Nginx – http-сервер, который зачастую используют совместно или вместо традиционного Apache, который, в силу своего богатого функционала потребляет приличное кол-во системных ресурсов. Большинство элементов сайта – статичны(изображения, css и т.п.) и для их передачи пользователю не требуется какой либо особые инструменты. Так зачем нам использовать для их передачи толстый и медленный Apache? Возложим эту несложную задачу на плечи быстрого и маловесного nginx!

Собственно, владельцы VDS могут включить nginx прямо через админку, те же, кто сидит на шареде – пишем хостеру и просим включить. Nginx используется всеми более-менее популярными хостингами, насколько я знаю.

Смотрим на счетчик:

21 / 2.523 / 12.13mb

Еще минус полсекунды.

6.  Плагины для кэширования.

Ну, по этой части все, думаю, понятно. Страница кладется в кэш, формируется статический вариант, который и отдается впоследствии пользователю. Плагинов для кэширования в сети дофига, самый популярный – WP Super Cache. Сразу скажу, мне он не помог. Даже когда я занимался ГСами, толку от него было ноль. Не знаю, почему так получалось, да и не разбирался особо. Если у вас он заработал – оставляйте, нет смысла ничего менять, положительных отзывов о нем очень много. Инструкций по настройке тоже дофига, здесь не буду уделять этому время.

После того, как перерыл очередную гору материалов остановился на SJ Object Cache. По ссылке можете найти полное его описание, функционал, инструкции по установке(устанавливается, как любой другой плагин), а так же фидбэк с разработчиком. Отмечу, что плагин ориентирован на VDS-системы и для его работы необходимы eAccelerator/APC/xCache. Для шаред-хостингов предназначен его аналог от того же автора – WP File Cache.

Настроек там еще меньше чем в WP Super Cache. Единственное, отмечу, что в качестве кэширующего модуля я выбрал FileGroupCache, с этим значением результат получился самым продуктивным.

Смотрим на счетчик. Вот тут-то я и обрадовался:

5 / 1.993 / 2.8mb

Отличный результат, что еще сказать.

7. Ревизии постов.

Нашел еще один метод, связанный с ревизиями постов в  WP. Суть в том, что во время написания или редактирования поста движок регулярно сохраняет “промежуточные” его версии, чтобы в любой момент можно было откатиться к любому из вариантов. Дело, конечно, полезное, но база пухнет с фантастической скоростью. Попробуем их отключить, а заодно и очистим базу.

Открывает wp-config.php, и добавляем следующую строку:

define(‘WP_POST_REVISIONS’, false);

Сохраняем, заливаем. Далее, открываем базу и делаем следующий SQL-запрос:

DELETE FROM wp_posts WHERE post_type=’revision’

Готово.

Мне этот метод особой производительности не принес. Думаю, это связано с тем, что на блоге пока не особо много постов и резвизий было удалено около 50 штук(и это с 4-х постов). Если у вас более-менее старый блог – эта операция должна существенно облегчить вашу БД.

8. Подводим итоги.

Итак, что у нас вышло? Для начала напомним начальные данные:

Счетчик:

21 / 5.167 / 18.04mb

Теперь, что у нас в итоге получилось:

Счетчик:

5 / 1.993 / 2.8mb

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

Подводя итог, следует отметить, что самыми результативными оказались два метода: использование lite-версии локализации и кэширование. Остальные методы оказались не столь полезны, хотя, конечно же, тоже внесли свои 5 копеек. Главное, что блог стал загружаться в несколько раз быстрее, а значит, все, проделанное выше было не зря. That’s all, folks!