Всем привет, очень давно не публиковал новых статей, потому что занимался внутренней и внешней оптимизацией сайта. Накопившийся опыт и шишки набитые при создании блога, о них буду рассказывать вам постепенно, так сказать порциями. Сегодня же поговорим о том как уменьшить запросы к базе данных WordPressб, что в следствии даст нам огромный результат.
Что даст нам сокращение запросов к БД? Во-первых, мы значительно уменьшим нагрузку на сервер, во-вторых, в разы ускорим загрузку страниц сайта. Да потратив примерно час времени вы добьетесь колоссального успеха сразу в нескольких направлениях — оптимизируете, ускорите свой сайт, уменьшите нагрузку на ваш сервер.
Стандартные запросы к базе данных функциями WordPress
Для начала давайте поговорим о том, от куда же возникают запросы к базе в WordPress? Для того что бы понять что мы “вытаскиваем” с нашей базы данных давайте проанализируем некоторые данные:
- Название сайта;
- Описание сайта;
- Ссылки на CSS файлы темы;
- Параметры документа выводимые в теге head;
- Вывод категорий, записей, меток.
- При установке картинок шаблона также прописывается их местоположение с помощью функций WordPress и обращением к БД;
- Формирование главного меню;
- Другое;
Это текстовые данные которые извлекаются из базы путем вызова стандартной функции wordpress bloginfo () и других встроенных функций вызывающие запросы к базе данных WordPress. Вы даже представить себе не можете сколько раз используются функции на ваших страницах сайта, НА ВСЕХ СТРАНИЦАХ! А ведь все это можно с легкостью заменить на стандартный текст и внедрить непосредственно в шаблон, тем самым исключить огромное количество запросов.
ВНИМАНИЕ: если у вас нет хотя бы минимальных знаний html и PHP, настоятельно рекомендую сделать резервную копию сайта перед изменением кода. При обновлении темы все изменения скорее всего пропадут, по этому стоит задуматься о создании дочерней темы.
Правим и избавляемся от лишних запросов в header.php.
Давайте перейдем от теории к практике. Для того что бы править наш шаблон нам нужен доступ к файлам. Для этого подключаемся к серверу через FTP доступ и копируем папку с темой на наш локальный компьютер.
Скопировали? Отлично, теперь находим основной шаблон темы index.php открываем его для правки. Для наглядности я выбрал стандартную, новую тему twentyfifteen, которая появилась с выходом WordPress 4.4.
Открыв главный шаблон мы можем увидеть какие файлы подключает наша тема, и первым на что мы обращаем внимание это вызов функции get_header(), которая подключает нашу шапку сайта, файл header.php, именно к нему мы и обращаемся.
Находим нужный нам шаблон в папке темы, открываем его и смотрим что же нам тут можно сменить.
В первом же теге <html> встречается вызов функции language_attributes(), которая выводит значение языка установленного на вашем сайте, для того что бы избавиться от вызова этой функции нужно всего лишь заменить текущую функцию значением lang=”ru-RU “, после этого мы избавимся от одного запроса к БД на каждой странице вашего сайта.
Не будем останавливаться и идем далее, и следующее что нам попадается это строчка с указанием кодировки:
<meta charset=”<?php bloginfo( ‘charset’ ); ?>” >.
Строки выделенные после изменения у нас должно получиться следующее:
<meta http-equiv=”Content-Type” content=”text/html” ; charset=”utf-8″/>
Мы не только избавились от лишнего кода, но и добавили несколько необходимых параметров в header.
Далее мы встречаем строчку:
<link rel=”pingback” href=” <?php bloginfo( ‘pingback_url’ ); ?> ” >
Ее можно вовсе удалить она нам не нужна.
Идем дальше, и находим следующую строку:
<h1 class= ” site-title”><a href= ” <?php echo esc_url( home_url( ‘/’ ) ); ?> ” rel= ” home ” ><?php bloginfo( ‘name’ ); ?></a></h1>
Тут используется сразу две функции:
- Извлекается и добавляется URL сайта, то-есть ссылка на главную страницу;
- Выводиться название сайта.
Так как мы работаем непосредственно с одним сайтом и подгоняем наш шаблон конкретно под наш сайт, значит мы знаем эти параметры и можем их заменить:
<h1 class= ” site-title ” ><a href= ” mysite.ru ” rel=”home”>Название сайта</a></h1>
Этим действием мы “убили” еще два запроса.
Далее мы видим такой же код в теге <p>, который мы аналогично изменяем.
Опускаемся ниже, находим код который выводит описание сайта, его так же можно заменить на более простой:
<?php endif;
$description = get_bloginfo( ‘description’, ‘display’ );
if ( $description || is_customize_preview() ) : ?>
<p class=”site-description”><?php echo $description; ?></p>
Все что нам нужно оставить из этого:
<?php endif;
?>
<p class=”site-description”>Описание сайта</p>
С хедером по нашему шаблону пока все, в вашей же теме могут быть и другие функции выводящие те или иные результаты, перед их правкой внимательно изучите их предназначение и замените на нужный вам вариант.
Теперь переходи к файлу footer.php, находим его в нашей теме, открываем и смотрим что нам можно тут исправить. В случае с темой twentyfifteen кроме как убрать лишние ссылки у меня править нечего, но в большинстве шаблонов в футере так же встречаются функции home_url() и bloginfo( ), которые можно так же заменять, как и в примере с header.php. Не забываем перед каждой правкой проверять значение параметра который установлен в функции и правильно заменять его на статическую информацию.
Конечно же вы можете сказать что в вашем шаблоне все совсем по другому и функции другие и строки иначе написаны, но поверьте, в WordPress в 99% случаев используют указанные функции в шаблонах. Если вы их не нашли в указанных мною файлах, значит поищите их в functions.php и других файлах, возможно они были вынесены именно туда. Естественно чем дальше от ссылки на функцию вы залезете в код тем больше вероятность его повредить, но вы всегда можете экспериментировать на локальном компьютере, как установить WP на локальный комп я уже рассказывал.
Проделав все необходимые замены вы избавитесь к примеру от 10 запросов к базе с каждой страницы сайта. А если подсчитать сколько у вас просмотров страниц в день да умножить это число на 10. Вывод можете сделать сами, нужны ли вам эти изменения или нет.
“Более продвинутые” это слишком громко сказано, для того что бы избавиться от запросов в навигационном меню и сайт баре вам достаточно будет знать html и немножко CSS, как именно оформлять я рассказывать ну буду, возможно как то в другой раз, сейчас расскажу только суть самого процесса.
В зависимости от того где расположено ваше главное меню, в большинстве случаев это горизонтальное меню в верхней части сайта, вы должны найти функцию отвечающую за вывод такого меню на экран это функция wp_nav_menu() и предшествующая ей функция has_nav_menu (), проверяющая регистрацию меню навигации.
Тут сложность заключается в том, что бы правильно вставить нужный фрагмент html на место функции.
Настоятельно рекомендую играться с кодом на локальном компьютере, имея несколько копий файлов для возврата предыдущих версий редактирования.
Суть заключается в том, что бы убрать PHP код и заменить его html списком с прописанными URL адресами навигации и их анкорами. Для большинства пользователей на слух это тяжело воспринимать, поэтому попытаюсь показать на примере.
Допустим у меня есть такой фрагмент кода отвечающий за вывод навигации:
<div id=”secondary” class=”secondary”>
<?php if ( has_nav_menu( ‘primary’ ) ) : ?>
<nav id=”site-navigation” class=”main-navigation” role=”navigation”>
<?php
// Primary navigation menu.
wp_nav_menu( array(
‘menu_class’ => ‘nav-menu’,
‘theme_location’ => ‘primary’,
) );
?>
</nav>
И я хочу его заменить стандартным html фрагментом, который будет выводиться статически, без использования запросов к базе данных и обработки на сервере.
Я делаю следующие изменения:
- Полностью удаляю весь PHP код;
- Создаю список нужных мне страниц для навигации, создаю список;
- Проставляю в списке правильные URL;
- Внедряю список в код, смотрим результат.
<div id=”secondary” class=”secondary”>
<nav id=”site-navigation” class=”main-navigation” role=”navigation”>
<ul><li><a href=”https://yrokiwp.ru”>Главная</a></li>
<li><a href=”//yrokiwp.ru/lessons-wp/”>Уроки</a></li>
<li><a href=”//yrokiwp.ru/category/plaginyi/”>Плагины</a></li>
<li><a href=”//yrokiwp.ru/video-uroki-wordpress/”>Видео</a></li>
<li><a href=”//yrokiwp.ru/obratnaya-svyaz-yrokiwp/”>Контакты</a></li></ul>
</nav>
После обновления страницы ничего измениться не должно, все то же меню с теми же ссылками, но без запросов к БД и нагрузки на сервер.
Помните, что это лишь частный пример и вариантов может быть огромное количество. После изменения могут возникнуть ошибки в коде PHP, неправильное отображение меню из за отсутствия CSS правил и многие другие мелкие погрешности, по этому и нужны хотя бы базовые знания HTML, CSS и PHP, что бы хотя бы понимать где искать ошибки и как найти их решение.
Сайдбар, что можно изменить и как это сделать.
С сайдбаром все немного проще чем с навигацией, дело в том, что нам не нужно полностью изменять и удалять код PHP, достаточно в шаблоне sidebar.php добавить html код, который будет отображать необходимые вам материалы в нужном месте.
Зачем нам это может понадобится? Ну к примеру у вас на блоге есть 5-7 рубрик, которые выводятся в сайдбаре и это отображается одинаково на всех страницах сайта. Так почему бы не сделать этот участок статическим и облегчить работу сервера?
Делается это по такому же принципу, как и в навигации. Берем контейнер сайт бара, это блоки с классами в которых расположен наш сайт бар, копируем их и вставляем в нужном месте. Для примера возьмем блок “категории”, который часто используется на сайтах. Расположим его выше чем вызов вывода сайдбара, эта операция сделает следующее:
- Выведет ваш статический код с категориями;
- Добавит настроенные вами виджеты ниже.
Если вам потребуется вставить код именно после конкретного блока сайдбара, тогда вам придется писать функцию самостоятельно.
В заключение хочу сказать что проделав все указанные в статье изменения я уменьшил количество запросов к базе данных при формировании главной страницы в 5 раз, с 75 запросов до 15. На сколько это эффективно судить вам.
Знаю что многим будет не совсем легко справиться с такой задачей, но тем кто всего однажды сядет и потратит на это время эффект очень понравиться. Вы можете так же написать возникшие вопросы в комментариях или через страницу “Контакты” и мы попробуем решить ваши проблемы.
Помните, уменьшив количество запросов к базе данных вы “убиваете сразу двоих зайцев” ускоряете загрузку страниц, снимаете нагрузку на сервер. Желаю удачи.
Хочу сказать на счет меню. Его мне кажется изменять все же не надо. Допустим, я изменил пхп код на хтмл. Затем, мне понадобилось добавить новую рубрику в менюшку. А так как пхп кода у меня уже нет, то придется снова лезть на хостинг и дописывать там хтмл код.
Речь идет не об удобстве, а об оптимизации и ускорении загрузки сайта. Если вы сумели заменить меню на статическое, добавить один два пункта к списку не составит большого труда. Но опять же дело каждого, это только рекомендации.
Я так понял, что в целях оптимизации выгодно вообще все элементы приводить к статистическому виду, но так-то нам никто не запрещает что-то оставить, для полного удобства. К примеру, название и адрес сайта уж точно можно делать статическим, но при этом меню можно оставить в том виде.
Вообще, у автора вышла очень дельная статья. Большое спасибо. Так-то, если WP оптимизировать, то выйдет штука еще намного круче, чем maxsite, который сейчас все нахваливают.
На всех сайтах примерно одно и то же… поправьте под сайта. А может есть что-то проще, плагин, который делает это за вас? Ведь при очередном обновлении вордпресс, все придется вносить вручную заново!
Конечно есть, и не один. Называются плагинами кеширования. Нагрузка на бд снизится вообще до нуля, не знаю зачем автор изобретал велосипед. К тому же активный пункт меню будет работать, если он в тема как-то выделен.
В функции bloginfo( ) вызывается функция get_option() внутри которой вызывается wp_load_alloptions() в мануале которой написано: “Эта функция вызывается автоматически на раннем этапе загрузки WordPress. Она загружает все опции из таблицы wp_options. Далее, когда мы получаем опцию, с помощью get_option() опция уже берется из кэша, а не из базы данных.” Так что хоть прописывайте в коде прямо название сайта к примеру , хоть нет wp_load_alloptions() всё равно отработает и запрос к базе данных будет. Сомнительная оптимитизация.
Оптимизация похожа больше на то, как из темы для вопродпресса сделать просто тему на html+css и в целом как вычленить вордпресс из неё. Пик такой оптимизации это уехать с водрпресса и руками все вносить. Будет все летать