Обратите внимание, что вместо WordPress
лучше использовать современную и качественную
систему управления сайтом - MaxSite CMS!

Выпуск 19. Оптимизация WordPress

4 ноября 2006 г. Просмотров: 8026 RSS 7
WordPress » Архив рассылки

Оптимизация WordPress

В своей статье "Производительность WordPress" я рассказал о том, как работает WordPress с базой данных MySQL. Вы можете почитать эту статью, чтобы иметь об этом общее представление. Сегодня же я продолжу эту тему, но уже в практическом разрезе: мы поговорим о том, как оптимизировать WordPress, чтобы обеспечить максимальную производительность блога.

Основные направления оптимизации

В общем-то есть три базовых момента, которые будут влиять на нагрузку, создаваемую блогом на WordPress.

Первый - локализация. Дело в том, что локализация (то есть перевод на русский) на сегодняшний день существует в двух варианта. Первая, которая выполнена по "стандартной" технологии, используется на сайте MyWordpress.ru. В этой локализации перевод хранится в отдельном файле. Проблема здесь в том, что сам файл перевода имеет размер больше 150Кб и загружается каждый раз при вызове страниц сайта. Если учесть, что в основном перевод требуется только для админ-панели, то понятно, что это бессмысленная нагрузка на сервер.

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

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

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

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

Шаблоны

Поскольку с локализацией всё ясно, то сразу же приступим к шаблонам.

Большинство шаблонов использует стандартные WordPress-функции. Например для указания кодировки блога используется:

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

Ничего здеь необычного нет, но если подумать, то какой смысл в этом действии? Не каждый день меняется кодировка блога, поэтому можно явно указать кодировку и без помощи PHP.

То есть там, где можно явно указать путь или параметр, лучше так и сделать. Пусть это хоть немного, но снизит нагрузку на сервер.

Следующий важный момент это бессмысленное использование функций _e() и __(). Суть этих функций в том, чтобы принять строку и перевести её. Рассмотрим такой код:

<h2><?php _e('Archives:'); ?></h2>

Казалось бы всё верно. Однако в результате мы просто получаем перевод "Archives:". То есть вся эта строка превращается до банального:

<h2>Архив:</h2>

и никаких PHP-функций. grin

Другой пример:

<?php comments_number(__('No Comments'), __('1 Comment'), __('% Comments')); ?>

Здесь мы встречаем функцию __(). Действуем по аналогии и получаем в результате:

<?php comments_number('No Comments', '1 Comment', '% Comments'); ?>

То есть как минимум мы сократили вызов трех функций.

Иногда в шаблонах встречаются html-комментарии, в которых включен php-код, например:

<!--
<?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds.
-->

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

Важное замечание. Некоторые html-блоки должны выводиться в html-комментариях, например: стили, скрипты, rdf.

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

Плагины

Главное правило - деактивируйте все плагины, которые вы не используете. Многие плагины цепляются к различным событиям WordPress и работают, когда вы об этом даже не догадываетесь. Например, плагин "Контактная форма". Обычно под неё выделяют отдельную страничку, где и помещают код этого плагина. Но сам плагин написан таким образом, то вызывается при каждой загрузке страницы. Любой. Это можно наблюдать, если вы посмотрите в браузере html-код и увидите добавленный блог CSS-стилей. В принципе это довольно-таки безобидный плагин, поскольку добавляемый код очень незначителен и им можно пренебречь. Но суть, думаю, вам понятна.

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

Для того, чтобы отключить автоматическое выполнение ("срабатывание") плагина нужно в нем убрать (закомментировать) несколько строчек.

Учитывайте, что для этих действий у вас должен быть хороший уровень подготовки и знаний PHP!

Обычно для привязки функции плагина к какому-либо событию используют функции add_action() или add_filter(). Общего рецепта здесь нет, смотрите по коду.

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

Особенности WordPress

На быстродействие WordPress будут влиять еще несколько факторов.

:список:

**Количество и объём постоянных страниц. Чем их больше, тем большим будет обмен данными с базой данных. По возможности следует избегать ихчрезмерного использования, тем более, что по функциональности они почти такие же, как и обычные сообщения.

**Количество опций. В WordPress отлично реализован механизм добавления и использования глобальных настроек. Это очень активно используется в плагинах, чтобы не создавать лишние таблицы в базе данных. Но, при всём этом существует проблема удаления ненужных данных. Например вы установили плагин, он вам не понравился и вы его удалили. Однако настройки плагина всё-равно остались в WordPress'е. Таким образом накапливается довольно существенный объем данных. Но главное здесь то, что в каждой такой опции есть параметр autoload, который указывает WordPress загружать его автоматически каждый раз. И по-умолчанию autoload включен и получается, что хоть плагин вы удалили, его параметры всё-равно загружаются.

**Используйте кэш. WordPress достаточно эффективно использует кэш и этим может существенно снизить нагрузку на сервер. Но, в версиях старше 2.0.1, вкралась ошибка, отключающая этот кэш. Если вы еще не сделали обновление, то не откладывате на потом. Сразу скажу, что в официальной версии 2.0.5 этот баг также не исправлен. В моих же сборках после 22 сентября 2006 г. этот баг был исправлен.

:/список:


twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru friendfeed.com google.com yandex.ru
Комментариев: 7
  1. Да, я просто изумляюсь популярной в wordpress технике конструирования специфических страниц наподобии контактной формы, когда захламляется весь вывод. Главное, что все это легко делается по-человечески. Код же того самого писателя контактной формы для его плагина по FAQ меня просто в истерику вогнал - куча javascript на ВСЕХ страницах, а, главное КАК этот плагинописец аякс "применил"...

    Что еще я бы порекомендовал для "оптимизации" чужих плагинов... У них многие функции и фильтры нужны только для админки. Если хватит квалификации, то лучше выделить весь этот код условным оператором типа if (in_admin()) { всякий код }, чтобы даже "мысли" не возникало это подключать в общедоступной части сайта.

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

  2. 2008-07-23 в 11:07:54 | валерий

    ".....Но главное здесь то, что в каждой такой опции есть параметр autoload, который указывает WordPress загружать его автоматически каждый раз. И по-умолчанию autoload включен и получается, что хоть плагин вы удалили, его параметры всё-равно загружаются. "

    а как от этого избавиться?!

  3. Кое-что удалось применить из этой инструкции к своему блогу, но в любом случае, абсолютно не понимаю, почему потребления рамы на блоге Макса менее 6 мб, здесь же версия 2.6! По идее должно быть около 10 мб.

  4. 2008-11-08 в 15:51:18 | Максим

    C чего вы решили, что здесь 2.6? :razz:

  5. Просто в генератор посмотрел. Значит 2.3.х на самом деле?

  6. 2008-11-08 в 16:22:16 | Максим

    На самом деле 2.0.12 с некоторыми моими правками. wink

  7. Ёлки-палки... Ну, в принципе, от добра добра не ищут. Все правильно LOL

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

grin LOL cheese smile wink smirk rolleyes confused surprised big surprise tongue laugh tongue rolleye tongue wink raspberry blank stare long face ohh grrr gulp oh oh downer red face sick shut eye hmmm mad angry zipper kiss shock cool smile cool smirk cool grin cool hmm cool mad cool cheese vampire snake excaim question

Комментарий будет опубликован после проверки

(войти без комментирования)

Имя и сайт используются только при регистрации

Авторизация: Loginza.

(обязательно)

РЕКЛАМА Квартирный переезд Киев профессиональные грузчики доступно