PHP 7.4 против PHP 8.2 на хостинге: разница в скорости

PHP 7.4 не получает обновлений безопасности с конца 2022 года. Восьмая ветка на тех же запросах работает на 15-30 процентов быстрее, и это заметно на времени генерации страницы. Переключение занимает минуту, а вот проверка совместимости требует тестовой копии.

PHP 7.4 официально устарел в ноябре 2022 года. В 2026-м он вторично устарел: на shared-хостингах часто стоит как опция совместимости со старыми сайтами, а свежие тарифы предлагают только 8.1, 8.2, 8.3. Многие владельцы сайтов до сих пор сидят на 7.4, потому что когда-то поставили и боятся переключать.

Зря боятся. Разница в скорости заметная, безопасность критично выше, а ломается обычно меньше, чем кажется. Разберу реальные замеры на типичных WordPress и Битрикс, что обновляется автоматически и где приходится править руками.

Почему вообще обновляться

Три причины по убыванию важности.

Безопасность. PHP 7.4 не получает обновлений безопасности с конца 2022 года. Уязвимости, найденные после этой даты, в 7.4 не закрываются. Все хостинги формально пишут на свой страх и риск, и в случае массового CVE отвечать будет владелец сайта.

Производительность. PHP 8.0 принёс JIT, и хотя на типичном веб-приложении JIT даёт скромные 5-10 процентов, общая зрелость интерпретатора выросла. PHP 8.2 на тех же запросах работает на 15-30 процентов быстрее, чем 7.4. На большом WordPress с десятками плагинов это превращается в 100-300 миллисекунд TTFB.

Поддержка плагинов и библиотек. Современные плагины WordPress (Yoast SEO, WooCommerce последних версий, Elementor 3.x) уже требуют PHP 8.0 как минимум. На 7.4 они либо отказываются ставиться, либо работают со скрипом.

Что реально замеряется

Я делал замеры на одном и том же оборудовании, без других изменений, с двумя версиями PHP. Сайты разные, ниже усреднённое.

WordPress 6.4 с темой Astra и пятнадцатью плагинами (Yoast, WP Rocket, Contact Form 7, RankMath disabled, ACF, WooCommerce, ещё штук десять):

• TTFB на главной без серверного кеша. PHP 7.4: 850 мс. PHP 8.2: 620 мс. Разница 27 процентов.
• TTFB на категории WooCommerce. PHP 7.4: 1200 мс. PHP 8.2: 850 мс. Разница 30 процентов.
• TTFB на странице товара. PHP 7.4: 920 мс. PHP 8.2: 670 мс.
• Память на запрос: PHP 7.4 38 МБ, PHP 8.2 32 МБ.

Битрикс 1С (small business) с типичным набором компонентов:

• TTFB на главной без композита. PHP 7.4: 1100 мс. PHP 8.2: 760 мс. Разница 31 процент.
• TTFB на каталоге. PHP 7.4: 1450 мс. PHP 8.2: 1050 мс.
• Память: PHP 7.4 96 МБ, PHP 8.2 84 МБ.

Astro / Next.js / Hugo и другие SSG: PHP вообще не задействован, эти сайты работают через статику, разница 0 процентов. Это к тому, что переход на 8.2 нужен только если у вас PHP-приложение.

Заметил, что прирост на сайтах с большим количеством плагинов больше, чем на лёгких. Причина: PHP 8.x улучшил скорость работы с массивами и объектами, а в плагинах WordPress этих структур данных миллион.

Что ломается при переходе

Главный страх владельцев: обновили версию, сайт упал. Бывает. Но реже, чем рассказывают.

В моей практике из 30+ переходов с 7.4 на 8.2 ничего критически не ломалось в 22 случаях. В 8 случаях были разной степени проблемы, в основном следующие.

Несовместимый плагин (классика)

Плагин использует синтаксис, удалённый в PHP 8: например, передачу null в функцию, которая ожидает строку. На 7.4 это выдавало предупреждение, на 8.2 фатальная ошибка.

Лечение: обновить плагин. Большинство популярных плагинов давно совместимы с 8.x. Если плагин не обновляется (заброшен, авторские права), искать замену или снимать функционал.

Я ловил на проектах: старые версии WPML, забытые плагины ACF Pro 4-й версии, древний Buddy Press, кастомные плагины от подрядчиков, которые писали 7-8 лет назад и забыли.

Стандартные функции, удалённые в 8.x

