40 советов по оптимизации WordPress (часть 3)

Обслуживание блога - 40 советов по оптимизации

В этой части мы поговорим о техобслуживании блога. Техническая поддержка блога прежде всего необходима для обеспечения постоянного быстродействия, поддержания блога “в чистоте” и порядке.

16. Делайте регулярные бэкапы базы данных.

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

На мой взгляд, самым удобным плагином для эти целей является WordPress Database Backup. Скачать его можно отсюда. Плагин позволяет выбрать набор таблиц из базы, подлежащих архивации, указать путь для сохранения, e-mail для отправки, а так же периодичность бэкапов.

17. Делайте регулярно оптимизацию базы данных.

Для этих целей можно использовать описанный мной в посте “Оптимизируем блог на WordPress” плагин WP-Optimize. Повторятся в описании и возможностях данного плагина не буду. Все описано в указанном посте. Плагин очень удобный, легкий и не нагружающий. Минус – отсутствие возможности планирования оптимизации, но это вовсе не критично. Если вы регулярно заходите на блог, то сделать пару кликов для оптимизации займет не более 5-10 секунд времени.

18. Делайте бэкапы файлов каждый день.

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

Для этих целей можно использовать плагин WordPress Backup. Данный плагин удобен в использовании, обладает всеми необходимыми функциями:

  • установка интервала бэкапа;
  • email’а для отправки бэкапа;
  • путей для сохранения бэкапа на сервере.

19. Удалите “больные” плагины.

“Больные” плагины – враг движка WordPress’а. Нам известно, что WordPress и так кушает немало ресурсов. Установка дополнительных плагинов только подпитывает аппетиты движка. К сожалению, в силу того, что WordPress – движок с открытым кодом и множество плагинов пишеться “под себя” не всегда высококвалифицированными программистами, в плагинах (и не только) может быть множество ошибок, неточностей и т.д. и т.п., способных привести к фатальному торможению блога. Особенно в пиковых нагрузках. Помниться, меня не раз отключали хостеры типа за чрезмерное использование ресурсов виртуального хоста. Сейчас, конечно для меня это не проблема, т.к. мой блог висит на выделенном сервере, но все же раскидываться ресурсами на лево и на право не стоит. Да и думаю, не у всех и сразу найдутся средства на оплату выделенного сервера.

Сберечь ресурсы от “больных” плагинов поможет плагин “Debug Queries”. Суть работы плагина такова, что после его активизации в футере блога отображаются выполненные запросы и время их выполнения. Если какой-то запрос выполняется слишком долго, то вероятность его сбоя в пиковой нагрузке сервера чрезмерно высока, что может привести, в лучшем случае к уменьшению скорости загрузки блога, в худшем – сбоям и недоступности блога.

Проанализировав отладочную информацию, можно выявить плагины, составляющие слишком большую нагрузку на сервер. Если в списке запросов был обнаружен запрос, выполняемый существенно дольше остальных, то следует задуматься над целесообразностью использования того или иного плагина, его деактивацией, альтернативой и т.д. Исключением конечно будут запросы, выполняемые ядром движка блога. Их исключить мы не сможем, правда сможем кэшировать с помощью плагина DB-Cache, который я рассматривал в посте “Ускорение блога на WordPress (продолжение)”.

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

20. Используйте АнтиСпам плагин, например Akismet.

Akismet входит в состав базового пакета WordPress. Плагин вполне адекватно борется со спамом в комментариях. Не знаю, есть ли более “продвинутые” антиспам плагины под Вордпресс, но лично для моих потребностей вполне хватает. Из настроек требует только ввода API-ключа, который можно получить на WordPress.com. Если кто не знает, как это сделать – пишите в комменты. Будем получать вместе!

Для дополнительной борьбы с трэкбэк спамом я установил еще плагин “Simple Trackback Validation”. Данный плагин позволяет отфильтровать трэкбэки по IP-адресу, сравнивая IP сервера и IP url-адреса в трэкбэке, а также проверяет наличие ссылки на ваш блог на указанной в трэкбэке странице.

Плагин настраивается легко и позволяет:

  • указать действие, выполняемое со спам-трэкбеком (удалить; поместить на модерацию; пометить как спам);
  • включить/выключить валидацию трэкбэков по IP;
  • включить/выключить валидацию трэкбэков по URL;
  • указать дополнительные признаки спам-трэкбэков;
  • включить/выключить ведение лога.

После установки этого плагина, спам-трэкбэки эффективно отсеиваются.

21. Проверяйте реферреров в комментариях.

Реферрер – ссылающаяся страница, с которой пришел посетитель (либо бот) на ваш сайт. Спаммерские технологии развиваются и с каждым днем “умного” (способного обходить всеобразные caprcha-защиты, но и содержащего осмысленные текстовки) спама приходит все больше. Отследить такой спам можно по рефссылке. Спаммерские комментарии чаще всего не содержат рефссылок или они представляют из себя странный набор символов (например, “\\\” ref“). В некоторых случаях это могут ссылки с поисковиков.

Для фиксации реферреров в комментариях можно использовать плагин “Wordpress Comments Referer Plugin”.

22. Уберите ненужные виджеты.

Особо комментировать этот пункт нет необходимости. Отмечу, что каждый виджет – это дополнительная нагрузка на сервер и память. Не стоит пихать все, что видите в виджеты. Оставьте там только самое необходимое и актуальное. Банальные виджеты с информацией типа “Мой блог стоит …” не особо интересны пользователям, а лишь загромождают блог.

