WordPress как на ладони
Готовые темы (шаблоны) для WordPress wordpress jino

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

Как быть?

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

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

Оптимизация производительности WordPress за счет постоянных ссылок (теория) 10 комментариев
  • seezer cайт: blog.seezer.ru

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

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

    Ответить6.5 лет назад #
    • Kama4294

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

      Ответить6.5 лет назад #
  • eavasi cайт: www.eavasi.ru

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

    Ответить6.5 лет назад #
    • Kama4294

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

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

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

      Ответить6.5 лет назад #
  • Timur

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

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

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

    Ответить4.9 года назад #
  • Kolobokk cайт: oldoctober.com

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

    Ответить4.8 года назад #
  • Sergey cайт: liex.co

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

    Ответить3.7 года назад #

Здравствуйте, !

Ваш комментарий