Якщо ви останнім часом пробували знайти в Мережі різноманітні поради по збільшенню продуктивності WordPress, то, ймовірно, стикалися з різними методами, які пропонують люди.

У тому числі механізми кешування, такі як зворотні проксі, кешування об’єктів і плагінів, мінімізація CSS, використання спрайтів для зображень і так далі. Всі вони мають право на існування і в тій чи іншій мірі ефективно вирішують завдання прискорення роботи веб-сайту на WordPress.

Однак при реалізації будь-якого з цих методів слід бути дуже обережним і завжди перевіряти, як вони вплинуть на роботу сайту.

У цій статті ми розглянемо деякі з найбільш поширених проблем, пов’язаних з різними прискорювачами, і опишемо рішення, які допоможуть вам вирішити ці проблеми або хоча б обійти їх.

Можливі проблеми при використанні зворотних проксі, таких як Varnish і Nginx

Я почну з зворотних проксі, тому що при правильному використанні, вони можуть дати вам найбільший приріст швидкості.

Аналогічно при неналежному застосуванні вони можуть привести до серйозних проблем. Аж до недоступності сайту або відображення некоректної інформації.

Як працюють зворотні проксі?

Зворотні проксі-сервери, такі як Varnish і Nginx, обробляють дані між клієнтом користувача та веб-сервером. Коли надходить запит на одній із сторінок сайту, веб-сервер, як правило, повинен запустити PHP-сервіс, який виконує звернення до бази даних, і потім забезпечує висновок сторінки, а статичні ресурси повинні візуалізувати сторінку.

Коли в процес включений проксі-сервер, цей результат зберігається в кеш, і наступного разу, коли хтось запитає цю ж сторінку, готовий результат виводиться із зворотного проксі-сервера, який працює набагато швидше і до того ж не створює навантаження на сервер.

Це все чудово, але для коректної роботи, кеш повинен очищатися кожен раз, коли на сторінці щось змінилося. Саме з-за цього все може піти не так. В основному тому, що WordPress не підтримує зворотні проксі-сервера, і, щоб кеш очищався правильно, потрібно їх додаткове налаштування.

Як правило, очищення кеша здійснюється з допомогою основних звернень WordPress за замовчуванням (які в цьому випадку відстежують події) — коли оновлюється повідомлення, коли додається коментар, коли створюється повідомлення і т. д.

Однак, якщо при реалізації зворотного проксі-сервера, який ви використовуєте, було упущено важливе звернення, то можуть виникнути проблеми.

Крім того, вміст вашого сайту можуть змінювати численні події, що не входять до складу базових звернень WordPress — ті, що виконуються за допомогою плагінів.

Можливі проблеми при оновленні WordPress

Оновлення WordPress переводить сайт в режим обслуговування, оновлює свої файли, а потім відключає режим обслуговування. Зворотний проксі міг захопити в кеш деякі з ваших сторінок, в той час як сайт знаходився в режимі обслуговування.

Це означає, що, якщо кеш не очиститься, то ця сторінка буде знаходитися в режимі обслуговування, через що відвідувачі не зможуть потрапити на сайт, навіть якщо він знаходиться в робочому стані на веб-сервері.

Коли ви оновлюєте плагін WordPress відключає його, видаляє всю його папку, а потім додає нові файли. Протягом цього часу плагін фактично не працює. Якщо це великий плагін, який додає безліч функцій, таких як галерея або інтернет-магазин, то ваш зворотний проксі може закешувати сторінки з помилками.

При оновленні елементів системи вручну ви можете легко налагодити або відключити кешування під час оновлення, або ж очистити кеш вручну, як тільки оновлення виконано. Тим не менш, при використанні автоматичного оновлення WordPress, ці рішення є не дуже практичними.

Це повинен робити добре налагоджений зворотний проксі, а не система автоматичного очищення кешу при кожному оновленні.

