Каждый год кто-то объявляет, что PHP всё, и каждый год огромная часть веба продолжает работать на нём — включая большинство новостных порталов и интернет-магазинов, с которыми я работаю. И дело не в ностальгии. Создав системы контента и электронной коммерции для более чем 200 продакшен-сайтов, я вижу, как PHP 8.2 продолжает побеждать в той самой битве, которая действительно важна для этой сферы: выпуск стабильного, быстрого сайта с серверным рендерингом, который небольшая команда может поддерживать годами без полного переписывания.

Это не хайповая статья в духе «PHP теперь на самом деле крут». Это конкретные причины, почему скучная, типизированная среда выполнения, работающая по принципу «один запрос на страницу», всё ещё остаётся правильным выбором по умолчанию для CMS в сфере новостей и электронной коммерции в 2026 году — а также честный разбор ситуаций, когда это не так.

Реальная нагрузка, а не синтетические бенчмарки

У новостных сайтов и e-commerce очень специфичный профиль:

  •  Преобладание чтения, отличная кэшируемость (Read-heavy, cache-friendly). Большинство посетителей анонимны и смотрят одну и ту же статью или страницу товара. Всё, что вам нужно — отрендерить HTML на сервере, жестко его закэшировать и не мешать.
  •  Специфика пиковых нагрузок (Spiky). Горячая новость или маркетинговая акция могут увеличить трафик в разы за считанные минуты. Среда выполнения должна деградировать грациозно, а не падать.
  •  Долговечность. Такие сайты живут по 5–10 лет. Команда, которая поддерживает их на шестой год, редко бывает той же, что создавала их в первый.
  •  Критичность для SEO. Для новостей попадание в Google Новости и быстрый Largest Contentful Paint — это не просто приятные бонусы, это основа бизнеса.

Модель исполнения PHP подходит под эти требования почти идеально. Каждый запрос начинается с чистого листа, делает свою работу и умирает. Никаких долгоживущих процессов, накапливающих утечки памяти, никакого общего мутабельного состояния, о котором нужно думать между запросами. Для страницы, которая читает из базы данных, рендерит шаблон и возвращает HTML, архитектура «shared-nothing» — это фича, а не ограничение.

Что на самом деле дал нам 8.2

Переход от мышления времён PHP 5.x/7.x к 8.2 кардинально изменил читаемость кодовой базы. На практике основной вклад вносят всего несколько возможностей.

Свойства   readonly  сделали value objects надежными. В CMS передается множество мелких неизменяемых объектов — обработанная статья, цена с валютой, узел категории. Возможность сказать на уровне языка «это не может измениться после создания» устраняет целый класс багов типа «кто это изменил?».

 final class Money
{
    public function __construct(
        public readonly int $amount,      // minor units (kuruş/cents)
        public readonly string $currency, // 'TRY', 'USD'
    ) {}

    public function withVat(int $ratePercent): self
    {
        return new self(
            (int) round($this->amount * (100 + $ratePercent) / 100),
            $this->currency,
        );
    }
}
 

Никаких сеттеров, никаких случайных мутаций тремя уровнями глубже, а денежная математика остается в целочисленных копейках/центах там, где ей и место.

 Enums (появились в 8.1, но окончательно прижились в кодовых базах на 8.2) заменили кучу целых чисел вида  const STATUS_DRAFT = 0 , которую тащит за собой любая легаси-CMS. Статус статьи или состояние заказа становятся полноценным типом, который понимают IDE и статический анализатор:

 enum OrderStatus: string
{
    case Pending  = 'pending';
    case Paid     = 'paid';
    case Shipped  = 'shipped';
    case Refunded = 'refunded';

    public function isFinal(): bool
    {
        return $this === self::Refunded || $this === self::Shipped;
    }
}
 

 Продвижение свойств в конструкторе (Constructor promotion) + типизированные свойства убрали лишний шаблонный код, из-за которого старый PHP казался громоздким. Сервисный класс теперь содержит только полезную нагрузку:

 final class ArticleRenderer
{
    public function __construct(
        private readonly TemplateEngine $view,
        private readonly CacheInterface $cache,
    ) {}
}
 

Типы возвращаемого значения   never , классы  readonly  и более строгое приведение типов в совокупности означают, что анализатор типов ловит гораздо больше ошибок еще до того, как код попадет на стейджинг. В долгоживущей кодовой базе это разница между рефакторингом с уверенностью и рефакторингом с молитвой.

Ни одна из этих фич не выглядит кричащей. Но вместе они превращают PHP из «скриптового языка, который приходится терпеть» в «типизированный прикладной язык, у которого к тому же лучший процесс деплоя в вебе».

Серверный рендеринг HTML снова стал конкурентным преимуществом

В течение нескольких лет дефолтным ответом на вопрос «как мне сделать фронтенд?» был JavaScript SPA. Для новостной статьи или карточки товара это почти всегда было ошибочным решением. Вы платили налог в виде размера бандла и сложности, чтобы заново реализовать в браузере то единственное, что сервер и так делает идеально: превращать данные в HTML.

