Компиляторный подход к производительности веб‑приложений: взгляд Rich Harris

Почему некоторые веб‑приложения кажутся медленными даже на хороших устройствах

Пользователи редко говорят о производительности технически. Они говорят, что приложение кажется тяжёлым. Страницы немного задерживаются перед тем, как что‑то показать, кнопки реагируют с опозданием, и простые действия — открыть меню, ввести запрос в поиск или переключить вкладку — подтормаживают.

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

Многое из этого — стоимость выполнения в рантайме. Проще говоря, это работа, которую браузеру нужно выполнить после загрузки страницы, чтобы приложение стало пригодным: докачать JavaScript, распарсить его, выполнить, построить UI, прикрепить обработчики, а затем продолжать делать дополнительную работу при каждом обновлении. Даже на быстрых устройствах есть предел тому, сколько JavaScript браузер выдержит, прежде чем опыт начнёт тяготить.

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

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

Runtime‑тяжёлые vs компиляция на этапе сборки: базовая идея

Большинство фронтенд‑фреймворков помогают делать две вещи: строить приложение и поддерживать UI синхронизированным с данными. Ключевое различие — когда происходит вторая часть.

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

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

Полезная модель для мышления:

• Runtime‑тяжёлый подход похож на отправку инструкции и набора инструментов, а сборку вы выполняете у клиента.
• Компиляция на этапе сборки похожа на отправку уже нарезанных и промаркированных деталей, так что сборка идёт быстрее.

Большинство реальных продуктов находятся где‑то посередине. Компилятор‑первый подход всё ещё отправляет некоторый рантайм (роутинг, получение данных, анимации, обработка ошибок). Рантайм‑тяжёлые фреймворки тоже используют приёмы на этапе сборки (минификация, разделение кода, серверный рендеринг), чтобы снизить работу на клиенте. Практический вопрос — не в том, какая модель «правильная», а какая смесь подходит вашему продукту.

Rich Harris и почему важно «фреймворк как компилятор»

Rich Harris — один из наиболее ясных голосов в движении «compiler‑first» для фронтенда. Его аргумент прост: делайте больше работы заранее, чтобы пользователи качали меньше кода, а браузер выполнял меньше работы.

Мотивация практична. Многие рантайм‑тяжёлые фреймворки продают универсальный движок: логика компонентов, реактивность, диффинг, планирование и вспомогательные утилиты, которые должны работать для любого приложения. Такая универсальность стоит байтов и CPU. Даже если ваш UI небольшой, вы всё равно платите за большой рантайм.

Компиляторный подход меняет модель. Во время сборки компилятор смотрит на реальные компоненты и генерирует тот самый код обновления DOM, который им нужен. Если метка никогда не меняется, она становится простым HTML. Если меняется только одно значение, генерируется только путь обновления для этого значения. Вместо отправки универсальной UI‑машины вы отправляете вывод, адаптированный под ваш продукт.

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

Тем не менее есть компромиссы:

• Некоторые динамичные паттерны сложнее, когда компилятор не может предсказать их на этапе сборки.
• Качество инструментов важнее (скорость сборки, отладка, sourcemap‑ы).
• Конвенции экосистемы могут отличаться, что влияет на найм и повторное использование.
• Рантайм‑хелперы всё равно могут понадобиться, просто меньшие и более целевые.

Практическое правило: если ваш UI в основном предсказуем на этапе сборки, компилятор может сгенерировать компактный вывод. Если интерфейс очень динамичен или плагин‑ориентирован, более тяжёлый рантайм может быть удобнее.

Что на практике улучшается при оптимизации на этапе сборки

Оптимизация при сборке меняет место, где выполняется работа. Больше решений принимается во время сборки, и меньше остаётся для браузера.

Одним из видимых эффектов становится уменьшение объёма JavaScript. Меньшие бандлы снижают сетевое время, время парсинга и задержку до момента, когда страница может ответить на тап или клик. На средних телефонах это важнее, чем многие команды ожидают.

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

