独立站PHP版本升级：兼容性检查、扩展安装与性能提升
一、PHP版本为什么影响独立站性能
WordPress написан на PHP: каждый запрос страницы сначала прогоняется через интерпретатор PHP, который переводит код в машинные инструкции. Чем новее версия PHP, тем быстрее перевод — в PHP 8.x сделана масса низкоуровневых оптимизаций, включая улучшенный OPcache, JIT-компиляцию и оптимизацию управления памятью, поэтому тот же код на 8.2 работает примерно в 2 раза быстрее, чем на 7.4.
这种性能提升对独立站是直接可感知的。一个在PHP 7.4上LCP为3.5秒的站，升到8.2并开启OPcache后，LCP能降到2秒左右，Core Web Vitals直接从红变绿。不需要改主题、不需要换插件、不需要加缓存，只换PHP版本就有这个效果。这是为什么运维团队建议每两年至少升一次PHP版本。
| Версия PHP | Дата выпуска | Окончание поддержки безопасности | Производительность относительно 7.4 | 独立站建议 |
|---|---|---|---|---|
| PHP 5.6 и ниже | до 2014 года | давно прекращена | ниже базовой | категорически нельзя |
| PHP 7.0至7.3 | 2015至2018 | прекращена | около 0,8× | обновите как можно скорее |
| PHP 7.4 | 2019 год | прекращена в 2022 году | базовая 1,0 | переходная версия, обновите скорее |
| PHP 8.0 | 2020 год | прекращена в 2023 году | около 1,5× | работает, но не для долгого использования |
| PHP 8.1 | 2021 год | конец 2025 года | около 1,8× | рекомендуется, стабильная |
| PHP 8.2 | 2022 год | конец 2026 года | около 2,0× | рекомендуется, последняя стабильная версия |
很多独立站还跑在PHP 7.4甚至7.3上，原因是”一直跑得好好的，不敢动”。但7.4从2022年11月起就没有安全补丁了，这意味着发现新漏洞也没人修。对出海站来说，跑在无安全更新的PHP版本上，被黑的风险随时间递增。网站被黑后的清理流程见 Что делать после взлома сайта, а про защиту и бэкапы — в статье Бэкап и восстановление сайта.
II. Проверка совместимости: три обязательных шага перед обновлением
Главный риск при обновлении PHP — не производительность, а совместимость. В PHP 8.x есть ломающие изменения синтаксиса: устаревшие функции, более строгая типизация, изменившееся поведение. Если тема или плагин используют устаревший код, после обновления сайт выдаст белый экран, и даже в админку не зайти.
Перед обновлением нужно сделать три вещи. Первое: обновите все плагины и темы до последних версий — старые версии часто несовместимы с новым PHP, а в новых это обычно уже исправлено. Второе: просканируйте весь код сайта плагином вроде PHP Compatibility Checker и посмотрите, где остались несовместимые конструкции. Третье: переключите PHP на staging-сервере и проверьте все ключевые функции.
| Что проверить | Как проверить | Критерий прохождения | Что делать при несовместимости |
|---|---|---|---|
| Совместимость плагинов | Сканирование через PHP Compatibility Checker | Все плагины без критических ошибок | Найти замену или связаться с автором |
| Совместимость темы | То же самое, сканируем папку темы | В теме нет вызовов устаревших функций | Сменить тему или ждать обновления от автора |
| Версия ядра WordPress | Посмотреть версию WP в админке | PHP 8.2 поддерживается только с WP 6.0 | Сначала обновить ядро WP |
| Расширения базы данных | Проверить в phpinfo, есть ли mysqli | mysqli включён | Установить расширение mysqli |
| Собственный код | Просканировать дочернюю тему и собственные плагины | Нет устаревших функций | Исправить код вручную |
Пример: на одном B2B-сайте стоял старый плагин форм 2019 года, который выдавал ошибку на PHP 8.1. Перед обновлением прогнали Compatibility Checker и увидели, что плагин использует функции mysql_* (устаревшие ещё в PHP 7.0). В этом случае не стоит насильно обновлять PHP: сначала найдите замену (например, WPForms или Fluent Forms), перенесите формы, а потом обновляйте PHP. Как crater решает вопросы совместимости плагинов на сайтах для выхода на зарубежные рынки, читайте в статье Технологический стек crater и четыре собственных плагина.
Контринтуитивный вывод: подсказки о совместимости с PHP в разделе «Здоровье сайта» в админке WordPress часто неточны. Он проверяет только текущие версии установленных плагинов: если у вас стоит последняя версия плагина, но автор не обновил тесты совместимости, админка всё равно покажет, что всё в порядке. Правильно — прогнать сканер самостоятельно, а затем реально проверить всё на staging-сервере, а не полагаться только на подсказки в админке.
III. Выбор версии PHP: 8.1 или 8.2
Какую версию выбрать, зависит от двух факторов: сколько ещё продлится поддержка безопасности и совместимость с вашей экосистемой плагинов. PHP 8.1 поддерживается по части безопасности до конца 2025 года, PHP 8.2 — до конца 2026 года. Для большинства сайтов 8.2 — более надёжный выбор: лучшая производительность и самая долгая поддержка безопасности. Но если какой-то ключевой плагин явно заявляет поддержку только до 8.1, сначала обновитесь до 8.1, а до 8.2 — когда плагин обновится.
Не перескакивайте через версии. Прыжок с 7.4 сразу на 8.2 — это два крупных релиза подряд, а устаревшие функции и изменения синтаксиса накапливаются, поэтому вероятность проблем намного выше, чем при постепенном обновлении. Правильный путь: 7.4 → 8.0 → 8.1 → 8.2. Каждую версию проверяйте на staging, и только если всё в порядке — переходите к следующей.
| Ситуация | Рекомендуемая версия | Почему | На что обратить внимание |
|---|---|---|---|
| Сайт только что создан | PHP 8.2 | Последняя стабильная версия, лучшая производительность | Убедитесь, что все плагины поддерживают 8.2 |
| Старый сайт работает на 7.4 | Сначала 8.1, потом 8.2 | Обновляйтесь пошагово, чтобы снизить риски | Каждую версию проверяйте на staging |
| Устаревшая экосистема плагинов | PHP 8.0 или 8.1 | Лучшая совместимость | Дождитесь обновления плагинов |
| Интернет-магазин | PHP 8.1 | Самая зрелая экосистема | Часть платёжных плагинов несовместима с 8.2 |
| Чисто блоговый сайт | PHP 8.2 | Мало плагинов, хорошая совместимость | Сразу обновляйтесь до 8.2 |
Пример: контентный сайт с пятью плагинами (Yoast, WP Rocket, WPForms, UpdraftPlus, Wordfence). Все эти популярные плагины поддерживают PHP 8.2. В таком случае обновляйтесь до 8.2 прямо на staging, проверьте — и если всё в порядке, переносите на продакшен. Но если на сайте WooCommerce и ещё десяток плагинов для электронной коммерции, лучше сначала остановиться на 8.1: когда 8.2 только вышла, многие плагины для платежей и доставки ещё не были адаптированы.
4. Установка расширений: OPcache и ключевые расширения
Если вы обновили PHP, но не установили OPcache, вы получите лишь половину прироста производительности. OPcache хранит скомпилированный байт-код PHP в памяти, и при следующем запуске тот же код читается прямо оттуда, без повторной компиляции. С включённым OPcache время выполнения PHP сокращается более чем на 50% — это больше, чем даёт обновление с 7.4 до 8.0.
Помимо OPcache, отдельному сайту нужны несколько базовых расширений: mysqli (подключение к базе данных, обязательно для WordPress), gd или imagick (обработка изображений, нужна медиабиблиотеке), intl (мультиязычность и локализация), mbstring (обработка многобайтовых строк, нужна сайтам на китайском). На большинстве хостингов эти расширения установлены по умолчанию, но на shared-хостинге их, возможно, придётся включить вручную.
| Расширение | Что даёт | Обязательно | Рекомендации по настройке |
|---|---|---|---|
| OPcache | Кэш байт-кода PHP | Обязательно, удваивает производительность | memory=256MB, revalidate_freq=60 |
| mysqli | Подключение к базе данных MySQL | Обязательно, зависит ядро WP | По умолчанию |
| gd / imagick | Обработка изображений | Обязательно для медиабиблиотеки | imagick быстрее gd |
| intl | Локализация и мультиязычность | Обязательно для мультиязычных сайтов | По умолчанию |
| mbstring | Многобайтовые строки | Обязательно для сайтов на китайском | По умолчанию |
| curl | Внешние HTTP-запросы | Обязательно, зависит REST API | По умолчанию |
| xml | Разбор XML | Обязательно, RSS и sitemap | По умолчанию |
Ключевые настройки OPcache: opcache.memory_consumption = 256 (МБ), opcache.revalidate_freq = 60 (секунд) — это значит, что после изменения кода проверка повторяется через 60 секунд. В среде разработки установите revalidate_freq = 0, чтобы код перекомпилировался при каждом запросе; на продакшене ставьте 60 секунд, чтобы соблюсти баланс между производительностью и своевременностью обновлений. Лимит памяти PHP (memory_limit) рекомендуется ставить 256M и выше, а на сайтах с большим количеством плагинов — 512M.
OPcache и кэш страниц — это два разных уровня, не путайте их. Кэш страниц сохраняет HTML в файлы, OPcache держит байт-код PHP в памяти. Только вместе они позволяют снизить LCP до минимума. Настройка уровней кэширования — в разделе Трёхуровневая стратегия кэширования для интернет-магазина, целевые показатели производительности — в разделе Оптимизация Core Web Vitals.
V. Порядок обновления и план отката
Обновлять PHP в продакшене нужно в часы низкой нагрузки (с 2 до 4 утра по пекинскому времени) и заранее подготовить план отката. Если в процессе что-то пойдёт не так, за 5 минут вернитесь на старую версию. Не обновляйте днём: сбой ударит по посетителям и заявкам.
| Шаг | Действия | Время | Способ отката |
|---|---|---|---|
| 1. Резервная копия всего сайта | Полная копия файлов и базы данных | 10–30 минут | Копии хранить не менее 7 дней |
| 2. Выбрать часы низкой нагрузки | С 2 до 4 утра по пекинскому времени | — | Определить по логам посещений |
| 3. Переключить версию PHP | Через панель хостинга или SSH | 1–5 минут | Возврат на старую версию — в один клик |
| 4. Проверить ключевые сценарии | Главная, страницы товаров, отправка форм | 10 минут | Белый экран — сразу вернуть старую версию |
| 5. Наблюдать 30 минут | Смотреть логи ошибок и посещаемость | 30 минут | При ошибках немедленно откатиться |
| 6. Очистить OPcache | Перезапустить PHP-FPM или веб-сервер | 1 минута | — |
场景示例：你在宝塔面板或cPanel里把PHP从7.4切到8.1，刷新首页发现白屏。不要慌，第一件事是切回7.4——大部分主机面板切换PHP版本就是点一下的事，10秒切回去。然后看错误日志，找到具体哪个插件报错，解决后再试。不要在白屏状态下反复试，那会让访客一直看到错误页。
После обновления наблюдайте неделю. Смотрите два показателя: появляются ли в логах PHP Fatal Error и вырос ли балл Lighthouse. Если логи чистые, а LCP упал с 3,5 секунды до 2 — обновление прошло успешно. Если появились новые предупреждения PHP, проверьте, не связаны ли они с deprecated в каком-то плагине: на работу они не влияют, но их нужно записать и устранить при следующем обновлении плагина. В регулярном обслуживании проверка версии PHP — обязательный пункт, см.Шесть задач на месяц в период обслуживания сайта. Мониторинг и оповещения — в разделе Мониторинг сайта и оповещения.
FAQ: частые вопросы
Какую версию PHP выбрать для сайта на WordPress?
Что делать, если после обновления PHP сайт показывает белый экран?
Что такое OPcache и обязательно ли его включать?
Можно ли обновлять PHP через версию?
Нужно ли делать бэкап перед обновлением PHP?
Нормально ли, что после обновления PHP метрика LCP не изменилась?
В заключение
В обновлении PHP главное препятствие — не техническое, а психологическое: страх “трогать”. У многих команд сайты уже три года работают на 7.4 и “всё же нормально”, пока после очередного обновления плагина не появится белый экран или сайт не взломают — только тогда вспоминают про PHP. На самом деле обновление PHP — самое выгодное вложение среди всех оптимизаций производительности: не нужно менять код проекта, достаточно переключить версию в панели хостинга и потратить час на проверку основных функций.
Три шага: первый — сделайте бэкап всего сайта и базы данных, затем проверьте совместимость плагинов и темы через Compatibility Checker. Второй — обновляйтесь по одной версии в staging-окружении (7.4→8.0→8.1→8.2) и после каждой версии тестируйте ключевые сценарии. Третий — выкатывайте на продакшен в часы низкой нагрузки, наблюдайте 30 минут и при проблемах сразу откатывайтесь. После этих трёх шагов производительность сайта удвоится, а патчи безопасности будут установлены.
一句可以记住的话：PHP升级是独立站性价比最高的性能操作——从7.4升到8.2快2倍，但前提是先把兼容性测完，一个老插件就能让你白屏。