Оптимизация блога WordPress для снижения нагрузки на сервер

Logo
Оптимизация блога WordPress для снижения нагрузки на сервер

Здравствуйте дорогие читатели блога dmitriydenisov.com. В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер. Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.

Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.

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

Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.

Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.

Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.

После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку

define( 'WP_CACHE', true );

Лучше это делать ближе к концу файла, но не дальше строк

if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.

  • Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
  • Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
  • Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
  • Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
  • Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.

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

<!-- hyper cache: 4db91f2a2fe614e38d24d4a7aa5c73b0 -->

Если она есть, то плагин работает нормально.

Снижение нагрузки на сервер за счет кэширования запросов к базе данных.

Для этого можно использовать специальный плагин DB Cache Reloaded. Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.

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

Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код

<?php if (is_user_logged_in()) { ?>
<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.
<?php } ?>

Приведенный выше вариант будет выводить информацию о количестве обращений к БД и времени загрузки страницы. Замечу, что информация будет видна только вам. То есть будет выводиться только тогда, когда вы авторизированны на сайте. Выглядеть это будет примерно так:

Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.

Оптимизация шаблона WordPress

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

Оптимизация header.php

1. Находим код

<?php bloginfo('name'); ?>

и меняем его на название своего блога. У меня это

dmitriydenisov.com — создание и продвижение сайтов, блогов, заработок на сайте.

2. Код, отвечающий за вывод описания, заменяем на статический.

<?php bloginfo('description'); ?>

3. Строка, отвечающая за вывод кодировки.

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

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

5. Заменяем путь к таблице стилей вашего шаблона на статичный.

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

После модификации будет иметь примерно такой вид:

<link rel="stylesheet" href="http://dmitriydenisov.com/wp-content/themes/Ваша тема/style.css" type="text/css" media="screen" />

6. Меняем путь к 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="dmitriydenisov.com — создание и продвижение сайтов, блогов, заработок на сайте RSS Feed" href="http://dmitriydenisov.com/feed" />

7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).

<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />

Заменяем на

<link rel="pingback" href="http://dmitriydenisov.com/xmlrpc.php" />

Оптимизация файла footer.php

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

<?php bloginfo('name'); ?>

заменяем на свой текст. У меня это

<div class="copyright"><a href="http://dmitriydenisov.com/" title="Доступно о создании и продвижении сайтов, блогов. Поисковая оптимизация. Заработок на сайте.">&copy; dmitriydenisov.com — создание и продвижение сайтов, блогов, заработок на сайте</a></div>

Также рекомендую ознакомиться со следующими статьями по оптимизации и ускорению сайтов.

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

На этом все. Удачи вам и успехов в оптимизации сайтов.

Обнаружили ошибку? Выделите ее и нажмите Ctrl+Enter

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

  • Mary

    Кстати, количество запросов к базе данных с Вашего блога видно не только Вам, но и всем посетителям Вашего блога :)))

  • Дмитрий

    Да, я знаю:)) Сделано это специально, чтобы можно было наблюдать за сайтом без авторизации. Плюс это как бы наглядный пример работы кода, описанного в этой статье.
    Спасибо за наблюдательность!)

  • Andrew

    Дмитрий, а у меня проблема с DB Cache Reloaded

    DB Cache Reloaded Error: wpdb class is redefined, plugin cannot work! :(

  • Дмитрий

    Andrew, я давно перестал использовать данный плагин, так как особой нужны в нем нет.
    На данный момент на одном аккаунте 3 сайта (2 WordPress и 1 UMI CMS), а нагрузки практически нет. Исключением являются случаи, когда работаешь в админке. Тогда нагрузка может подскочить. Главное правильно оптимизировать шаблон и настроить кэширование. Вот и весь секрет:)

  • Andrew

    Дмитрий, спасибо большое за оперативный ответ!
    Удачи!

  • Дмитрий

    И вам всего доброго.
    Возникнут вопросы — обращайтесь. Буду рад помочь.

  • Владимир

    Вопрос? а будет ли этот плагин работать на локальном хостинге или только на удолённом. Пробовал смотреть проверку работы не увидел на своей странице хост локальный помогите разобраться. Спасибо

  • Дмитрий

    Он будет работать как на хостинге, так и на локальном компьютере. Главное включить кэширование в конфигурационном файле wp-config.php и активировать плагин. Хочу сразу заметить, что иногда кэширование не включается с первого раза. Особенно это касается более новых версий плагина. В этом случае лучше попробовать деактивировать плагин, а затем снова активировать. Зачастую это помогает решить проблему.
    Также хочу обратить ваше внимание на то, что вы не сможете проверить работу плагина, если будете авторизированы в админке. То есть для проверки работы нужно сначала разлогиниться.
    Так… Вроде все сказал и ничего не забыл:)
    Если у вас остались вопросы — пишите. Я обязательно отвечу.

  • Сергей

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

    Опытным путем выяснил, что если очистить файл "admin-ajax.php" — нагрузка возвращается в норму.
    Хостер помочь найти проблему отказался. Возможно, подсажена какая-то "зараза". Замена файлов движка на "из дистрибутива" ничего не дала…

    Было бы интересно узнать о методике тестирования на причину такой нагрузки. Может что посоветуете?

  • Дмитрий

    Сергей, нужно смотреть логи сервера, а также анализировать скорость загрузки сайта. Скорее всего причина в кривом шаблоне или плагине. Лично я все шаблоны создаю сам. При этом количество плагинов на сайтах обычно меньше 10. Только самое необходимое. Весь функционал стараюсь реализовать самостоятельно без использования плагинов. Также хочу заметить, что я не прибегаю к крайностям и не заменяю пути на статические. То есть, все создается универсальным с использованием php функций и обращений к базе данных. Несмотря на это, сайты стабильно работают на обычном дешевом хостинге со 128 мб. оперативной памяти, выделенными на один аккаунт. При этом на одном аккаунте может быть до пяти сайтов, а общая посещаемость превышает 4000 чел. в сутки. Исходя из этого, я не думаю что причина в файлах движка. Скорее всего это связано с шаблоном или плагинами. Особое внимание обратите на плагины рейтинга и все то, что автоматически создает запросы к базе данных, например, при просмотре страницы. По возможности от всего этого нужно избавиться.

Оставить комментарий

отменить ответ