WordPress Хостинг та Плагіни
Зробіть WordPress швидким та безпечним: контрольний список для продуктивності та плагінів
WordPress настільки швидкий і безпечний, наскільки швидке і безпечне те, що на ньому запущено. Ось практичний чек-лист, який ми застосовуємо до кожного сайту WordPress на нашому хостингу: що кешувати, як захищати, які плагіни дійсно корисні, а які платформа робить зайвими.
WordPress настільки хороший, наскільки хороше те, що ним керує
WordPress забезпечує роботу значної частини веб-простору завдяки своїй гнучкості, але ця гнучкість також є причиною того, чому він стає повільним і небезпечним: стандартна інсталяція звертається до бази даних десятки разів на сторінку, транслює свою версію та стек будь-кому, хто подивиться, і заохочує встановлювати плагіни, поки продуктивність і поверхня атаки непомітно не зростуть. Усе це не стільки вада WordPress, скільки наслідок запуску на інфраструктурі, яка ніяк не допомагає.
Хороша новина полягає в тому, що кілька однакових рішень виправляють більшу частину цього, і це рішення щодо стека, а не щодо контенту. Кешуйте агресивно на правильному рівні, тримайте базу даних поза гарячим шляхом, запускайте лише ті кілька плагінів, які дійсно заслужили своє місце, тримайте все оновленим та ізолюйте сайт, щоб проблема залишалася локалізованою. Цей пост — і є цей чек-лист у тій послідовності, в якій ми застосовуємо його до кожного сайту WordPress на платформі.
Кеш на сервері, а не лише в плагіні
Найважливішим чинником для швидкості WordPress є відсутність запуску самого WordPress для більшості відвідин. Стандартний запит завантажує WordPress, запускає ваші плагіни та виконує запити до бази даних перед надсиланням хоча б одного байта; кеш цілої сторінки віддає готову сторінку безпосередньо з вебсервера під час наступного звернення, оминаючи весь процес завантаження. Розташування цього кешу має значення: кешувальний плагін працює всередині PHP, тому PHP усе одно запускається до того, як кеш зможе відповісти, тоді як кеш на рівні сервера відповідає раніше в процесі обробки запиту та зберігає сторінки у форматі, який сервер може миттєво віддати.
Кожен сайт WordPress, який ми розміщуємо, працює на LiteSpeed Enterprise з LSCache на рівні сервера, а наш власний плагін кешування підключає до нього WordPress одразу після встановлення — він попередньо встановлений і оновлюється автоматично, тож це на одну річ менше, яку потрібно налаштовувати чи підтримувати в актуальному стані. На сервері без LiteSpeed той самий плагін просто не виводить заголовки повносторінкового кешу та не заважає роботі об’єктного кешу, тому мігрований сайт ніколи не залишається напівналаштованим. Практичне правило для вашого власного чеклиста: один повносторінковий кеш на сервері, і не встановлюйте другий плагін кешування поверх нього — вони конфліктуватимуть.
Об'єктний кеш і база даних
Не кожен запит може бути статичною сторінкою. Авторизовані сесії, адміністративна панель, пошук, кошики та будь-які персоналізовані фрагменти мають виконувати PHP, і для них мета зміщується з обходу застосунку на обхід бази даних. Кеш об'єктів для кожного сайту — у нашому випадку Redis — зберігає результати повторюваних читань бази даних у пам'яті, тому самі й ті самі параметри, транзієнти та запити не надсилаються до бази даних під час кожного звернення. Ефект проявляється саме там, де кешування повноцінних сторінок безсиле: швидша адмін-панель, швидші кошики та значно менше навантаження на базу даних за умов трафіку.
Ключовим тут є слово «для кожного сайту». Спільний кеш об’єктів означає, що один активний або погано написаний сайт може витіснити кешовані дані всіх інших і позбавити сусідів ресурсів бази даних; виділений кеш для кожного сайту в поєднанні з обмеженнями бази даних для кожного сайту утримує цю зону ураження під контролем. У своєму чек-листі вважайте постійний кеш об’єктів обов’язковим для будь-якого сайту з авторизованими користувачами чи магазином і остерігайтеся хостингу, де він є спільним для кількох орендарів.
Плагіни, які варто використовувати, і ті, які платформа замінює
Кожен плагін, який ви додаєте, — це код, який виконується під час запитів, і потенційні двері, через які хтось колись може зайти, тому чесна мета — використовувати найменшу кількість плагінів, які виконують найбільшу роботу. Гарний хостинг усуває потребу в цілій їхній категорії: завдяки кешуванню на рівні сервера, кешу кешуваних об'єктів під управлінням та резервним копіюванням платформи вам не потрібен плагін кешування, окремий плагін об'єктного кешу чи плагін резервного копіювання — ці завдання краще виконувати поза межами WordPress, а їх запуску зверху додає лише конфліктів та накладних витрат.
Те, що варто залишати — це невелика кількість плагінів із реальною функціональністю: ті, які дійсно потрібні вашому сайту для роботи, а також — на нашій платформі — два плагіни репозиторного рівня, які ми створюємо та постачаємо з кожним сайтом. Наш плагін кешування підключає WordPress до серверного кешу та керує розумним очищенням, щоб редагування очищувало лише ті сторінки, які потрібно. Наш плагін footprint видаляє ознаки, які транслює інсталяція WordPress за замовчуванням — тег версії та генератора, кінцеві точки виявлення, XML-RPC, пінгбеки та заголовок powered-by — під час кожного розгортання, тож оновлення плагіна чи теми не зможе непомітно повернути їх назад. Обидва створено відповідно до стандартів каталогу плагінів WordPress.org, вони є безкоштовними та оновлюються самостійно.
Підтримка безпеки та актуальності WordPress
Більшість зламу WordPress не є витонченими — вони старі. Застаріле ядро, тема чи плагін із відомою опублікованою вразливістю — це переважно найпоширеніший спосіб атаки на сайти, через що підтримка актуальності є найважливішою роботою з безпеки та водночас найнуднішою, тому її й пропускають. Керований хостинг має позбавити вас цього клопоту: оновлювати стек під WordPress, а також робити оновлення ядра та плагінів безпечними для застосування, надаючи вам копію для тестування (staging) та резервну копію для відкоту.
Окрім цього, очікуйте, що захисні бар'єри будуть налаштовані за вас: сканування на шкідливе ПЗ за замовчуванням, щоб зараження було зупинене, а не виявлене відвідувачем; ізоляція, яка не дозволяє одному зламаному сайту отримати доступ до іншого; захист від DDoS на рівні мережі та повсюдний TLS із сертифікатами, що оновлюються автоматично. Усе це не замінює базової гігієни — надійних облікових даних, доступу з мінімальними привілеями та видалення плагінів, якими ви більше не користуєтеся, — проте гарантує, що слабкою ланкою не стане сама інфраструктура. У вашому контрольному списку питання до будь-якого хостера звучить просто: чи є безпека стандартом за замовчуванням, чи додатковою послугою, яку потрібно купувати?
WooCommerce та сторінки, які заборонено кешувати
Магазин — це місце, де агресивне кешування приносить найбільшу вигоду і завдає найбільшої шкоди, якщо воно наївне. Сторінки каталогу, товарів і категорій мають найбільший трафік і кешуються найкраще, а їхнє подавання з повносторінкового кешу — це найкраще, що ви можете зробити для швидкості магазину. Але кошик, оформлення замовлення та сторінки облікового запису є особистими й у жодному разі не повинні обслуговуватися зі спільного кешу: якщо зробити це, покупець побачить чужий кошик, що є водночас непрацюючим магазином і порушенням приватності.
Спосіб отримати і те, і інше — кешувати сторінку та робити виключення для динамічних елементів. Edge Side Includes відмальовують фрагмент кошика, загальну суму міні-кошика та стан облікового запису для кожного запиту, тоді як решта сторінки завантажується з кешу, а кошик, оформлення замовлення, мій акаунт і будь-які сторінки з nonce чи сесіями виключаються за замовчуванням. За актуальністю стежить розумне автоочищення, яке спрацьовує при зміні товару, ціни чи замовлення, тож застаріла ціна ніколи не затримається. Якщо ви використовуєте WooCommerce, це саме той пункт у чек-листі, який потрібно налаштувати ідеально: швидка вітрина з кешу, живий кошик для кожного користувача та жодних особистих даних у кеші.
Часті запитання
Чи потрібен мені плагін кешування на зразок WP Rocket?
Ні. Кешування цілих сторінок здійснюється на вебсервері за допомогою LiteSpeed's LSCache, наш власний плагін кешування підключає до нього WordPress і забезпечує розумне очищення, а за ним розташовується об’єктний кеш Redis для кожного сайту. Додавання другого плагіна кешування цілих сторінок зазвичай конфліктує з кешем на рівні сервера, а не допомагає, тому це ані не потрібно, ані не рекомендується.
Які плагіни робить непотрібними платформа?
Плагіни кешування, окремі плагіни об'єктного кешу та плагіни резервного копіювання тут є зайвими, оскільки ці завдання виконуються на рівні нижче WordPress — за допомогою кешування на рівні сервера, кешу об'єктів для кожного сайту та резервного копіювання платформи. Їх видалення зменшує кількість конфліктів та поверхню атаки. Варто залишити лише ті плагіни, які дійсно потрібні для функціонування вашого сайту, а також наші два безплатні плагіни кешу та footprint, які постачаються попередньо встановленими.
Чи порушить кешування мій кошик WooCommerce або сторінки для ввійслених користувачів?
Ні. Кошик, оформлення замовлення, мій кабінет і будь-які сторінки nonce чи сеансів виключаються з кешу за замовчуванням, а Edge Side Includes підтримують фрагмент кошика та загальні суми в реальному часі на сторінках, які інакше кешуються. Покупці завжди бачать свій власний кошик і працююче оформлення замовлення, поки вітрина магазину все ще завантажується з кешу, а розумне автоочищення видаляє з кешу уражені сторінки, коли змінюється товар, ціна чи замовлення.
Як ви забезпечуєте безпеку WordPress без мого керування?
Ми виправляємо вразливості в стеку під WordPress, робимо оновлення ядра та плагінів безпечними завдяки тестовому середовищу (staging) та відновленню в один клік, запускаємо сканування на шкідливе ПЗ та захист від DDoS за замовчуванням, ізолюємо кожен сайт, щоб зараження не поширювалося, а також автоматично випускаємо та оновлюємо TLS-сертифікати. Це позбавляє інфраструктуру статусу слабкої ланки; базові правила гігієни, як-от надійні облікові дані та видалення невикористовуваних плагінів, залишаються вашим обов'язком.
Пов'язані
Спробуйте безплатно протягом 14 днів
Запустіть свої перші сайти безплатно на 14 днів — без картки. Переносите існуючий сайт або мережу? Ваша перша міграція за наш рахунок.
Почати безплатно