Анализ на этапе сборки помогает сильнее «tree‑shaking» и удалению неиспользуемого кода. Выигрыш — не только в меньших файлах, но и в меньшем количестве путей кода, которые браузеру нужно загрузить и выполнить.

Гидратация — ещё одна область, где решения на этапе сборки помогают. Гидратация — это шаг, когда серверно‑отрендераная страница становится интерактивной путём навешивания обработчиков и восстановления состояния. Если сборка может пометить, что действительно требует интерактивности, можно сократить работу при первичной загрузке.

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

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

Где рантайм‑тяжёлые фреймворки всё ещё уместны

Большой рантайм не всегда плохо. Он часто покупает гибкость: паттерны, решаемые в рантайме, множество сторонних компонентов и рабочие процессы, проверенные временем.

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

Рантайм платит за удобство

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

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

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

Когда нагрузка рантайма не является узким местом

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

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

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

Производительность против скорости итераций: реальная дилемма команд

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

Работа над производительностью замедляет цикл, если её делать слишком рано или повсеместно. Если каждый PR превращается в обсуждение микрооптимизаций, команда перестаёт рисковать. Если вы строите сложный пайплайн прежде, чем поймёте продукт, люди тратят время на борьбу с инструментами вместо общения с пользователями.

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

Практический бюджет может включать:

• страница становится пригодной в пределах нескольких секунд на средних телефонах;
• JavaScript на маршрут остаётся в пределах согласованного лимита;
• ключевые взаимодействия (поиск, добавление в корзину, сохранение) реагируют быстро;
• ни одна фича не добавляет больше фиксированного небольшого объёма JS или CSS.

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

Инструменты compiler‑first могут сместить этот компромисс: вы соглашаетесь на чуть более долгие сборки, но уменьшаете работу, которая выполняется на каждом устройстве при каждом визите.

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

Как измерять производительность, не теряясь в деталях

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

Простой стартовый набор:

• первичная загрузка (время до первого пригодного экрана)
• задержка взаимодействия (как долго тап/клик кажется «зависшим»)
• размер бандла (что браузер должен скачать и распарсить)
• задержки API (время ответа бэкенда)

Измеряйте на репрезентативных устройствах, а не только на ноутбуке разработчика. Быстрый CPU, тёплый кэш и локальный сервер могут скрыть задержки, которые проявятся на среднем телефоне по мобильной сети.

Делайте ставку на приземлённость: выберите два‑три устройства, соответствующие реальным пользователям, и запускайте один и тот же сценарий (главная, вход, обычная задача). Повторяйте последовательно.

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

Если метрики ухудшаются, не гадать. Проверьте, что было задеплоено, что блокировало рендер, и куда уходило время: сеть, JavaScript или бэкенд.

Практическая пошаговая схема принятия решения

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

1. Определите поверхности продукта. Разделите маркетинговые страницы, внутри­авторизованный дашборд, мобильную часть и внутренние админ‑инструменты. У каждой поверхности свои пользователи, устройства и ожидания.
2. Установите бюджет производительности. Выберите 2–3 числа, которые будете защищать, например время первой загрузки на среднем телефоне и время одного ключевого взаимодействия (поиск, фильтр, сохранение).
3. Ранжируйте ограничения. Честно оцените приоритеты сейчас: навыки команды, сроки, SEO, правила конфиденциальности и где приложение должно работать.
4. Выберите подход. Компилятор‑первый подходит, когда первичная загрузка и отзывчивость критичны. Рантайм‑первый — когда важна гибкость и скорость итераций. Часто выигрывает гибрид: держите критичные поверхности лёгкими, а тяжёлый рантайм используйте там, где он действительно ускоряет экспериментирование.
5. Провалидируйте тонкий срез, затем закрепите решение. Постройте один реальный пользовательский путь «end‑to‑end», измерьте его по бюджету и запишите выбор и причины.

