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-циклов измерений.