브라우저 렌더링 엔진 동작과정은 크게 4~6단계로 이루어진다!
1. HTML,CSS 파싱
2. DOM Tree 구축, CSSOM Tree 구축
3. 렌더 트리 구축
4. 렌더 트리 배치(Layout 단계 ⇒ Paint 단계)
5. 렌더 트리를 Reflow해서 그리기
6. Repaint까지
1. 파싱이란?
파싱이란 '(문장을 문법적으로) 분석하다' 라는 뜻으로 하나의 프로그램을 런타임환경 (예를 들면, 브라우저 내 자바스크립트 엔진)이 실제로 행할 수 있게 분석하고 변환해주는 것을 의미한다!
- 파싱은 다운로드한 HTML을 해석하여 DOM 트리를 구성
- HTML 또는 리소스에 CSS가 포함된 경우에는 CSSOM 트리 구성 작업도 함께 진행
DOM 트리 구성
DOM이란 Document Object Model 의 약자로 '문서 객체 모델'을 의미한다!
- 브라우저의 요청에 의해 서버가 응답한 HTML 문서는 문자열로 이루어진 순수한 텍스트
- 순수한 텍스트인 HTML 문서를 브라우저에 시각적인 픽셀로 렌더링하려면 HTML 문서를 브라우저가 이해할 수 있는 자료구조로 변환하여 메모리에 저장
- 브라우저의 렌더링 엔진은 응답받은 HTML 문서를 파싱하여 브라우저가 이해할 수 있는 자료구조인 DOM을 생성
⇒ DOM은 HTML 문서를 파싱한 결과물
⇒ DOM은 웹페이지(웹 문서 document)를 객체로 만들어서 객체를 통한 웹 문서 태그, 스타일, 내용 등을 조작할 수 있도록 함
CCSOM 트리 구성
- 렌더링 엔진이 DOM을 생성해 나가다가 CSS를 로드하는 link 태그나 style 태그를 만나면 DOM 생성을 일시 중단
- link 태그의 href 어트리뷰트에 지정된 CSS 파일을 서버에 요청하여 로드한 CSS파일이나 style 태그 내의 CSS를 HTML과 동일한 파싱 과정(바이트->문자->토큰->노드->CSSOM)을 거치며 해석하여 CSSOM을 생성
- 이후 CSS 파싱을 완료하면 HTML 파싱이 중단된 지점부터 다시 HTML을 파싱하기 시작하여 DOM 생성을 재개
2. Render Tree 생성
DOM + CSSOM 트리를 가지고 렌더 트리를 만든다!
DOM Tree와는 달리 Render Tree에는 스타일 정보가 설정되어 있으며 실제 화면에 표현되는 노드들로만 구성
- 브라우저의 최적화를 위해 RenderTree가 있는 것!!
- DOM Tree → CSSOM Tree ⇒ RenderTree
- 브라우저마다 사용하는 렌더링 엔진은 다양하다
3. Layout 단계
레이아웃 단계에서는 노드의 정확한 위치와 크기를 계산 후 렌더트리에 반영!
css박스 모델링에 의해서 각 돔 노드가 레이아웃을 잡게되고 후에 페인트 과정을 통해 레이아웃이 잡힌 놈 노드에 픽셀이 찍히게 된다
4. Paint 단계
Layout 단계가 완료되면 요소들을 실제 화면에 그리게 된다. 이 단계를 페인팅 단계라고 한다!
따로 업데이트가 없다면 위 과정에서 마무리되지만 웹페이지상 css나 js 이벤트가 일어나면 다시 레이아웃을 배치하고 repaint를 해야된다!
5. ReFlow 단계
렌더트리를 재생산하는 과정이다. 새로운 HTML 요소가 추가되거나, 기존 태그들의 스타일이 변경되면 렌더트리와 각 요소들의 크기와 위치를 다시 계산하게 되는데, 이러한 과정을 Reflow라고 한다.
5. RePaint 단계
Repaint는 Reflow가 끝난 후 재생성된 렌더 트리를 다시 그리는 과정을 말한다.
리플로우 단계는 변경사항을 반영하기 위해 렌더트리를 다시 생성하고 레이아웃 과정을 다시 수행하는 것이고, 실제 화면을 그리기 위해서는 다시 페인팅 단계를 수행해야하는데, 이 과정을 RePaint라고 한다.
*** 항상 리플로우 -> 리페인트 단계를 거치는게 아니고 레이아웃에 영향을 미치지않는 background-color 변경 같은 경우는 바로 리페인트만 수행하게 된다!
Reflow와 Repaint가 실행되는 시점
Reflow
- DOM 엘리먼트 추가, 제거 또는 변경
- CSS 스타일 추가, 제거 또는 변경
- CSS 스타일을 직접 변경하거나, 클래스를 추가함으로써 레이아웃이 변경 될 수 있음
- 엘리먼트의 길이를 변경하면, DOM 트리에 있는 다른 노드에 영향을 줄 수 있다
- CSS3 애니메이션과 트랜지션. 애니메이션의 모든 프레임에서 리플로우가 발생
- offsetWidth 와 offsetHeight 의 사용. offsetWidth 와 offsetHeight 속성을 읽으면, 초기 리플로우가 트리거되어 수치가 계산
- 유저 행동. 유저 인터랙션으로 발생하는 hover 효과, 필드에 텍스트 입력, 창 크기 조정, 글꼴 크기 변경, 스타일시트 또는 글꼴 전환등을 활성화하여 리플로우를 트리거할 수 있다
Repaint
- 가시성이 변경되는 순간 (opacity, background-color, visibility, outline)
- Reflow 가 실행된 순간 뒤에 실행
[웹페이지 속도 최적화 방법]
1. 웹 페이지 로드 최적화
(1) 브라우저 상에서 최적화
DOMContentLoaded : html, css 파싱 끝난 시점 , 렌더 트리를 구성할 준비가 된(DOM 및 CSSOM 구성이 끝난) 상황
→ 페이지가 로딩될 때 보이는 처음 흰색 창
Loaded : html 상에 모든 리소스가 load된 시점 → 흰색 창이 끝나고 보이는 웹페이지
(2) 사용자 상에서 최적화
사용자 기준의 성능 측정은 사용자에 따라서 주관적 + 상대적이다!!
***시점
FP(First Paint)
흰 화면에서 화면에 무언가가 처음으로 그려지기 시작하는 순간
FCP(First Contentful Paint)
텍스트나 이미지가 출력되기 시작하는 순간
FMP(First Meaningful Paint)
사용자에게 의미 있는 콘텐츠가 그려지기 시작하는 첫 순간. 콘텐츠를 노출하는데 필요한 CSS, 자바스크립트 로드가 시작되고 스타일이 적용되어 주요 콘텐츠를 읽을 수 있다.
TTI(Time to Interactive)
자바스크립트의 초기 실행이 완료되어서 사용자가 직접 행동을 취할 수 있는 순간
***사용자 기준에서 성능을 좋게 하기 위해서 FMP를 앞당겨야 한다!!
대기중(TTFB) : 초기 응답(Time To First Byte)을 기다리는 데 소비한 시간 (서버 왕복 시간)
콘텐츠 다운로드 : 리소스 실제 다운로드 시간
2. 웹 페이지 로딩 최적화
2.1 CSS 최적화
- HTML 문서 최상단(<head> 아래)에 배치
DOM 트리는 파싱 중 태그를 발견할 때마다 순차적으로 만들어갈 수 있지만 CSSOM 트리는 CSS를 모두 해석해야만 구성 가능!
→ 렌더 트리는 돔 트리와 CSSOM 트리를 모두 만들어야만 만들 수 있는데 CSSOM이 만들어지지 않으면 렌더 트리가 차단되는 문제가 발생한다!
→ 이런 문제 때문에 CSSOM을 렌더링 차단 리소스라함
→ 이런 문제 발생하지 않기 위해 HTML 문서 최상단(<head> 아래)에 배치!!
- 외부 스타일시트를 가져올 때 사용하는 [@import](<https://developer.mozilla.org/ko/docs/Web/CSS/@import>) 사용은 피한다. 아래와 같이 @import를 사용했을 때 브라우저는 스타일시트를 병렬로 다운로드 할 수 없기 때문에 로드 시간이 늘어날 수 있다. → 시간 단축
- 가능하다면 내부 스타일시트를 사용한다. → 시간 단축
2.2 자바 스크립트 최적화
- HTML 문서 최하단(</body> 직전)에 배치
<script> 태그를 만나면 스크립트가 실행되며 그 이전까지 생성된 DOM에만 접근할 수 있다.
스크립트가 실행 완료가 될 때까지 돔 트리는 생성되지 않는다.
외부에서 가져오는 자바스크립트의 경우에는 모든 스크립트가 다운로드되고 실행될 때까지 DOM 트리 생성이 중단된다.
—> 이러한 이유로 자바스크립트도 렌더링 차단 리소스
2.3 리소스 요청 수 단축
1. 이미지 스프라이트 방법
예를들어 한 페이지에서 사용되는 이미지가 5개 있으면 리소스 요청을 5번 하게되는데 이것을 한번으로 줄일 수 있는 방법!!
—> 이미지 좌표 쉽게 찾아주는 웹사이트!
.kakao-icon {
background-image: url(./images/icon-sprite.png);
background-position: 10px 10px;
width: 45px;
height: 45px;
}
**** 이미지 스프라이트로 발생할 수 있는 단점 :::
- More development time for slicing images, combining them, and programming background positions in the CSS.
- More maintenance time. Whenever a modification is needed, the whole sprite needs to be re-generated carefully
- Less SEO friendly. Some images are better be placed in the HTML rather than being backgrounds. HTML images can contain Titles and Alternative texts that are more beneficial to SEO, while CSS backgrounds cannot.
2. CSS, 자바스크립트 번들
분리된 리소스를 사용하는 경우 (최적화 전)
<html>
<head>
<link href="foo.css" rel="stylesheet" />
<link href="bar_baz.css" rel="stylesheet" />
</head>
<body>
<div id="foo">...</div>
<script async src="foo.js" type="text/javascript">
</script>
<script async src="bar.js" type="text/javascript">
</script><script async src="baz.js" type="text/javascript">
</script>
</body>
</html>
번들된 리소스를 사용하는 경우 (최적화 후)
<html>
<head>
<link href="bundle.css" rel="stylesheet" />
</head>
<body>
<div class="foo">...</div>
<script async src="bundle.js" type="text/javascript">
</script>
</body>
</html>
2.4 리소스 용량 줄이기
- 중복 코드 삭제하기
- 불필요한 공백, 주석 제거
- 중복되는 css는 id가 아닌 class 사용으로 묶어주기
- 압축하여 사용하기
압축 프로그램 사용하기
JPEG 대신 WebP 사용하면 평균 20 30 프로 정도 크기 감소를 시킬 수 있음
3.웹페이지 렌더링 최적화
3.1 레이아웃 최적화
렌더링 과정에서 레이아웃은 DOM 요소들이 화면에 어느 위치에 어떤 크기로 배치될지를 결정하게 되는 계산 과정
HTML, CSS 최적화
화면을 렌더링하기 위해서 필요한 데이터는 HTML과 CSS로, 각각 DOM트리와 CSSOM 트리를 만들고 렌더 트리를 만들 때 사용된다. DOM트리와 CSSOM 트리가 클수록 더 많은 계산이 필요하다. 그러므로 HTML과 CSS를 최적화하여 렌더링 성능을 향상시켜야 함
- DOM 깊이 최소화하기
- 애니메이션을 JS 보단 CSS로 하기..? → 속도 단축CSS has fairly good performance as it offloads animation logic onto the browser itself. This lets the browser optimize DOM interaction and memory consumption and most importantly, uses the GPU to improve performance. On the other hand, Javascript performance can range from reasonably faster to much slower than CSS. Javascript performance depends on the library used and puts the burden on the developer to optimize. For example, JQuery is a commonly used library but is notorious for slow animation performance because it is not designed with animation in mind. adding Javascript libraries creates more overhead and can increase page load times especially for mobile devices.
- https://www.seguetech.com/animation-css-vs-javascript/
- ***진짜로 그럴까?? :: 맞음
https://getlevelten.com/blog/ahmad-kharbat/css-image-sprites-pros-and-cons
https://velog.io/@suminllll/Reflow-RepaintNetwork
https://developer.mozilla.org/en-US/docs/Glossary/Parse
https://ui.toast.com/fe-guide/en_PERFORMANCEhttps://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction
'Frontend' 카테고리의 다른 글
| url 상태관리 (0) | 2024.07.15 |
|---|---|
| moduleResolution이란 (0) | 2024.06.08 |
| Button 태그에 type을 명시하면 좋은 점 (0) | 2023.07.25 |
| 🎵바닐라 JS로 크롬 앱 만들기🎵 (0) | 2022.03.21 |
| < Flex 정리 > (0) | 2022.03.10 |
