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

Окрім актуальності, очікуйте, що межі безпеки застосовуватимуться автоматично: сканування на наявність шкідливого програмного забезпечення увімкнено за замовчуванням, щоб інфікування виявлялося одразу, а не відвідувачем сайту, ізоляція, щоб зламаний сайт не міг вплинути на інший, захист від DDoS-атак на межі мережі та повсюдне використання TLS із сертифікатами, які продовжуються автоматично. Жоден із цих пунктів не замінює базову гігієну — надійні облікові дані, доступ із мінімальними привілеями, видалення плагінів, якими ви більше не користуєтеся, — проте це означає, що інфраструктура не є слабкою ланкою. У вашому контрольному списку запитання до будь-якого хостинг-провайдера просте: безпека є базовим параметром за замовчуванням чи платним пакетом послуг?

WooCommerce та сторінки, які ніколи не слід кешувати

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

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

Поширені запитання

Чи потрібен мені досі плагін для кешування, такий як WP Rocket?

Ні. Повне кешування сторінок виконується на вебсервері за допомогою LSCache від LiteSpeed, наш власний плагін кешування підключає до нього WordPress та забезпечує розумне очищення, а за ним працює об'єктний кеш Redis для кожного сайту. Додавання другого плагіна повного кешування сторінок зазвичай конфліктує з кешем на рівні сервера, а не допомагає, тому це непотрібно й не рекомендується.

Які плагіни платформа робить непотрібними?

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

Чи порушить кешування роботу мого кошика WooCommerce або сторінок для авторизованих користувачів?

Ні. Кошик, оформлення замовлення, my-account та будь-які сторінки з одноразовими ідентифікаторами (nonce) або сесіями за замовчуванням виключаються з кешу, а Edge Side Includes зберігають фрагмент кошика та підсумкові суми актуальними на сторінках, що кешуються. Покупці завжди бачать свій власний кошик і робоче оформлення замовлення, тоді як вітрина магазину все одно завантажується з кешу, а розумне автоочищення видаляє змінені сторінки у разі оновлення товару, ціни чи замовлення.

Як ви дбаєте про безпеку WordPress без потреби керувати ним з мого боку?

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

Спробуйте безкоштовно протягом 14 днів

Запустіть свої перші сайти безкоштовно на 14 днів — кредитна картка не потрібна. Переносите наявний сайт або мережу? Міграції безкоштовні та без обмежень.

Почати безкоштовно