Тому і ядро WordPress, і система оновлення плагінів повинні мати вбудовані обігу. Це легко може бути зроблено, і повинно бути зроблено, або Вами (якщо ви реалізуєте зворотний проксі самі), або хостинг-провайдером (якщо ви покладаєтеся на реалізації хоста).

Проблеми з плагінами WordPress для інтернет-магазинів

Незалежно від того, який плагін WordPress ви використовуєте для вашого інтернет-магазину, ви повинні бути дуже обережні при реалізації зворотного проксі кешування.

Наприклад, ви створили з допомогою віджетів прекрасну добірку товарів, що ваш клієнт, можливо, захоче купити. Якщо цей контент кешується зворотним проксі, то всі ваші відвідувачі будуть бачити ту ж добірку продуктів, що вибрав для покупки перший клієнт.

Все може вийти ще гірше, якщо сторінки, що містять особисту інформацію, наприклад, сторінки відгуків клієнтів, кешуються і відображаються не тим відвідувачам. Само собою зрозуміло, цього слід уникати будь-якою ціною.

Найбезпечніший спосіб уникнути подібних проблем — це виключити все, що стосується онлайн торгівлі, з кешу. Як правило, зворотні проксі, які реалізуються хостинговим компаніями, виключають найбільш поширені плагіни WordPress для електронної комерції з кешу за замовчуванням.

Якщо виключення всього, що стосується онлайн торгівлі, з кешу для вас не підходить — бо ви, очевидно, втрачаєте перевагу швидкості — то, теоретично, є більш складний спосіб обійти це обмеження: вказати за допомогою Edge Side Includes (ESI), які частини ваших сторінок не слід кешувати.

В теорії, ви просто могли б оточити HTML-код цих елементів тегам ESI:

Динамічний контент

В цьому випадку весь вміст між цими тегами буде безпосередньо динамічно завантажуватися кожен раз, коли запитується ця сторінка. Повз кеша.

На жаль, впровадити ESI на WordPress в принципі не просто. У зв’язку з відсутністю оригінальної підтримки зворотних проксі в WordPress. Таким чином, ESI, як правило, не є вдалим варіантом для хостів, що підтримують зворотні проксі-сервера.

Але цей варіант варто розглянути, якщо у вас є інтернет-магазин, побудований на WordPress, і ви реалізуєте зворотні проксі самостійно.

Проблеми з плагінами рейтингів

При використанні плагінів рейтингів на WordPress-сайті, де реалізовано кешування зворотного проксі-сервера, завжди є ймовірність, що відвідувачі будуть бачити неправильну оцінку з кешу, замість реального рейтингу на поточний момент.

Причина полягає в тому, що голосування відвідувачів, здійснюване через такий плагін, не охоплюється зверненнями WordPress за замовчуванням, отже, кеш не очищається.

Як і у випадку з інтернет-магазином, ви можете або виключити сторінки, на яких проводиться рейтингове голосування з кешу, або реалізувати ESI для цих сторінок, якщо це можливо.

Проблеми з плагінами повного кешування сторінок

У разі якщо ваш хостинг-провайдер не надає вам зворотний проксі-сервер кешування, ви можете розраховувати на один з так званих плагінів WordPress повного кешування сторінок.

Коли відвідувач запитує сторінку, плагін буде зберігати фактичний вихідний HTML-код в фізичному файлі на сервері. Наступного разу, коли хтось запитає цю сторінку, вона буде виводитися йому у вигляді статичного HTML-файлу.

Це набагато повільніше, ніж зворотний проксі-сервер, але все одно швидше, ніж без кешування.

На жаль, з-за використовуваних методів кешування, можливе виникнення різноманітних проблем, які я тільки що описав. Це справедливо і для зворотних проксі, і плагінів для повного кешування сторінки. Плюс для деяких інших нових плагінів.

Будьте обережні при використанні такого кешування на своєму веб-сайті, якщо він має велику кількість повідомлень або сторінок.