23. Установите мониторинг доступность блога.

Для этих целей можно использовать host-tracker.com, binokl.info или другие подобными сервисами. Если ваш блог вдруг станет недоступен, то лучше узнать об этом и начать решать проблема как можно раньше. Иначе вы будете терять драгоценных посетителей.

24. Контролируйте ошибки 404.

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

Получать уведомления о возникновении подобных ошибок можно с помощью плагина 404 Notifier или Redirect. Первый плагин простоуведомляет вас об ошибках и может их высылать на электронную почту. Второй имеет более широкий функционал, правда отправлять уведомления не может, но это вовсе не критично. Плагин Redirect способен задавать редиректы, вести логи, а значит “непосвященному” пользователю нет необходимости редактировать файл “.htaccess”. Все можно выполнить из админки.

25. Удалите ненужные мета-тэги.

Для этого вставьте в файл header.php вашего шаблона следующий код перед тэгом </head>:

// Clean up wp_head
// Remove Really simple discovery link
remove_action('wp_head', 'rsd_link');
// Remove Windows Live Writer link
remove_action('wp_head', 'wlwmanifest_link');
// Remove the version number
remove_action('wp_head', 'wp_generator');

На этом техническая часть заканчивается. В следующем выпуске будем говорить о “социальных” функциях, которыми обязательно должен обладать ваш блог. Чтобы не пропустить ничего интересного, подпишитесь на RSS-ленту моего блога. Не знаете что такое RSS? Подпишитесь по электронной почте через нижеследующую форму.

Пропустили предыдущие выпуски? Они тут “40 советов по оптимизации WordPress (часть 1)” и тут “40 советов по оптимизации WordPress (часть 2)”.

IgorOsa

 

12 комментариев

  1. Марина:

    Пункт 16 и 18 – это один и тот же плагин? Я пользуюсь WordPress Database Backup. Этого достаточно?

    • IgorOsa:

      WordPress Database Backup – это плагин к пункту 16. Он делает бэкап ТОЛЬКО БАЗЫ ДАННЫХ. В пункте 19 говориться про немного другой плагин WordPress Backup. Он делайет бэкапы файловой системы – загруженные картинки, темы, плагины и т.п., которые хранятся на диске, а не в базе данных. В случае сбоя потерять их тоже не хочется!

  2. Марина:

    Спасибо, Игорь, копии сделала. Но незнание английского и недоверие к электронному переводу приводит к глупым вопросам. Воспользовалась верхней частью плагина, а именно: Click Link to download a backup:
    Upload Image Directory Backup Backup Date: 2009-06-24 17:20:29
    Theme Directory Backup Backup Date: 2009-06-24 17:20:46
    Pluigin Directory Backup Backup Date: 2009-06-24 17:21:16 . Этого достаточно? Проверила копии, в которых имеются плагины, картинки и темы.

    • IgorOsa:

      Каждый раз при заходе в настройки плагина вы можете скачать указанные файлы. Сразу под ссылками на скачивание бэкапов есть еще два поля Interval between backups и Email address. Я указал 1 day и email куда отправлять ежедневно данные бэкапы, чтобы каждый день не заходить и не скачивать.

  3. grinder:

    Я использую для бэкапа возможности DirectAdmin

    • IgorOsa:

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

  4. Nikulya:

    Я тоже использую WordPress Database Backup, вроде бы хватает)

  5. Зайва Игорь Леонидович:

    На счет виджетов… Убрал у себя в шабе проверку наличия виджетов – освободил аж целых 2 мб ОЗУ хостинга 🙂 Также, удалил “дырявую тучу” тегов, поставил их вместо крутящего шара, простую версию – 10 мб съэкономил ОЗУ… Многие плагины вообще не активирую, а перерабатываю и втыкаю просто в шаб – еще 1-2 мб памяти уменьшил, да и гемороя меньше с активацией и обновлением – всё равно там всякую ерунду добавляют, языки, например, или еще чего 😉

  6. Александр:

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

  7. Dima:

    прописал:
    // Clean up wp_head
    // Remove Really simple discovery link
    remove_action(‘wp_head’, ‘rsd_link’);
    // Remove Windows Live Writer link
    remove_action(‘wp_head’, ‘wlwmanifest_link’);
    // Remove the version number
    remove_action(‘wp_head’, ‘wp_generator’);

    и у меня сверху шаба вылезло:
    // Clean up wp_head // Remove Really simple discovery link remove_action(‘wp_head’, ‘rsd_link’); // Remove Windows Live Writer link remove_action(‘wp_head’, ‘wlwmanifest_link’); // Remove the version number remove_action(‘wp_head’, ‘wp_generator’);

    что делать?

    • IgorOsa:

      Возможно вы вставили данные вне тегов язяка php и они выводяться как html! Попробуйте заключить прописанное в <?php и ?>:

      < ?php // Clean up wp_head // Remove Really simple discovery link remove_action(’wp_head’, ‘rsd_link’); // Remove Windows Live Writer link remove_action(’wp_head’, ‘wlwmanifest_link’); // Remove the version number remove_action(’wp_head’, ‘wp_generator’); ?>

  8. Валерия:

    Хорошие советы. Отличная инструкция для новичка.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

%d такие блоггеры, как: