![\"Матрица](\"/assets/editorial/2027/performance-capstone-2027-evidence-boundary-matrix.svg\")
Пользователь видит пустой или неполный первый экран. В DevTools рядом с ним растягивается полоса шрифта или изображения. Команда объявляет этот ресурс виновником и меняет порядок загрузки. Через релиз экран не ускоряется, зато появляется лишний preload, вспышка нестилизованного текста или гонка между скриптами. Цена ошибки — не только потерянные миллисекунды. Вы меняете контракт загрузки, не доказав, что страницу действительно задерживал этот запрос.
\nWaterfall показывает время сетевой работы. Он не показывает причинность сам по себе. Ресурс влияет на экран только тогда, когда его результат нужен конкретной зависимости: parser ждёт script, CSS нужен для построения стилей, layout ждёт шрифт, а компонент ждёт данные. Поэтому тезис статьи простой: ищите не самую длинную полосу, а цепочку «инициатор → ресурс → потребитель → наблюдаемый эффект».
\nУ каждой записи ресурса есть временная и причинная часть. startTime говорит, когда запрос начал работу, а responseEnd — когда браузер получил последний байт. initiatorType помогает понять, кто начал запрос: parser, script, css, fetch или другой источник. Эти поля описывают наблюдение. Они ещё не отвечают, ждал ли результат первый экран.
Для причинности добавьте три вопроса. Какой элемент или код потребляет ответ? В какой момент он потребляет его? Что изменится, если ответ придёт позже или не придёт вовсе? Если на последний вопрос нет проверяемого ответа, запись остаётся кандидатом. Её нельзя называть узким местом.
\n| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| CSS заканчивается поздно, первый экран пустой | Стили нужны до первого layout | Сопоставить тег link, DOM и момент первого визуального результата | Уменьшить критический CSS или разделить его, затем проверить layout shift |
| Script начинается рано и долго выполняется | Parser или главный поток ждёт выполнение | Проверить атрибуты, initiator и long task | Применить defer или разбить работу только после проверки зависимостей |
| Шрифт имеет длинную полосу, но контент уже виден | Шрифт не нужен первому экрану или заменяется fallback | Сравнить момент ответа шрифта с визуальным результатом и layout | Не добавлять preload; проверить font-display и потребителя |
| JSON заканчивается поздно, карточки пустые | Компонент ждёт fetch | Найти вызов, состояние ожидания и время отображения данных | Оптимизировать запрос или skeleton, не меняя случайные сетевые приоритеты |
| Одна запись отсутствует в отчёте | Нет поддержки поля, кросс-доменное ограничение или буфер очищен | Проверить браузер, Timing-Allow-Origin и момент чтения | Пометить «нет данных» и выбрать другой сигнал |
Рассмотрим страницу с таким HTML:
\n<head>\n <link rel=\"stylesheet\" href=\"/app.css\">\n <script src=\"/vendor.js\" defer></script>\n <script src=\"/analytics.js\" async></script>\n</head>\n<body>\n <main id=\"catalog\"></main>\n <script src=\"/catalog.js\" defer></script>\n</body>app.css может влиять на первый layout. vendor.js и catalog.js загружаются параллельно с разбором HTML, но выполняются после разбора документа и сохраняют порядок между собой. analytics.js выполняется, когда загрузится, поэтому не должен зависеть от глобального объекта, который создаёт другой script. Его длинная полоса не объясняет задержку каталога, если аналитика не участвует в рендере.
Учебный наблюдатель ниже читает доступные записи после загрузки страницы. Он не меняет сеть и не утверждает, что каждая ранняя запись блокирует экран. Пример предназначен для локальной или тестовой страницы. Он показывает границу данных: если поле не поддерживается, результат будет unknown, а не выдуманный статус.
const navigation = performance.getEntriesByType('navigation')[0];\nconst domEnd = navigation?.domContentLoadedEventEnd ?? Infinity;\n\nconst resources = performance\n .getEntriesByType('resource')\n .filter((entry) => entry.startTime < domEnd)\n .map((entry) => ({\n name: new URL(entry.name).pathname,\n initiator: entry.initiatorType || 'unknown',\n start: Math.round(entry.startTime),\n end: Math.round(entry.responseEnd),\n duration: Math.round(entry.duration),\n blocking: entry.renderBlockingStatus ?? 'unknown',\n }));\n\nconsole.table(resources);Фильтр ограничивает список ресурсами, которые начали работу до DOMContentLoaded. Это удобная граница для первичного поиска, но не доказательство готовности экрана. DOM мог закончить разбор, пока изображение, шрифт или отрисовка ещё продолжаются. Для визуального симптома нужен отдельный браузерный прогон и понятный элемент, который считается первым полезным результатом.
Дальше найдите инициатор в HTML или исходном коде. Для parser проверьте тег. Для script найдите вызов fetch, импорт или создание элемента. Для css проверьте правило и используемый шрифт. Затем назовите потребителя. Формулировка «CSS заканчивается поздно» слишком слабая. Формулировка «карточки не получают стили до первого layout, потому что link указывает на полный файл» уже задаёт проверяемое действие.
preload запускает запрос раньше. Это полезно для действительно критичного ресурса, но лишний preload конкурирует с HTML, CSS и данными. Укажите правильный as и проверьте, что документ использует ответ. Иначе браузер предупреждает о неиспользованной загрузке, а критический путь становится шире.
async освобождает parser, но отдаёт порядок выполнения сети. Он подходит для независимого кода. Если script читает объект, который создаёт другой script, или меняет DOM до инициализации компонента, появится гонка. defer сохраняет порядок отложенных скриптов, но не уменьшает размер файла и не доказывает, что работа главного потока стала короче.
Разделение CSS снижает ранний объём только при точной границе. Ошибка даёт FOUC, неверный порядок правил или layout shift. Отложенный шрифт может убрать блокировку, но изменить переносы строк и высоту блока. Каждое исправление нужно оценивать по тому же потребителю, который породил исходный симптом.
\nОтрицательный путь важен. Если waterfall показывает поздний запрос, но первый экран от него не зависит, остановите оптимизацию этой строки. Если данные недоступны из-за политики браузера, не подставляйте ноль. Если замер меняет состояние кэша, не сравнивайте его с холодным запуском. Честный вывод «причина не доказана» экономит больше времени, чем уверенная правка не того слоя.
\nResource Timing зависит от браузера и политики доступа. Кросс-доменные значения могут быть скрыты без Timing-Allow-Origin. renderBlockingStatus может отсутствовать. DOMContentLoaded не равен FCP или LCP, а локальная сеть не воспроизводит мобильное устройство. Записи Performance API не описывают серверную очередь, весь главный поток и пользовательский опыт одной цифрой.
Учебный код не даёт production-результатов. Его задача — показать форму проверки. Для реального решения нужны повторяемые прогоны в целевых браузерах, сохранённые условия и выбранный визуальный критерий. Не называйте ресурс блокирующим только потому, что он большой, ранний или заметный на скриншоте DevTools.
\nРабота готова, когда для заявленного симптома есть исходная запись и повторяемый критерий, у спорного ресурса найден инициатор и потребитель, одно изменение прошло в тех же условиях, а отрицательный путь тоже описан. После изменения должен измениться именно наблюдаемый симптом или заранее выбранная метрика. Если меняется только длина полосы, расследование не закончено.
\n