From 49495826c0647df81ed311f1b4d83bbf8f37b7d2 Mon Sep 17 00:00:00 2001
From: Faustze <baros24@mail.ru>
Date: Fri, 24 Jul 2026 15:33:42 +0300
Subject: [PATCH 1/2] sync: update vault notes

Rename in Obsidian-Vault: browser/Event Loop/Event Loop.md ->
Event Loop, Microtasks, Macrotasks.md. Updates the two index pages and
Rendering Pipeline.md that link to it.
---
 content-ru/.translation-manifest.json         | 12 +--
 .../Event Loop, Microtasks, Macrotasks.md     | 88 +++++++++++++++++
 content-ru/browser/Event Loop/Event Loop.md   | 93 ------------------
 .../browser/Event Loop/Rendering Pipeline.md  | 97 +++++++++----------
 content-ru/browser/Event Loop/index.md        |  6 +-
 content-ru/browser/index.md                   | 18 ++--
 ... => Event Loop, Microtasks, Macrotasks.md} |  0
 .../browser/Event Loop/Rendering Pipeline.md  |  2 +-
 content/browser/Event Loop/index.md           |  2 +-
 content/browser/index.md                      |  2 +-
 10 files changed, 155 insertions(+), 165 deletions(-)
 create mode 100644 content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
 delete mode 100644 content-ru/browser/Event Loop/Event Loop.md
 rename content/browser/Event Loop/{Event Loop.md => Event Loop, Microtasks, Macrotasks.md} (100%)

diff --git a/content-ru/.translation-manifest.json b/content-ru/.translation-manifest.json
index 5f437b0190c1..8d0fd1d0eda6 100644
--- a/content-ru/.translation-manifest.json
+++ b/content-ru/.translation-manifest.json
@@ -1,15 +1,15 @@
 {
-  "browser/Event Loop/Event Loop.md": "ef7e18bdfa11924dff151a6a5557be2893e4004c9c10068ffb553f0008c36225",
-  "browser/Event Loop/Rendering Pipeline.md": "b698d9525fdb3aea1de4b3243b52c8bc411ad011ace105e9388a18ea704192d6",
-  "browser/Event Loop/index.md": "00cc102dabdebcb267cbfa6c0f10ca45571ecb015de4a2ac221857421f2e9db4",
+  "browser/Event Loop/Rendering Pipeline.md": "272e73f40aadfd7fbe43603dc75f044beee1672196e992f76f240937a0cb8bd6",
+  "browser/Event Loop/Event Loop, Microtasks, Macrotasks.md": "ef7e18bdfa11924dff151a6a5557be2893e4004c9c10068ffb553f0008c36225",
   "browser/Network/CORS.md": "90a34e5d48b1faad3fdb74ecb7b41fa0b78bb87af7e157c439f2c537d60632a8",
   "browser/Network/Cookies & Storage.md": "9a49a4e936342471acae3b88e5f5f81f9c2c7c83e14be4a19dbe3acb88330d87",
+  "browser/Event Loop/index.md": "f9f7836aceeba96e0518a91f66bb916e1d194bc7e52f58ba2e8684a643866840",
   "browser/Network/HTTP Headers & Caching.md": "84d40df2788021f2466cb63770346463df8cab99283ec7f78ed57026ee035c09",
   "browser/Network/TCP & TLS Handshake.md": "40b29f2a89a82ff105ec0b9e581a3b0bf7b6d0b27937deebb636225c2fd8db16",
   "browser/Network/index.md": "8562b0aabb62de7630dcf0b354e7c903792255721a1c57f519b4f1245651e483",
-  "browser/index.md": "36cb2ffc1ebf165c0ceabc5aab8c514d292f06d148fdb359ac03da0a14964313",
   "headhunter/JavaScript-easy-level.md": "07d772fee0195708ac9b6bdf41e1f0fcd2efcf15861cc34947dbce0975d26277",
   "headhunter/JavaScript-middle-level.md": "46ae57febadc70bebdc4f8116a7cf2db901c525e2b573bcfa34377be7af45ac0",
+  "browser/index.md": "2eb4623fd4287396fe34aa7ce75076ae5e30f88af39c8a4e3eab03b3530ebab9",
   "headhunter/index.md": "d9888f62e5b1a3e71f67b05616d51e15e1eccb67be651c33da850f48f438afd2",
   "index.md": "9da5f03310750282a9d78c77d9f3d8bd547ca447608377e930b344b05465465a",
   "leetcode/Array/11-container-with-most-water.md": "8a735550d14dee7e853dee42c6ba6fd04b8671a31b76958370e192972cb39d5a",
@@ -99,6 +99,6 @@
   "leetcode/index.md": "88c151c7c5564227dea91e47d96076632d854dd7fc1eddfa45440093be401dc3",
   "vue/Internals/Compiler.md": "c46b3dd12912b11bc4f0a34b2abba574baff9626f42df410eab279ae77b99e90",
   "vue/Internals/Reactivity.md": "9b502f513195b4512f4d8188f1ac30746030e1c5a52a6a626d51c80c15752d24",
-  "vue/index.md": "aa6244e7ef392b574ddd86f1cafeeac49e03dda7df6eb83b1767e493d1059669",
-  "vue/Internals/index.md": "0637645f58c346554c1687702236afa74ed3b25e795a4c0ad5038369ed0479fb"
+  "vue/Internals/index.md": "0637645f58c346554c1687702236afa74ed3b25e795a4c0ad5038369ed0479fb",
+  "vue/index.md": "aa6244e7ef392b574ddd86f1cafeeac49e03dda7df6eb83b1767e493d1059669"
 }
