이 편에서 만드는 파일

(코드 없음) 04편부터 notes-app 프로젝트 폴더를 만듭니다.

개념 정리

HTML 파싱부터 화면까지

브라우저는 서버에서 받은 HTML 문서를 아래 순서로 처리해 화면에 픽셀을 그립니다.

DOM을 바꾸면 무슨 일이 일어나는가

element.textContent = "새 메모"처럼 DOM을 바꾸는 자바스크립트 코드를 실행해도 화면이 즉시 다시 그려지지 않습니다. 브라우저는 한 프레임(보통 초당 60번, 약 16.7밀리초 간격) 동안 쌓인 변경 사항을 모아서 레이아웃·페인트를 한 번에 처리합니다. 이것이 04편부터 만들 render.js가 매번 document.createElement를 호출해도 화면이 버벅이지 않는 이유입니다.

문제는 자바스크립트 코드에서 레이아웃 값을 읽는 것(element.offsetHeight, getBoundingClientRect() 등)입니다. 이런 값을 읽으려면 브라우저가 그 시점까지 쌓인 변경 사항의 레이아웃을 강제로 즉시 계산해야 합니다. 이를 강제 동기 레이아웃(forced synchronous layout)이라고 부르며, DOM을 바꾸는 코드와 레이아웃 값을 읽는 코드를 번갈아 반복하면 프레임 하나 안에서 레이아웃이 여러 번 실행되어 느려집니다.

애니메이션을 만들 때 left 대신 transform을 쓰라는 조언이 흔한 이유가 여기 있습니다. left를 바꾸면 레이아웃부터 다시 계산하지만, transform은 레이아웃과 페인트를 건너뛰고 컴포지트 단계만 다시 실행할 수 있습니다.

메인 스레드와의 관계

레이아웃·페인트 계산 자체는 메인 스레드에서 일어납니다(컴포지트 일부만 별도 스레드가 처리). 01편에서 본 이벤트 루프의 콜 스택이 무거운 자바스크립트 계산으로 계속 채워져 있으면, 그동안 브라우저는 레이아웃·페인트를 실행할 틈이 없어 화면이 멈춘 것처럼 보입니다. 13편의 ResizeObserver, 14편의 requestAnimationFrame은 모두 “언제 레이아웃이 끝나고 다음 프레임이 그려지는 시점”에 맞춰 코드를 실행하기 위한 API입니다.

개발자 도구로 확인하기

const el = document.body;
console.time("read");
for (let i = 0; i < 1000; i++) {
  el.style.width = (300 + i) + "px";
  el.offsetWidth; // 레이아웃 값을 즉시 읽음 → 매번 강제 레이아웃 발생
}
console.timeEnd("read");

확인

• Paint flashing을 켰을 때 페이지 전체가 아니라 실제로 바뀐 영역만 깜빡이는 것을 확인합니다.
• Performance 탭 타임라인에서 Layout, Paint 구간의 이름과 색을 구분할 수 있습니다.
• 콘솔의 offsetWidth 반복 읽기 예제가 눈에 띄게 오래 걸리는 것을 console.time/console.timeEnd 결과로 확인합니다.

직접 해보기

1. 위 콘솔 예제에서 el.offsetWidth; 줄을 지우고 다시 console.time으로 시간을 재봅니다. 읽기를 반복문 밖으로 빼면 얼마나 빨라지는지 비교해봅니다.
2. Performance 탭에서 CSS transform으로 움직이는 애니메이션과 left로 움직이는 애니메이션을 각각 녹화해 Layout 구간 발생 빈도를 비교해봅니다.

자주 하는 실수

확인 문제

참고 자료

• MDN - Populating the page: how browsers work 
• web.dev - Rendering Performance