При створенні контенту на WordPress-сайті, крім тих сторінок, які ви безпосередньо створюєте, існує ще велика кількість сторінок, які створюються автоматично: сторінки категорій, в яких перераховані всі повідомлення цієї категорії, сторінки тегів, архівів, сторінки авторів, сторінки завантажених зображень і т. д.

Все це додає велику кількість URL-адрес, які обслуговує ваш сайт. Тепер уявіть, що всі ці URL-адреси перетворюються в HTML-файли в якійсь папці (зазвичай це папка uploads) на веб-сервері. Коли в одній директорії розміщуються тисячі файлів, навіть зі списком цих файлів вже важко працювати, ми говоримо зараз про ОС Linux.

В результаті на великих сайтах, як правило, скупчується величезна кількість файлів, що призводить до проблем вводу / виводу на сервері, і, в кінцевому підсумку, сайт починає працювати повільно, а також виникають проблеми з хостинг-провайдером.

Не існує конкретного значення кількості записів, при досягненні якого ви не повинні використовувати цей метод. Багато що залежить від конкретного місця, де плагін зберігає кеш — наприклад, з використанням декількох папок замість однієї.

Це було б більш ефективно. Але все ж таки не достатньо для справді великого сайту. Просто майте на увазі, що якщо ви використовуєте такий метод кешування, і ваш сайт починає працювати повільніше, причина може полягати саме в цьому.

Кешування об’єктів (Memcached) і проблеми, які з ним пов’язані

Кешування об’єктів відмінно підходить для сайту, який отримує багато запитів до бази даних, це справді може прискорити деякі сайти.

Memcached зберігає результат найбільш часто виконуваних запитів до бази даних в оперативній пам’яті сервера і виводить результати з кешу, замість запитів до сервера MySQL. На жаль, в деяких випадках, це може істотно знизити продуктивність вашого сайту. І ось чому.

Деякі плагіни WordPress налаштовані (і в цьому проблема) для зберігання величезної кількості даних в базі даних програми. Сервіс Memcached має обмежений обсяг пам’яті для кешування. Уявіть собі, що станеться, якщо плагін зберігає в базі даних величезні зображення.

Memcached спробує зберегти результат цього запиту у буфері, але не буде мати досить вільного місця. Потім він почне видаляти раніше збережені дані методом first-in, first-out. Якщо результати запиту є досить великими, то фактичний вміст не буде кешуватися повністю, тому що його частина буде вилучена до того, як сервіс обробив його другий раз.

У цьому випадку, ваш сайт буде насправді працювати повільніше, тому що ви не тільки не зможете зняти це навантаження на служби MySQL, але і змушені будете додати в процес ще один сервіс, який вимагає додатковий час на обчислення.

Якщо ви виявили, що ваш сайт став працювати повільніше після включення Memcached, то, на жаль, єдиним рішенням для вас буде або вимкнути всі плагіни, які зберігають величезну кількість даних в базі даних, або відключити сам сервіс Memcached.

Спрайт: Так, з ними теж можуть виникнути проблеми

Я люблю спрайт з-за того збільшення продуктивності, яке вони дають сайту при правильному їх використанні. Ось чому, коли ми нещодавно переробили SiteGround, ми перевели всі елементи навігації, користувальницькі інтерфейси і багато іншого на спрайт.

Наш сайт став набагато швидше, і ми були цілком задоволені результатом. І після цього ми продовжили додавати елементи до спрайт-зображень, поки в якийсь момент не помітили проблеми при завантаженні деяких сторінки на IOS-пристроях.

Це сталося тому, що ми якраз вийшли за ліміт Mobile Safari для максимальної кількості декодованих пікселів, які можуть відображатися. Це обмеження різне для різних пристроїв.

Ви можете легко згенерувати спрайт з великою кількістю пікселів, і якщо він досягне граничного розміру, то браузер не буде його завантажувати. В результаті чого сайт залишиться без всіх елементів, що містяться в цьому спрайте. Звичайно, ви не хочете, щоб це сталося.