diff --git a/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md b/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
new file mode 100644
index 000000000000..e86cc23d8130
--- /dev/null
+++ b/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md	
@@ -0,0 +1,88 @@
+# ⏱ Event Loop, микротаски, макротаски, requestAnimationFrame
+
+## 💡 Основная идея
+
+> Event Loop не выполняет код. Это диспетчер: он проверяет, пуст ли стек вызовов, и затем перемещает следующую задачу из очереди в него.
+
+Два вопроса, на которые отвечает эта заметка: почему `setTimeout(fn, 0)` всегда выполняется после всего синхронного кода *и* всех промисов? И почему бесконечная цепочка `Promise.then()` намертво замораживает вкладку, а бесконечный цикл `requestAnimationFrame` — нет?
+
+---
+# 🧭 Участники
+
+1. **Call Stack (стек вызовов)** — выполняет синхронный JS построчно. Пока он не пуст, ничего другого не выполняется.
+2. **JS-движок (V8 и т.д.)** — выполняет только стек вызовов. У него нет встроенного понятия `setTimeout`, DOM или `fetch` — ничего из этого не входит в спецификацию ECMAScript.
+3. **Web API** (браузер) / **libuv** (Node.js) — отдельная часть рантайма, которая фактически отсчитывает таймеры, слушает сетевые/DOM-события и подготавливает кадры.
+4. **Очередь макротасков** — `setTimeout`, `setInterval`, DOM-события, I/O. FIFO; Event Loop извлекает из неё **по одной задаче за раз**.
+5. **Очередь микротасков** — `Promise.then`, `queueMicrotask`, `MutationObserver`. FIFO, но Event Loop **полностью опустошает её**, прежде чем делать что-либо ещё.
+6. **Event Loop** — сам диспетчер: в цикле проверяет «пуст ли стек вызовов?», извлекает следующую задачу, помещает её в стек.
+
+---
+# 🔑 Золотое правило
+
+> После каждой синхронной задачи Event Loop **полностью опустошает** очередь микротасков — включая микротаски, добавленные во время самого опустошения. Только когда очередь пуста, он переходит дальше (к рендерингу или к одному макротаску).
+
+Разница не в «приоритете» — а в разной стратегии опустошения: микротаски означают *«заверши всё, что накопилось, сколько бы там ни оказалось»*; макротаск означает *«возьми ровно одну вещь и верни управление диспетчеру»*.
+
+**Одна полная итерация цикла:**
+
+```
+Call Stack (весь синхронный код)
+  → полностью опустошить очередь микротасков (даже если она пополняется во время опустошения)
+      → колбэки requestAnimationFrame (снимок ровно этого кадра)
+          → Render: Layout → Paint → Composite
+              → взять ОДИН макротаск → выполнить его
+                  → снова опустошить очередь микротасков
+                      → ... повторить
+```
+
+---
+# 🎞 requestAnimationFrame
+
+`requestAnimationFrame(cb)` просит браузер *«выполнить это прямо перед отрисовкой следующего кадра»*. Это не таймер, и он не даёт гарантий по точным миллисекундам — он привязан к реальному циклу обновления экрана (~60/сек).
+
+Порядок выполнения с учётом rAF:
+
+```js
+Promise.resolve().then(() => console.log('promise'));
+requestAnimationFrame(() => console.log('raf'));
+setTimeout(() => console.log('timeout'), 0);
+
+// promise → raf → timeout
+```
+
+---
+# ❄️ Почему бесконечный Promise.then() замораживает вкладку, а бесконечный rAF — нет
+
+Это не совпадение — обе очереди работают по принципиально разной механике.
+
+**Очередь микротасков проверяется динамически.** Перед каждым шагом Event Loop спрашивает «очередь пуста?». Если выполняющийся сейчас микротаск добавляет в очередь новый, тот присоединяется к очереди и выполняется **в этом же проходе**. Для бесконечной цепочки условие выхода («пусто») никогда не наступает:
+
+```js
+function loop() {
+  Promise.resolve().then(loop); // каждый .then() порождает следующий
+}
+loop();
+// Event Loop никогда не доходит до рендеринга, макротасков или кликов — вкладка мертва
+```
+
+**Очередь rAF для кадра — это снимок (батч), зафиксированный в начале обработки этого кадра.** Всё, что регистрируется через `requestAnimationFrame(...)` *во время* выполнения текущего батча, физически не может попасть в этот же батч — только в следующий кадр:
+
+```js
+function animate() {
+  x++;
+  requestAnimationFrame(animate); // попадёт в СЛЕДУЮЩИЙ кадр, не в этот
+}
+requestAnimationFrame(animate);
+// Render (Layout → Paint → Composite) гарантированно происходит между кадрами
+```
+
+Поэтому бесконечная рекурсия через rAF не блокирует браузер: рендер всегда происходит между итерациями. Ключевое различие не в том, насколько быстро выполняется каждый колбэк — а в том, что у очереди микротасков нет границы-снимка, а у батча rAF она есть.
+
+---
+# 🧠 Одним предложением
+
+> Условие выхода Event Loop для очереди микротасков — «пусто», а самопополняющаяся очередь никогда его не достигает. Очередь rAF же выходит через *снимок*: всё, что добавляется во время батча, откладывается на следующий, независимо от скорости выполнения.
+
+[[browser/Event Loop/index|Event Loop & Rendering]]
+[[browser/Event Loop/Rendering Pipeline|Rendering Pipeline — что происходит после опустошения очереди микротасков]]
+#browser
diff --git a/content-ru/browser/Event Loop/Event Loop.md b/content-ru/browser/Event Loop/Event Loop.md
deleted file mode 100644
index 91139d336c39..000000000000
--- a/content-ru/browser/Event Loop/Event Loop.md	
+++ /dev/null
@@ -1,93 +0,0 @@
-# ⏱ Event Loop, микротаски, макротаски, requestAnimationFrame
-
-## 💡 Основная идея
-
-> Event Loop не выполняет код. Это диспетчер: он проверяет, пуст ли call stack, и затем перекладывает в него следующую задачу из очереди.
-
-На два вопроса отвечает эта заметка: почему `setTimeout(fn, 0)` всегда выполняется после всего синхронного кода _и_ всех промисов? И почему бесконечная цепочка `Promise.then()` намертво замораживает вкладку, а бесконечный цикл `requestAnimationFrame` — нет?
-
----
-
-# 🧭 Участники
-
-1. **Call Stack** — выполняет синхронный JS строку за строкой. Пока он не пуст, ничего другого не выполняется.
-2. **JS-движок (V8 и т.д.)** — выполняет только call stack. У него нет встроенного понятия `setTimeout`, DOM или `fetch` — ничего из этого не входит в спецификацию ECMAScript.
-3. **Web API** (браузер) / **libuv** (Node.js) — отдельная часть рантайма, которая непосредственно считает таймеры, слушает сетевые/DOM-события и готовит кадры.
-4. **Очередь макротасков** — `setTimeout`, `setInterval`, DOM-события, I/O. FIFO; Event Loop забирает из неё **по одной задаче за раз**.
-5. **Очередь микротасков** — `Promise.then`, `queueMicrotask`, `MutationObserver`. FIFO, но Event Loop **опустошает её полностью**, прежде чем заняться чем-либо ещё.
-6. **Event Loop** — сам диспетчер: в цикле проверяет «пуст ли call stack?», забирает следующую задачу, помещает её в стек.
-
----
-
-# 🔑 Золотое правило
-
-> После каждой синхронной задачи Event Loop **полностью опустошает** очередь микротасков — включая те, что добавляются во время самого опустошения. И только когда очередь пуста, он переходит дальше (к рендерингу или к одному-единственному макротаску).
-
-Разница не в «приоритете» — это разная стратегия опустошения: микротаски означают _«доделать всё, что накопилось, сколько бы его ни оказалось»_; макротаск означает _«взять ровно одну вещь и вернуть управление диспетчеру»_.
-
-**Одна полная итерация цикла:**
-
-```
-Call Stack (весь синхронный код)
-  → опустошить очередь микротасков ПОЛНОСТЬЮ (даже если она пополняется в процессе)
-      → колбэки requestAnimationFrame (снимок ровно этого кадра)
-          → Рендер: Layout → Paint → Composite
-              → взять ОДИН макротаск → выполнить его
-                  → снова опустошить очередь микротасков
-                      → ... повторить
-```
-
----
-
-# 🎞 requestAnimationFrame
-
-`requestAnimationFrame(cb)` просит браузер _«выполнить это прямо перед отрисовкой следующего кадра»_. Это не таймер, и он не даёт гарантий по точным миллисекундам — он привязан к реальному циклу обновления экрана (~60/сек).
-
-Порядок выполнения с учётом rAF:
-
-```js
-Promise.resolve().then(() => console.log("promise"))
-requestAnimationFrame(() => console.log("raf"))
-setTimeout(() => console.log("timeout"), 0)
-
-// promise → raf → timeout
-```
-
----
-
-# ❄️ Почему бесконечный Promise.then() замораживает вкладку, а бесконечный rAF — нет
-
-Это не совпадение — обе очереди работают по принципиально разной механике.
-
-**Очередь микротасков проверяется динамически.** Перед каждым шагом Event Loop спрашивает «пуста ли очередь?». Если выполняющийся сейчас микротаск ставит в очередь новый, тот присоединяется к очереди и выполняется **в этом же проходе**. Для бесконечной цепочки условие выхода («пусто») никогда не наступает:
-
-```js
-function loop() {
-  Promise.resolve().then(loop) // каждый .then() порождает следующий
-}
-loop()
-// Event Loop никогда не доходит до рендеринга, макротасков или кликов — вкладка мертва
-```
-
-**Очередь rAF для кадра — это снимок (batch), зафиксированный в начале обработки этого кадра.** Всё, что регистрируется через `requestAnimationFrame(...)` _во время_ выполнения текущего batch, физически не может попасть в этот же batch — только в следующий кадр:
-
-```js
-function animate() {
-  x++
-  requestAnimationFrame(animate) // попадёт в СЛЕДУЮЩИЙ кадр, не в этот
-}
-requestAnimationFrame(animate)
-// Рендер (Layout → Paint → Composite) гарантированно происходит между кадрами
-```
-
-Поэтому бесконечная рекурсия через rAF не блокирует браузер: рендер гарантированно вклинивается между итерациями. Ключевое отличие не в том, насколько быстро выполняется каждый из колбэков — а в том, что у очереди микротасков нет границы-снимка, а у batch'а rAF она есть.
-
----
-
-# 🧠 Одним предложением
-
-> Условие выхода Event Loop для очереди микротасков — «пусто», а самопополняющаяся очередь никогда его не достигает. Очередь rAF, напротив, выходит по _снимку_: всё, что добавляется во время batch'а, откладывается на следующий, независимо от того, насколько быстро он выполняется.
-
-[[browser/Event Loop/index|Event Loop & Rendering]]
-[[browser/Event Loop/Rendering Pipeline|Rendering Pipeline — что происходит после опустошения очереди микротасков]]
-#browser
diff --git a/content-ru/browser/Event Loop/Rendering Pipeline.md b/content-ru/browser/Event Loop/Rendering Pipeline.md
index c14c89913134..a2ce209900f5 100644
--- a/content-ru/browser/Event Loop/Rendering Pipeline.md	
+++ b/content-ru/browser/Event Loop/Rendering Pipeline.md	
@@ -2,115 +2,106 @@
 
 ## 💡 Основная идея
 
