PHP для бизнеса: какие задачи стоит решать на этом языке

Любой разговор о PHP неизбежно сталкивает противоположные точки зрения. Для одних это фундамент современного веба, для других — технология, давно оставшаяся в прошлом. Нам, как и многим, непросто сохранять объективность: с PHP нас связывает многолетний опыт. Но с момента публикации первой версии этого обзора в 2020 году многое изменилось — и в самой технологии, и на рынке разработки. Пошатнулась ли наша вера в PHP? Предлагаем разобраться, что изменилось за эти годы, и ответить на главный вопрос: остается ли PHP разумным выбором для новых проектов с точки зрения бизнес-задач.

Что такое PHP простыми словами

PHP — серверный язык программирования. Когда вы открываете сайт, где\-то на сервере PHP собирает страницу: достает данные из базы, подставляет их в шаблон и отдает браузеру готовый HTML. Именно для этого язык и создавался — генерировать веб\-страницы под каждый запрос.

Сегодня PHP остается самым распространенным серверным языком публичного веба. По данным W3Techs (март 2026\) на нем работает 71,8% сайтов, кратно больше любого конкурента, хотя этот показатель с каждым годом немного уменьшается. Поклонники PHP часто переиначивают эту цифру, говоря, что на PHP держится чуть ли не весь интернет, однако это не так: за кадром остается ИТ в закрытых контурах: корпоративные системы, банковский и промышленный бэкенд, где правят Java, C\# и Python.

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

Язык не планировался, и это многое объясняет

В 1994 году датский программист Расмус Лердорф написал несколько скриптов на C для подсчета просмотров его онлайн-резюме. Набор он назвал Personal Home Page Tools. Никакого замысла создать язык программирования не было, только конкретная бытовая задача.

Сам Лердорф позже говорил о себе так: «Я не настоящий программист. Я просто соединял вместе вещи, которые работали». Эта фраза многое объясняет в характере PHP. Язык вырос не из академического проекта и не из корпоративной лаборатории, а из практической нужды одного человека. Как мы увидим дальше, вся природа технологии пропитана подходом «лишь бы работало».

Дальнейшим толчком послужил открытый код. Лердорф выложил скрипты в общий доступ, разработчики начали их дополнять, и набор утилит постепенно превратился в язык. В 1997 году два студента из Хайфы, Энди Гутманс и Зеев Сураски, полностью переписали движок, так как старая версия не годилась для интернет-магазина, который они разрабатывали. Так появился PHP 3, а Гутманс и Сураски основали компанию Zend, которая по сей день стоит за движком языка.

Разрыв между тем, чем PHP был и чем стал, виден даже в названии. Сначала аббревиатура означала «Personal Home Page, личная домашняя страница. Сегодня она расшифровывается рекурсивно: «PHP: Hypertext Preprocessor», PHP: препроцессор гипертекста. От утилиты для резюме до серверного движка половины интернета.

Даже брендинг технологии случаен. В 1998 году французский дизайнер Венсан Понтье разглядел в буквах P-H-P силуэт слона, если смотреть сбоку. Нарисовал и выложил на сайт для скачивания. Файл назвал elePHPant, просто как каламбур.

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

Управление без управления: кто стоит за PHP

PHP проект с открытым кодом без единого корпоративного владельца. Язык развивает PHP Group, неформальное сообщество разработчиков. Коммерческий интерес есть у Zend (принадлежит Perforce), но контроля над языком у компании нет. Решения принимаются через RFC (Request for Comments): любой может предложить изменение, за который голосуют мейнтейнеры ядра. Нет четкой бизнес-стратегии, нет приоритетов, только консенсус энтузиастов.

Отсюда показательная история в биографии языка: версия PHP 6, которая так и не вышла. Сообщество несколько лет разрабатывало нативную поддержку Unicode, уперлось в непреодолимые технические проблемы и около 2010 года тихо похоронило ветку. Следующей версией стала не 6, а сразу 7, цифру пропустили насовсем, чтобы не путать пользователей, так как уже была гора статей, написанных про несуществующий релиз. Это прямое следствие модели управления: масштабная инициатива несколько лет двигалась к тупику, и остановить ее заранее было некому.

