Фраза «картинка тормозит страницу» слишком широка, чтобы её исправить. Проблема может скрываться в лишнем исходнике для маленького slot, отсутствии зарезервированного места, неверной композиции первого экрана или предположении о browser priority без trace. Цена общей формулировки — опасный релиз: одновременно меняются CDN variant, CSS и атрибуты, а после этого никто не может объяснить, что помогло или что сломало доступный кадр.
Начать нужно не с benchmark и не с обещания конкретной метрики. Возьмите один URL страницы, один viewport, один media slot и одно наблюдение пользователя. Затем отделите проверяемые поля component contract от того, что действительно увидел браузер. Учебная fixture этой партии проверяет только порядок локальных labels. Она не открывает страницу, не получает response и не выдаёт число за LCP или CLS.
Карточка расследования до первой правки
| Поле | Пример записи | Почему нужно | Чего не утверждает |
|---|---|---|---|
| Slot | product-card/main-image | ограничивает область изменения | что все изображения страницы одинаковы |
| Geometry contract | 960×540, источник в данных карточки | даёт ожидаемую рамку review | реальный CSS box и отсутствие shift |
| Intent | critical-candidate или deferred-candidate | объясняет ожидание команды | расписание browser scheduler |
| Observation conditions | browser, viewport, cache state, route | делает повторный прогон сопоставимым | универсальный эффект во всех средах |
| Rollback | вернуть прежний source mapping | ограничивает риск правки | отмену уже увиденного пользователем состояния |
Три похожих симптома, три разные проверки
Поздний hero проверяется не тем же способом, что и скачок layout. Для hero сначала посмотрите, какой slot продукт считает главным, какой source ему сопоставлен и какие конкуренты были в конкретном browser report. Для скачка сначала проверяется geometry contract и фактический DOM/layout выбранного сценария. Для «неверного priority» сначала уточняется, что означает это слово: product intent или факт, замеченный в trace. Одно измерение не закрывает все три вопроса.
Полезно заранее записать и отрицательный результат. Например: «в component data dimensions есть, но при открытии фильтра slot меняет контейнер; вывод о причине не сделан». Такая запись лучше красивого диагноза, потому что она не превращает гипотезу в релизное решение. Сначала ограничивается неисправность, потом выбирается один эксперимент. Это особенно важно для изображений: они одновременно касаются content, CSS, доставки и доступности.
# Запускает только учебную in-memory модель Node.js.
node web/scripts/upgrade-2022-08.mjs --verify-fixture
# PASS fixture: 14/14 assertions
# Нет DOM, CSS layout, сети, decode(), PerformanceObserver, LCP или CLS.Команда может добавить этот fixture рядом с данными или reducer, чтобы не потерять простую границу: нельзя declared decode до declared load; геометрия принимается отдельно; record внешнего наблюдения не делает realMetricMeasured истинным. Но fixture не заменяет полевой разбор. Если она PASS, это значит только, что локальный contract не назвал свою собственную строку браузерной метрикой.
Проверка геометрии без ложного обещания CLS
Зарезервированная geometry — хороший кандидат на маленькую правку, потому что у неё есть конкретный owner. В data contract можно отклонить нулевую ширину или высоту, показать fallback и не допустить, чтобы component молча получил неизвестную рамку. Но это не завершённый вывод о layout shift. Реальная страница содержит шрифты, контейнеры, соседние блоки и разные ветви состояния. Проверить их можно только через фактическую разметку и условия запуска.
Если geometry добавляется в API впервые, rollback должен быть простым: вернуть прежнюю обработку конкретного slot и не удалять evidence packet. Не используйте откат как способ скрыть дефект: если прежний путь снова даёт скачок, он остаётся известным состоянием задачи. Следующая итерация меняет другую, явно названную причину — например контейнер или источник ratio, — а не все слои сразу.
Проверка источника и priority без волшебного атрибута
Для правильного источника недостаточно назвать меньший файл «лучшим». Slot может требовать другой crop, плотность, формат или доступный fallback. Сопоставьте resource-to-slot в одном месте и проверьте, что alt относится к содержанию, а не к имени файла. Если источник меняется, зафиксируйте, какой визуальный и content result ожидается; иначе откат будет невозможен, потому что новый файл окажется «оптимизацией» без критерия пригодности.
Priority intent полезен как вопрос к архитектуре страницы: почему этот ресурс critical, а следующий deferred? Но ответ о фактическом порядке лежит в browser observation, а не в строке config. Даже датированный LCP draft не превращает product label в measurement. Поэтому report должен отделять: «мы задали такое намерение» и «в таких условиях увидели такой сигнал». Между ними остаётся место для других ресурсов, браузерной версии и cache state.
Маршрут: симптом → причина → проверка → действие
- Симптом. Запишите одно воспроизводимое наблюдение и его условия. Не начинайте с общего «нужно улучшить скорость».
- Причина. Составьте список возможных слоёв: source mapping, declared geometry, page composition, application intent или platform behaviour. Не выбирайте виновника по заголовку DevTools.
- Проверка contract. Проверьте component data и fixture: есть ли markup, положительная geometry, явный intent и отсутствует ли ложный metric claim.
- Проверка браузера. Зафиксируйте browser/version, route, viewport, cache state и trace. Назовите отдельно факт и интерпретацию.
- Действие. Внесите одну обратимую правку: geometry, source mapping или page composition. Сохраните прежнее значение для rollback.
- Повтор. Прогоните тот же сценарий. Если гипотеза не подтверждена, откатите одну правку и расширьте evidence, а не добавляйте следующую оптимизацию поверх неё.
Пример границы для code review
На review стоит задать несколько коротких вопросов. Где у slot живут dimensions? Откуда они берутся и что происходит, если их нет? Почему этот ресурс находится в early path? Каким наблюдением это проверялось и где лежат условия? Какой один mapping будет возвращён, если результат неверен? Эти вопросы не требуют сложной платформенной теории, но не дают превратить optional attribute в неподтверждённое performance обещание.
Ответ «проверили локально» недостаточен, если не указан слой. Локально можно проверить object и component render; в браузере — конкретный page state; в аналитике — выбранный сбор событий. У каждого слоя своя ошибка и свой владелец. Эта статья сознательно не приводит выдуманный trace или изменение процентов: без реального артефакта такие цифры только мешают отличать рабочую гипотезу от удачного пересказа.
Историческая граница августа 2022
В источниках используется датированный W3C First Public Working Draft LCP от 24 мая 2022 года и HTML 5.2 Recommendation от 14 декабря 2017 года. Первый документ описывает API наблюдения и его ограничения; второй — platform-level разметку. Ни один из них не доказывает поведение конкретного CDN, браузера или продукта. Labels critical-candidate, deferred-candidate и teaching tokens принадлежат только этой модели.
Ограничение и следующий шаг
Пакет не покрывает video, audio, background images, preload, lazy loading, srcset, image decode errors, server components, CDN transformation, field telemetry и доступность реального UI. Он также не задаёт target LCP/CLS, потому что без продукта, аудитории и среды это были бы произвольные числа. Не добавляйте такую цифру в задачу, пока не определён метод и условия наблюдения.
Следующий шаг — провести один разбор по таблице и сохранить короткий report рядом с изменением. Если slot действительно требует новой geometry или source, добавьте соответствующий unit test. Затем отдельно повторите browser-прогон. Если есть расхождение, это не повод переписать историю: обновите гипотезу, откатите узкую правку и оставьте trace как вход следующей итерации.
Проверяемые источники
- Largest Contentful Paint, W3C First Public Working Draft от 24 мая 2022 года — датированный первичный документ. Он определяет API наблюдения candidate largest contentful paint и отдельно перечисляет его ограничения; fixture ниже этот API не вызывает и LCP не измеряет.
- HTML 5.2, W3C Recommendation от 14 декабря 2017 года — неизменяемая нормативная версия, доступная в августе 2022 года. Она задаёт элемент img и его атрибуты; проектные labels, операции модели и выводы о метриках в ней не определены.