WordPress как на ладони
Недорогой хостинг для сайтов на WordPress: wordpress.jino.ru

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

Расскажу об еще одном виде оптимизации WordPress, автором которого являюсь я. Назову его: «оптимизация на пермалинках». Этот принцип я использую на некоторых сайтах, где в ЧПУ используются рубрики. В остальных случаях, когда ЧПУ состоит только из названия поста, ID поста, даты + названия, или всего этого вместе или по отдельности взятого, игра не стоит свеч. Также, разумеется нет никакого смысла, в этой оптимизации, если у вас вообще не включены ЧПУ.

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

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

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

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

Пользователям 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, и что на этот момент нужно обратить внимание, особенно, если вы по некоторым причинам не можете использовать плагины кэширования или используете плагины, кэширующие запросы, а не всю страницу.

Как быть?

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

9 комментов
  • seezer blog.seezer.ru

    Тем не менее, многие во имя SEO устанавливают ссылки типа %category% / %postname% чтобы сразу было понятно к какой рубрике относится пост.

    Сам я обычно предпочитаю не извращаться, а ставить стандартную конструкцию / %year% / %monthnum% / %day% / %postname% / либо что-то с %post_id%

    Ответить24.Окт.2010 в 20:55 #
    • Kama7641

      Для тех у кого вид %category%/%postname% решение будет весьма кстати.

      Ответить24.Окт.2010 в 23:29 #
  • eavasi www.eavasi.ru

    Я не доверяю генерацию пермалинков системе и всегда по окончании статьи пишу их самостоятельно. Использую при этом или сокращенный перевод названия статьи на англит, или суть статьи одним - двумя словами по-английски. Пермалинк в моем случае принимает форму: HTTP://МОЙ_САЙТ/МОЕ_НАЗВАНИЕ_ССЫЛКИ/
    Для кеширования применяю коммерческий скрипт Maxcache, который превосходно кеширует страницы и минимизирует запросы к базе до 1-3 и очень сильно снижает время генерации страницы до долей секунды.

    Ответить25.Окт.2010 в 10:25 #
    • Kama7641

      Тут речь, не об этом. То что вы пишите вручную название, это вы всего-лишь руками указываете slug(название) статьи. В вашем случае ЧПУ настроены так: /%postname%/.

      Maxcache не пользовался, но уверен скрипт отличный MAX плохого не делает smile Просто, страничное кэширование обладает некоторыми недостатками...

      А вообще, страничный кэш и ЧПУ вашего вида - эта статья вам абсолютно не нужна.

      Ответить25.Окт.2010 в 17:27 #
  • Timur

    По поводу "проблемных" трех меток которые ты указал в статье:
    Слушай...на сколько я помню разработчики решили эту проблему с производительностью в вп3.3

    Почитай тут
    Заголовок "Performance issues with permalinks".

    Это я к чему хочу сказать, актуально ли это решение по сей день? все таки статья 2010 года.

    Ответить26.Май.2012 в 11:30 #
  • Kolobokk oldoctober.com

    А я вручную определяю ссылки для каждой статьи. Обычно, это одно-два коротких слова на английском, соответствующие названию статьи.

    Ответить12.Июн.2012 в 12:21 #
  • Sergey liex.co

    Я пока тоже пишу вручную на своём блоге. Благо, не сложно и не лень. Но вот если это делать на сателлитах всяких, то можно и задолбаться smile . Так что, статья и мысль - нужные.

    Ответить24.Июл.2013 в 19:34 #
  • Возможно чутка не в тему, тем не менее лучшей статьи для вопроса не нашел пока.

    Я так понимаю, что для кулинарного сайта нужно формировать слаг из id поста + транслита названия поста, так как есть вероятность создания множества записей с дублирующимся названием (и исходя из этого слагом в обычной реализации типа /%category%/%postname%).
    Т.е. на выходе должно получиться примерно такое /retsepty/129643-zapechennyy-kabachok-s-kurinoy-pechenyu , так? (нужен совет, рекомендация).
    Как это можно реализовать в wordpress?
    Ведь выходит, что перед и после "post_id" должен быть слеш "/", верно (иначе тег не работает корректно, если не ошибаюсь)? А значит скорее всего не будет работать структура типа "/retsepty/%post_id%-%postname%"?

    Ответить13.Авг.2019 в 14:11 #
    • @Kama, приветствую! По возможности, дайте пожалуйста обратную связь по моему вопросу. Он еще в силе и актуален. Спасибо.

      Ответить08.Окт.2019 в 10:43 #
Здравствуйте, !     Войти . Зарегистрироваться