-> Не каждое изменение стиля одинаково дорого. То, что триггерит CSS-свойство — Layout, Paint или просто Composite — определяет, будет ли анимация плавной или начнёт дропать кадры.
+> Не все изменения стилей одинаково затратны. То, что триггерит конкретное CSS-свойство — Layout, Paint или просто Composite — решает, будет ли анимация плавной или начнёт терять кадры.
 
 ---
-
 # 🧭 Полный пайплайн
 
 ```
 Parse HTML → DOM
 Parse CSS  → CSSOM
-DOM + CSSOM → Render Tree (excludes display:none)
-Render Tree → Layout      (geometry: x, y, width, height)
-Layout      → Paint       (pixels: color, text, shadows)
-Paint       → Composite   (GPU assembles layers)
+DOM + CSSOM → Render Tree (исключает display:none)
+Render Tree → Layout      (геометрия: x, y, width, height)
+Layout      → Paint       (пиксели: цвет, текст, тени)
+Paint       → Composite   (GPU собирает слои)
 ```
 
-`element.style.width = '100px'` **не** триггерит layout немедленно. Браузер просто помечает элемент (и часто его поддерево) как «грязный» и откладывает пересчёт до следующей естественной точки рендера — шага, который идёт сразу после того, как опустошается очередь микротасков и отрабатывают колбэки rAF в [[browser/Event Loop/Event Loop|Event Loop]].
+`element.style.width = '100px'` **не** триггерит layout немедленно. Браузер просто помечает элемент (и часто его поддерево) как "грязный" и откладывает пересчёт до следующей естественной точки рендера — шага, который идёт сразу после того, как очередь микрозадач опустеет и отработают колбэки rAF в [[browser/Event Loop/Event Loop|Event Loop]].
 
