사용자에게 도착한 페이지가 브라우저에 표현되기 까지의 과정
통신과정을 거치고 이제 브라우저는 해당 선물(DOM 문서) 를 풀고 그것을 사용자 웹페이지에 보여준다.
브라우저는 선물 상자를 풀어 사용자에게 보여주기 까지 4가지의 행위가 필요하다.
- 선물 박스 parsing → Dom Tree, Cssom Tree 생성
- render Tree 생성
- 사용자 화면 비율을 보고 각 레이아웃을 배치한다
- 틀을 그렸으니 색칠한다.
- parsing → html , css Dom Tree 생성
- Render Tree → dom, cssom 기반으로 render 트리 생성
- 페이지를 렌더링 하는데 필요한 노드만 포함합니다.
- 비가시적 요소를 그려놓지 않아요! ex) → { display:none }
- 레이아웃 계산
뷰포트 내에서 각 요소의 정확한 위치와 크기를 정확하게 캡쳐합니다.
- 페이팅 단계
각 노드의 크기, 색상, 등 스타일 계산은 이미 레이아웃단계에서 마쳤으니각 노드를 화면의 실제 픽셀로 변환해요!
그런데 이걸 왜 알아야 할까요?
사용자와 상호작용하기 위해 Dom을 조작하는데 비효율적인 부분을 알기 위해서 알아야 해요!
Reflow, Repaint
사용자에가 웹 페이지 접속하면 위 4가지 과정을 거쳐 화면에 보여집니다.
사용자가 메뉴 버튼을 누르면 메뉴바가 옆에서 툭 튀어나오, 다시 들어가고 하는 행위가 일어난다고 가정해볼게요!
메뉴가 툭 튀어나오고, 다시 들어가는 각 일련의 행위를 “이벤트” 라는 단어로 취급해요
이러한 이벤트로 인해 기존 있었던 레이아웃의 변화 그리고 레이아웃 변화로 픽셀도 영향을 받게 되요!
즉, 레이아웃 그리기, 페인팅 단계가 다시 발생되어야 합니다. 그러면 렌더트리를 재생성해야겠죠?
렌더트리 생성, 레이아웃 과정을 다시 수행하는 것이 ⇒ Reflow 현상
해당 화면을 다시 그리기 ⇒ Repaint 현상
해당 과정이 빈번하게 발생되면 사용자에게 화면이 보이는데 느려서 답답함을 느끼고 사이트를 접속안하겠죠 ㅠㅠ
그렇기 때문에 최대한 dom을 과도하게 조작하면 문제가 생겨요.
그래서 렌더링 과정을 알고 어디에서 해당 문제가 될 수 있는 지 파악할 수 있는 수단이 될 수 있기도 합니다.
그리고 DOM 조작을 미리 하면 오류가 발생될 수 있으니 각 적절한 라이프 사이클에서 DOM을 조작해야 합니다!
참고)Reflow → RePaint
- Reflow가 일어나면 반드시 Repaint가 일어나요
- Repaint만 발생하면 ReFlow는 발생하지 않아요
다음은 리플로우(Reflow)가 일어나는 대표적인 속성들입니다.
position, width, height, margin, padding, border, border-width, font-size, font-weight, line-height, text-align, overflow
다음은 리페인트(Repaint)만 일어나는 대표적인 속성들입니다.
background, color, text-decoration, border-style, border-radius
