Поліпшення продуктивності WordPress, які можуть призвести до потенційних проблем, все про

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

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

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

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

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

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

Можливі проблеми під час оновлень WordPress

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кешування об'єктів (Memcached)

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

Деякі WordPress-плагіни кодовані (жахливо), щоб зберегти величезний обсяг даних у базі даних програми. Сервіс Memcached має обмежений об'єм пам'яті для кешування. Уявіть собі, що станеться, якщо плагін збереже величезні зображення до бази даних. Memcached спробує зберегти результат цього запиту до буфера, проте вичерпає доступний простір. Потім він почне видаляти кешований раніше контент на основі методу "першим прийшов - першим пішов". Якщо результати запиту надто великі, то в такому разі ніякий актуальний контент не буде кешований, оскільки його буде видалено ще до повторної видачі. В даному випадку ваш веб-сайт сильно сповільнюватиметься, оскільки ви не тільки не знизите навантаження на MySQL-сервіс, але і, навпаки, додасте ще один сервіс в процес, який вимагає свого часу виконання.

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

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

Мені подобаються спрайти, які дають змогу збільшити продуктивність сайту при своєму коректному використанні. Саме з цієї причини в ході недавнього редизайну SiteGround ми вирішили перевести всі навігаційні та UI елементи, а також багато інших елементів сторінки до спрайтів. Наш сайт почав працювати набагато швидше і ми були задоволені отриманим результатом. У результаті ми продовжили додавати елементи до спрайтів, доки не зіткнулися з проблемами, пов'язаними із завантаженням деяких сторінок на iOS-пристроях.

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

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

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

Існуючі ризики з мінімізацією CSS та Javascript

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

Gzip: помилок з ним бути не може, але ми можемо зробити стиск краще

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

Більшість користувачів WordPress часто покладаються на плагіни – принаймні ті люди, які не можуть або не хочуть писати код, у тому числі й при включенні Gzip. На жаль, Gzip плагіни працюють через PHP, що, незважаючи на швидкість роботи, не дозволяє досягти такої ж швидкості, як запуск безпосередньо з сервера Apache. Все, що вам потрібно зробити - встановити mod_deflate (дізнайтеся у свого хостинг-провайдера, чи доступна така можливість - зазвичай вона доступна, оскільки є стандартом індустрії) і додати кілька рядків у ваш файл .htaccess:

Висновок

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

---