브라우저 기본 구조
User Interface
주소창, 뒤로가기/앞으로가기 버튼, 즐겨찾기 기능등을 포함하며 브라우저 중 웹페이지 표시부분(document)을 제외한 거의 모든 부분에 해당.
Browser Engine
렌더링 엔진에 질의를 보내며, 조작하는 인터페이스
Rendering Engine
요청된 콘텐츠를 화면에 뿌려주는 기능을 담당함. (전송된 HTML과 CSS 등을 파싱하여 디스플레이)
Networking
HTTP 리퀘스트와 같은 네트워크 통신기능 수행.
UI Backend
브라우처 창의 형태나 셀렉트버튼, 체크박스 등을 표현함. OS의 UI 메소드에 의존함. (XP에서의 셀렉트박스와 윈도우7에서의 셀렉트박스가 다른 것을 생각하면 이해가 쉬움)
Javascript Interpreter
자바스크립트 코드의 파싱과 실행에 사용 (유명한 것이 바로 Chrome의 V8 엔진)
Data Storage
지속적인 계층(쿠키 등을 위한 저장공간). HTML5에서는 웹DB가 해당됨.
브라우저 동작 과정
특정 url로 요청을 하면 브라우저는 서버로부터 HTML, CSS, Javascript, 이미지 파일 등을 응답받는다.
브라우저의 렌더링 엔진을 통해 여러 과정을 거쳐 화면에 보여진다.
parsing 및 DOM, CSSOM 생성
1. 브라우저가 이해하고 사용하도록 파서를 통해 파싱과정을 거친다.
HTML, CSS파일은 각각 다른 파서를 사용하며 파싱 후에
HTML -> DOM (Document Object Model) 트리
Style Sheet -> CSSOM (CSS Object Model) 트리로 변환
-
Attach 진행, 렌더트리 생성
1에서 생성한 DOM, CSSOM 트리를 이용해 실제 렌더링에 사용할 트리를 생성한다. 이 과정에서 script, meta tag, hidden(css) 같이 렌더링에 반영되지 않는 노드들은 렌더 트리에서 생략된다. -
Layout
생성된 렌더 트리를 토대로, 뷰포트 내에서 노드의 정확한 위치와 크기를 계산한다.이 단계에서 상대적 단위들은 모두 px로 계산된다.
레이아웃 변화가 생기는 경우 계산이 다시 이루어져서 Reflow라고 부름 -
Paint
뷰포트에 위치할 계산이 완료되면 화면에 그리는 단계 즉 Paint를 진행한다.
단순하고 작은 규모의 문서일수록 빠르다. 고급효과 사용하거나 문서규모가 커지면 시간이 더 걸린다.
레이아웃변화 생기면 reflow발생하고 다시 paint를 하게 되며, 이 과정을 Repaint라고 한다.
+)
script태그는 렌더링엔진이 아닌 자바스크립트 엔진에서 처리하게 되는데, HTML 파서는 script 태그를 만나면 자바스크립트 코드를 실행하기 위해 DOM 생성 프로세스를 중지하고 자바스크립트 엔진으로 제어 권한을 넘긴다. 브라우저는 동기(Synchronous)적으로 HTML, CSS, Javascript을 처리한다. 이것은 script 태그의 위치에 따라 블로킹이 발생하여 DOM의 생성이 지연될 수 있다는 것을 의미한다. 따라서 script 태그의 위치는 중요하다
해결법 ) body태그 최하단에 script 태그를 쓰는 것
React, Next에서는 분리하여 태그 사용하면 고려할 일이 없는가?
레이아웃단계에서 변화가 일어나 reflow 발생하면 렌더링 성능 저하시킨다.
Reflow 발생할 수 있는 원인을 최소화 한다.
Reflow는 퍼포먼스 측면에서 매우 고비용발생시킨다. 페이지 전체를 다시한번 레이아웃시키는 결과를 초래하는 경우가 빈번하다.
무엇이 Reflow를 유발하는가?
특정 엘리먼트에 스타일변화 발생하면 해당 개체가 가진 자식요소에 대한 레이아웃 재정리를 위해 Reflow 발생. 작은 변화에도 자식개체 및 페이지 전체에 Reflow 실행된다.
- Mozilla에 따른 Reflow 발생 케이스
윈도우 리사이징
폰트의 변화
스타일 추가 또는 제거
내용 변화 (인풋박스에 텍스트 입력 등..)
:hover와 같은 CSS Pseudo Class
클래스 Attribute의 동적 변화
JS를 통한 DOM 동적 변화
엘리먼트에 대한 offsetWidth / offsetHeight (화면에서 보여지는 좌표) 계산시
스타일 Attribute 동적변화
Reflow를 피하거나 영향 최소화 방법
1. 클래스 변화에 따른 스타일 변화를 원할 경우, 최대한 DOM 구조 상 끝단에 위치한 노드에 주어라.
DOM 트리에서 가급적 말단에 위치한 노드에 위치시켜 리플로우의 행동반경을 제한하자. 전체 페이지를 감싸는 wrapper에 클래스를 수정하는 행위는 꼭 피한다. 또한 OOCSS 방식을 통해 클래스변화가 발생할 경우 리플로우의 영향을 최소화하여 퍼포먼스 이득을 볼 수 있다.
2. 인라인 스타일을 최대한 배제하라.
인라인상에 스타일이 주어진 경우, 리플로우는 페이지 전체에 걸쳐 수차례 발생. 인라인스타일이 없다면 외부스타일 클래스 조합으로 단 한번의 리플로우 발생
- 애니메이션이 들어간 엘리먼트는 가급적 position:fixed 또는 position:absolute 로 지정하라.
JS (특히 jQuery)나 CSS3로 width/height 또는 위치이동을 구현한 애니메이션은 초단위로 리플로우 일으킨다. 해당 경우에 position을 fixed 혹은 absolute로 주면 다른 요소에 영향을 끼치지 않아서 페이지 전체의 Reflow대신 해당 애니메이션 요소의 Repaint만을 유발한다.
4. 퀄리티와 퍼포먼스 사이에서 타협하라.
5. 테이블 레이아웃을 피하라.
테이블로 구성된 페이지 레이아웃은 점진적 페이지렌더링 적용되지 않는다. 모두 로드, 계산된 후에 화면에 뿌려진다. 테이블 레이아웃은 아주 작은 변화에도 해당 테이블 전체 노드에 대한 리플로우를 발생시킨다. table-layout:fixed 속성을 주는 것이 디폴트값인 auto에 비해 성능면에서 더 좋다고 한다.
6. JS를 통해 스타일변화를 주어야 할 경우, 가급적 한번에 처리하라.
여러번에 거쳐 스타일 변화를 주지 말고 한번에 처리
7. CSS Rules는 필요한 만큼만 정리하라.
8. position:relative 사용 시 주의하자.
css calculation 이 발생할 경우, Box model Calculation (margin, border, padding, content(width,height) 등 ) -> Normal Flow 순서로 계산이 진행됨 (Normal Flow 는 Layout 혹은 Reflow 과정의 일부)
-1 Box model Calculation에 의한 계산
-2 Normal flow에 의해 선형적으로 배치
Box model 계산 후, 마크업 순서에 따라 화면 내 배치를 실행한다. (단, position:absolute 또는 fixed일 경우 Normal flow를 거치지 않고 Out of flow 즉, 곧바로 Positioning을 진행한다.)
-3 Normal Flow 이후
case 1. Float 속성을 가진 요소
Normal flow 이후 별도의 Positioning 계산은 없으며, 왼쪽 또는 오른쪽으로 자신이 갈수있는 한 끝까지 이동한다.
(Box model → Normal flow → Floating)
caes 2. position:relative;와 함께 top,left 등 위치값을 가진 요소
Normal flow 상태에서 한번 더 Positioning 프로세스를 거치게 된다.
(Box model → Normal flow → Positioning)
case 3. position:absolute 또는 fixed를 가진 요소
Box model 계산 후 Normal flow 과정을 거치지 않고 바로 자신의 위치에 박히게 된다. (Out of flow)
(Box model → Positioning)
결론: position:relative가 오히려 position:absolute 또는 float 속성보다 더 큰 비용을 가진다.
상당수 반복되는 LI과 같은 요소에 position:relative 와 top,left 속성등을 주는 경우, 퍼포먼스 하락이 발생한다.
css 방법론?
1. OOCSS (Object Oriented CSS)
2. BEM (Block Element Modifier)
3. SMACSS (Scalable and Modular Architecture for CSS)
