{
  "index": 208,
  "slug": "editorial-2022-03-field-browser-rendering",
  "title": "Тяжёлый кадр в браузере: как найти причину и проверить обратимую правку",
  "excerpt": "Если интерфейс дёргается, широкий участок Performance trace ещё не объясняет причину. Разбираем один пользовательский шаг через DOM-результат, владельца изменения, узкий диапазон записи и rollback.",
  "contentHtml": "<p>После добавления большого списка простая анимация начинает дёргаться. В панели Performance виден широкий участок главного потока с JavaScript, style, layout и paint. Если назвать весь участок «медленным рендером», команда может удалить нужную мутацию, перенести работу в другой callback или оптимизировать не тот экран. Цена ошибки — потерянный визуальный результат, новый дефект вместо ускорения и повторное расследование после релиза.</p>\n<p>Рабочий порядок начинается с наблюдаемого результата. Сначала зафиксируйте, что изменилось в DOM. Затем свяжите одно действие пользователя с узким диапазоном записи. После этого проверьте одну гипотезу маленькой обратимой правкой. Обсуждать эффект можно только после новой записи, в которой ожидаемый DOM-результат сохранился.</p>\n<h2>Механизм: результат важнее ярлыка в записи</h2>\n<p>Браузер не получает от приложения готовую команду «сделай layout». Код меняет DOM, CSS-классы, inline-стили, текст или геометрию. В стандарте обновление отображения описано как абстрактный алгоритм пользовательского агента; конкретная реализация и запись зависят от браузера. Поэтому слова <code>style</code>, <code>layout</code>, <code>paint</code> и <code>composite</code> помогают сформулировать вопрос, но сами по себе не указывают владельца.</p>\n<p>Владелец находится в коде и в контракте результата. Для примера контракт выглядит так: пользователь отправляет форму один раз; целевая карточка остаётся той же; <code>className</code> меняется с <code>card is-pending</code> на <code>card is-ready</code>; при ошибке класс не меняется; откат возвращает исходное состояние. Если запись стала короче, но класс больше не меняется, оптимизация не прошла функциональную проверку.</p>\n<pre><code>function onSave(card, response) {\n  const before = card.className;\n\n  if (!response.ok) {\n    card.className = before;\n    return { result: 'error', before, after: card.className };\n  }\n\n  const after = 'card is-ready';\n  card.className = after;\n  return { result: 'ready', before, after: card.className };\n}\n\nfunction rollback(card, before) {\n  card.className = before;\n}</code></pre>\n<p>Код учебный. Он не измеряет длительность, не вызывает настоящий сетевой запрос и не доказывает, что браузер нарисовал карточку в конкретном кадре. Его задача — показать границу наблюдения: до оптимизации известны <code>before</code> и <code>after</code>, а у изменения есть явная отмена. В рабочем компоненте тот же контракт нужно связать с реальным обработчиком, состоянием ошибки и снимком DOM.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика одного тяжёлого кадра</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Кнопка отвечает с задержкой</td><td>В запись попали соседние таймеры, сеть или расширение</td><td>Повторить одну отправку формы на чистом экране и найти соответствующее действие</td><td>Отделить диапазон действия от соседних событий</td></tr><tr><td>Запись широкая, причина неясна</td><td>Ищут общий ярлык вместо связи с DOM-результатом</td><td>Сравнить целевой элемент, свойство, исходное и итоговое состояния</td><td>Вернуться к изменению и назвать одного владельца</td></tr><tr><td>После правки график спокойнее, класс не меняется</td><td>Удалили функциональную мутацию вместе с лишней работой</td><td>Проверить итоговое состояние DOM тем же сценарием</td><td>Откатить правку и разделить визуальный результат и оптимизацию</td></tr><tr><td>Появился layout, но действие не меняло геометрию</td><td>Проверяется не тот диапазон или другой код прочитал геометрию</td><td>Найти вызов чтения размеров и его стек</td><td>Проверить одно чтение геометрии, а не весь layout</td></tr><tr><td>Повторная запись даёт другой результат записи</td><td>Изменились CPU, область просмотра, кэш, данные или версия браузера</td><td>Зафиксировать среду и повторить сценарий несколько раз</td><td>Сравнивать только согласованные условия и сохранять запись</td></tr><tr><td>«Улучшение» нельзя отменить</td><td>Не определены старое состояние и путь отката</td><td>Вернуть исходное состояние отдельным запуском и проверить DOM</td><td>Сделать изменение локальным, переключаемым или отдельным коммитом</td></tr></tbody></table></div>\n<h2>Пример: одно действие и один результат в DOM</h2>\n<p>В качестве учебного сценария возьмём форму сохранения карточки. До действия в DOM есть <code>&lt;article class=\"card is-pending\"&gt;</code>. Пользователь нажимает кнопку. Обработчик отправляет данные и после успешного ответа добавляет <code>is-ready</code>. Чтение геометрии сразу после записи стиля — проверяемая гипотеза, а не объяснение исходного случая с анимацией и большим списком. Её нужно подтвердить стеком вызовов и новой записью.</p>\n<pre><code>function updateCard(card) {\n  const before = card.className;\n  card.classList.add('is-ready');\n  const height = card.getBoundingClientRect().height;\n  return { before, after: card.className, height };\n}</code></pre>\n<p>Такой порядок может потребовать дополнительной работы по обновлению стилей и layout, но по одному фрагменту нельзя заключить, что именно он вызвал задержку. Возможно, размер уже был нужен другому коду. Возможно, запись попала в другой пользовательский сценарий. Проверка должна ответить на узкий вопрос: связан ли этот обработчик и это чтение с выбранным участком записи, и сохраняется ли <code>is-ready</code> после изменения?</p>\n<p>Отрицательный путь обязателен. Если сервер вернул ошибку, карточка должна остаться <code>is-pending</code>, сообщение об ошибке должно остаться доступным пользователю, а запись нельзя объявлять успешным только потому, что в нём стало меньше событий. Если выбранный элемент уже имел <code>is-ready</code>, действие может оказаться пустым. Тогда новая запись не проверяет переход состояния: сначала нужно вернуть исходное состояние и повторить сценарий.</p>\n<figure><img src=\"/assets/editorial/2022/browser-rendering-diagnosis-rollback-2022.svg\" alt=\"Схема диагностики тяжёлого кадра: DOM-результат, действие, вопросы к записи, обратимая правка и откат\" loading=\"lazy\" /><figcaption>Учебная схема связывает исходное и итоговое состояние DOM с одним пользовательским действием и одной гипотезой. Ветка пустого действия останавливает разбор, а откат возвращает исходный результат. Схема не является снимком DevTools trace и не содержит рабочих метрик.</figcaption></figure>\n<h2>Как читать Performance panel</h2>\n<p>Начинайте запись на уже подготовленной странице. Выполните одно действие и остановите запись сразу после появления ожидаемого результата. Не включайте в один профиль загрузку, несколько кликов и длинный период ожидания. Чистое воспроизведение не делает измерение идеальным, но уменьшает число несвязанных событий.</p>\n<p>После записи сначала найдите пользовательский шаг, а не самый длинный прямоугольник. В Chrome DevTools этот шаг виден на дорожке Interactions, а выбранное событие на дорожке Main раскрывает длительность, стек вызовов и ссылку на строку исходника. Затем сопоставьте их с обработчиком. Скриншот кадра помогает увидеть, что видел пользователь, но не доказывает причину. Вкладка Summary показывает разбиение работы, а flame chart — порядок событий и стек вызовов. Ни один из этих видов не заменяет сравнение исходного и итогового DOM.</p>\n<p>Если подозрение связано со стилями или геометрией, ограничьте вопрос. «Почему layout длинный?» слишком широко. «Какой вызов прочитал геометрию после записи класса в этом обработчике?» уже можно проверить. Если выбранный диапазон не содержит такого обработчика, остановитесь: запись и код не связаны. Если изменение не даёт ожидаемый результат в DOM, остановитесь ещё раньше.</p>\n<h2>Обратимая правка</h2>\n<p>У первой правки должны быть четыре поля: один владелец, ожидаемое итоговое состояние DOM, способ проверить запись и путь отката. Например, временно вынести одно чтение геометрии из обработчика, локально выключить визуальный эффект через переключатель или изменить один селектор. Не меняйте одновременно рендер списка, кэш, анимацию и порядок сетевых запросов. Иначе новая запись не скажет, какое изменение повлияло на результат.</p>\n<p>После правки повторите тот же сценарий в той же среде. Проверьте две вещи: карточка по-прежнему получает <code>is-ready</code>, а выбранный участок записи изменился так, как предполагала гипотеза. Если DOM сохранился, но запись не подтверждает гипотезу, это отрицательный результат: выберите другого владельца или верните код. Если DOM сломался, откат должен вернуть исходное поведение, а не просто удалить строку из diff.</p>\n<pre><code>const baseClassName = 'card is-pending';\n\nfunction applyForward(card) {\n  card.className = 'card is-ready';\n}\n\nfunction applyRollback(card) {\n  card.className = baseClassName;\n}\n\nfunction assertResult(card, expected) {\n  if (card.className !== expected) {\n    throw new Error(`unexpected DOM result: ${card.className}`);\n  }\n}</code></pre>\n<p>Этот пример проверяет только наблюдаемое состояние. Он не измеряет FPS, не моделирует планировщик и не доказывает отсутствие layout. Решение для рабочего кода требует реальной записи и подходящего набора пользовательских сценариев. Учебный код полезен как каркас вопроса, но не заменяет доказательство.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Опишите симптом.</strong> Запишите действие, видимый сбой и цену ошибки. Например: «после отправки формы карточка появляется с задержкой, а при ошибке состояние остаётся неясным».</li><li><strong>Зафиксируйте контракт.</strong> Сохраните целевой элемент, свойство, исходное состояние DOM, итоговое состояние для успеха и состояние для ошибки. Укажите, что считается пустым действием.</li><li><strong>Подготовьте среду.</strong> Зафиксируйте браузер, область просмотра, ограничение CPU, данные, кэш и наличие расширений. Снимите запись на чистом экране.</li><li><strong>Запишите одно пользовательское действие.</strong> Выполните один шаг. Остановите запись сразу после видимого результата. Не смешивайте несколько гипотез.</li><li><strong>Свяжите запись с кодом.</strong> Найдите обработчик, изменение и выбранный диапазон. Если связи нет, не называйте причину.</li><li><strong>Сформулируйте гипотезу.</strong> Назовите одного владельца и один проверяемый вопрос: например, влияет ли конкретное чтение геометрии на работу после изменения.</li><li><strong>Внесите одну обратимую правку.</strong> Измените небольшой участок, сохраните способ отката и не меняйте контракт результата.</li><li><strong>Повторите запись.</strong> Сравните согласованные диапазоны, но не переносите условные локальные единицы или локальные числа на рабочий трафик.</li><li><strong>Проверьте обе ветки.</strong> Успешный путь должен дать ожидаемое итоговое состояние DOM. Ошибка и пустое действие не должны маскироваться под успешный переход.</li><li><strong>Зафиксируйте вывод.</strong> Оставьте среду, шаг, исходное и итоговое состояние, ссылку на код, диапазон, гипотезу, результат повторной записи и способ отката.</li></ol>\n<h2>Ограничения</h2>\n<p>Разбор Performance panel относится к конкретной среде. Браузер, версия DevTools, устройство, ограничение CPU, размер области просмотра, расширения, кэш, данные и состояние страницы меняют запись. Даже повтор одного сценария может дать другой порядок и длительность работы. Поэтому нельзя переносить вывод из Chrome на Firefox или Safari без отдельной проверки и нельзя считать локальную запись полевым измерением пользовательского опыта.</p>\n<p>Названия этапов в записи не образуют универсальную последовательность. HTML Standard описывает абстрактное поведение пользовательского агента, а DevTools показывает представление конкретного инструмента. <code>requestAnimationFrame</code> не является гарантией, что всё необходимое обновление отображения завершится до следующей строки. CSS-анимация, compositor, изображения, шрифты и изоляция layout, сеть и расширения могут изменить картину.</p>\n<p>Не объявляйте улучшением уменьшение одного участка без функциональной проверки. Работа может переместиться в другой callback, появиться при другом viewport или проявиться только на слабом устройстве. Если после правки исчезла карточка, сообщение или состояние ошибки, более короткая временная шкала ничего не доказывает. Если откат возвращает только класс, но не возвращает сетевой или серверный результат, это локальная отмена, а не полный откат операции.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Исследование готово, когда другой инженер может повторить один сценарий в указанной среде, увидеть исходное и итоговое состояние DOM, открыть выбранный диапазон и найти связь с конкретным изменением. Для правки записаны владелец, ожидаемый результат, наблюдаемый эффект и откат. Успешная ветка сохраняет функциональный результат в DOM. Ошибка и пустое действие проходят отдельно и не выдаются за успешное изменение. Если этих артефактов нет, формулировка «ускорили рендер» остаётся предположением.</p>\n<p>Минимальный итог можно проверить четырьмя вопросами: что сделал пользователь; какой DOM-результат изменился; какой владелец кода связан с диапазоном; что произошло после обратимой правки. На каждый вопрос должна быть ссылка на повторяемый шаг или сохранённую запись. Числа из учебного примера, цвет блока в записи и субъективное ощущение плавности не заменяют эту проверку.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://developer.chrome.com/docs/devtools/performance\" target=\"_blank\" rel=\"noopener noreferrer\">Chrome for Developers: Analyze runtime performance</a> — официальная инструкция по записи runtime-профиля, чтению FPS/CPU и поиску узкого места в Performance panel; страница предупреждает, что интерфейс зависит от версии Chrome.</li><li><a href=\"https://developer.chrome.com/docs/devtools/performance/reference\" target=\"_blank\" rel=\"noopener noreferrer\">Chrome for Developers: Performance features reference</a> — справочник по дорожкам Interactions и Main, выбору диапазона записи, стеку вызовов и настройкам CPU/network ограничение.</li><li><a href=\"https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing\" target=\"_blank\" rel=\"noopener noreferrer\">web.dev: Avoid large, complex layouts and layout thrashing</a> — объяснение forced synchronous layout и причины, по которой чтение геометрии после изменения стиля может потребовать срочного пересчёта.</li><li><a href=\"https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering\" target=\"_blank\" rel=\"noopener noreferrer\">WHATWG HTML Standard: Update the rendering</a> — нормативное описание абстрактного алгоритма обновления отображения пользовательского агента, без обещания фиксированной внутренней последовательности для всех браузеров.</li></ul>"
}