WordPress Quick Tricks #02. Оптимизация

WordPress – одна из самых популярных CMS, но что мешает накидать им несколько камней в огород?

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

Дабы было наглядней – продемонстрирую график использования памяти wordpress’ом, который построил Макс:

Кэшируем

Вначале мой взгляд упал на репозиторий плагинов WordPress, я вытащил оттель WP Super Cache плагин – хостингу конечно полегчало – но не так, чтобы супер, ведь до начала работы данного плагина, двиг WP должен таки подняться. Потом нашел MaxCache, смысл данного кеширования – определять попадание в кэш до загрузки WP, и этот прирост производительности стал существенным – LA сервера упал с ~1.0-1.6 до ~0.2-0.4, памяти кушать стали тоже меньше – 634Mb > 525Mb.

Отключаем плагины

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

• Akismet – алгоритм данной защиты предполагает отправку комментариев на сервис для проверки – но при >200 спам комментариев – это напрягает
• WP-PostViews – это просто примочка – смысл работы – после загрузки страницы AJAX’ом стучится на сервер для инкрементации счетчика – т.е. для отображения страницы у вас дважды поднимается движек WP

Если сталкивались с еще какими “чудными” плагинами – отпишитесь в комментариях…

Оптимизируем БД

Небольшой запрос на удаление мусора из БД (взято отсель).

// удаляем ревизии постов и все, что с ними связано
DELETE `p`, `pm`, `c`, `tr`
  FROM `wp_posts` AS `p`
    LEFT JOIN `wp_postmeta` AS `pm`
        ON `p`.`ID` = `pm`.`post_id`
    LEFT JOIN `wp_comments` AS `c`
        ON `p`.`ID` = `c`.`comment_post_ID`
    LEFT JOIN `wp_term_relationships` AS `tr`
        ON `p`.`ID` = `tr`.`object_id`
  WHERE 
        `p`.`post_type` = 'revision';

// запускаем встроенные механизмы оптимизации
OPTIMIZE TABLE
    `wp_posts`,
    `wp_postmeta`,
    `wp_comments`,
    `wp_term_relationships`; 

Защита

Скажите “к чему это тут”, а нет – тут самое место – достаточно часто админка популярных блогов подвергается атаке, а это тоже забирает ресурсы. Как по мне – самый лучший способ – это правильно настроенный htaccess для директории /wp-admin/:

• Ограничить доступ по IP

  order deny,allow
  deny from all
  allow from 255.255.255.255
  

• Добавить аутентификацию средствами Apache

Клиентская оптимизация

Ох, тут можно рассказывать очень много, я лишь скину ссылку на тематический сайт – webo.in – а там вы найдете много материала, копипастить нет смысла, скажу лишь так – данная оптимизация станет критичной уже при десятке тысяч посетителей, я же остановился на небольшой правке файла .htaccess:

# Enable ETag
FileETag MTime Size

# Enable Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript

<ifModule mod_expires.c>;
  ExpiresActive On
  ExpiresDefault 'access plus 1 seconds'
  ExpiresByType text/html 'access plus 1 seconds'
  ExpiresByType image/x-icon 'access plus 2592000 seconds'
  ExpiresByType image/gif 'access plus 2592000 seconds'
  ExpiresByType image/jpeg 'access plus 2592000 seconds'
  ExpiresByType image/png 'access plus 2592000 seconds'
  ExpiresByType text/css 'access plus 604800 seconds'
  ExpiresByType text/javascript 'access plus 216000 seconds'
  ExpiresByType application/x-javascript 'access plus 216000 seconds'
</ifModule>

Результаты данного изменения отслеживал при помощи Firefox+Firebug+YSlow, вот собственно и скрины ДО и ПОСЛЕ изменений:

P.S. Кстати, хостинг у меня теперь украинский, и сайт, для основной части аудитории, теперь будет просто летать…