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