Справедливости ради, после этого провала язык реабилитировался. PHP 7 в 2015 году стал переломным: производительность выросла вдвое, потребление памяти упало вдвое, что закрыло главные претензии критиков на тот момент. PHP 8 в 2020 году добавил JIT-компиляцию и подтянул язык к скорости компилируемых технологий (разбор Zend). То есть технически современный PHP, объективно стабильный и быстрый язык. Проблема не в производительности движка, а в том, что у языка нет единого вектора развития.

Свежий пример той же болезни — многопоточность. На момент публикации первой версии этой статьи, настоящую многопоточность анонсировали как ближайший прорыв, сопоставимый по значимости с появлением ООП в PHP 5. Мы, как и все сообщество, в это верили и ждали. Но случилось то, что случилось: спустя больше пяти лет прорыва так и нет. Появились файберы, но это не та многопоточность, которую обещали; ключевой RFC про нативную асинхронность в конце 2025 года отклонили, а рабочая реализация до сих пор живет экспериментом вне ядра. Для нас это несбывшееся ожидание стало одним из поводов всерьез присмотреться к альтернативам, где конкурентность не «обещают в следующем релизе», а она просто есть.

Особенности экосистемы: два разных лагеря

Внутри PHP сообщества два почти не пересекающихся мира. И это второй ключ к пониманию, почему вокруг языка столько противоречий.

Первый лагерь — CMS, готовые системы управления сайтом. WordPress, Joomla, Drupal, в России — «1С-Битрикс». Здесь разработчик почти не пишет код с нуля: ядро CMS берет на себя сложные операции, а нужный функционал собирается из готовых модулей и плагинов. Эти платформы сами по себе являются обширными экосистемами и неплохо подходят для стандартных задач: с их помощью создают интернет-магазины, новостные порталы, корпоративные сайты. Порог входа низкий, типовой сайт запускается быстро.

Второй лагерь — фреймворки: Laravel, Symfony, Yii. Это инструменты для тех, кто пишет нестандартную бизнес-логику, под которую коробочные CMS не подходят. Здесь нужны полноценные навыки программирования: архитектура, паттерны, тестирование. Как правило типичный сценарий выглядел так — запустились на CMS, столкнулись с проблемами масштабирования, переписали с нуля на фреймворке.

Как так вышло, что они разошлись настолько далеко? Из-за разного порога входа. PHP было легко начать использовать, и язык притянул огромную массу людей, которым хватало уровня «настроить готовую CMS». Параллельно те, кто решал сложные задачи, строили вокруг языка серьезную инженерную культуру с фреймворками. Два сообщества выросли рядом, но у них разный инструментарий, разные задачи и, как увидим дальше, разное отношение друг к другу.

Устаревание CMS

Коробочные CMS на PHP по сегодняшним меркам в большинстве случаев — вчерашний день. Их архитектура родом из эпохи, когда сайт был набором серверных страниц: бэкенд, фронтенд и админка слиты в один монолит, обновления болезненны, кастомизация упирается в потолок платформы.

Современная альтернатива — headless-подход. Идея в том, чтобы отделить «внутренности» (управление контентом, товарами, заказами) от «витрины» (то, что видит пользователь). Контент отдается через API, а интерфейс собирается отдельно — на современном фронтенде вроде React или Next.js.

Для контентных сайтов это headless-CMS, например Strapi. Для интернет-магазинов — движки вроде Medusa: обе платформы написаны на Node.js. Headless-связка дает то, чего коробочные CMS дать не могут: фронтенд и бэкенд развиваются независимо.

Стагнация PHP-фреймворков

Если CMS-ландшафт устарел медленно и предсказуемо, то с фреймворками история турбулентная. За 30 лет вокруг PHP сменилось несколько поколений инструментов, и это хороший индикатор того, на чем рискованно строить вдолгую. Одни умерли, другие сменили имя, третьи годами не могли выпустить новую версию.

