Измеряйте перед оптимизацией: рабочий процесс Paul Irish для скорости

Почему сначала оптимизировать обычно пустая трата времени

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

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

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

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

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

Paul Irish и привычка измерять в первую очередь

Paul Irish — один из самых известных голосов в веб‑производительности. Через работу над инструментами браузера и рекомендации по производительности он помог популяризировать простую идею: ваша первая задача — не угадывать, что медленно, а доказать это.

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

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

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

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

Производительность как задача инструментации

Сначала относитесь к производительности как к задаче инструментации: добавьте способы наблюдать за тем, что действительно видят пользователи. Если вы не видите проблему, вы будете спорить мнениями, а не фактами. В этом и есть смысл измерять сначала.

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

• Что кажется медленным?
• Куда уходит время?
• Помогло ли наше изменение?

Обычно вам нужны два типа данных.

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

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

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

Эти сигналы обычно хранятся в нескольких местах: DevTools браузера для лабораторного профилирования, серверные логи и трейсы для бэкенд‑таймингов, и аналитика или RUM‑дашборды для данных реальных пользователей. Например, если оформление заказа кажется медленным, DevTools может показать, что браузер занят рендером большого UI корзины, тогда как логи сервера показывают, что API быстрый. Без инструментации вы можете оптимизировать бэкенд и так и не исправить реальную проблему.

Шаг 1: Установите повторяемую базу

Чтобы измерять перед оптимизацией, нужен надёжный исход. База — это одно и то же действие, измеренное одинаково, в тех же условиях.

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

Далее выберите 1–3 метрики, которые соответствуют пути. Для просмотра страницы обычно берут пару LCP (как быстро отображается основной контент) и TTFB (как быстро отвечает сервер). Для потока вроде оформления заказа фиксируйте время на завершение шага 1 и время ответа API платежа. Слишком много метрик облегчает выборку данных под желаемый результат.

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

• Устройство и браузер (включая версию)
• Сеть (wifi vs 4G, throttling вкл/выкл)
• Состояние кеша (cold vs warm)
• Локация и тестовые данные (регион, тип аккаунта, размер корзины)
• Количество прогонов (например, 5 прогонов и используйте медиану)

Наконец, определите «достаточно хорошо» для вашей аудитории. Например: «LCP < 2.5с на телефоне среднего класса при 4G». Если вы используете Koder.ai, снимок состояния перед тестированием помогает привязать базу к конкретной версии.