Модель измерения производительности сайта

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

В этой серии рассмотрим отдельный проект speed-lab: учебную статью со схемой доставки и карточками материалов. Он напоминает задачи большой библиотеки ProfessorWeb, но не является её измерением. Исходники серии подготовлены для ручного прогона читателем; они не запускались автором. Все числовые примеры ниже специально выдуманы и служат разбору метода.

От действия к измеряемому событию

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

У карточек возникает другая задача. Текст давно показан, но после ввода темы интерфейс не реагирует. Маленький размер HTML здесь ничего не объясняет: задержка относится к обработке взаимодействия. Наконец, картинка способна сдвинуть уже читаемый абзац. Человек теряет место чтения, хотя ресурсы доставлены быстро. Поэтому загрузку, реакцию и устойчивость расположения рассматриваем раздельно.

Для этих сторон пользовательского опыта существуют Core Web Vitals: LCP относится к показу крупнейшего подходящего содержимого, INP — к отклику на взаимодействия, CLS — к неожиданным сдвигам. Текущие ориентиры хорошего результата: LCP не более 2,5 секунды, INP не более 200 миллисекунд, CLS не более 0,1; оценка аудитории использует 75-й процентиль с разделением мобильных и настольных посещений. Это опубликованные пороги, а не наши измерения. Описание Web Vitals.

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

Протокол одного сравнения

В исходниках находятся два варианта: baseline и candidate. Первый намеренно создаёт изображение после искусственного таймера, второй содержит его в HTML. У вариантов также различается обработка карточек. Для начального знакомства можно просмотреть оба целиком. Однако доказать причину изменения позволяет эксперимент, в котором переносится только один приём, а остальные условия сохраняются.

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

Сценарий: обычный переход к статье из новой вкладки
Версия: baseline, затем копия с изображением в HTML
Viewport и DPR: записать фактические значения
Браузер, устройство, профиль сети и CPU: записать
Кеш: холодная доставка; DevTools открыт
Наблюдение: время и элемент LCP, инициатор изображения
Гипотеза: раннее обнаружение запроса уменьшит ожидание ресурса

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

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

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

Повторы и неопределённость

Один запуск способен попасть на занятый процессор, сетевую паузу или прогрев внутреннего состояния браузера. Выполните несколько повторов одного сценария и сохраняйте отдельные значения. Тогда видно, существует ли устойчивое различие или вывод держится на одной удачной попытке. В исходниках есть пустая таблица для ручной сессии; заполненных результатов автора в ней нет.

Рассмотрим выдуманные учебные значения времени: версия A дала 3100, 2800 и 3000 миллисекунд, версия B — 2700, 3200 и 2900. Эти диапазоны пересекаются. По одной лучшей попытке B нельзя заявить, что каждое посещение ускорилось. Следует исследовать разброс, увеличить число наблюдений при необходимости и проверить, действительно ли менялась одна переменная.

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

Из наблюдения в гипотезу

Если картинка появляется поздно, возможны разные причины: поздний запрос, длительная доставка или задержка отображения после загрузки. Уменьшение файла помогает только части этой цепочки. Запишем гипотезу в проверяемой форме: «ресурс начинается поздно, потому что URL создаётся JavaScript; перенос URL в исходный HTML должен изменить инициатора и начало запроса».

Здесь ожидаем не просто меньшее итоговое число, а конкретное изменение механизма. В Network читатель должен увидеть другой момент обнаружения, а в Performance — связь с показом содержимого. Если запрос начинается раньше, но LCP остаётся прежним, гипотеза о позднем обнаружении могла подтвердиться, однако основное ограничение оказалось в другой фазе. Это полезный результат исследования.

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

Сохранение основания вывода

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

При передаче материалов другому разработчику разделите подготовленный стенд и полученный отчёт. Исходники показывают воспроизводимое условие, а отчёт — конкретное выполнение в конкретном окружении. Другой человек способен получить иные времена, сохранив ту же причинную цепочку. Различие чисел требует исследования условий, но не отменяет наблюдение о позднем обнаружении URL. Такой договор помогает обсуждать результат предметно.

К концу этой страницы у вас должна быть одна заполненная формулировка сценария и одна независимая переменная. Не требуется заранее знать, какой приём окажется успешным. Требуется уметь отличить наблюдение от объяснения: «запрос начался раньше» — факт собственной сессии; «это произошло из-за HTML» — вывод, который нужно связать с трассой. Теперь можно изучать инструменты без подмены результата красивым баллом.

Оглавление курса