Тонкий срез должен включать грязные части: реальные данные, авторизацию и самый медленный экран.

Если нужен быстрый способ прототипировать такой срез, Koder.ai (koder.ai) позволяет строить веб, бэкенд и мобильные потоки через чат и экспортировать исходники. Это помогает протестировать реальный маршрут рано и делать эксперименты обратимыми с помощью снимков и откатов.

Документируйте решение простым языком, включая триггеры для пересмотра (рост трафика, доля мобильных, цели по SEO). Это делает выбор устойчивым при смене команды.

Распространённые ошибки команд при выборе по производительности

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

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

Ещё одна ошибка — игнорировать рост бандла до того, как он начнёт мешать. На 200 КБ всё может быть нормально, а пару «маленьких» добавлений позже вы уже шлёте мегабайты. Простая привычка помогает: отслеживайте размер бандлов со временем и относитесь к резким скачкам как к багам.

Команды также по умолчанию делают всё рендерингом на клиенте, даже когда некоторые маршруты в основном статичны (страницы с прайсингом, документация, шаги онбординга). Такие страницы обычно можно отдать с гораздо меньшей работой на устройстве.

Тихий убийца — добавление большого UI‑библиотечного решения ради удобства без измерения его стоимости в продакшн‑сборках. Удобство допустимо; просто ясно понимайте, за что вы платите: дополнительные байты JS, лишний CSS и замедленные взаимодействия на средних телефонах.

Наконец, смешивание подходов без ясных границ создаёт трудно отлаживаемые приложения. Если половина приложения ожидает сгенерированных компилятором обновлений, а другая — полагается на рантайм‑магии, вы получите неясные правила и запутанные ошибки.

Несколько практических ограждений, которые работают в реальных командах:

• Установите бюджет размера бандла для каждого крупного маршрута, а не только для всего приложения.
• Решите, какие маршруты должны быть быстры при первичной загрузке, и делайте рендеринг вокруг этого.
• Добавляйте библиотеки только после проверки их веса в продакшн‑сборке.
• Записывайте границы (какие части оптимизированы компилятором, какие работают через рантайм).
• Пересматривайте решения после появления реальных данных от пользователей, а не раньше.

Реалистичный пример: как выпустить SaaS, не загнав себя в угол

Представьте команду из трёх человек, строящую SaaS для планирования и биллинга. У продукта две стороны: публичный маркетинговый сайт (лендинги, прайсинг, документация) и защищённый дашборд (календарь, инвойсы, отчёты, настройки).

При пути через рантайм‑первый подход они выбирают тяжёлый рантайм, потому что так быстрее вносить изменения в UI. Дашборд становится большим клиентским приложением с переиспользуемыми компонентами, библиотекой состояния и насыщенными взаимодействиями. Итерации быстрые. Со временем первичная загрузка начинает ощущаться тяжёлой на средних телефонах.

При компилятор‑первом пути они берут фреймворк, который переносит больше работы в момент сборки и уменьшает клиентский JavaScript. Общие потоки, такие как открытие дашборда, переключение вкладок и поиск, становятся более отзывчивыми. Компромисс в том, что команде приходится более обдуманно подходить к паттернам и инструментам, и некоторые простые рантайм‑фишки не так просто подключить.

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

Гибрид часто выигрывает. Держите маркетинговые страницы лёгкими (серверный рендер или почти статика, минимум клиентского кода) и принимайте более тяжёлый рантайм в дашборде, где интерактивность окупает себя.

Используя шаги принятия решения: они называют критические пути (регистрация, первый счёт, еженедельные отчёты), измеряют их на среднем телефоне, ставят бюджет и выбирают гибрид. Компилятор‑первое поведение по умолчанию для публичных страниц и общих компонентов; рантайм‑тяжёлый подход только там, где он действительно ускоряет экспериментирование.