Когда-то популярный Kohana, легкий HMVC-фреймворк, сегодня официально не поддерживается. CodeIgniter пережил забвение и перезапуск новой командой, однако вернуть прошлые позиции не смог. CakePHP также ушел из мейнстрима. Zend Framework в 2019 году передали под управление Linux Foundation и переименовали в Laminas, старые пакеты заархивированы на GitHub и помечены как «заброшенные» на Packagist. Третью версию Yii ждали почти семь лет: разработку Yii начали еще в 2018, а релиз состоялся только в декабре 2025 года, причем архитектуру переделали радикально, вместо единого репозитория полторы сотни независимых пакетов, что значит обновления легаси проектов на нем бессмысленно. Каждый из этих фреймворков в свое время был «правильным выбором» и ни один из них себя не оправдал на длительной дистанции.

Как обстоят дела с лидерами последних лет, Laravel и Symfony? Формально они под активной поддержкой: Laravel выпускает мажорную версию ежегодно, Symfony дошел до 8-й. Но если посмотреть, что внутри этих релизов, складывается ощущение стагнации. Laravel 12 (2025) в собственных примечания к релизу назван «относительно незначительным обновлением для технического обслуживания». Laravel 13 (март 2026\) — снова с акцентом на стабильность, а не новые возможности. Symfony пошел еще дальше: по официальному блогу проекта, Symfony 8.0 — это «Symfony 7.4 минус deprecations», то есть обе версии содержат ровно один и тот же набор функций, мажорный релиз свелся к вычистке устаревшего кода. Принципиально нового в последних версиях нет, в основном перетасовка, исправления и подчистка. Это очевидный признак того, что вместе с языком стагнируют и его флагманские фреймворки.

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

Экономика обновлений: почему отставание на три версии означает «переписать заново»

Из нестабильной дорожной карты языка и турбулентности фреймворков вытекает практическое следствие, которое мы видим на собственных проектах. Специфика PHP-экосистемы такая: если проект отстал от актуальных версий, языка или фреймворка, на два\-три мажорных релиза, обновление перестает быть обновлением и превращается в переписывание.

Механика простая. Между мажорными версиями PHP и фреймворков накапливаются ломающие изменения: удаленные функции, измененные сигнатуры, удаленный устаревший код. Подняться на одну версию еще посильная задача; но сами авторы фреймворков прямо предупреждают, что прыгать через версии нельзя, обновляться нужно последовательно, по одному мажорному релизу за раз, иначе будут проблемы. А когда между вашей версией и актуальной лежит три релиза, последовательный апгрейд превращается в длинную цепочку миграций, каждая со своими рисками регрессии и тестированием. Часто перебрать всю эту цепочку по трудозатратам выходит дороже, чем переписать функциональность с нуля на современном стеке.

Это вывод из нашей практики: для бизнеса, который сидит на старом PHP-легаси, «обновиться» и «переписать» по стоимости нередко меняются местами. И если уж все равно переписывать, появляется развилка: остаться на PHP или взять то, что под задачу сегодня подходит лучше. Так перед выбором обновления версий с Laravel 5 и PHP 7 мы вместе с заказчиком выбрали переписать сервис видеомониторинга для торговых судов на Node.js

Стратификация внутри языка и проблема найма

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

Логика расслоения такая. Чтобы настроить готовую CMS, не нужно понимать архитектуру, паттерны проектирования, тестирование — ядро делает сложную работу за тебя. Фреймворк-разработчик пишет бизнес-логику с нуля, отвечает за структуру кода и его поддерживаемость, и видит в CMS-разработке ремесло сборки из готовых блоков, а не инженерию.

Справедливо ли это — отдельный вопрос. CMS-разработка также решает реальные бизнес-задачи, и хороший Битрикс-специалист находится сложно и стоит дорого. Но социально граница существует: снобизм направлен в основном со стороны фреймворков в сторону CMS.

Эта внутренняя стратификация — частный случай большой проблемы, к которой переходим дальше.

Слон в комнате: неудобная правда про угасающую популярность

Возможно, PHP не умирает, но точно стареет. И это для бизнеса важнее, чем любые технические ограничения.

