Web Performance
A to Z -> C :Dali
Web Performance
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
1. Intro & Quiz
2. Base: - 브라우저 렌더링 과정 (feat.CRP)
4. 정리하며 + 퀴즈 답 살펴보기
1. Intro & Quiz
1. Intro
특히 느린 네트워크를 만날 때
화면 로드가 어떻게 되는지에 따라 UX가 천차만별 !
1. Intro
사실... 웹 성능 크게 관심 없었습니다.
특히 우리나라 인프라가 너무 잘 갖춰져 있어서 ...
But...
LightHouse 를 돌려보기 전 까지는요....
Text
Text
Text
성능 측정도구로 돌려본 결과 참담한 결과
지금은 그래도 4점이지만... 최소 30점이 목표입니다 :)
이따가 다뤄볼 것이지만 한 번
Audits/ LightHouse 실행을 한 번 같이 살펴보기로 합시다 :)
2. 성능 측정에 영향을 줄 수 있으므로 탭은 하나만 띄워서 진행합니다
1. 시크릿 창을 띄운다.
3. chrome://extensions/ 으로 들어가셔서 측정할때는
모두 disable합시당 :)
4. clear storage(no cache) 및 desktop mobile 설정 보고 클릭
DCL,
FMP,
L
를 잘 기억해둡시다.
Quiz :D
01 브라우저가 렌더링 하는 과정에 대해서 설명해주세요 :)
01.2 렌더링은 언제 중단시키는 요소들은 무엇일까요?
02 사용자에게 의미 있는 컨텐츠를 보여주는 시간을 나타내는 용어를
무엇이라고 할까요?
03 리소스 최적화 방법중 틀린 것을 고르세요
* css파일 갯수를 줄인다.
* 서버사이드 렌더링을 사용하여 FMP를 빠르게 한다.
* minify하여 용량을 줄인다.
* 이미지 스프라이트를 사용하여 네트워크 요청을 줄인다
Quiz 02 :D
04 크리티컬 렌더링 패스에 대해서 설명해주세요
05 다른 곳에서 참조하고 있는 DOM Node를 삭제할 경우
자연스럽게 Garbage Collector에 대상이 되서 삭제 된다.
06 HTML에 포함된 JS는 html Parsing을 중단 시킨다? (O,X)
2. Base: How to render page
W3C navigation Timing
FE Processing - OnLoad
브라우저가 렌더 하는 과정
PARSE ->STYLE -> LAYOUT (Reflow)-> Paint->Composition
단방향으로 발생 즉, LayOut이 변하면 Paint, Render를 다시 하는 과정
DOMTree-CSSOMTRee-RenderTree바탕으로LayOut-Paint-Composition진행
브라우저가 렌더 하는 과정 1.PARSE
style download -> cssom 트리 구축 작업
HTM 파싱 -> script, link, img 등 자원 요청 태그 많다면 요청 및 다운로드
브라우저가 렌더 하는 과정 2.STYLE
1. 렌더에 반영되지 않는 meta, link, script같은 태그는 넘어가고 <strong> <em> 요런 tag도 넘어가겠쥬
2. display:none과 같은 감춘노드도 렌더트리에서 제외
3. 노드에 중첩된 스타일 반영 cascade style
브라우저가 렌더 하는 과정 2.STYLE
DOM 트리의 CSSOM-> RenderTree를 만드는 과정
이를 바탕으로 LayOut Paint가 진행 !
브라우저가 렌더 하는 과정 2.STYLE
ParseCss-CSSOM-Style적용 이 부분이 재귀적 적용
Recaculate Style
브라우저가 렌더 하는 과정 3.LayOut
브라우저가 렌더 하는 과정 3.LayOut
뷰포트 안의 노드가 가져야 할 위치와 크기 계산
루트노드를 순회 하면서 계산
Dirty Bit Sysytem -> 새롭게 추가 될 때 자신(dirty , children)
(글꼴, 뷰포트-> 글로벌)
브라우저가 렌더 하는 과정 3.LayOut
부모, root-node, window -> width
Contents - (img, text)-> height
boxmodel, block
브라우저가 렌더 하는 과정 4.PAINT
화면상의 실제 픽셀로 변환 -> 색상, 투명도 등 적용
브라우저가 렌더 하는 과정 5.COMPOSITE
브라우저가 렌더 하는 과정 5.COMPOSITE
memory: heap memory 추이
screenshots : 시간에 따른 렌더화면
gc: 강제로 gc를 수행할 수 있음
FCP: First Paint
FMP: First Meaningful Paint
DCP : DomcontentLoaded
L: Load 이벤트
마우스 휠로 확대-축소 ,
영역 선택 범위 클릭-클릭 - 더블클릭 나가기
끝 -> 최적화로 :)
렌더 트리 생성 :) Display: none 같은 경우 제외된다.
다음은 브라우저의 단계를 빠르게 되짚어 보겠습니다.
- HTML 마크업을 처리하고 DOM 트리를 빌드합니다.
- CSS 마크업을 처리하고 CSSOM 트리를 빌드합니다.
- DOM 및 CSSOM을 결합하여 렌더링 트리를 형성합니다.
- 렌더링 트리에서 레이아웃을 실행하여 각 노드의 기하학적 형태를 계산합니다.
- 개별 노드를 화면에 페인트합니다.
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
최적화 기준 브라우저 & 사용자 물론 User
First Meaningful Paint 최적화
Loading 시간이 같아도 경험이 많이 다를 수 있다 !
FMP 정의(계속 update중) 주요 콘텐츠 렌더링
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
JS dom | css 조작
style-> layout-> paint -> composite
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
최적화 CSS는 최상단에 위치
media query 적절히 사용 -> 필요할 때만 적용됨 ex)print
<link href="print.css" rel="stylesheet" media="print">
인라인 css -> build파일을 인라인 형태로 네트워크 요청을 줄인다.
<head>
<link href="style.css" rel="stylesheet">
</head>CSS 최적화 기법 259kb-> 9kb로 줄인 사례
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
JS async & defer ie>=10
async 순서 보장 x
defer 순서보장
3. 웹 페이지 로딩 최적화 및 렌더링 최적화
최적화 기법
1. Script 태그는 html parsing 최대한 한 후에 처리
body 밑 | async defer 이용
render block 요소
Example fmp 1,2,3
3.2 렌더링 최적화
Reflow 가 언제 발생하는지
DOM Tree 추가 삭제
CSS 속성 width, height, font-size, line-height, position 변경시
반면에 color, background-color, visibility ... 는 repaint진행
Reflow부터 안 가고 Repaint 진행할 수 있게 하면 빠르겠지유
3.2 렌더링 최적화
CSS 규칙 최적화 -> BEM, SMACS
공통 스타일 통일
DOM depth 적을수록 + 가능한 자식노드의 스타일을 변경
display:none-> 수정하는 경우 layout 동작 안 함
3.2 리소스 최적화
네트워크 요청 줄이기
실제 리소스 용량 줄이기
HTTP 1-> 동시에 6개의 TCP 연결만 가능
하나의 js, css 파일 사용 웹팩 bundling
이미지 스프라이트 , 단순한 벡터 icon-> svg사용
minify
애니매이션
setTimeOut, setInterval보단 , requestAnimationFrame을 적극 사용
1.기본 browserFrame주사율 60fps에 맞춰서 실행
2.프레임 시작시 컬백이 호출 setTimeOut, Interval은 종료시 호출
3.페이지가 보이지 않으면 렌더링 발생 안함
60FPS
ETC
JS로 style조작하지 말고 클래스로 한 꺼번에 처리
DOM 추가 한 꺼번에 조작 하기
모아서 innerHTML 활용
myelement.style.width = '100px';
myelement.style.height = '200px';
myelement.style.margin = '10px';3번 리플로우 발생
TransForm처럼 Composite영역만 처리하는 것을 적극 활용할 것 ! but 맹신 (x) gpu처리가 또 너무 많아지면 성능 저하
Deview 발표에서는 30개가 넘어가면 성능이 저하된다고 한다.
강제동기 LayOut
Layout_trashing.html
Memory 해제
참조되고 있으면 DOM에서 삭제해도 해제
* debounce -> input
* scroll및,LayOut ->
Intersection Observer API
알고 계신 성능 최적화 팁 같은 걸
Notion 에 공유 같이 하면 어떨까요?
4.정리
* 결국 필요한 만큼만 자원 요청 동적 로드 (Lazy Loading)
* 중복 제거 및 네트워크 요청 줄이기