-Важное различие: **CSSOM** (распарсенные правила из `<style>`/стилшитов) и инлайновый `element.style` (объект `CSSStyleDeclaration`, привязанный к атрибуту `style` одного элемента) — это разные объекты. Запись `el.style.width = ...` никогда не трогает CSSOM — она только помечает грязным этот один элемент.
+Важное различие: **CSSOM** (распарсенные правила из `<style>`/стилшитов) и инлайновый `element.style` (объект `CSSStyleDeclaration`, привязанный к атрибуту `style` одного элемента) — разные объекты. Запись `el.style.width = ...` никогда не трогает CSSOM — она помечает "грязным" только этот один элемент.
 
 ---
-
-# ⚡ Что триггерит каждый этап
+# ⚡ Что триггерит каждую стадию
 
 ```
 Layout:          width/height, top/left/right/bottom, margin/padding,
-                  border-width, font-size, display, adding/removing DOM nodes
+                  border-width, font-size, display, добавление/удаление DOM-узлов
 Paint:            color, background, box-shadow, border-radius, visibility, outline
-Composite-only:   transform, opacity
+Только Composite: transform, opacity
 ```
 
-## Почему transform/opacity дешёвые
+## Почему transform/opacity дёшевы
 
-Не потому что _значат_ эти свойства — а из-за того, _где_ они обрабатываются. Если у элемента уже есть свой compositor layer (GPU-текстура — от `will-change`, идущей анимации, `position: fixed`, `<video>`, `<canvas>` и т.д.), изменение `transform`/`opacity` — это просто применение матрицы трансформации или значения альфа-канала к _уже растеризованной_ текстуре, целиком на **compositor thread**. Layout и Paint вообще не запускаются.
+Не из-за того, что *означают* эти свойства — а из-за того, *где* они обрабатываются. Если у элемента уже есть свой слой компоузинга (текстура GPU — от `will-change`, идущей анимации, `position: fixed`, `<video>`, `<canvas>` и т.д.), изменение `transform`/`opacity` — это просто применение матрицы трансформации или значения альфа-канала к *уже отрастеризованной* текстуре, целиком на **потоке компоузитора**. Layout и Paint вообще не выполняются.
 
-- `transform` — это не категория «свойств для анимации», это геометрические трансформации (translate/scale/rotate/skew/matrix), которые оказались дешёвыми в анимации.
+- `transform` — это не категория "анимационных свойств", это геометрические трансформации (translate/scale/rotate/skew/matrix), которые просто дёшево анимировать.
 - `opacity` — это не яркость, это альфа-канал (0 = невидимо, 1 = непрозрачно).
 
 Все функции `transform` компилируются в одну каноническую форму:
 
 - `translate(x, y)` — сдвиг по осям (`translateX/Y/Z`, `translate3d`)
-- `scale(x, y)` — изменение размера (`scale(1.5)` = в 1.5 раза больше); `scaleX`/`scaleY` независимо по каждой оси
+- `scale(x, y)` — изменение размера (`scale(1.5)` = больше в 1.5 раза); `scaleX`/`scaleY` независимо по каждой оси
 - `rotate(angle)` — вращение вокруг точки (по умолчанию: центр элемента); `rotateX/Y/Z` для 3D
-- `skew(x-angle, y-angle)` — сдвиг/скос: превращает прямоугольник в параллелограмм
-- `matrix(a, b, c, d, e, f)` — низкоуровневая матрица 2×3 affine, в которую компилируется всё вышеперечисленное (`matrix3d` — 4×4, для 3D)
+- `skew(x-angle, y-angle)` — сдвиг (shear): превращает прямоугольник в параллелограмм
+- `matrix(a, b, c, d, e, f)` — низкоуровневая аффинная матрица 2×3, в которую компилируется всё вышеперечисленное (`matrix3d` — 4×4, для 3D)
 
 ---
-
 # 🧵 Main thread vs Compositor thread
 
 ```
-Main thread:        JS execution → Style calc → Layout → Paint
+Main thread:        выполнение JS → Style calc → Layout → Paint
 Compositor thread:  Composite (transform/opacity)
 ```
 
-Main thread — это место, где живут [[browser/Event Loop/Event Loop|Event Loop]], call stack и весь JS — Style, Layout и Paint тоже находятся там. Если main thread заблокирован (долгий синхронный JS, forced reflow), всё замирает: скролл, клики и любая анимация на `width`/`top`.
+Main thread — это место, где живут [[browser/Event Loop/Event Loop|Event Loop]], стек вызовов и весь JS — Style, Layout и Paint тоже находятся там. Если main thread заблокирован (долгий синхронный JS, forced reflow), всё останавливается: скролл, клики и любая анимация на `width`/`top`.
 
-Compositor thread отдельный и не блокируется main thread'ом. К моменту выполнения Composite DOM/CSSOM уже не важны: Paint (на main thread) уже превратил элемент в растеризованную GPU-текстуру. Compositor thread видит только готовые текстуры и матрицы трансформаций — он никогда не трогает дерево DOM. Composite — это не «рисование поверх HTML/CSS-скелета», это «размещение уже готовых картинок на экране».
+Compositor thread отдельный и не блокируется main thread'ом. К моменту выполнения Composite DOM/CSSOM уже не имеют значения: Paint (на main thread) уже превратил элемент в отрастеризованную GPU-текстуру. Compositor thread видит только готовые текстуры и матрицы трансформаций — он никогда не трогает дерево DOM. Composite — это не "рисование поверх HTML/CSS-скелета", это "размещение уже готовых изображений на экране".
 
-## Как формируются compositor layers
+## Как формируются слои компоузинга
 
 Слой — это не DOM-элемент, а область пикселей плюс правило её позиционирования. Он состоит из:
 
-- **display list** — записанных Paint команд рисования («залить этот прямоугольник», «нарисовать этот текст») для части DOM в этом слое
-- **растеризованной текстуры (bitmap)** — результата выполнения display list, обычно нарезанной на **тайлы** (например, 256×256px) для эффективной перезагрузки
-- **свойств трансформации** — матрицы (transform), opacity и позиции в системе координат compositor'а
+- **display list** — записанные командами рисования от Paint ("залить этот прямоугольник", "нарисовать этот текст") для той части DOM, что входит в слой
+- **растеризованной текстуры (bitmap)** — результата выполнения display list, обычно нарезанного на **тайлы** (например, 256×256px) для эффективной перезагрузки
+- **свойств трансформации** — матрицы (transform), opacity и позиции в системе координат компоузитора
 
