NVMe, PHP 8.3 і кеш: що реально прискорює сайт, а що маркетинг

Коротка відповідь

Якщо розставити фактори за величиною ефекту - від найбільшого до найменшого - вийде такий порядок:

1. Кеш готових сторінок. Прибирає генерацію взагалі. Замість 400-800 мс роботи PHP і бази - 20-50 мс на віддачу готового HTML.
2. Код сайту: тема, плагіни, запити до бази. Один поганий запит у циклі перекриває будь-яке залізо.
3. Версія PHP і OPcache. Перехід зі старої гілки на 8.3 - десятки відсотків на генерації сторінки.
4. Ядра і RAM тарифу. Вирішують не швидкість однієї сторінки, а скільки їх сервер віддасть одночасно.
5. NVMe замість SATA SSD. Десятки мілісекунд на звичайному запиті, у рази - на важких операціях із базою і файлами.
6. CDN перед сайтом. Прискорює картинки, скрипти і стилі для далеких відвідувачів. HTML за замовчуванням не чіпає.

Практичний висновок простий: спершу кеш і код, потім PHP, і тільки потім розмови про диск. Якщо ж ви зараз обираєте тариф - беріть NVMe, бо доплата за нього мізерна, але не чекайте, що він сам по собі полагодить повільний сайт. Не полагодить.

З чого складається час завантаження

Щоб не сперечатись про «швидкий хостинг» наосліп, час до появи сторінки треба розкласти на чотири частини - кожна технологія б'є рівно в одну з них:

• Мережа до сервера - DNS, TCP, TLS. Зазвичай 30-150 мс, залежить від географії.
• Генерація сторінки - PHP виконує код, ходить у MySQL, збирає HTML. У WordPress без кешу це 300-900 мс, у магазині з великим каталогом буває і 2-3 секунди.
• Віддача статики - картинки, CSS, шрифти. Вирішує розмір файлів і стиснення, а не процесор.
• Рендер у браузері - розбір HTML, виконання JavaScript. Хостинг на це не впливає.

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

1. NVMe чи SSD для хостингу: де різниця видно, а де ні

Це різні способи під'єднати накопичувач. SATA SSD упирається в шину: 6 Гбіт/с, тобто близько 550 МБ/с, і приблизно 90 тисяч дрібних операцій за секунду. NVMe під'єднаний напряму по PCIe - це вже гігабайти за секунду і сотні тисяч операцій. Але для сайту важлива не лінійна швидкість, а затримка на дрібній випадковій операції: у SATA це близько 100 мікросекунд, у NVMe - 20-30.

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

А от де NVMe відіграє по-справжньому:

• Важка база. MySQL пише журнал і читає індекси дрібними блоками - диск у вузькому горлі щодня. Каталог на 20-30 тисяч товарів на SATA і на NVMe - різні відчуття в адмінці.
• Сервер під навантаженням. Коли на сайт одночасно зайшли люди, черга до диска росте. NVMe розгрібає її швидше, і сайт не «підвисає» хвилями.
• Разові важкі операції. Імпорт прайса, перебудова індексу пошуку, відновлення з бекапа: те, що на SATA займає 15 хвилин, на NVMe займає 3-4.

Чесно про власний продукт: NVMe стоїть у всіх моїх тарифах, від найдешевшого. Це не привід продавати його як «сайт у шість разів швидший» - у шість разів швидший диск, а не сайт. Сайт стане швидшим настільки, наскільки він упирався саме в диск.

2. PHP 8.3 і OPcache: найдешевший приріст з усіх

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

Версія PHP - друга половина цієї історії. Вісімка помітно швидша за сімку на тих самих CMS. За моїми замірами під час перенесень, перехід із 7.4 на 8.3 дає приблизно 15-30% на генерації сторінки WordPress - залежно від теми і набору плагінів. Це відчутно, але це не рази.

Перемкнути версію можна самостійно: DirectAdmin → Select PHP Version. Два зауваження з практики:

• Стара CMS або покинутий плагін на 8.3 можуть віддати білий екран. Перемикайте не в п'ятницю ввечері і одразу дивіться error.log.
• Якщо сайт досі на 5.6 чи 7.0 - питання вже не у швидкості, а в безпеці: ці гілки не отримують оновлень.

3. Кеш: єдиний фактор, який дає рази

Слово «кеш» означає чотири різні речі, і плутанина між ними - причина половини суперечок про швидкість:

• OPcache - кеш байткоду PHP. Прибирає компіляцію, не прибирає запити до бази.
• Об'єктний кеш - зберігає результати запитів до бази між викликами.
• Кеш сторінок - зберігає зібраний HTML цілком. Наступний відвідувач отримує файл, PHP і MySQL не запускаються взагалі.
• Кеш браузера і CDN - статика, яку не треба качати вдруге.