Рендеринг HTML на сервере — нативное поведение для PHP. Добавьте к нему шаблонизатор и немного JavaScript в гипермедиа-стиле для действительно интерактивных элементов (фильтры, бесконечный скролл, обновление корзины), и вы получите:

  • Первоначальную отрисовку, которая не ждёт загрузки JS-рантайма — это отлично для LCP и Google Новостей.
  • HTML, полностью доступный для поисковых ботов и ИИ-скрейперов без необходимости настраивать Headless-рендеринг.
  • Фронтенд, который может поддерживать бэкенд-разработчик, вместо необходимости держать второй полноценный стек.

То, как индустрия заново открывала для себя серверный рендеринг HTML в 2024–2026 годах, с точки зрения разработчика на PHP выглядело как наблюдение за тем, как все возвращаются туда, где этот язык стоял всегда.

Обработка пиков: кэшируйте, а не масштабируйте

Для профиля с преобладанием чтения и резкими всплесками нагрузки в мире PHP есть проверенное решение, а модель выполнения PHP 8.2 делает его изящным:

  1.  Полностраничное кэширование (Full-page cache) для анонимного трафика. Большинство читателей горячей новости не авторизованы и видят одно и то же: отдайте им закэшированную HTML-страницу, даже не обращаясь к базе данных.
  2.  Opcode + предварительная загрузка (preloading), чтобы сам фреймворк не парсился заново при каждом запросе.
  3.  Слой кэширования, включающийся под нагрузкой, вместо того чтобы работать постоянно: обычный трафик ходит в базу за свежими данными, а при пике сайт автоматически переключается в режим агрессивного кэширования.

Поскольку каждый запрос изолирован, вам не нужно защищать состояние прогрева и переживать о повреждении данных между запросами, когда вы ставите перед приложением кэш. Ментальная модель остается простой, а это именно то, что вам нужно в 3 часа ночи, когда статья становится вирусной.

Аргумент в пользу поддержки, который никто не выносит на слайды

Причина, по которой я продолжаю выбирать PHP 8.2 для клиентских проектов, не описана ни в одном ченджлоге:  вы можете передать кодовую базу другому разработчику на 4-й год, и он начнёт приносить пользу уже через неделю.

  • Жизненный цикл запроса очевиден. Запрос пришел, ответ ушел.
  • Деплой — это  rsync  и сброс кэша, а не сложная схема оркестрации.
  • Хостинг доступен везде и стоит копейки, что чрезвычайно важно для региональных новостных сайтов и небольших магазинов.
  • Система типов теперь достаточно хорошо документирует намерения, так что новичок может прочитать сервисный класс и сразу понять, что тот делает.

Для ПО, которое должно пережить своих авторов, эта скучность — самое главное преимущество. «Умная» среда выполнения, которую понимает только её создатель — это обуза для сайта с 10-летней историей.

Где PHP 8.2 — не решение

Честность вызывает доверие. Я не выбираю PHP, если:

  •  Нагрузка долгоживущая и хранит состояние (stateful) — веб-сокет сервер, бэкенд для совместной работы в реальном времени, стриминговый пайплайн. Модель изоляции каждого запроса здесь не подходит; это работа для долгоживущего процесса в другой среде выполнения.
  •  Продукт по своей сути является насыщенным клиентским приложением (rich client app) — графический редактор, инструмент с постоянным интерактивным взаимодействием. Для этого действительно нужен полноценный фронтенд-стек.
  •  Требуются интенсивные вычисления с высокой нагрузкой на CPU. PHP справится, но вы вряд ли останетесь довольны результатом.

Работа с CMS для новостей и e-commerce не относится ни к чему из этого. Это ввод данных, вывод HTML, активное кэширование и поддержка годами. Это домашнее поле для PHP.

Вердикт 2026 года

Выбор языка — это решение о поддержке, замаскированное под техническое. Для контентных и e-commerce систем реальные ограничения, с которыми вы сталкиваетесь: быстрые страницы с серверным рендерингом, предсказуемое поведение при пиковых нагрузках, дешевый и доступный повсюду хостинг, а также кодовая база, которую небольшая команда все еще может понять годы спустя. PHP 8.2 — типизированный, с  readonly , энумами и опкод-кэшированием — попадает точно в каждую из этих точек, не требуя от вас излишней мудрёности.

Вот почему сайты, которые я строю для новостей и e-commerce, по-прежнему начинаются с PHP 8.2, и почему я рассчитываю, что они всё ещё будут работать и поддаваться поддержке спустя долгое время после очередного поста «PHP мёртв». Если вы хотите увидеть, как выглядит современный стек PHP для новостей и e-commerce в продакшене, этому полностью посвящен проект alestaweb.com.

Выбирайте ту среду выполнения, поддержку которой вы сможете позволить себе и на шестой год. Для этой сферы это по-прежнему PHP.