intermediate
Layout thrashing
Избегайте forced synchronous layout: группируйте чтение и запись DOM и измеряйте layout в предсказуемых точках.
Layout thrashing (forced synchronous layout) возникает, когда JavaScript чередует записи в DOM и чтения layout. Каждое чтение может заставить браузер немедленно сбросить отложенные style и layout.
// Плохо: чередование read-write
elements.forEach((el) => {
el.style.width = el.offsetWidth + 10 + 'px'; // read и write на итерацию
});
// Лучше: сначала reads, потом writes
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
el.style.width = widths[i] + 10 + 'px';
});
API вроде `offsetWidth`, `getBoundingClientRect` и `scrollTop` запускают layout при «грязном» дереве. Батчите reads, затем writes; `requestAnimationFrame` для визуальных обновлений; throttle для scroll и resize.
На интервью: связь DOM API с forced synchronous layout и как batching убирает просадки кадров.
Компромисс: императивные измерения DOM против декларативного CSS layout, когда подходит любой подход.
Типовые ошибки: оптимизация селекторов при игноре read-write циклов; измерения layout в горячих scroll handlers.
Чеклист:
- Сначала все измерения, потом мутации.
- rAF для визуальных обновлений DOM.
- Throttle тяжёлого resize/scroll.
- CSS layout вместо JS-циклов измерений.