MWC 2018
2018
Computex
IFA 2018
Если открыть любой крупный сайт и посмотреть, сколько данных он загружает при первом посещении, можно удивиться: десятки мегабайт кода, сотни запросов к серверу, сложная логика, выполняемая прямо в браузере. Иногда современный веб-сервис весит больше старого десктопного приложения. При этом пользователь все равно может жаловаться: «тормозит».
Почему веб стал таким сложным? Виноваты ли React, Vue и Angular? Что происходит в споре SPA и SSR? И почему зеленый отчет Lighthouse не гарантирует хороший пользовательский опыт?
3DNews поговорил с Владиславом Мещеряковым, senior frontend-разработчиком и тимлидом. За его плечами работа в продуктовых командах и заказной разработке, а сегодня – участие в создании highload-продуктов в сфере спортивных развлечений, обслуживающих миллионы пользователей, где архитектурные решения напрямую влияют на бизнес.
— Владислав, расскажите, в какой момент веб начал «тяжелеть», на ваш взгляд?
Владислав Мещеряков: Не было одного переломного дня, это была постепенная эволюция. Изначально сайт – это страница с текстом и картинками. Сервер отдает HTML, браузер его показывает и на этом все.
Сегодня веб – это прикладная платформа: он должен мгновенно реагировать, обновлять данные в реальном времени и поддерживать сложные сценарии. Пользователь привык к мобильным приложениям, где все плавно, быстро и интерактивно. Теперь он ждет того же от браузера. Чтобы это обеспечить, логика начала «переезжать» в браузер. Раньше сервер формировал страницу целиком. Сейчас значительная часть вычислений происходит на стороне клиента – в JavaScript. Это автоматически увеличивает объем кода и сложность системы. В highload-продуктах фронтенд уже не просто «отображает», а становится частью вычислительной системы.
— То есть виноват не React?
Владислав Мещеряков: React и другие фреймворки – это скорее ответ на проблему, а не ее причина. Когда интерфейс состоит из сотен элементов, которые зависят друг от друга, нужна система управления состоянием – механизм, который отслеживает, какие данные изменились и какие части интерфейса нужно обновить. Именно для этого появились React, Vue, Angular.
Они добавляют вес – да. Но без них управлять сложностью современных интерфейсов было бы почти невозможно. Ключевой фактор – рост бизнес-требований. Современный веб обслуживает миллионы пользователей, интегрируется с аналитикой и внешними API, выдерживает пиковые нагрузки. Это уже инфраструктура, а не просто сайт.
В многопользовательских, широкофункциональных продуктах фокус неизбежно смещается с выбора инструментов на архитектурные решения в целом. Именно они, а не сам факт использования фреймворка, чаще всего определяют устойчивость, масштабируемость и управляемость системы.
— Если говорить честно: насколько React, Vue или Angular утяжеляют проект?
Владислав Мещеряков: У них есть измеримая цена. Подключая фреймворк, мы загружаем не только свой код, но и его рантайм, систему реактивности, роутер и инструменты управления состоянием. В результате даже базовый «пустой» проект может весить сотни килобайт или больше. Десять лет назад это считалось большим веб-приложением.
Но важно понимать масштаб. В реальности проблемы производительности чаще возникают не из-за самого фреймворка, а из-за архитектурных решений: хранится слишком много данных в глобальном состоянии; интерфейс перерисовывается чаще, чем нужно; подключаются тяжелые сторонние библиотеки; не используется code-splitting – разделение кода на части, которые загружаются по мере необходимости; отсутствует ленивая загрузка компонентов.
В заказной разработке я видел, как проект «раздувается» из-за отсутствия архитектурной стратегии. В продуктовой разработке, где система живет годами и развивается, такие ошибки начинают дорого стоить. И не в теории – в реальных цифрах. Проще говоря, фреймворк – это инструмент. Если им пользоваться без дисциплины, он усиливает хаос.
— То есть он нужен не всегда?
Владислав Мещеряков: Конечно. Если речь о статическом сайте с несколькими формами – React может быть избыточным. Нативный JavaScript будет проще и легче. Фреймворки оправданы там, где: интерфейс живет долго и постоянно развивается; есть сложное состояние; много интерактивности; продукт регулярно масштабируется.
Цена фреймворка становится оправданной тогда, когда стоимость архитектурных ошибок выше, чем размер бандла. В highload-среде это становится особенно очевидно: неправильное решение на старте потом приходится долго компенсировать – через рефакторинг, оптимизацию и переработку архитектуры.
— В чем разница между SPA и SSR – и что побеждает?
Владислав Мещеряков: Если упростить: SPA – это модель, при которой браузер загружает большой JavaScript-файл и дальше обновляет интерфейс без полной перезагрузки страницы. SSR (Server-Side Rendering) – это когда сервер заранее формирует HTML, и пользователь получает уже готовую страницу.
SPA дает богатую интерактивность, но первый экран может появляться медленно – пока загрузится и выполнится весь JavaScript. SSR быстрее показывает контент, но увеличивает нагрузку на сервер и усложняет масштабирование.
В 2026 году серьезные highload-проекты почти не выбирают «или-или». Используется гибрид:
- первый экран и критичные страницы – через SSR или SSG (предварительную генерацию);
- сложная интерактивность и real-time-сценарии – через SPA-логику.
Решает не выбор подхода, а архитектура доставки: CDN, кэширование, code-splitting и грамотная «гидрация», когда серверный HTML «оживает». В продуктах с миллионами пользователей любые просчеты в этой архитектуре быстро становятся заметны – особенно в моменты пиковых нагрузок. Опытный разработчик думает не только о технической корректности решения, но и о том, как система поведет себя под реальной нагрузкой и пиковым трафиком.
— Многие ориентируются на Lighthouse. Почему этого недостаточно?
Владислав Мещеряков: Lighthouse – лабораторный тест, который измеряет загрузку страницы в контролируемых условиях. Но реальный пользователь живет в других условиях.
Во-первых, UX – это не один визит. Это поведение интерфейса во времени. Во-вторых, высокая скорость первого экрана (например, хороший LCP – Largest Contentful Paint, то есть время отображения основного контента) не гарантирует, что интерфейс будет отзывчивым дальше.
Сегодня я больше ориентируюсь на:
- INP (Interaction to Next Paint) – насколько быстро интерфейс реагирует на действие пользователя;
- стабильность в длинных сессиях;
- отсутствие фризов и утечек памяти;
- поведение под реальной нагрузкой.
Можно «перекрасить» отчет, но нельзя обмануть миллионы пользователей, если интерфейс начинает лагать. Хороший UX – это когда пользователь не думает о производительности вообще.
— «Веб тяжелый» – это трагедия?
Владислав Мещеряков: Скорее взросление. Мы требуем от веба того же, что от мобильных и десктопных приложений. Веб сложнее, потому что задачи сложнее. Проблема не в размере, а в отсутствии системного подхода. В высоконагруженных продуктах очень быстро понимаешь: хаос в архитектуре становится дорогим. Тяжелым веб делает не React, а отсутствие дисциплины. А дисциплина – это уже не вопрос технологий, а вопрос инженерной культуры и профессиональной зрелости разработчика.