WordPress. Практикум по оптимизации блога.

Уф!.. Вот уже больше недели вожусь с блогами. Сначала несколько дней ушло на то, чтобы разобраться с новым дизайном, затем – чтобы оптимизировать скорость загрузки страниц. Ибо 40-50 сек на загрузку страницы – это что-то несуразное.
Дальнейший текст будет больше полезен для специалистов, нежели для основной аудитории этого блога, однако я решил опубликовать этот материал, поскольку он может оказаться полезен кому-либо.
Итак, исходные данные. Стоит мультисайтовый WP 3.3. Хостинг – VPS, процессор – 1100 МГц, дисковая система – 10Гб, оперативная память – 600Мб. Сервер – был apache+lenny, но версий уже не помню.
В сети 4 блога – 1 основной, приаттаченный к основному домену, и три – на поддоменах третьего уровня. Основной блог содержит свыше 200 записей и 4200 комментариев. Информация на блоге – текстовая, графика практически отсутствует. Остальные блоги в сети недавно, поэтому содержат небольшое количество записей.
Поставил на основной блог после доработки под свои нужды Ксанину тему Blue Dream. Блог и до этого не сказать бы, что “летал”, а после смены темы – стал откровенно тормозить. Загрузка отдельных страниц занимала по 40-50 с., а то и вообще отрубалась по тайм-ауту. Не помогал и кеширующий плагин – W3 Total Cash – уменьшалось время загрузки только индексной страницы блога.
Естественно, в такой ситуации нужно было что-то делать.
В качестве методических рекомендаций использовался цикл статей Ксаны по оптимизации блога на wordpress.
Первым делом я напряг хостера. Хостер поставил nginx, однако это не улучшило ситуацию.
Я стал анализировать, какие компоненты вызывают наибольшую задержку. Для этого включил плагин wp-tuner.
Нужно отметить, что несмотря на откровенную полезность данного плагина автор не обновляет его с 2009 года. Поэтому, если прописать в wp-config инструкции, которые рекомендует руководство по использованию данного плагина, то блог отрубается. Я оставил плагин включенным, но wp-config по требованию инструкции не менял.
Плагин показал, что наибольшее время отбирала обработка загрузки постов – post_selection и выполнение запросов, обращающихся к таблицам wp-posts и wp-comments.
Я решил провести небольшой эксперимент – подключил эту же тему к другим блогам сети. Время загрузки страниц на других блогах составляло в районе 2с.
После этого я провел второй эксперимент – отключил все плагины. Это тоже снизило скорость загрузки страниц до приемлемых нескольких секунд.
Мы со службой поддержки хостера пришли к выводу, что на загрузку страниц влияли как обращения к базе данных, так и скорость обработки скриптов. Количество обращений к базе данных на главной странице с включенными плагинами составляло где-то 120. После отключения – в районе 90.
Я занялся оптимизацией БД, хостер – ускорением обработки скриптов.
Хостер поставил ускоритель eAccellerator – примочку, кеширующую php-скрипты на сервере.
Я тем временем, оптимизировал таблицы баз данных. Оптимизацию можно провести непосредственно из phpMyAdmin, но если кто не особо понимает в базах данных, то в принципе можно воспользоваться и специальным плагином – wp- DBManager.
Также я уменьшил количество обращений к базе данных за счет редактирования шаблонов темы согласно приведенным в статье Ксаны советам (в основном это header.php)
Затем я стал по одному включать плагины. А их у меня было в районе 50 штук. Причем, как я не старался найти и отключить ненужные, все равно меньше 38 включенных плагинов оставить не получалось – все были нужные.
Мои наблюдения при последовательном подключении плагинов показали, что подключение большинства плагинов на скорость загрузки страниц блога влияли несущественно либо вообще не влияли. Я подключил около 30 плагинов, а скорость загрузки отдельных страниц возросла в среднем с 1,7 сек до 2,2 сек.
Затем пошли более «тяжеловесные» плагины, которые задействовали обращения к базе данных, и в конечном итоге скорость загрузки страниц в среднем остановилась на отметке где-то в 6-7 сек, что в целом я считаю вполне приемлемым.
Надеюсь этот опыт может оказаться кому-то полезным.