-Этапы формирования:
+Шаги формирования:
 
 1. **Style** — вычисляются значения CSS
 2. **Layout** — вычисляется геометрия (размеры, позиции)
-3. **Построение дерева слоёв (layerization)** — main thread решает, какие элементы получают собственный compositor layer. Триггеры: анимированные `transform`/`opacity`, `will-change`, `position: fixed`, `<video>`, `<canvas>`. Всё остальное рисуется в слой родителя.
-4. **Paint** — main thread не рисует пиксели, он записывает display list для каждого слоя
-5. **Растеризация** — display list превращается в реальные пиксели, обычно через GPU (например, GPU-бэкенд Skia), часто на отдельных raster-потоках
+3. **Построение дерева слоёв (layerization)** — main thread решает, какие элементы получат собственный слой компоузинга. Триггеры: анимируемые `transform`/`opacity`, `will-change`, `position: fixed`, `<video>`, `<canvas>`. Всё остальное рисуется в слое родителя.
+4. **Paint** — main thread не рисует пиксели, а записывает display list для каждого слоя
+5. **Растеризация** — display list превращается в реальные пиксели, обычно через GPU (например, GPU-бэкенд Skia), часто на отдельных потоках растеризации
 6. **Compositing** — compositor thread собирает готовые текстуры слоёв в финальный кадр, применяя transform/opacity каждого слоя целиком
 
-Шаги 1–4 выполняются на main thread; шаги 5–6 — на отдельных потоках. Если у элемента, который уже имеет слой, меняется только `transform`/`opacity`, шаги 1–4 полностью пропускаются — сразу к шагу 6 с существующей текстурой.
+Шаги 1–4 выполняются на main thread; шаги 5–6 — на отдельных потоках. Если у элемента, у которого уже есть слой, меняется только `transform`/`opacity`, шаги 1–4 полностью пропускаются — сразу к шагу 6 с уже существующей текстурой.
 
-Почему каждый слой рендерится в свою текстуру: её можно переиспользовать без перерисовки. Если слой уже содержит что-то дорогое (текст, тени, градиенты) и его просто перемещают (`translateX`), нет нужды заново выполнять команды рисования — GPU просто перепозиционирует готовую текстуру. Это также распараллеливает работу: разные слои растеризуются одновременно на разных потоках, и перерисовывается только тот слой, который реально изменился.
+Почему каждый слой рендерится в свою текстуру: её можно переиспользовать без повторной отрисовки. Если слой уже содержит что-то дорогое (текст, тени, градиенты) и его просто перемещают (`translateX`), нет нужды заново выполнять команды рисования — GPU просто перепозиционирует готовую текстуру. Это также распараллеливает работу: разные слои растеризуются одновременно на разных потоках, и перерисовывается только тот слой, который реально изменился.
 
 ---
+# 🐢 Принудительный синхронный layout
 
-# 🐢 Forced synchronous layout
-
-Если вы записываете стиль и сразу читаете свойство, зависящее от layout (`offsetWidth`, `getBoundingClientRect()`, `clientHeight`, `scrollTop`, …), браузер обязан пересчитать геометрию **синхронно, прямо на месте**, чтобы дать точный ответ — он не может отложить это до следующей точки рендера.
+Если вы записываете стиль и сразу читаете зависящее от layout свойство (`offsetWidth`, `getBoundingClientRect()`, `clientHeight`, `scrollTop`, …), браузер вынужден пересчитать геометрию **синхронно, прямо здесь**, чтобы дать точный ответ — он не может отложить это до следующей точки рендера.
 
 ```js
-// bad: 1000 forced layouts, one per iteration
-items.forEach((item) => {
-  item.style.width = "100px" // write — flags the element dirty
-  console.log(item.offsetWidth) // read — forces a full recalculation NOW
-})
-
-// good: one layout for the whole batch
-items.forEach((item) => {
-  item.style.width = "100px"
-}) // all writes first
-items.forEach((item) => {
-  console.log(item.offsetWidth)
-}) // all reads — first read recomputes, the rest hit the cache
+// плохо: 1000 forced layouts, по одному на итерацию
+items.forEach(item => {
+  item.style.width = '100px';       // запись — помечает элемент грязным
+  console.log(item.offsetWidth);    // чтение — форсирует полный пересчёт СЕЙЧАС
+});
+
+// хорошо: один layout на весь батч
+items.forEach(item => { item.style.width = '100px'; });    // сначала все записи
+items.forEach(item => { console.log(item.offsetWidth); }); // затем все чтения — первое чтение пересчитывает, остальные берутся из кэша
 ```
 
-Почему это дорого: layout вычисляет геометрию не только для затронутого элемента — обычно для значительной затронутой части дерева (элементы влияют друг на друга через flexbox, проценты, реflow текста). Это как заново измерять 1000 стен и звать инспектора после каждой, вместо того чтобы позвать его один раз в конце.
+Почему это дорого: layout вычисляет геометрию не только для затронутого элемента — обычно для большой затронутой части дерева (элементы влияют друг на друга через flexbox, проценты, реflow текста). Это как перемерять 1000 стен и вызывать инспектора после каждой, вместо того чтобы вызвать его один раз в конце.
 
 ---
+# 🧠 В одном предложении
 
-# 🧠 Одним предложением
-
-> Изменения `width`/`top` стоят Layout + Paint на main thread; изменения `color`/`shadow` стоят только Paint; `transform`/`opacity` пропускают и то, и другое и остаются на compositor thread — это и есть вся причина предпочитать анимировать именно их.
+> Изменения `width`/`top` стоят Layout + Paint на main thread; изменения `color`/`shadow` стоят только Paint; `transform`/`opacity` пропускают оба этих шага и остаются на compositor thread — в этом вся причина предпочитать анимировать именно их.
 
 [[browser/Event Loop/index|Event Loop & Rendering]]
-[[browser/Event Loop/Event Loop|Event Loop — where render fits into the loop]]
+[[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop — как рендер встраивается в цикл]]
 #browser
diff --git a/content-ru/browser/Event Loop/index.md b/content-ru/browser/Event Loop/index.md
index 1ddcab49d6e3..2722dccf2d81 100644
--- a/content-ru/browser/Event Loop/index.md	
+++ b/content-ru/browser/Event Loop/index.md	
@@ -1,12 +1,12 @@
 ---
