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

Як бути?

Свій варіант вирішення цієї проблеми я опублікував у другій частині статті .