Рази дає третій. Для WordPress це будь-який пристойний плагін кешування сторінок, для OpenCart - вбудований кеш плюс кеш шаблонів. Типова картина після вмикання: час відповіді падає з 600-700 мс до 40-80 мс, бо сервер більше не думає, а просто віддає готовий файл.

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

4. Cloudflare перед сайтом: що дає і чого не дає

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

Чого він не робить - так це не прискорює генерацію сторінки. За замовчуванням CDN кешує картинки, CSS і скрипти, а HTML щоразу тягне з сервера. Тобто якщо ваш PHP думає 800 мс, з Cloudflare він так само думатиме 800 мс, просто картинки приїдуть швидше. Розповіді про «прискорення сайту в рази лише вмиканням CDN» стосуються випадків, коли на сторінці 3 МБ картинок, а відвідувач - у Німеччині. Статика при цьому віддається стисненою і кешується на рік - це вже налаштовано, робити нічого не треба.

5. Ядра і RAM: коли справа не в диску

Диск і PHP визначають, скільки триває одна сторінка. Ядра визначають, скільки таких сторінок одночасно сервер порахує, не ставши в чергу. Це різні речі, і плутають їх постійно: сайт «гальмує тільки ввечері» - це майже завжди не диск, а брак ядер у години пік.

Ось як це виглядає в моїх тарифах - цифри місячні, при річній оплаті:

Помісячна оплата дорожча: Старт виходить 479 грн/міс. Різниця між планами - не «швидкість диска», NVMe однаковий скрізь, а саме ядра, пам'ять і місце. Тому апгрейд лікує рівно одну хворобу - нестачу ресурсів у пік, і не лікує повільний код. Якщо ви вже отримували лист про ліміти, почніть звідси: «Перевищено ліміт ресурсів»: що це означає.

6. Що з реклами хостингів означає нічого

Список формулювань, які я б на вашому місці пропускав очима:

• «До 20 разів швидше». Ключове слово - «до». Порівняння завжди з найгіршим налаштуванням: сайт без кешу на PHP 7.0 проти сайту з кешем на 8.3. Прискорив кеш, а продали диск.
• «Турбо-режим», «прискорювач сайтів». Зазвичай це той самий OPcache плюс кеш сторінок під власною торговою маркою.
• «Необмежене місце». Обмеження є завжди, просто воно в договорі, а не в таблиці. У мене в тарифах написані конкретні гігабайти - 10, 20, 30, 100.
• «100% аптайму». Такого не буває: сервер треба перезавантажувати після оновлень ядра. Я заявляю 99.9%.
• «Оптимізовано під WordPress». Часто означає просто передвстановлений WordPress. Дивіться на конкретику: версія PHP, OPcache, ліміти - розібрав це окремо в статті хостинг для WordPress.
• «Безлімітний трафік». Він справді є і в мене, і в більшості - але це давно не перевага, а норма ринку.

Що з чого складається: підсумкова таблиця

Чек-лист: у якому порядку це робити

1. Заміряти TTFB і час повного завантаження - до будь-яких змін, щоб було з чим порівнювати.
2. Увімкнути кеш сторінок. Перевірити, що кошик, оформлення і кабінет із кешу виключені.
3. Перемкнути PHP на 8.3 у DirectAdmin, після перемикання відкрити error.log.
4. Стиснути картинки і віддавати їх у WebP. Часто це більший виграш, ніж усе серверне разом.
5. Вимкнути плагіни, якими ніхто не користується. Кожен з них - код у кожному запиті.
6. Подивитись повільні запити до бази: у магазині це зазвичай пошук і фільтри каталогу.
7. Тільки після цього дивитись на тариф: якщо сайт просідає саме в години пік - додати ядра.
8. Заміряти ще раз тими самими інструментами і в той самий час доби.

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

Підсумок

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

З мого боку середовище однакове на всіх планах: NVMe-диски, Apache 2.4 з PHP 8.3 і OPcache, можливість перемкнути версію під стару CMS, Cloudflare перед сайтом зі стисненою статикою, DirectAdmin, безкоштовний SSL Let's Encrypt, щоденні бекапи поза сервером, дата-центр у Франції. Доступність заявлена на рівні 99.9%, не «сто відсотків». Плани відрізняються ядрами, пам'яттю і місцем - найдешевший Старт це 1 ядро, 2 GB RAM і 10 GB NVMe за 142 грн/міс при річній оплаті: оформити - кілька хвилин. Якщо сайту вже тісно в одному ядрі, дивіться решту тарифів - різниця між ними саме в цьому.

І остання порада, безкоштовна: перш ніж платити за швидкість, витратьте пів години на заміри. Дуже часто виявляється, що сайт гальмує через картинку на 4 МБ у шапці, а не через диск під сервером.