PHP-версії на хостингу: як одна цифра у налаштуваннях може прискорити сайт удвічі

Уявіть: ви купили спортивний автомобіль, але їздите на ньому виключно на першій передачі. Двигун ревіт, витрата пального космічна, а сусідка на велосипеді вас обганяє. Приблизно так виглядає сайт, який працює на PHP 7.0, коли на сервері доступний PHP 8.3. І знаєте, що найгірше? Більшість власників сайтів навіть не підозрюють, що ця «перша передача» увімкнена. Вони витрачають гроші на CDN, оптимізують картинки, міняють теми - а проблема ховається в одному рядку конфігурації хостингу.

Чому версія PHP - це не просто цифра для гіків

PHP - мова, на якій працює близько 77% усіх сайтів у світі. WordPress, Joomla, Drupal, OpenCart, Laravel-проєкти - усе це PHP. І кожна нова мажорна версія приносить не косметичні зміни, а реальний стрибок продуктивності.

Ось конкретні цифри, які варто побачити:

Різниця між PHP 7.0 і 8.3 - це майже подвоєння швидкості обробки запитів. Без жодних змін у коді вашого сайту. Просто інша цифра у панелі хостингу.

Як перевірити, яка версія PHP працює на вашому хостингу прямо зараз

Це займе менше хвилини. Серйозно.

1. Через панель хостингу (cPanel / Plesk / DirectAdmin): зайдіть у розділ «PHP» або «Software» - там зазвичай вказана поточна версія і доступний перемикач.
2. Через WordPress: меню «Інструменти» → «Здоров'я сайту» → «Інформація» → «Сервер» - рядок «Версія PHP».
3. Через файл phpinfo(): створіть файл info.php з вмістом <?php phpinfo(); ?>, завантажте у корінь сайту, відкрийте в браузері. Побачите абсолютно все про PHP-конфігурацію. Тільки не забудьте видалити файл після перевірки - це вразливість!
4. Через SSH: команда php -v покаже версію CLI, але вона може відрізнятися від тієї, що обслуговує ваш сайт через FPM або mod_php.

Якщо ви побачили щось нижче за 8.1 - це вже сигнал до дій. Якщо побачили 7.x - це сирена, а не сигнал.

Безпека: чому застаріла PHP - це відчинені двері для хакерів

Коли розробники PHP припиняють підтримку версії, вони припиняють випускати патчі безпеки. Знайдена вразливість? Класно, але ніхто її не закриє. Ваш сервер залишається з дірою, про яку знає весь даркнет.

«Кожна третя зламана WordPress-інсталяція у 2024 році працювала на версії PHP, що вже не підтримується. Це не вразливість плагінів, не слабкий пароль - це фундамент, на якому стоїть увесь будинок, і він прогнив.» - звіт Sucuri Security Trends Q3 2024

Я особисто знаю випадок, коли інтернет-магазин на OpenCart втратив базу з 12 000 клієнтів через експлойт, що цілив у PHP 7.2. Власник навіть не знав, яка версія у нього стоїть. Він думав, що хостинг «все робить сам». Хостинг не робить сам. Хостинг дає інструменти - натискати кнопки має хтось.

Ось мінімальний чекліст безпеки, пов'язаний з PHP:

• Використовуйте тільки версії з активною підтримкою або хоча б із підтримкою безпеки
• Увімкніть автоматичне оновлення мінорних версій (8.3.x → 8.3.y), якщо хостинг дозволяє
• Вимкніть відображення помилок PHP на «живому» сайті - директива display_errors = Off
• Заборонить небезпечні функції: exec, shell_exec, passthru, system у php.ini

Як оновити PHP і нічого не зламати: покроковий план

Ось тут починається найцікавіше. Бо оновити цифру легко - наслідки можуть бути різними. Старий плагін, кастомний код з 2018 року, ідеально працюючий на PHP 7.4, може розсипатися на PHP 8.3 як картковий будиночок.

