Чому ми перейшли з WordPress на статичний сайт
Цей блог ви читаєте на статиці. А рік тому тут крутився WordPress - 15 плагінів, PHP, база даних MariaDB і 254 МБ в одній тільки папці wp-content. Для блогу, де виходить кілька статей на місяць, це виявилося як вантажівка заради поїздки за хлібом.
Розкажу, чому ми все знесли і переїхали на Astro - і що з цього вийшло в цифрах.
Чим не влаштував WordPress
WordPress - чудова річ, якщо вам потрібні коментарі, форми, особисті кабінети, плагін під кожен рух. Нам не потрібно було нічого з цього. Ми публікуємо текст. А платити доводилося за все одразу.
Безпека. WordPress - найбільш атакована CMS у світі просто тому, що її найбільше. Боти гатять у wp-login.php цілодобово, діра в будь-якому з 15 плагінів - і твій сервер вже майнить чужі монети. Кожен плагін це ще один чужий код, якому ти фактично видав ключі від дому.
Ресурси. PHP і MySQL висять у пам’яті завжди, навіть коли на сайті нуль відвідувачів. Близько 300 МБ RAM зайнято під сам факт існування блогу. На домашньому сервері, де кожен мегабайт на рахунку, це дратує.
Швидкість. Кожен запит - це PHP збирає сторінку з бази, проганяє через тему і плагіни і тільки потім віддає. Кешування допомагає, але ти лікуєш симптом: кешуєш те, що взагалі не повинно генеруватися на льоту.
Оновлення. Ядро, тема, плагіни оновлюються щомісяця, і кожне оновлення це шанс щось зламати. Контентний блог не повинен вимагати обслуговування як бойовий сервер.
Чому Astro
Astro - генератор статичних сайтів. Ідея проста: сторінки збираються один раз під час збірки, на виході чистий HTML, який nginx віддає як звичайний файл. Жодного PHP в рантаймі, жодної бази даних.
Що зайшло:
- Zero JS за замовчуванням - на сторінку не їде жодного байта скрипту, поки він реально не потрібен.
- Контент у Markdown - статті це просто текстові файли в git. Версіонування, історія правок, відкат - все безкоштовно.
- Пошук через Pagefind - індекс збирається під час збірки і працює на клієнті, серверу база не потрібна.
Статтю я пишу в Markdown, роблю git commit, запускаю deploy.sh - він гонить astro build, збирає індекс пошуку і перезавантажує nginx. Півхвилини - і новий текст у проді. Без адмінки, без візуального редактора, без «зберегти чернетку в базу».
Що показали цифри
| Метрика | WordPress | Astro + nginx |
|---|---|---|
| Lighthouse Performance | 62 | 98 |
| Час завантаження | 2,8 с | 0,4 с |
| Споживання RAM | ~300 МБ | ~5 МБ |
| Поверхня атаки | висока | мінімальна |
5 МБ проти 300 - це nginx, що віддає статику. Він тримав би цей блог навіть на найслабшому VPS і не спітнів би.
Чесно: що ми втратили
Переїзд на статику - це розмін, і дещо залишилося на тому боці.
Коментарі під статтями тепер не з коробки: захочемо - підключимо зовнішній сервіс. Візуальної адмінки немає, правки йдуть через редактор і git - для нас це плюс, але підійде не кожному. А динаміку на кшталт форм, особистих кабінетів і кошика на чистій статиці не зробити: для такого WordPress або нормальний бекенд залишаються правильним вибором.
Для контентного блогу нічого з цього не болить. Наше завдання - віддавати текст, і тепер ми віддаємо його швидко, дешево і без дір.
Навіщо це вам
Якщо у вас блог або лендинг на WordPress, а використовуєте ви від сили десяту частину його можливостей - порахуйте, у що обходиться решта. Швидше за все, статика закриє ваші завдання за копійки ресурсів і водночас зніме головний біль із безпекою.
Ми в PuraMind так і будуємо інфраструктуру: беремо мінімальний інструмент, який вирішує завдання, без зайвих шарів зверху. Розкажіть про свій проект - подивимося, що підійде вам.