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

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. Кстати, хостинг у меня теперь украинский, и сайт, для основной части аудитории, теперь будет просто летать…