-title: event loop
+title: цикл событий
 ---
 
-# Event Loop и рендеринг
+# Цикл событий и рендеринг
 
 [[browser/index|← Browser]]
 
-- [[browser/Event Loop/Event Loop|Event Loop, микрозадачи, макрозадачи]]
+- [[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop, Microtasks, Macrotasks]]
 - [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
 
 #browser
diff --git a/content-ru/browser/index.md b/content-ru/browser/index.md
index 1d88249eb869..251d72e386c2 100644
--- a/content-ru/browser/index.md
+++ b/content-ru/browser/index.md
@@ -1,12 +1,16 @@
+---
+title: browser
+---
+
 # Браузер
 
-- [[browser/Event Loop/index|Event Loop и рендеринг]]
-  - [[browser/Event Loop/Event Loop|Event Loop, микрозадачи, макрозадачи]]
-  - [[browser/Event Loop/Rendering Pipeline|Конвейер рендеринга: Layout, Paint, Composite]]
-- [[browser/Network/index|HTTP и сеть]]
-  - [[browser/Network/TCP & TLS Handshake|TCP и TLS Handshake]]
-  - [[browser/Network/HTTP Headers & Caching|HTTP-заголовки и кеширование]]
+- [[browser/Event Loop/index|Event Loop & Rendering]]
+  - [[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop, Microtasks, Macrotasks]]
+  - [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
+- [[browser/Network/index|HTTP & Network]]
+  - [[browser/Network/TCP & TLS Handshake|TCP & TLS Handshake]]
+  - [[browser/Network/HTTP Headers & Caching|HTTP Headers & Caching]]
   - [[browser/Network/CORS|CORS]]
-  - [[browser/Network/Cookies & Storage|Cookies и хранилище]]
+  - [[browser/Network/Cookies & Storage|Cookies & Storage]]
 
 #browser
diff --git a/content/browser/Event Loop/Event Loop.md b/content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
similarity index 100%
rename from content/browser/Event Loop/Event Loop.md
rename to content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
diff --git a/content/browser/Event Loop/Rendering Pipeline.md b/content/browser/Event Loop/Rendering Pipeline.md
index 88c393a06fa4..73b162cbbe9c 100644
--- a/content/browser/Event Loop/Rendering Pipeline.md	
+++ b/content/browser/Event Loop/Rendering Pipeline.md	
@@ -103,5 +103,5 @@ Why this is expensive: layout doesn't just compute geometry for the touched elem
 > `width`/`top` changes cost Layout + Paint on the main thread; `color`/`shadow` changes cost Paint only; `transform`/`opacity` skip both and stay on the compositor thread — that's the entire reason to prefer animating the latter.
 
 [[browser/Event Loop/index|Event Loop & Rendering]]
-[[browser/Event Loop/Event Loop|Event Loop — where render fits into the loop]]
+[[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop — where render fits into the loop]]
 #browser
diff --git a/content/browser/Event Loop/index.md b/content/browser/Event Loop/index.md
index 76e369eb9b2b..0dfdce2a75a5 100644
--- a/content/browser/Event Loop/index.md	
+++ b/content/browser/Event Loop/index.md	
@@ -6,7 +6,7 @@ title: event loop
 
 [[browser/index|← Browser]]
 
-- [[browser/Event Loop/Event Loop|Event Loop, Microtasks, Macrotasks]]
+- [[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop, Microtasks, Macrotasks]]
 - [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
 
 #browser
diff --git a/content/browser/index.md b/content/browser/index.md
index 7991d41febba..fc2560926d75 100644
--- a/content/browser/index.md
+++ b/content/browser/index.md
@@ -5,7 +5,7 @@ title: browser
 # Browser
 
 - [[browser/Event Loop/index|Event Loop & Rendering]]
-  - [[browser/Event Loop/Event Loop|Event Loop, Microtasks, Macrotasks]]
+  - [[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop, Microtasks, Macrotasks]]
   - [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
 - [[browser/Network/index|HTTP & Network]]
   - [[browser/Network/TCP & TLS Handshake|TCP & TLS Handshake]]

From d2d5a0bbc97a0b626696059301e61bb09b99dc1b Mon Sep 17 00:00:00 2001
From: Faustze <baros24@mail.ru>
Date: Fri, 24 Jul 2026 15:35:58 +0300
Subject: [PATCH 2/2] style: fix prettier formatting in content-ru/browser

---
 content-ru/.translation-manifest.json         |  6 ++--
 .../Event Loop, Microtasks, Macrotasks.md     | 31 +++++++++++--------
 .../browser/Event Loop/Rendering Pipeline.md  | 23 +++++++++-----
 3 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/content-ru/.translation-manifest.json b/content-ru/.translation-manifest.json
index 8d0fd1d0eda6..c77d13498bbc 100644
--- a/content-ru/.translation-manifest.json
+++ b/content-ru/.translation-manifest.json
@@ -1,15 +1,15 @@
 {
-  "browser/Event Loop/Rendering Pipeline.md": "272e73f40aadfd7fbe43603dc75f044beee1672196e992f76f240937a0cb8bd6",
   "browser/Event Loop/Event Loop, Microtasks, Macrotasks.md": "ef7e18bdfa11924dff151a6a5557be2893e4004c9c10068ffb553f0008c36225",
+  "browser/Event Loop/Rendering Pipeline.md": "272e73f40aadfd7fbe43603dc75f044beee1672196e992f76f240937a0cb8bd6",
+  "browser/Event Loop/index.md": "f9f7836aceeba96e0518a91f66bb916e1d194bc7e52f58ba2e8684a643866840",
   "browser/Network/CORS.md": "90a34e5d48b1faad3fdb74ecb7b41fa0b78bb87af7e157c439f2c537d60632a8",
   "browser/Network/Cookies & Storage.md": "9a49a4e936342471acae3b88e5f5f81f9c2c7c83e14be4a19dbe3acb88330d87",
-  "browser/Event Loop/index.md": "f9f7836aceeba96e0518a91f66bb916e1d194bc7e52f58ba2e8684a643866840",
   "browser/Network/HTTP Headers & Caching.md": "84d40df2788021f2466cb63770346463df8cab99283ec7f78ed57026ee035c09",
   "browser/Network/TCP & TLS Handshake.md": "40b29f2a89a82ff105ec0b9e581a3b0bf7b6d0b27937deebb636225c2fd8db16",
   "browser/Network/index.md": "8562b0aabb62de7630dcf0b354e7c903792255721a1c57f519b4f1245651e483",
+  "browser/index.md": "2eb4623fd4287396fe34aa7ce75076ae5e30f88af39c8a4e3eab03b3530ebab9",
   "headhunter/JavaScript-easy-level.md": "07d772fee0195708ac9b6bdf41e1f0fcd2efcf15861cc34947dbce0975d26277",
   "headhunter/JavaScript-middle-level.md": "46ae57febadc70bebdc4f8116a7cf2db901c525e2b573bcfa34377be7af45ac0",
-  "browser/index.md": "2eb4623fd4287396fe34aa7ce75076ae5e30f88af39c8a4e3eab03b3530ebab9",
   "headhunter/index.md": "d9888f62e5b1a3e71f67b05616d51e15e1eccb67be651c33da850f48f438afd2",
   "index.md": "9da5f03310750282a9d78c77d9f3d8bd547ca447608377e930b344b05465465a",
   "leetcode/Array/11-container-with-most-water.md": "8a735550d14dee7e853dee42c6ba6fd04b8671a31b76958370e192972cb39d5a",
diff --git a/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md b/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
index e86cc23d8130..eb375f0f7536 100644
--- a/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md	
+++ b/content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md	
@@ -4,9 +4,10 @@
 
 > Event Loop не выполняет код. Это диспетчер: он проверяет, пуст ли стек вызовов, и затем перемещает следующую задачу из очереди в него.
 
-Два вопроса, на которые отвечает эта заметка: почему `setTimeout(fn, 0)` всегда выполняется после всего синхронного кода *и* всех промисов? И почему бесконечная цепочка `Promise.then()` намертво замораживает вкладку, а бесконечный цикл `requestAnimationFrame` — нет?
+Два вопроса, на которые отвечает эта заметка: почему `setTimeout(fn, 0)` всегда выполняется после всего синхронного кода _и_ всех промисов? И почему бесконечная цепочка `Promise.then()` намертво замораживает вкладку, а бесконечный цикл `requestAnimationFrame` — нет?
 
 ---
+
 # 🧭 Участники
 
 1. **Call Stack (стек вызовов)** — выполняет синхронный JS построчно. Пока он не пуст, ничего другого не выполняется.
@@ -17,11 +18,12 @@
 6. **Event Loop** — сам диспетчер: в цикле проверяет «пуст ли стек вызовов?», извлекает следующую задачу, помещает её в стек.
 
 ---
+
 # 🔑 Золотое правило
 
 > После каждой синхронной задачи Event Loop **полностью опустошает** очередь микротасков — включая микротаски, добавленные во время самого опустошения. Только когда очередь пуста, он переходит дальше (к рендерингу или к одному макротаску).
 
-Разница не в «приоритете» — а в разной стратегии опустошения: микротаски означают *«заверши всё, что накопилось, сколько бы там ни оказалось»*; макротаск означает *«возьми ровно одну вещь и верни управление диспетчеру»*.
+Разница не в «приоритете» — а в разной стратегии опустошения: микротаски означают _«заверши всё, что накопилось, сколько бы там ни оказалось»_; макротаск означает _«возьми ровно одну вещь и верни управление диспетчеру»_.
 
 **Одна полная итерация цикла:**
 
@@ -36,21 +38,23 @@ Call Stack (весь синхронный код)
 ```
 
 ---
+
 # 🎞 requestAnimationFrame
 
-`requestAnimationFrame(cb)` просит браузер *«выполнить это прямо перед отрисовкой следующего кадра»*. Это не таймер, и он не даёт гарантий по точным миллисекундам — он привязан к реальному циклу обновления экрана (~60/сек).
+`requestAnimationFrame(cb)` просит браузер _«выполнить это прямо перед отрисовкой следующего кадра»_. Это не таймер, и он не даёт гарантий по точным миллисекундам — он привязан к реальному циклу обновления экрана (~60/сек).
 
 Порядок выполнения с учётом rAF:
 
 ```js
-Promise.resolve().then(() => console.log('promise'));
-requestAnimationFrame(() => console.log('raf'));
-setTimeout(() => console.log('timeout'), 0);
+Promise.resolve().then(() => console.log("promise"))
+requestAnimationFrame(() => console.log("raf"))
+setTimeout(() => console.log("timeout"), 0)
 
 // promise → raf → timeout
 ```
 
 ---
+
 # ❄️ Почему бесконечный Promise.then() замораживает вкладку, а бесконечный rAF — нет
 
 Это не совпадение — обе очереди работают по принципиально разной механике.
@@ -59,29 +63,30 @@ setTimeout(() => console.log('timeout'), 0);
 
 ```js
 function loop() {
-  Promise.resolve().then(loop); // каждый .then() порождает следующий
+  Promise.resolve().then(loop) // каждый .then() порождает следующий
 }
-loop();
+loop()
 // Event Loop никогда не доходит до рендеринга, макротасков или кликов — вкладка мертва
 ```
 
-**Очередь rAF для кадра — это снимок (батч), зафиксированный в начале обработки этого кадра.** Всё, что регистрируется через `requestAnimationFrame(...)` *во время* выполнения текущего батча, физически не может попасть в этот же батч — только в следующий кадр:
+**Очередь rAF для кадра — это снимок (батч), зафиксированный в начале обработки этого кадра.** Всё, что регистрируется через `requestAnimationFrame(...)` _во время_ выполнения текущего батча, физически не может попасть в этот же батч — только в следующий кадр:
 
 ```js
 function animate() {
-  x++;
-  requestAnimationFrame(animate); // попадёт в СЛЕДУЮЩИЙ кадр, не в этот
+  x++
+  requestAnimationFrame(animate) // попадёт в СЛЕДУЮЩИЙ кадр, не в этот
 }
-requestAnimationFrame(animate);
+requestAnimationFrame(animate)
 // Render (Layout → Paint → Composite) гарантированно происходит между кадрами
 ```
 
 Поэтому бесконечная рекурсия через rAF не блокирует браузер: рендер всегда происходит между итерациями. Ключевое различие не в том, насколько быстро выполняется каждый колбэк — а в том, что у очереди микротасков нет границы-снимка, а у батча rAF она есть.
 
 ---
+
 # 🧠 Одним предложением
 
-> Условие выхода Event Loop для очереди микротасков — «пусто», а самопополняющаяся очередь никогда его не достигает. Очередь rAF же выходит через *снимок*: всё, что добавляется во время батча, откладывается на следующий, независимо от скорости выполнения.
+> Условие выхода Event Loop для очереди микротасков — «пусто», а самопополняющаяся очередь никогда его не достигает. Очередь rAF же выходит через _снимок_: всё, что добавляется во время батча, откладывается на следующий, независимо от скорости выполнения.
 
 [[browser/Event Loop/index|Event Loop & Rendering]]
 [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline — что происходит после опустошения очереди микротасков]]
diff --git a/content-ru/browser/Event Loop/Rendering Pipeline.md b/content-ru/browser/Event Loop/Rendering Pipeline.md
index a2ce209900f5..56ba1dfd792a 100644
--- a/content-ru/browser/Event Loop/Rendering Pipeline.md	
+++ b/content-ru/browser/Event Loop/Rendering Pipeline.md	
@@ -5,6 +5,7 @@
 > Не все изменения стилей одинаково затратны. То, что триггерит конкретное CSS-свойство — Layout, Paint или просто Composite — решает, будет ли анимация плавной или начнёт терять кадры.
 
 ---
+
 # 🧭 Полный пайплайн
 
 ```
@@ -21,6 +22,7 @@ Paint       → Composite   (GPU собирает слои)
 Важное различие: **CSSOM** (распарсенные правила из `<style>`/стилшитов) и инлайновый `element.style` (объект `CSSStyleDeclaration`, привязанный к атрибуту `style` одного элемента) — разные объекты. Запись `el.style.width = ...` никогда не трогает CSSOM — она помечает "грязным" только этот один элемент.
 
 ---
+
 # ⚡ Что триггерит каждую стадию
 
 ```
@@ -32,7 +34,7 @@ Paint:            color, background, box-shadow, border-radius, visibility, outl
 
 ## Почему transform/opacity дёшевы
 
-Не из-за того, что *означают* эти свойства — а из-за того, *где* они обрабатываются. Если у элемента уже есть свой слой компоузинга (текстура GPU — от `will-change`, идущей анимации, `position: fixed`, `<video>`, `<canvas>` и т.д.), изменение `transform`/`opacity` — это просто применение матрицы трансформации или значения альфа-канала к *уже отрастеризованной* текстуре, целиком на **потоке компоузитора**. Layout и Paint вообще не выполняются.
+Не из-за того, что _означают_ эти свойства — а из-за того, _где_ они обрабатываются. Если у элемента уже есть свой слой компоузинга (текстура GPU — от `will-change`, идущей анимации, `position: fixed`, `<video>`, `<canvas>` и т.д.), изменение `transform`/`opacity` — это просто применение матрицы трансформации или значения альфа-канала к _уже отрастеризованной_ текстуре, целиком на **потоке компоузитора**. Layout и Paint вообще не выполняются.
 
 - `transform` — это не категория "анимационных свойств", это геометрические трансформации (translate/scale/rotate/skew/matrix), которые просто дёшево анимировать.
 - `opacity` — это не яркость, это альфа-канал (0 = невидимо, 1 = непрозрачно).
@@ -46,6 +48,7 @@ Paint:            color, background, box-shadow, border-radius, visibility, outl
 - `matrix(a, b, c, d, e, f)` — низкоуровневая аффинная матрица 2×3, в которую компилируется всё вышеперечисленное (`matrix3d` — 4×4, для 3D)
 
 ---
+
 # 🧵 Main thread vs Compositor thread
 
 ```
@@ -79,25 +82,31 @@ Compositor thread отдельный и не блокируется main thread'
 Почему каждый слой рендерится в свою текстуру: её можно переиспользовать без повторной отрисовки. Если слой уже содержит что-то дорогое (текст, тени, градиенты) и его просто перемещают (`translateX`), нет нужды заново выполнять команды рисования — GPU просто перепозиционирует готовую текстуру. Это также распараллеливает работу: разные слои растеризуются одновременно на разных потоках, и перерисовывается только тот слой, который реально изменился.
 
 ---
+
 # 🐢 Принудительный синхронный layout
 
 Если вы записываете стиль и сразу читаете зависящее от layout свойство (`offsetWidth`, `getBoundingClientRect()`, `clientHeight`, `scrollTop`, …), браузер вынужден пересчитать геометрию **синхронно, прямо здесь**, чтобы дать точный ответ — он не может отложить это до следующей точки рендера.
 
 ```js
 // плохо: 1000 forced layouts, по одному на итерацию
-items.forEach(item => {
-  item.style.width = '100px';       // запись — помечает элемент грязным
-  console.log(item.offsetWidth);    // чтение — форсирует полный пересчёт СЕЙЧАС
-});
+items.forEach((item) => {
+  item.style.width = "100px" // запись — помечает элемент грязным
+  console.log(item.offsetWidth) // чтение — форсирует полный пересчёт СЕЙЧАС
+})
 
 // хорошо: один layout на весь батч
-items.forEach(item => { item.style.width = '100px'; });    // сначала все записи
-items.forEach(item => { console.log(item.offsetWidth); }); // затем все чтения — первое чтение пересчитывает, остальные берутся из кэша
+items.forEach((item) => {
+  item.style.width = "100px"
+}) // сначала все записи
+items.forEach((item) => {
+  console.log(item.offsetWidth)
+}) // затем все чтения — первое чтение пересчитывает, остальные берутся из кэша
 ```
 
 Почему это дорого: layout вычисляет геометрию не только для затронутого элемента — обычно для большой затронутой части дерева (элементы влияют друг на друга через flexbox, проценты, реflow текста). Это как перемерять 1000 стен и вызывать инспектора после каждой, вместо того чтобы вызвать его один раз в конце.
 
 ---
+
 # 🧠 В одном предложении
 
 > Изменения `width`/`top` стоят Layout + Paint на main thread; изменения `color`/`shadow` стоят только Paint; `transform`/`opacity` пропускают оба этих шага и остаются на compositor thread — в этом вся причина предпочитать анимировать именно их.