diff --git a/editorial/agent-rewrites/210.json b/editorial/agent-rewrites/210.json
index 34a9627..5874d39 100644
--- a/editorial/agent-rewrites/210.json
+++ b/editorial/agent-rewrites/210.json
@@ -2,6 +2,6 @@
   "index": 210,
   "slug": "editorial-2022-03-practice-browser-rendering",
   "title": "Медленный рендер: как связать DOM-изменение с причиной в кадре",
-  "excerpt": "Если интерфейс дёргается после одного действия, не называйте виновником весь браузер. Зафиксируйте DOM-изменение, отделите JavaScript от работы rendering pipeline и проверьте гипотезу одной записью Performance panel.",
-  "contentHtml": "<p>После нажатия «Сохранить» карточка должна сменить состояние, но экран на мгновение замирает. Иногда задержка заметна только на слабом ноутбуке. Иногда она появляется после добавления списка, тени или анимации. Команда видит слово «медленный рендер» и начинает менять всё сразу: переносит обработчик, добавляет <code>debounce</code>, убирает CSS и обвиняет фреймворк. Цена такой ошибки — потраченные часы и изменённый интерфейс без доказательства, что причина исчезла.</p>\n<p>Рабочий тезис проще: исследуйте одно пользовательское действие и один наблюдаемый результат DOM. Сначала зафиксируйте, что сделал JavaScript. Затем проверьте, какая работа последовала за этим изменением в конкретной записи. Слова <code>style</code>, <code>layout</code>, <code>paint</code> и <code>composite</code> удобны как вопросы к записи. Они не гарантируют одинаковый внутренний порядок во всех браузерах и не заменяют trace.</p>\n<h2>Симптом и граница задачи</h2>\n<p>Возьмём карточку заказа с кнопкой <code>save-card</code>. До клика у неё класс <code>card is-pending</code>. После успешного ответа интерфейс должен получить <code>card is-ready</code>. Сетевой запрос в этой статье не является предметом измерения. Нас интересует момент, когда обработчик применяет новый класс, и работа, которую браузер выполняет, чтобы показать результат.</p>\n<p>У такой задачи есть проверяемая граница: один клик, один target, одно свойство и два состояния. Не «страница тормозит», а «после клика на <code>save-card</code> меняется <code>className</code> с X на Y». Граница не ускоряет страницу сама. Она убирает лишние события из расследования и позволяет повторить тот же сценарий после правки.</p>\n<figure><img src=\"/assets/editorial/2022/browser-rendering-timeline-2022.svg\" alt=\"Учебная схема: после DOM-мутации показаны стадии style, layout, paint и composite, а synthetic units отделены от реального trace\" loading=\"lazy\" /><figcaption>Учебная timeline помогает задать порядок вопросов. Она не измеряет миллисекунды и не является записью Performance panel.</figcaption></figure>\n<h2>Механизм: от записи JavaScript к кадру</h2>\n<p>JavaScript меняет состояние документа. Например, обработчик записывает новое значение <code>className</code>. После этого user agent может пересчитать применимые стили, геометрию и визуальное представление. Часть работы может быть объединена, отложена или выполнена иначе. Приложение не получает универсальный контракт «после каждой записи всегда будут пять событий».</p>\n<p>Для диагностики полезна учебная цепочка. <code>js-mutation</code> означает изменение DOM. <code>style</code> задаёт вопрос о применимых стилях. <code>layout</code> — вопрос о геометрии. <code>paint</code> — вопрос об обновлении визуального представления. <code>composite</code> — вопрос о сборке результата. Это карта рассуждения, а не названия, которые нужно буквально искать в каждом trace.</p>\n<p>Модель помогает увидеть и отрицательный путь. Если обработчик записал тот же класс, новый visual result мог не появиться. Если выбранный элемент не меняется, длинный участок записи может относиться к таймеру, соседней анимации или расширению браузера. Если после правки исчезла задержка, но исчез и обязательный класс <code>is-ready</code>, это не исправление. Функциональный результат и производительность нужно проверять вместе.</p>\n<h2>Минимальный пример</h2>\n<p>Ниже — учебный код. Он показывает границу действия и ставит метки, чтобы связать запись с обработчиком. Он не обещает конкретное время, FPS, INP или порядок внутренних событий браузера.</p>\n<pre><code>const card = document.querySelector('#save-card');\n\nfunction setCardState(from, to) {\n  if (!card || card.className !== from) {\n    return false;\n  }\n\n  performance.mark('card-state-before');\n  card.className = to;\n  performance.mark('card-state-after');\n  performance.measure(\n    'card-state-change',\n    'card-state-before',\n    'card-state-after'\n  );\n  return true;\n}\n\nbutton.addEventListener('click', () => {\n  setCardState('card is-pending', 'card is-ready');\n});</code></pre>\n<p>Метки ограничивают время JavaScript между двумя точками. Они не доказывают длительность layout или paint. Для этого нужна запись исполнения в выбранной версии браузера. В реальном проекте сохраните также состояние до и после. Иначе вы можете сравнить две записи, в которых обработчик сделал разные вещи.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Рабочая таблица для одного DOM-изменения</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>В одну проблему смешаны handler, layout и соседние события</td><td>Записать один клик и выделить его диапазон</td><td>Сузить запись до interaction и одного target</td></tr><tr><td>Длинный участок есть, но владелец неясен</td><td>Не зафиксированы before и after</td><td>Проверить класс в Elements и место записи в коде</td><td>Обновить контракт действия или остановить исследование</td></tr><tr><td>После изменения CSS стало «быстрее»</td><td>Исчез визуальный результат, а не причина</td><td>Сверить <code>className</code>, геометрию и screenshot</td><td>Откатить правку и проверить другой участок</td></tr><tr><td>В модели нет новой работы</td><td>from и to совпали либо выбран не тот элемент</td><td>Проверить no-op и повторить действие с чистым состоянием</td><td>Не искать layout в записи без новой мутации</td></tr><tr><td>Стадии trace отличаются от схемы</td><td>Учебные labels приняли за API браузера</td><td>Сверить документацию версии и фактические события</td><td>Описать наблюдаемую работу, не переименовывать её насильно</td></tr></tbody></table></div>\n<h2>Порядок проверки</h2>\n<ol><li>Опишите симптом как действие и наблюдаемый эффект: «после клика на <code>save-card</code> экран отвечает неровно, класс должен стать <code>card is-ready</code>».</li><li>Зафиксируйте target, свойство, значение до и значение после. Проверьте исходный DOM в Elements, а не только исходный код.</li><li>Откройте страницу в согласованном состоянии. Остановите лишние действия, очистите состояние сценария и запишите только один клик в Performance panel.</li><li>Найдите interaction и узкий диапазон вокруг неё. Сначала проверьте handler и DOM-result, затем рассматривайте связанные участки rendering.</li><li>Выберите одну гипотезу: лишний geometry read, широкий selector, дорогая визуальная область или лишняя работа JavaScript. Не меняйте несколько причин за один эксперимент.</li><li>Внесите обратимую правку. Сохраните ожидаемый DOM-result и опишите, какое наблюдение должно измениться, если гипотеза верна.</li><li>Повторите тот же сценарий в той же среде. Сравните запись, функциональный результат и отрицательный путь: no-op, ошибка или неверный target.</li><li>Сохраните trace или краткую ссылку на результат вместе с версией браузера и условиями запуска. Без этих условий цифры нельзя честно сравнивать.</li></ol>\n<h2>Что делать, если гипотеза не подтверждается</h2>\n<p>Если DOM после клика не соответствует контракту, остановитесь. Вы исследуете другой путь. Если метка JavaScript есть, а ожидаемой работы после неё нет, не делайте вывод «рендер бесплатный»: работу могли объединить или перенести. Если запись показывает длинный участок вне выбранной interaction, не приписывайте его кнопке. Сначала повторите сценарий с чистым состоянием.</p>\n<p>Не отключайте проверку стилей, не удаляйте обязательный визуальный результат и не добавляйте таймер как доказательство. <code>requestAnimationFrame</code> может помочь синхронизировать учебный эксперимент с обновлением кадра, но он не превращает callback в измерение причины. <code>PerformanceObserver</code> сообщает о поддерживаемых performance entries; он также не раскрывает весь внутренний pipeline и не заменяет запись DevTools.</p>\n<h2>Ограничения</h2>\n<p>Стоимость работы зависит от DOM, CSS, размера обновляемой области, устройства, браузера и состояния страницы. Один trace не описывает все устройства. Chrome DevTools показывает собственные представления и меняет интерфейс между версиями. Firefox и Safari могут группировать или называть события иначе. Даже в одном браузере кеш, шрифты, расширения, throttling и фоновые задачи меняют результат.</p>\n<p>Учебный пример с пятью labels и synthetic units нужен только для проверки порядка рассуждения. Synthetic units не являются миллисекундами, CPU time, FPS, LCP, INP или production-данными. В статье нет утверждения, что конкретная правка ускорила реальный продукт. Реальный вывод появляется только после повторяемой записи на нужном сценарии и подтверждения, что функциональный результат сохранился.</p>\n<h2>Критерий готовности</h2>\n<p>Диагностика готова, если выполнены четыре условия: записано одно действие; DOM before и after совпадают с контрактом; выбранный участок trace связан с этим действием и описан фактическими, а не учебными названиями; после обратимой правки повторная запись сравнима с исходной, а карточка сохраняет состояние <code>is-ready</code>. Если хотя бы одно условие не выполнено, результатом является новая гипотеза, а не заявление «рендер исправлен».</p>\n<h2>Проверяемые источники</h2>\n<ul><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> — описывает алгоритм обновления rendering и не задаёт приложению фиксированный список внутренних событий.</li><li><a href=\"https://developer.chrome.com/docs/devtools/performance/reference\" target=\"_blank\" rel=\"noopener noreferrer\">Chrome DevTools: Performance features reference</a> — объясняет запись, навигацию по trace и связь выбранных участков с анализом.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver\" target=\"_blank\" rel=\"noopener noreferrer\">MDN Web APIs: PerformanceObserver</a> — фиксирует назначение API для наблюдения за доступными performance entries.</li></ul>"
+  "excerpt": "Если интерфейс дёргается после одного действия, не называйте виновником весь браузер. Зафиксируйте DOM-изменение, отделите JavaScript от работы конвейера отрисовки и проверьте гипотезу одной записью Performance panel.",
+  "contentHtml": "<p>После нажатия «Сохранить» карточка должна сменить состояние, но экран на мгновение замирает. На быстром компьютере задержка почти незаметна, а на слабом ноутбуке превращается в рывок. Команда видит слово «медленный рендер» и начинает менять всё сразу: переносит обработчик, добавляет <code>debounce</code>, убирает CSS и обвиняет фреймворк. Цена такой ошибки — часы работы и изменённый интерфейс без доказательства, что причина исчезла.</p>\n<p>Разбор начинается с более узкого вопроса: какое действие сделал пользователь, какой DOM-результат должен появиться и какая работа попала в тот же участок записи? Сначала фиксируем код и состояние до/после, затем смотрим trace (запись работы браузера) в Performance panel. Слова <code>style</code>, <code>layout</code>, <code>paint</code> и <code>composite</code> помогают задать вопрос к записи, но не образуют универсальный порядок для всех браузеров.</p>\n<h2>Симптом и граница задачи</h2>\n<p>Возьмём кнопку <code>save-card</code>, которая после успешного ответа должна получить класс <code>card is-ready</code>. До клика её состояние — <code>card is-pending</code>. Сеть в этом примере не измеряется: считаем, что ответ уже получен и исследуем только обработчик, DOM-изменение и последующую работу браузера.</p>\n<p>Граница расследования состоит из одного клика, одного target (элемента-цели), одного свойства и двух значений. Формулировка «страница тормозит» ничего не связывает с кодом. Формулировка «после клика на <code>save-card</code> свойство <code>className</code> меняется с <code>card is-pending</code> на <code>card is-ready</code>» уже допускает повторную проверку.</p>\n<figure><img src='/assets/editorial/2022/browser-rendering-timeline-2022.svg' alt='Учебная схема: клик меняет className карточки, после чего показаны условные вопросы о style, layout, paint и composite; synthetic units отделены от реального trace' loading='lazy' /><figcaption>Схема задаёт порядок вопросов к одному DOM-изменению. Synthetic units — условные единицы рисунка, а не миллисекунды и не запись Performance panel.</figcaption></figure>\n<h2>Механизм: от JavaScript к обновлению экрана</h2>\n<p>JavaScript меняет состояние документа. Когда обработчик присваивает новый класс, браузеру может понадобиться пересчитать применимые стили и layout — геометрию элементов. Затем движок обновляет визуальное представление; конкретная реализация может объединить, отложить или пропустить часть работы. Поэтому приложение не получает контракт «после каждой записи будут ровно пять событий».</p>\n<p>Для разговора с коллегой удобна рабочая карта: mutation — изменение DOM; style — пересчёт применимых стилей; layout — вычисление геометрии; paint — подготовка визуальных пикселей; composite — сборка слоёв. Это не обязательные имена событий в trace. Если запись показывает другой набор или порядок, описываем то, что действительно наблюдаем, и сверяем его с версией браузера.</p>\n<p>Отдельный кандидат на причину — чтение геометрии сразу после записи. Например, после изменения класса код читает <code>offsetWidth</code>. Это свойство возвращает layout-ширину элемента, а в Chrome чтение после инвалидирования стилей может потребовать немедленного layout. Такая гипотеза проверяется trace, а не самим присутствием свойства в коде: если стили не изменились или элемент не участвует в нужной геометрии, вывод будет другим.</p>\n<h2>Минимальный воспроизводимый пример</h2>\n<p>Ниже приведён самодостаточный фрагмент для страницы, где кнопка является карточкой. Сначала поместите разметку в HTML, затем выполните JavaScript после появления кнопки в документе. Строка с <code>offsetWidth</code> оставлена намеренно: она позволяет проверить гипотезу о чтении геометрии после записи. В рабочем коде не добавляйте такое чтение без причины. После первого клика состояние станет <code>card is-ready</code>; для повторного прогона обновите страницу.</p>\n<pre><code>&lt;button id='save-card' class='card is-pending' type='button'&gt;Сохранить&lt;/button&gt;\n\n// JavaScript\nconst card = document.querySelector('#save-card');\n\nfunction setCardState(from, to) {\n  if (!card || card.className !== from) {\n    return false;\n  }\n\n  performance.mark('card-state-before');\n  card.className = to;\n  const width = card.offsetWidth;\n  console.log('measured width:', width);\n  performance.mark('card-state-after');\n  performance.measure(\n    'card-state-change',\n    'card-state-before',\n    'card-state-after'\n  );\n  return true;\n}\n\ncard.addEventListener('click', () =&gt; {\n  setCardState('card is-pending', 'card is-ready');\n});</code></pre>\n<p>Функциональный результат здесь проверяем отдельно: после клика в Elements должно быть <code>class='card is-ready'</code>. Метки User Timing показывают длительность собственного участка JavaScript и появляются в Performance panel. Они не измеряют весь layout или paint, поэтому запись должна включать сам клик и выбранный диапазон Main track.</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>В один вывод смешаны обработчик, layout и соседние события</td><td>Записать один клик и выделить его interaction</td><td>Сузить trace до действия и одного target</td></tr><tr><td>Длинный участок есть, но владелец неясен</td><td>Не зафиксированы DOM before и after</td><td>Проверить класс в Elements и место записи в коде</td><td>Сначала восстановить контракт, потом искать причину</td></tr><tr><td>После чтения геометрии появился Layout</td><td>Запись класса инвалидировала стили, а чтение потребовало размер</td><td>Сопоставить вызов <code>offsetWidth</code> с выбранным событием</td><td>Разнести запись и чтение либо убрать ненужное чтение; подтвердить повторной записью</td></tr><tr><td>После CSS-правки стало «быстрее»</td><td>Исчез обязательный визуальный результат</td><td>Сверить класс, геометрию и screenshot</td><td>Не принимать сокращённый trace без функциональной проверки</td></tr><tr><td>В записи нет новой работы</td><td>Значения from и to совпали либо выбран не тот элемент</td><td>Проверить no-op и чистое исходное состояние</td><td>Не искать layout там, где не было новой mutation</td></tr><tr><td>Стадии trace отличаются от схемы</td><td>Учебные labels приняли за API браузера</td><td>Сверить документацию версии и фактические события</td><td>Описать наблюдаемую работу без принудительного переименования</td></tr></tbody></table></div>\n<h2>Порядок проверки в Performance panel</h2>\n<ol><li>Опишите симптом как действие и видимый результат: «после клика на <code>save-card</code> интерфейс отвечает неровно, класс должен стать <code>card is-ready</code>».</li><li>Зафиксируйте target, свойство, DOM before и DOM after. Отдельно опишите ожидаемое состояние при ошибке и no-op, когда переход не должен происходить.</li><li>Подготовьте страницу: одинаковые данные, viewport, браузер, cache и настройки throttling. Уберите лишние клики и фоновые действия, но запишите условия запуска.</li><li>Откройте Performance panel, включите запись runtime и выполните один клик. Остановите запись сразу после появления ожидаемого DOM-результата.</li><li>Найдите interaction и узкий диапазон вокруг неё. В Main track проверьте обработчик, User Timing marks и связанные события, а не только самый длинный прямоугольник.</li><li>Выберите одну гипотезу. Для geometry read это конкретный вызов <code>offsetWidth</code>, а не общее утверждение «рендер дорогой».</li><li>Внесите одну обратимую правку: уберите чтение, разделите записи и чтения или измените один selector. Сохраните ожидаемый DOM-result и способ rollback.</li><li>Повторите тот же сценарий в той же среде. Сравните выбранные диапазоны, DOM-result и отрицательный путь. Если trace не подтверждает гипотезу, верните правку и выберите следующий вопрос.</li></ol>\n<h2>Если гипотеза не подтверждается</h2>\n<p>Если DOM после клика не соответствует контракту, остановитесь: вы исследуете не тот путь. Если метка JavaScript есть, а ожидаемого layout или paint в выбранном диапазоне нет, это не доказывает, что рендер «бесплатный». Работа могла быть объединена или перенесена. Если длинный участок лежит вне выбранной interaction, не приписывайте его кнопке без связи с кодом.</p>\n<p>Не отключайте проверку стилей, не удаляйте обязательный визуальный результат и не добавляйте таймер как доказательство. <code>requestAnimationFrame</code> может помочь привязать учебный шаг к очередной возможности отрисовки, но сам callback не объясняет причину задержки. <code>PerformanceObserver</code> наблюдает поддерживаемые performance entries; он не раскрывает весь внутренний pipeline и не заменяет trace DevTools.</p>\n<h2>Ограничения измерения</h2>\n<p>Запись относится к конкретной среде. Версия браузера и DevTools, устройство, viewport, throttling, cache, шрифты, расширения, размер DOM и фоновые задачи меняют длительность и состав работы. Chrome DevTools показывает собственное представление trace; Firefox и Safari могут группировать или называть события иначе. Один локальный прогон не описывает все устройства и не является полевым измерением пользовательского опыта.</p>\n<p>Метки на рисунке и числа в учебной модели не являются миллисекундами, CPU time, FPS, LCP, INP или production-данными. Не переносите результат «стало быстрее» из одного trace на весь продукт. Улучшение принимается только вместе с сохранённым функциональным результатом и повторной записью на нужном сценарии.</p>\n<h2>Критерий готовности</h2>\n<p>Диагностика готова, когда другой инженер может повторить один сценарий в указанной среде, увидеть DOM before и after, найти обработчик и открыть связанный диапазон trace. Для правки записаны одна гипотеза, ожидаемый эффект и rollback. Успешная ветка сохраняет <code>card is-ready</code>, ошибка и no-op проверяются отдельно. Если хотя бы одного артефакта нет, итогом остаётся новая гипотеза, а не заявление «рендер исправлен».</p>\n<h2>Проверяемые источники</h2>\n<ul><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> — описывает rendering opportunity, пересчёт стилей и layout, а также обновление интерфейса без обещания фиксированного списка внутренних событий.</li><li><a href='https://developer.chrome.com/docs/devtools/performance/reference' target='_blank' rel='noopener noreferrer'>Chrome DevTools: Performance features reference</a> — описывает runtime-запись, Main track, навигацию по trace и пользовательские настройки записи.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/User_timing' target='_blank' rel='noopener noreferrer'>MDN Web APIs: User Timing</a> — определяет именованные <code>PerformanceMark</code> и измерения <code>PerformanceMeasure</code>, которые используются в примере.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetWidth' target='_blank' rel='noopener noreferrer'>MDN Web APIs: HTMLElement.offsetWidth</a> — описывает возвращаемую layout-ширину и границы значения свойства.</li></ul>"
 }