Профилируйте пользовательский путь перед изменением кода
Выберите один важный маршрут и взаимодействие — например открытие навигации, фильтрацию результатов или отправку формы. Запишите его в панели Performance Chrome DevTools в чистом состоянии браузера. Повторите действие и снимите трассу с ограниченным CPU, а также с машины разработчика; десктопные трейсы могут скрывать работу, которая нарушает работу на менее мощном телефоне.
Используйте трассу для проверки узкой гипотезы, а не для поиска виновного компонента по отчёту по бандлу. В Main flame chart более широкие полосы означают больше времени, а сложенные полосы показывают стек вызовов. Красный треугольник на Task указывает на потенциальный long task — выберите его и следуйте ссылке на инициирующий код. Сохраняйте трассы «до» и «после» для осмысленных изменений.
Записывайте чуть до действия и останавливайте после видимого результата.
Держите маршрут, состояние аккаунта и последовательность действий постоянными.
Присвойте каждому верхнему источнику затрат команду или вендора, которые могут его изменить.
Читать трассу как очередь работы
Long task — это порог для расследования, а не полноценный диагноз. Спецификация W3C Long Tasks фиксирует задачи длительностью 50 миллисекунд и более. Посмотрите, что происходит внутри задачи: это может быть выполнение JavaScript, обработчик события, пересчёт стилей, layout или paint. Стек вызовов показывает, с чего начать; тайминги подсказывают, связана ли проблема с кодом, отрисовкой или сторонним фреймом.
Приоритизируйте затраты, которые повторяются при ценном взаимодействии. Короткий обработчик всё ещё может казаться медленным, если он вызывает layout или стоит в очереди за ранней работой. Трасса — это лабораторное измерение, поэтому подтверждайте исправление на репрезентативных устройствах и, где доступна, с учётом приватной полевой телеметрии.
Парсинг при старте требует иного решения, чем обработчик после касания.
Найдите повторяющиеся паттерны «запись стилей — чтение layout» перед рефакторингом.
Прикрепляйте трассу, сценарий и основные затраты к задаче в трекере.
Отправляйте меньше кода в момент, когда это важно
Составьте инвентаризацию скриптов по маршрутам и назначению. Удалите неиспользуемые пакеты, дубликаты, устаревшие эксперименты и код для функций, которые больше не используются. Затем разделите функции, специфичные для маршрута или редко используемые, чтобы они загружались по необходимости, а не при начальной загрузке. Динамическая загрузка может уменьшить нагрузку при старте, но создать заметную задержку, когда пользователю функция нужна сразу.
Задайте вопрос: нужен ли компоненту полноценный клиентский фреймворк, дублирует ли утилита уже существующую возможность и подойдёт ли статический HTML с небольшим улучшением. Протестируйте запасной вариант для отложенного модуля. Страница должна аккуратно откладывать необязательную функциональность, а не показывать нерабочую кнопку.
Документируйте, какие скрипты разрешены на маршруте и почему.
Рассмотрите такой подход для необязательных редакторов, карт, плееров или аналитических представлений.
Тестируйте аутентификацию, доступность, оплату и заполнение форм; привлекайте квалифицированный обзор, когда затрагиваются элементы управления.
Разбивайте работу, чтобы браузер мог отвечать
Разбиение кода на небольшие функции само по себе не создаёт отдельных задач браузера, если эти функции выполняются синхронно. Для длинного цикла разбейте работу на пакеты, сразу обновите видимое пользователю состояние интерфейса и затем уступите управление перед продолжением. Это позволит браузеру обрабатывать ввод и отрисовку между пакетами.
При поддержке браузером scheduler.yield() позволяет текущей задаче уступить управление и позже продолжить работу; проверяйте наличие этой функции и предусмотрите запасной вариант для неподдерживаемых браузеров. Не уступайте управление после каждой мелкой операции: это создаёт накладные расходы и может увеличить время завершения. Выбирайте границы по результатам измерений, сохраняйте возможность отмены и не допускайте, чтобы устаревшие результаты заменяли более актуальное состояние.
Покажите подтверждение или прогресс до невидимых последующих действий.
Уступайте контроль до того, как измеренная работа станет длинной, а не по одному элементу.
Текущее руководство web.dev не рекомендует новую стратегию, основанную на isInputPending().
Переносите вычисления, а не интерфейс, в воркер
Web Worker выполняет скрипт в фоновом потоке, отдельном от основного потока выполнения. Он подходит для дорогого парсинга, преобразования данных, индексирования поиска и других вычислений, которые не требуют прямого доступа к интерфейсу. Отправляйте определённый ввод, возвращайте определённый результат и оставляйте отрисовку и видимые изменения состояния в основном потоке.
Воркер не универсален. Он не может напрямую манипулировать DOM или использовать Window, а обмен сообщениями обычно копирует данные. Создание воркера, перемещение данных и координация ошибок могут перевесить выгоду от небольшой операции. Измеряйте полное взаимодействие, завершайте ненужные воркеры и проектируйте запасной вариант на случай ошибки воркера.
Начните с вычисления, ввод и вывод которого можно сериализовать и протестировать.
Отбрасывайте результаты, созданные для старого фильтра, маршрута или действия.
Сообщайте о значимом прогрессе через обычный интерфейс.
Управляйте сторонним JavaScript как зависимостью продакшна
Аналитика, реклама, эксперименты, социальные вставки, видеоплееры и виджеты поддержки могут добавлять запросы, выполнение JavaScript, iframes и зависимости. Скрипт вендора может быть необходим, но он находится вне прямого контроля команды приложения и может влиять на производительность, приватность, безопасность и непрерывность. Задокументируйте его назначение, маршруты, условие загрузки, утверждающего, требование согласия и владельца удаления.
Где позволяют условия и контракты, сравните репрезентативную страницу с одним сторонним происхождением и без него. Инструменты производительности покажут дорогое выполнение, payloadы и атрибуцию long task. Оставляйте лёгкую или отложенную интеграцию только если её документированная ценность оправдывает измеренные затраты. Подтвердите работу основного контента и основную транзакцию, когда опциональная зависимость медленная или отсутствует.
Загружайте тег только на тех маршрутах и при тех условиях, где он нужен.
Включайте изменения в менеджере тегов в обзоры по производительности, приватности, безопасности и откату.
Документируйте и тестируйте способ отключения некритичной интеграции.
Сделайте отзывчивость критерием готовности к релизу
Преобразуйте выигрышную трассу в маленькую проверку регрессии для важного сценария. Определите покрываемые взаимодействия, устройство или ограничение CPU, ожидаемый отклик и рецензента. Сочетайте это с ревизией бандлов и сторонних зависимостей, чтобы новый пакет или тег не вернул тихо нагрузку на основной поток.
Status Is UP использует эти доказательства для проактивной оптимизации и безопасной корректировки, а не чтобы заменить мониторинг доступности в реальном времени. Перед изменением с высоким риском подготовьте откат и проверьте критичный поток после релиза. Результаты зависят от устройства, сети, браузера, контента и состояния аккаунта; рассматривайте пороги как защитные ограждения, а не как гарантии.
Требуйте трассы «до» и «после» для общей навигации, оформления заказа, поиска или больших бандлов.
Знайте feature flag, настройку тега или версию деплоя, которая восстанавливает известное хорошее поведение.
Профилируйте заново после крупных релизов, смены вендоров или изменений в наборе устройств.