Оптимизация WordPress #3 — уменьшаем нагрузку на базу данных
Данные текст является переводом статьи Reduce WordPress CPU Usage #3 — Reduce your database queries, опубликованной в блоге cravingtech.com. Также вы можете ознакомиться с переводом первой и второй статьи из этой серии.
Высокая нагрузка на процессор может быть вызвана большим числом sql-запросов, производимых WordPress. В WordPress-блогах почти все данные берутся из базы данных — комментарии, посты, URL блога, расположение CSS-файлов и прочая информация, необходимая плагинам.
Некоторые из этих запросов необходимы, а некоторых можно избежать просто используя плагин WP-SuperCache. Тем не менее, запросы к базе данных все еще необходимы для генерации статических файлов после очистки кэша.
Как же выяснить, сколько обращений к базе данных производит блог? Вы можете вставить следующий кусок кода в файл footer.php (или любой другой) чтобы вывести число использованных запросов:
Для примера, я получил число запросов, используемое различными шаблонами:
- Vigilance Theme: 25 запросов;
- Arthemia Premium (тема, которую я использую сейчас): 58 запросов;
- Оригинальная Arthemia Premium (с демо-сайта, без исправлений): 101 запрос.
Vigilance Theme — это легкая тема, которую я использовал, когда меня заставил уменьшить нагрузку на процессор мой старый хостер, LunarPages. Как видите, эта тема использует наименьшее число запросов к БД.
Текущая тема этого блога, Arthemia Premium, использует множество запросов (для будущих постов, случайных постов и тд). Я уже сделал кое-какие исправления для уменьшения числа динамических элементов. Результат совершенно потрясающий: число запросов уменьшилось в два раза!
Каким образом можно уменьшить число запросов к БД, если не считать установки WP-SuperCache? Для начала необходимо уменьшить число используемых плагинов. Любой плагин, как правило, хранит информацию в базе данных. Некоторые плагины делают больше запросов, чем другие.
Если вам необходимо использовать некий плагин, попробуйте уменьшить число информации, которую он должен хранить или выводить насколько это возможно. Например, если вы можете отключить ведение журнала, сделайте это. В большинстве случаев он вам не потребуется. Еще пример: антиспам-плагин обычно позволяет выбрать — отображать или нет число отфильтрованных комментариев. Отключите эту возможность! Вам известно, что для определения этого числа плагину нужно произвести лишний запрос к БД?
Пропишите в коде очевидную информацию, такую, как URL вашего блога, вместо того, чтобы забирать ее из базы данных. Выясните, где в шаблоне используется абсолютный URL блога, просмотрев исходный код страницы, и жестко пропишите его с помощью редактора шаблонов. Не проделывайте этого с title — пусть WordPress генерирует его динамически для поисковой оптимизации.
Отключите ревизии постов с помощью плагина Disable Revisions plug-in. Во время написания поста в базе данных создается новая запись каждый раз, когда сохраняется черновик. Выключите эту возможность, если она вам не нужна! (Я бы советовал WP-Optimize — прим. пер.)
Сократите число выводимых постов на главной странице и количество виджетов в сайдбаре. Я удалил виджет со случайными постами в своей теме Arthemia Premium, поскольку он выполняет «дорогие» запросы к базе данных.
У меня все. Не стесняйтесь предлагать свои советы по ускорению WordPress в комментариях!
От переводчика: По моим наблюдениям, самый «тяжелый» запрос к БД создается виджетом «Облако меток». Я бы рекомендовал в первую очередь избавиться от него, и лишь потом решать, требуется ли дальнейшая оптимизация. В качестве альтернативы «Облаку меток» можно использовать виджет «Текст», поместив в него HTML-код, выводимый «Облаком меток».