Из 8.0 убраны: each(), create_function(), mb_strrpos со старой сигнатурой, ряд pdf_* функций. Если в коде темы или плагина они используются, на 8.0+ ошибка.

Лечение: либо обновляем код (each() заменяем на foreach, create_function на анонимные функции), либо ищем обновлённую версию плагина.

Strict types и более строгие проверки

PHP 8 строже относится к смешению типов. Передача строки в функцию, которая ожидает число, теперь даёт TypeError, а не молчаливое преобразование.

Это редко вызывает падения, но иногда выявляет давние баги. Лечится точечной правкой кода.

Проблемы с устаревшими расширениями

Старые версии Битрикса используют расширения, которые в новых сборках PHP отключены: mcrypt, mbstring с опциями старого формата.

Лечение: обновить движок Битрикса до последней версии текущей редакции. На 24 редакции и выше всё работает на 8.2.

Битриксовые тонкости

Битрикс официально поддерживает 8.2 с 2023 года. Старые проекты, не обновлявшиеся годами, могут падать на:

• Старых версиях BitrixMain.bizproc (бизнес-процессы).
• Кастомных компонентах, написанных по старому API.
• Старых плагинах от Маркетплейса, которые автор перестал поддерживать.

Лечение: обновлять движок и компоненты. На свежей версии Битрикс 24.x переход на 8.2 проходит почти безболезненно.

Как переключаться: безопасный план

Никогда не переключайте PHP-версию на проде первым делом. Алгоритм такой.

Шаг 1: тестовая копия

На большинстве хостингов есть staging или просто возможность создать поддомен с копией сайта. Если нет, поднимаете локально через Local by Flywheel, Devilbox или Docker.

Шаг 2: переключите PHP на копии

В панели хостинга меняете версию для конкретной папки или поддомена. Если хостер не даёт раздельной версии, локально поднимаете на 8.2.

Шаг 3: пройдитесь по сайту

• Главная страница открылась.
• Все типовые страницы открылись.
• Админка работает, можно зайти.
• Создание поста / товара / новости работает.
• Отправка заявки с формы работает, письмо приходит.
• Если магазин: добавление в корзину, оформление заказа, оплата (хотя бы тест).
• В логах ошибок нет PHP Fatal Error.
• В фронтенде нет белых экранов и предупреждений.

Логи смотрите в wp-content/debug.log, или в логах хостинга, или включаете WP_DEBUG_LOG = true в wp-config.php.

Шаг 4: исправьте найденные ошибки

Если что-то падает, разбираетесь:

• Ошибка от плагина: ищете обновление, обновляете на копии.
• Ошибка от темы: чините код или сменяете тему.
• Ошибка от ядра CMS: обновляете CMS до актуальной версии.
• Ошибка в кастомной правке: разбираетесь с автором или правите сами.

Шаг 5: переключите прод

Когда копия работает чисто, в часы низкой нагрузки переключаете прод. Сразу проверяете несколько критичных страниц.

Шаг 6: мониторинг

Первые 24 часа смотрите логи ошибок и метрики Метрики (если у вас настроена). Если что-то пошло не так, быстрый откат на 7.4 в панели хостинга. Это редко требуется, но запасной вариант должен быть.

Особенности популярных хостингов

Timeweb

Версии от 5.6 до 8.3 переключаются в панели в Сайты > Версия PHP. Есть отдельная настройка для каждого сайта. Для shared переключение мгновенное, для VPS — после рестарта PHP-FPM.

Beget

В разделе Управление сайтами > Настройки PHP переключается версия. Доступны 7.4, 8.0, 8.1, 8.2. Beget сохраняет старые версии на shared, что удобно для старых проектов.

Reg.ru

Версия меняется в панели. На некоторых тарифах нужно сделать запрос в поддержку. Бывает задержка переключения 5-10 минут.

FirstVDS, Selectel VPS

Здесь обычно настройка через update-alternatives для CLI и через php-fpm.conf для веб-сервера. Если вы на панели типа ISPmanager или FastPanel, всё через интерфейс.

Что дополнительно настроить после перехода

Переход на PHP 8.2 это хороший повод заодно покрутить пару полезных параметров.

OPcache

Включите, если выключен (бывает на старых конфигурациях). Минимум:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

memory_consumption=128 для среднего WordPress, для большого Битрикса может потребоваться 256.

JIT