Хороший чоловік на ім’я Вільям Мелоун створив зручний інструмент для перевірки того, чи спрайт-зображення правильно відображаються на всіх IOS-пристроях. Просто введіть розміри вашого спрайт-зображення калькулятор, і він видасть відповідь.

Якщо ваш спрайт має занадто великий розмір, можливим рішенням для вас може стати поділ його на два зображення. Якщо вам доведеться це зробити, то моя порада — залишайте в новому зображенні тільки новітні елементи.

В іншому випадку вам доведеться заново налаштовувати весь CSS-код, який використовує спрайт. Чого ви, звичайно, не хотіли б робити.

Ризики, пов’язані з мінімізацією CSS і JavaScript

Мінімізація CSS і JavaScript — це ще один з найпоширеніших способів прискорення веб-сайту. Як правило, мінімізація цих файлів тягне за собою видалення всіх непотрібних символів (переносів рядків, точок з комою в кінці властивості CSS, коментарів тощо), тим самим зменшується розмір файлів.

Цей метод застосовується не тільки в WordPress, але для будь-сторінок, які використовують CSS і JavaScript.

Багато інструменти і плагіни автоматично мінімізують файли. Тим не менш, деякі проводять більш агресивну обробку, ніж просто видалення порожніх символів. Ряд інструментів, наприклад, будуть переставляти CSS селектори, групуючи їх за властивостями і т. д. В деяких випадках, це може поламати всю логіку CSS-файлу і перетворити ваш сайт в щось, що всього лише нагадує оригінал.

Щоб уникнути подібних проблем, використовуйте неагресивні інструменти мінімізації, які видаляють із файлів JavaScript і CSS тільки непотрібні дані, без перепризначення властивостей.

Крім того, завжди зберігайте копію ваших не минимизированных файлів, так як, після мінімізації, вони стануть практично нечитабельним, внесення в них будь-яких подальших змін буде зробити набагато складніше. Я використовую для цього або спеціальний плагін, або онлайн сервіс FreeFormatter.

Gzip: тут особливих проблем виникнути не повинно, але ми можемо поліпшити його

Включення Gzip для WordPress дозволяє значно збільшити швидкість завантаження. Gzip стискає виводяться сторінки і передає їх в браузер відвідувача, як звичайний ZIP-файл. Після чого браузер розпаковує і виводить його.

Це здорово, тому що час, який витрачає браузер на розпаковування вмісту архіву, у багато разів менше, ніж час, необхідний, щоб фізично не передавати стисле вміст із сервера в браузер.

Більшість користувачів WordPress покладаються на плагіни, якщо такі існують для конкретних завдань — принаймні, ті, хто не вміє або не хоче копирсатися в коді. Це стосується і Gzip. На жаль, Gzip-плагіни працюють через PHP.

Це хоч і швидко, але не так швидко, як якщо працювати безпосередньо з сервера Apache. Все, що вам потрібно зробити, це встановити mod_deflate (поцікавтеся у вашого хостинг-провайдера, чи доступний він — він повинен бути доступний, тому що це прописано в більшості стандартів) і додати кілька рядків у файлі .htaccess:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Висновок

Розуміння всіх ризиків, пов’язаних з оптимізацією швидкості роботи вашого сайту на WordPress, не повинно зупиняти вас від експериментів.

Для досягнення найкращих результатів слідуйте декільком простим принципам: не міняйте занадто багато речей одночасно, тестуйте швидкість завантаження, використовуйте статичні копії, коли це можливо, і тестуйте функціональність сайту після застосування кожного нового методу.

У цьому випадку, ви зможете прискорити роботу свого сайту, не порушивши при цьому жодної з функцій, і не створивши проблем для відвідувачів.

Переклад статті «WordPress Performance Improvements That Can Go Wrong» був підготовлений дружною командою проекту Сайтостроение від А до Я.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here