Что произошло. Пока язык в 2010-х думал, куда развиваться, и мучительно проходил болезненные переходы между версиями, рынок не стоял на месте. Появились и завоевали массовую популярность альтернативы: Node.js ускорил разработку, Python забрал работу с данными, Go набрал популярность в хайлоаде. Момент, когда PHP был очевидным выбором для нового проекта, оказался упущен.

Цифры из исследования Perforce 2026 PHP Landscape Report показывают суть проблемы. Больше половины PHP-разработчиков имеют свыше 15 лет опыта с языком. И только 15% — пять лет или меньше. Поколение, выучившее PHP в нулевых, продолжает его поддерживать. Новое поколение язык не выбирает, молодые специалисты заходят в профессию через Python, TypeScript, Go.

Найм стал в 2026 году проблемой номер один для PHP-команд, а для руководителей — главной операционной сложностью. И здесь прямая связь с бизнесом: доступность кадров напрямую влияет на стоимость владения проектом. Когда опытных разработчиков мало, а молодые не приходят, поддержка дорожает, а риски при уходе ключевого человека растут.

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

Есть еще один фундаментальный сдвиг. PHP блестяще решал задачу серверной шаблонизации, собирая под каждый запрос HTML-страницу для браузера. Но веб изменился: появились одностраничные приложения (SPA), фронтенд отделился от бэкенда и зажил своей жизнью. Сегодня почти никто не делает контентные сайты на серверных шаблонах, там, где раньше PHP генерировал страницу целиком, теперь работает API плюс отдельный фронтенд. Задача, ради которой язык создавался, трансформировалась до неузнаваемости, и часть прежнего смысла существования PHP ушла вместе с ней.

Особенности PHP в России: почему язык все еще популярен

В России у PHP есть якорь, которого нет ни в одной другой стране, — «1С-Битрикс: Управление сайтом». Эта CMS на PHP стала фактическим стандартом корпоративного веба примерно с середины 2000-х. Понять, почему PHP здесь живее, чем на мировом рынке, без Битрикса невозможно.

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

Государственное регулирование. Включенность битрикса в Единый реестр российского ПО для госзаказчиков и компаний с госучастием — решающий аргумент: по 44-ФЗ заказчик обязан обосновывать выбор иностранного ПО при наличии отечественного аналога в реестре. Реестровый статус сам по себе снимает вопрос выбора платформы, многие директора и ИТ-руководители берут Битрикс именно поэтому.

В результате в России сложился целый рынок Битрикс-разработки, слабо связанный с мировыми тенденциями.

Крупный бизнес уходит от PHP: как российские технологические компании меняют стек

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

Авито — самый прямой пример ухода. Платформа строилась на PHP-монолите, который к середине 2010-х стал тормозить развитие. Инженеры компании описывали ситуацию открыто: кодовая база старая, поддерживать сложно, на доставку новой функциональности уходит много времени. С 2015 года Авито начал «распиливать» монолит на микросервисы; к 2021 году их стало больше 1500, и основной язык новых сервисов — Go. PHP-монолит при этом все еще жив, полный уход занимает годы.

ВКонтакте переводит сервисы с PHP на Go в рамках перехода к сервисной архитектуре. Один из опубликованных кейсов — миграция сервиса хостинга статики VK Mini Apps, которую команда делала в два захода на протяжении нескольких лет.

ВсеИнструменты.ру (Ви.Tech) публично описали три года переноса высоконагруженных компонентов с PHP-монолита на Go. Главный мотив — производительность на критических участках выросла в десятки раз.

Lamoda — один из первых российских e-commerce игроков, описавших переход с PHP на Go. Причина та же — снижение потребления памяти и CPU.

Отдельно стоит Ozon — это пример не ухода, а сознательного отказа от PHP на старте. Ozon исторически работал на Delphi-монолите, а при переходе на микросервисную архитектуру выбрал Go, а не PHP — публично объясняя выбор тем, что из\-за низкого порога входа в PHP-сообществе много специалистов с небольшим опытом.

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