Оптимизация производительности WordPress за счет постоянных ссылок (теория)

Сегодня я расскажу об еще одном виде оптимизации WordPress, автором которого являюсь я. Назову его: «оптимизация на пермалинках». Этот принцип я использую на всех свои сайтах.

Начну с того, что все ниже сказанное полезно, только если включена поддержка ЧПУ(человеко-понятных урлов).

Немного лирики

Дело было вечером, делать было нечего, потому что интернет отрубили уже четвертую неделю как. Именно тогда, в те скудные, без-интернетные дни, со времени которых, прошло уже около полу года, я придумал этот способ оптимизации.

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

Теория постоянных ссылок

Пользователям WordPress наверняка известна функция, генерирующая постоянные ссылки, имя которой - the_permalink(). Задумайтесь на секунду, как она работает? Кому на ум ничего не приходит, объясню: когда мы вызываем эту функцию (обычно внутри цикла WP), происходит множество операций (зависит от типа ЧПУ) по генерации УРЛа. Эта функция буквально собирает ссылку, в зависимости от того, какой тип ЧПУ установлен.

Например, у нас установлен один из базовых типов: /%year%/%monthnum%/%day%/%postname%/ в итоге ссылки на статьи имеют, примерно, такой вид: http://wp-kama.ru/2010/10/27/post-name/. Теперь, давайте разберемся как функция the_permalink() создает эту ссылку: при вызове функции, сначала получаются данные о том, какой тип ЧПУ у нас установлен, затем на основе установленного типа определяется какие данные нам нужны для того, чтобы сгенерировать ссылку, после этого выполняются операции по сбору ссылки. В данном примере, будет считывается глобальная переменная $post в которой находятся данные о дате поста и его имя (slag), затем на основе этих данных будет собрана ссылка.

Такой вариант ЧПУ в целом достаточен, чтобы the_permalink() не создавала излишних нагрузок на сервер при генерации страницы, однако они все равно есть. Оптимален он, потому что все эти данные находятся в переменной $post, которую функция может легко получить. Но что если структура ЧПУ содержит в себе метку %category%, %tag% или %author%? В таких случаях переменная $post не будет содержать всех данных для создания постоянной ссылки и будут запрошены дополнительные данные, которые хранятся в КЭШе, например, категории (%category%) или теги (%tag%) будут собираться через таксономию.

Получение категории, в которой находится пост и всех родительских категорий для текущей, процесс нужно сказать не самый быстрый, а представьте, если у вас на странице 200-300 ссылок, ведь они все собираются таким образом. Именно поэтому при отключении встроенного кэша WordPress количество запросов к БД увеличивается до сотен.

Если обратить внимание, на базовые настройки ЧПУ то мы увидим, что там нет таких вариантов, где бы использовались метки %category%, %tag% или %author%, и по дефолту ЧПУ отключены.

Кстати, вот все метки, которые можно использовать в построении ЧПУ в WordPress:

Метки которые доступны сразу и создают минимальную нагрузку на генерацию ссылки:

• %year% - год публикации поста. Например, 2004
• %monthnum% - месяц публикации поста. Например, 05
• %day% - день месяца. Например, 28
• %hour% - час, когда был опубликова пост. Например, 15
• %minute% - минута. Например, 43
• %second% - секунда. Например, 33
• %postname% - название поста, имя (post slug). Например, nazvanie-posta
• %post_id% - идентификатор поста (уникален – никогда не повторяется). Например, 423

Метки, которые создают повышенную нагрузку при генерации ссылки:

• %category% - названия категории, в которой находится пост. Если у категории есть родительская категория, то она будет так же показана. Например, glavnaya_kategoriya/kategoriya_posta.
• %tag% - адаптированное название метки поста. Например, metka_posta
• %author% - адаптированное название автора поста. Например author

Разработчики WordPress не рекомендуют использовать последние 3 метки.

Приводя конкретные числа, могу сказать, что для генерации ссылки типа %category%/%postname%, при выключенном КЭШе создается 5 запросов к Базе Данных. Если кэш включен, то 0 запросов к БД, данные берутся из Кэша. Также, не нужно забывать, что при этом происходит ряд PHP вычислений.

Думаю всего вышесказанного достаточно, чтобы понять как работают постоянные ссылки в WordPress, и что на этот момент нужно обратить внимание, особенно, если вы по некоторым причинам не можете использовать плагины кэширования или используете плагины, кэширующие запросы, а не всю страницу.

Как быть?

Как же можно решить эту проблему нагрузки? Предлагаю ответить на этот вопрос вам. Мне будет интересно услышать ваше мнение и возможные варианты реализации этой проблемы. Наверняка кто-то уже «нашел» выход и успешно его использует.

Свой вариант решения данной проблемы я опубликую во второй части статьи.