В PHP 8 есть JIT-компилятор. Для веб-приложений типа WordPress он даёт скромный выигрыш, иногда вообще нулевой. Но бывает заметным на CPU-bound задачах (генерация тяжёлых отчётов, обработка изображений).

Включается:

opcache.jit=tracing
opcache.jit_buffer_size=64M

Если после включения сайт работает стабильнее или нет, считайте это бонусом. Если стало хуже (бывает на специфичных плагинах), отключите обратно.

memory_limit и max_execution_time

С переходом на 8.2 обычно не нужны изменения, но проверьте:

memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 64M
post_max_size = 64M

Этих лимитов хватает для типичного коммерческого WordPress с медиатекой и WooCommerce.

Что делать, если плагин не совместим

Бывает: важный плагин не запустится на 8.2, а замены нет. Несколько вариантов.

Вариант 1: оплатите автору

Если плагин коммерческий и автор живой, иногда дешевле заплатить за разовую совместимость, чем переписывать функционал.

Вариант 2: форкните и поправьте

Если плагин открытый и проблема в одном-двух местах, копируете код в свою папку mu-plugins/, правите, оставляете как кастомное решение. Подходит для маленьких плагинов.

Вариант 3: замена

Каждый функциональный плагин обычно имеет 2-3 актуальных альтернативы. Поищите в каталоге, у активных плагинов в 2026-м совместимость с 8.x уже стандарт.

Вариант 4: оставайтесь на 7.4 и планируйте уход

Если функция критична и заменить нельзя, оставайтесь на 7.4 на отдельной площадке (не на shared, который через год сменит политику и заставит обновляться). Параллельно планируйте замену плагина или сайта в целом.

Сравнение с 8.3 и 8.4

PHP 8.3 (доступен с 2023) даёт ещё 5-10 процентов прироста относительно 8.2. PHP 8.4 (вышел в конце 2024) добавляет фичи языка, но прирост скорости небольшой.

На практике в 2026 году я ставлю клиентам 8.2 как самую стабильную и широко поддерживаемую. 8.3 ставлю на новых проектах и на тех, где проверена совместимость всех плагинов. 8.4 пока редко.

8.2 будет получать обновления безопасности до конца 2025 года, потом цикл закончится. К тому моменту план на 8.3 уже должен быть в работе.

Чек-лист безопасного перехода

• На staging-копии переключена нужная версия PHP (8.2 или 8.3).
• Сайт открывается полностью, без белых экранов.
• Админка доступна, авторизация работает.
• Создание контента (посты, товары) проходит без ошибок.
• Формы отправляют письма.
• Магазин: корзина и оплата работают.
• Логи ошибок на staging пустые.
• Все плагины обновлены до версий, совместимых с 8.x.
• Тема обновлена или подтверждена совместимая.
• Включен OPcache, проверены лимиты памяти.
• Переключение прода в часы низкой нагрузки.
• В первые сутки мониторинг ошибок и трафика.

Когда стоит делегировать

Перевод типичного WordPress-сайта с 7.4 на 8.2 это работа на 2-6 часов: проверка совместимости, обновление плагинов, тест на staging, переключение прода. На сложных Битрикс-сайтах с самописными компонентами до 12-16 часов из-за более тщательной проверки.

Эта работа входит в часовую ставку или в любой из тарифов на /#pricing. Если у вас сайт на 7.4 и страшно трогать, опишите ситуацию через /#contact. Сделаю аудит совместимости с конкретным списком, что обновить, и переведу под мониторингом.

Связанные материалы по скорости и хостингу в /blog/category/speed/ и /blog/category/support/, там есть статьи про TTFB, серверный кеш и выбор хостинга.

Частые вопросы

Стоит ли переходить с PHP 7.4 на 8.2

Стоит. Ветка 7.4 не получает исправлений безопасности, а восьмая быстрее на 15-30 процентов на том же коде. Единственная причина оставаться это несовместимый старый код.

Что ломается при переходе

Старые плагины и темы, которые используют убранные конструкции языка. Ядро актуальных CMS с восьмой веткой совместимо, проблемы приходят со стороны стороннего кода.

Как проверить совместимость

Поднять копию сайта, переключить версию там и пройти по главным сценариям, глядя в лог ошибок. Отдельно проверяют оплату, формы и админку.

Что делать с несовместимым плагином

Обновить его, найти замену или отказаться от функции. Оставаться ради одного плагина на ветке без обновлений безопасности это плохой размен.