1. Зробіть повний бекап. Файли + база даних. Не «хмарний знімок хостера», а свій, скачаний локально. Параноя тут - ваш друг.
2. Створіть staging-копію сайту. Більшість сучасних хостингів (SiteGround, Cloudways, HostPro) мають функцію «Staging». Якщо ні - піддомен + клон бази.
3. Перемкніть PHP на staging-копії. Спочатку на одну мажорну версію вгору. Якщо у вас 7.4 - спробуйте 8.0, потім 8.1, потім 8.2.
4. Перевірте ключові сценарії: головна сторінка, каталог, кошик, оформлення замовлення, форми зворотного зв'язку, адмін-панель.
5. Перевірте логи помилок PHP. Файл error_log у корені або через панель хостингу. Шукайте «Deprecated», «Fatal error», «Warning».
6. Оновіть проблемні плагіни/модулі. Якщо оновлень немає - шукайте альтернативу. Плагін, який не підтримує PHP 8.x у 2025 - це мертвий плагін.
7. Перемикайте бойовий сайт тільки після успішного тестування staging.

Золоте правило: ніколи не оновлюйте PHP на бойовому сайті в п'ятницю ввечері. Якщо щось піде не так - ви не хочете дебажити це у суботу о третій ночі.

PHP-FPM, OPcache та інші «ручки» тюнінгу, які ви ігноруєте

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

PHP-FPM (FastCGI Process Manager) - це спосіб, у який сервер обробляє PHP-запити. Якщо ваш хостинг ще використовує mod_php або звичайний CGI - ви втрачаєте від 15 до 40% швидкості. FPM дозволяє контролювати пул процесів: скільки «робітників» обслуговують відвідувачів одночасно.

OPcache - вбудований кеш, що зберігає скомпільований PHP-код у пам'яті. Замість того, щоб кожен раз «читати і перекладати» ваші PHP-файли, сервер бере готовий результат із кешу. Прискорення - від 30 до 70% на динамічних сайтах. Але він працює тільки якщо його правильно налаштувати:

• opcache.memory_consumption=256 - для середнього WordPress із 30+ плагінами 128 МБ вже буває мало
• opcache.max_accelerated_files=10000 - дефолтні 2000 файлів закінчуються миттєво на WooCommerce
• opcache.revalidate_freq=60 - на бойовому сайті перевіряти зміни раз на хвилину цілком достатньо
• opcache.validate_timestamps=0 - на продакшені можна вимкнути перевірку змін файлів повністю (але після деплою потрібен ручний скид кешу)

JIT-компіляція у PHP 8.x: маркетинг чи реальна перевага

Коли у 2020 році анонсували JIT (Just-In-Time компіляцію) у PHP 8.0, інтернет вибухнув ентузіазмом. «PHP тепер як C!» - писали у заголовках. Реальність трохи тверезіша.

JIT дає помітний приріст на обчислювально важких задачах: математика, обробка зображень на льоту, генерація PDF, машинне навчання на PHP (так, таке існує). Для типового WordPress або Laravel-сайту, де основне навантаження - це звернення до бази даних і відправка HTML клієнту, JIT дає від 0 до 5% приросту.

Чи варто вмикати? На PHP 8.3 - так, навіть заради тих 3-5%. Але якщо у вас обмежена оперативна пам'ять на VPS - JIT з'їдає додаткові мегабайти. На shared-хостингу ви, найімовірніше, просто не маєте доступу до цього налаштування.

Головний висновок: сама по собі версія PHP - це найлегший і найдешевший спосіб прискорити сайт. Нуль доларів. П'ять хвилин. Результат - видно в Google PageSpeed, у часі відповіді сервера (TTFB), у конверсії і навіть у позиціях видачі. І при цьому - це інструмент, який 60% вебмайстрів ігнорують роками.

Тож ось вам просте завдання на сьогодні: зайдіть у панель хостингу, подивіться на версію PHP вашого сайту і чесно запитайте себе - а ви точно їдете не на першій передачі?