성능 최적화

TOAST UI의 성능 최적화를 보고 정리한 글입니다.

목차

성능 최적화에 필요한 이론과 측정 도구

• 브라우저의 로딩 과정
• 레이아웃과 리페인트
• 블록 리소스와 주요 렌더링 경로
• 성능 개선 지표
• 성능 측정 도구

웹 페이지 로딩 최적화

• 블록 리소스(CSS, 자바스크립트) 최적화
• 리소스 요청 수 줄이기
• 리소스 용량 줄이기

웹 페이지 렌더링 최적화

• 레이아웃 최적화
• 애니메이션 최적화

맺음말

---

성능 최적화에 필요한 이론과 측정 도구

브라우저의 로딩 과정을 다루고, 각 과정에서 사용되는 용어와 성능을 측정하는 데에 사용되는 지표를 설명한다. 성능 측정 도구로 크롬 개발자 도구를 살펴본다.

---

브라우저의 로딩 과정

브라우저는 웹 페이지에 필요한 리소스를 내려받고 해석한 다음 여러 계산 과정을 거쳐 콘텐츠를 화면에 보여준다.

이를 브라우저의 로딩 과정이라고 하며 다운로드, 파싱, 스타일, 레이아웃, 페인트, 합성으로 나뉜다.

---

1. 파싱
   • 브라우저에서 웹 페이지를 로드하면 가장 먼저 HTML 파일을 다운로드한다. 파싱은 다운로드한 HTML을 해석하여 DOM 트리를 구성하는 단계이다.
   • 파싱 중 <script /> <link /> <img /> 를 발견하면 각 리소스를 요청하고 다운로드한다. HTML 또는 리소스에 CSS가 포함된 경우에는 CSSOM 트리 구성 작업도 함께 진행한다.
   DOM 트리 구성
   • HTML을 해석해 DOM을 생성한 후 각 DOM 객체를 트리 데이터 구조로 연결해 부모-자식 관계를 갖도록 한다. 각 태그가 DOM 트리의 노드로 생성되고 자식 노드를 참조한다.
   CSSOM 트리 구성
   • 외부 스타일시트 파일이나 내부 스타일시트 파일이 포함되어 있을 경우, CSS를 해석해 CSSOM 트리를 구성한다.
2. 스타일
   • 스타일 단계에서는 파싱 단계에서 생성된 DOM 트리와 CSSOM 트리를 가지고 스타일을 매칭시켜주는 과정을 거쳐 렌더 트리를 구성한다.
   • 렌더 트리에는 렌더링된 출력에 반영될 노드만 포함한다. 일부 노드가 display: none; 속성을 가진다면 렌더 트리에서 제외된다.
3. 레이아웃 - (Geometry Calculate, Layout)
   • 노드의 정확한 위치와 크기를 계산한다. 즉, 노드가 어디에 놓여야 하고, 어느정도 공간을 차지할 지 계산한다.
   • 이 과정에서 추상적인 계산식(% , vw , left ...)을 측정 가능한 픽셀 단위의 값으로 변환한다.
4. 페인트 - (Fragment Fill, Paint, Rasterization)
   • 레이아웃 단계에서 계산된 값을 이용해 렌더 트리의 각 노드를 화면상의 실제 픽셀로 변환(칠한다)한다. 위치와 관계없는 CSS 속성(색상, 투명도 등)을 적용한다.
   • 픽셀로 변환된 결과는 개별 레이어로 관리된다. 이 때 모든 요소가 모두 레이어가 되는 것은 아니고, transform 속성 등을 사용하면 레이어화 된다. (GPU가 처리할 수 있도록 분리시킴. 즉 transform 등의 속성을 사용하면 GPU가 해당 레이어를 그린다.)
5. 합성(composition) & 렌더(render)
   • 페인트 단계에서 생성된 레이어를 합성하여 화면을 업데이트한다. 합성과 렌더 단계가 끝나면 화면에서 웹 페이지를 볼 수 있다.

위의 5단계를 CRP(Critical Rendering Path, 주요 렌더링 경로)라고 부른다.

위 5단계를 수행하는 과정을 렌더링 과정이라고 하는데, 이는 상황에 따라 반복해서 발생할 수 있다.

예를 들어, DOM에 새로운 요소가 추가되어 DOM 트리를 재구성하거나, CSS 속성 값이 변경되어 CSSOM 트리를 재구성하는 경우, 렌더 트리가 재구성된다.

렌더 트리가 재구성되면서 요소에 기하적인 영향(높이, 넓이, 위치)이 있을 경우 레이아웃 이후의 과정을 다시 진행한다. 이를 리플로우(Reflow)라고 한다.

만약 렌더 트리가 재구성 되었을 때, 기하적인 변화가 없었다면 레이아웃 과정을 생략하고 페인트 과정부터 수행하며 이를 리페인트(Repaint)라고 한다.

레이아웃이 일어나면 전체 픽셀을 다시 계산해야 하므로 부하가 크다. 그에 비해서 리페인트는 이미 계산된 값을 이용해 화면을 그리므로 상대적으로 부하가 적다.

 

블록 리소스와 주요 렌더링 경로

브라우저 로딩 초기 단계에서 HTML 파싱이 일어날 때 CSS 또는 자바스크립트로 인해 파싱이 중단될 수 있다. 이를 HTML 파싱 블로킹이라고 표현하며, 블로킹의 원인이 되는 리소스를 블록 리소스(Block resource)라고 부른다. 블록 리소스는 페인트 과정을 지연시키므로, 블록 리소스가 HTML 파싱을 막는 상황이 발생하지 않도록 해야한다. 이를 주요 렌더링 경로 최적화라고하며 이를 통해 페인팅을 빠르게 하고 로딩 속도를 개선할 수 있다.

---

성능 개선 지표

로딩 속도가 느린지를 어떤 기준으로 판단할 수 있을까? 성능 지표의 측정 기준은 크게 브라우저와 사용자로 나눌 수 있다.

---

브라우저 기준의 성능 측정

전통적인 성능 측정 방식은 브라우저에서 발생하는 이벤트를 사용하는 것이었다. 웹 페이지가 로딩될 때 DOMContentLoaded, load 이벤트가 발생하며, 각 이벤트가 발생하는 시점으로 성능을 측정하게 된다. 두 이벤트의 발생 시점이 빠를 수록, 이벤트 발생 구간의 폭이 좁을 수록 성능이 좋다고 할 수 있다.

DOMContentLoaded

• HTML과 CSS 파싱이 끝나는 시점에 발생
• 렌더 트리를 구성할 준비가 된(DOM과 CSSOM 구성이 끝난) 상황

load

• HTML 상에 필요한 모든 리소스가 로드된 시점

개발 패러다임이 변화하면서 DOMContentLoaded, load 이벤트 발생 시점만 가지고 성능을 판단하기 어려워졌다. 최근 많이 사용되는 SPA(Single Page Application)에서는 웹 페이지에 적은 양의 HTML로 DOMContentLoaded, load 이벤트가 일찍 발생할 수 있으나, 이후에 수많은 스크립트 실행으로 인해 여전히 "느린 로딩"이 존재한다. 따라서 새로운 성능 측정 방식이 필요하게 되었다.

사용자 기준의 성능 측정

사용자 기준의 성능 측정은 사용자에게 콘텐츠를 보여주는 여러 시점을 기반으로 한다. 의미 있는 콘텐츠가 처음 보이는 시점이 빠를 수록 성능이 좋다고 판단하며, 이 시점을 앞당길 수 있도록 최적화 해야한다.

구글에서는 사용자가 웹 페이지 로딩이 빠르다, 느리다를 느낄 수 있는 여러 순간을 정의하고 성능을 측정하는 지표로 사용한다.

FP(First Paint)

• 화면에서 무언가가 처음으로 그려지기 시작하는 순간

FCP(First Contentful Paint)

• 텍스트나 이미지가 출력되기 시작하는 순간

FMP(First Meaningful Paint)

• 사용자에게 의미 있는 콘텐츠가 그려지기 시작하는 첫 순간. 콘텐츠를 노출하는데 필요한 CSS, 자바스크립트 로드가 시작되고 스타일이 적용되어 주요 콘텐츠를 읽을 수 있다.

LCP(Largest Contentful Paint)

• 가장 큰 이미지, 텍스트 블록이 화면에서 보여지는 순간

TTI(Time to Interactive)

• 자바스크립트의 초기 실행이 완료되어서 사용자가 직접 행동을 취할 수 있는 순간

이 중 가장 중요한 시점은 FMP인데, 로딩이 끝날 때까지 흰 화면 대신 의미 있는 콘텐츠를 먼저 보여주어 사용자 입장에서 성능을 좋게 느끼게 한다. FMP를 앞당기기 위해서는 주요 렌더링 경로를 최적화하여 해결한다.

과거(2019년 이전)에는 FMP를 주요 지표로 사용했지만 복잡하고, 설명하기 힘들고, 메인 콘텐츠가 로드되는 시점을 종종 틀리기 때문에, W3C Web Performance Working Group에서의 회의와 구글의 조사에 따라서, 더 정확하게 페이지의 주요 콘텐츠가 로드되는 순간을 위한 지표로 LCP를 사용한다. (참고)

 

성능 측정 도구

크롬 브라우저에서는 개발자 도구를 제공하며, 이를 사용해 위에서 설명한 내용을 눈으로 확인할 수 있다. 성능과 관련된 패널로는 Network, Performance, Lighthouse 등이 있다.

---

Performance 패널

• 웹 페이지의 로딩 단계를 차트 형태로 살펴볼 수 있다. 웹 페이지가 로딩되는 과정을 레코딩하고 단계마다 걸리는 시간을 확인할 수 있다. 로딩 과정에서 최적화가 필요한 부분을 찾을 때 사용한다.

Network 패널

• 웹 페이지가 로딩되는 동안 요청된 리소스의 상태를 차트 형태로 확인할 수 있으며, 리소스 최적화 상태를 비교할 때 사용한다. 각 리소스의 서버 요청 대기 시간을 자세히 볼 수 있다.

리소스의 서버 요청 대기 시간

• • Queuing : 대기열에 쌓아두는 시간 
    • 자바스크립트, CSS보다 우선순위가 낮아서 대기한다.
    • TCP 소켓 대기
    • TCP 연결 초과 대기
    • 디스크 캐시 항목 작성 소요 시간
  • Stalled : 요청을 보내기 전의 대기 시간
    • Queuing에서 쌓인 대기 시간 소모
    • 프록시 협상에 드는 시간
  • Waiting(TTFB) : 초기 응답(Time to First Byte)을 기다리는 데 소비한 시간 (서버 왕복 시간)
  • Content Download : 리소스 실제 다운로드 시간

Lighthouse 패널

• 사용자 기준의 성능 측정 지표를 확인할 수 있다. 측정 전 화면에서는 어떤 환경에서 성능을 측정할지 선택할 수 있다.
  • Metrics : 다양한 성능 측정 지표를 보여주는 영역
    • FCP, TTI, LCP 시점을 확인 할 수 있다.
  • Opportunities : 최적화 가능한 리소스 목록을 보여주는 영역
  • Diagnostics : 리소스 최적화 외에 성능을 개선할 수 있는 부분을 진단하고 해결 방안을 목록으로 보여주는 영역
  • Passed audits : 성능 측정 기준과 통과 목록을 보여주는 영역

 

웹 페이지 로딩 최적화

주요 렌더링 경로를 기반으로 최적화를 진행해보자.

---

블록 리소스(CSS, 자바스크립트) 최적화

브라우저 로딩 과정에서 파싱 중 블로킹이 일어날 수 있으며, CSS와 자바스크립트가 블록 리소스에 해당한다고 했다.

최적화의 첫 번째 단계는 이 블록 리소스를 최적화하는 것이다.

1. CSS 최적화
   • 렌더 트리를 구성하기 위해서는 DOM 트리와 CSSOM 트리가 필요하다. DOM 트리는 파싱 중에 태그를 발견할 때마다 순차적으로 구성이 가능하지만, CSSOM 트리는 CSS를 모두 해석해야 구성할 수 있다.(Cascading 특성 때문) 즉, CSSOM 트리가 구성되지 않으면 렌더 트리를 만들지 못하고 렌더링이 차단된다.
   • 이러한 이유로 CSS는 렌더링 차단 리소스(Render Blocking Resource)라고 하며, 렌더링이 차단되지 않도록 CSS는 항상 HTML 문서 최상단(<head> 아래)에 배치한다. (HTML이 모두 파싱됐을 때, CSS가 모두 해석되어 CSSOM 트리가 만들어져 있으면 베스트, 아니더라도 최대한 빠르게 CSS를 해석한다.)외부 스타일시트를 가져올 때 @import 사용을 피한다. @import 를 사용할 경우, 브라우저가 스타일시트를 병렬로 다운로드 할 수 없기 때문에 로드 시간이 늘어날 수 있다.
   • 특정 조건에서만 필요한 CSS가 있을 때 미디어 쿼리를 사용하여 불필요한 블로킹을 방지한다.(특정 경우에만 해당 CSS를 로드할 수 있도록 <link> 태그에 media 속성을 명시하여 사용한다.
2. 자바스크립트 최적화
   • 자바스크립트는 DOM 트리와 CSSOM 트리를 동적으로 변경할 수 있기 때문에 HTML 파싱을 차단하는 블록 리소스이다. <script> 태그를 만나면 스크립트가 실행 되며 그 이전까지 생성된 DOM에만 접근할 수 있다.
   • 스크립트 실행이 완료될 때까지 DOM 트리 생성이 중단된다. 외부에서 가져오는 자바스크립트의 경우 모든 스크립트가 로드되고 실행될 때까지 DOM 트리 생성이 중단된다.만약 <head> 아래에 포함되어 있거나 HTML 내부에 <script> 태그가 포함되어 있을 때에도 <script> 태그에 defer 나 async 속성을 명시하면 HTML 파싱을 멈추지 않게 할 수 있다. 브라우저 지원 범위에 유의한다.
   • 이러한 이유로 자바스크립트도 렌더링 차단 리소스라고 하며, HTML 문서 최하단(</body> 직전)에 배치한다.

 

리소스 요청 수 줄이기

CSS, 자바스크립트, 이미지 등 웹 페이지에 포함된 리소스는 서버 요청 후 다운로드되어야 사용할 수 있다. 리소스 파일 하나를 요청하는 데 많은 시간이 소요(요청에 필요한 시간)되므로, 필요한 요청만 할 수 있도록 최적화 해야 한다.

---

1. 이미지 스프라이트 - 여러 개 이미지를 하나로 만들고, CSS의 background-position 속성을 사용해 이미지의 일부분을 사용하는 방법
   • 아이콘마다 다른 이미지 파일을 사용할 경우 리소스 요청이 여러번 발생한다. 이런 경우 요청 시간을 줄이기 위해 이미지 스프라이트 기법을 사용하여 요청을 1번으로 줄인다.
2. CSS, 자바스크립트 번들링하기
   
   • 모듈 기반의 개발 방식이 등장하기 전까지 분리된 여러 개의 리소스 파일을 가져와 사용했었다. 이 경우 webpack 과 같은 번들러를 이용하여 CSS, 자바스크립트 파일 요청을 줄일 수 있다.
   • 번들러는 여러 개의 모듈 파일을 하나로 묶어서 1개의 파일로 생성해주는데 이것을 번들 파일이라고 한다. 이 번들 파일을 이용하여 리소스 요청을 줄일 수 있다.
3. 내부 스타일시트 사용하기
   
   • <link> 태그로 외부 스타일시트를 가져오는 대신, 문서 안에서 <style> 태그를 사용할 수 있다. 이런 방법을 내부 스타일시트라고 하며, 외부 스타일시트를 가져올 때 발생하는 요청 횟수를 줄일 수 있다.
   • 단, 내부 스타일시트를 사용하면 리소스 캐시를 사용할 수 없어서 HTML에 CSS가 매번 포함되므로 필요한 경우에만 사용한다.
4. 작은 이미지를 HTML, CSS로 대체
   • 웹 페이지에서 사용하는 아이콘 이미지 개수가 적은 경우, 다운로드한 이미지를 사용하는 대신 이미지를 HTML, CSS에 포함해 사용할 수 있다. Data URI로 처리할 수 있다.
   • 외부 이미지를 사용하기 위해 발생하는 요청 횟수를 줄일 수 있지만, 내부 스타일시트를 사용할 때와 마찬가지로 캐시 문제가 있으므로 필요한 경우에만 사용한다.

 

리소스 용량 줄이기

용량이 큰 리소스도 웹 페이지 로딩 시간(다운로드에 필요한 시간)을 느리게 하는 원인이 된다. 각 리소스에 맞게 불필요한 데이터를 제거하고 압축하여 사용하는 것이 좋다.

---

1. 중복 코드 제거하기
   • 자바스크립트 코드 중 자주 사용되는 코드를 공통 모듈로 분리한다. 중복 코드로 늘어나는 용량을 줄일 수 있다.
2. 만능 유틸 사용 주의하기되도록 사용하지 않는 기능이 많이 포함된 라이브러리 사용은 지양한다.
   • lodash 와 같은 만능 유틸 라이브러리를 사용할 때 주의한다. 유틸 함수 전체를 포함하지 말고, 필요한 함수만 부분적으로 가져올 수 있다.
3. HTML 마크업 최적화권장
   • HTML은 태그의 중첩을 최소화하여 단순하게 구성한다. 또한 공백, 주석 등을 제거하여 사용한다.
   • DOM 트리 노드 수는 전체 1500개 미만, 최대 깊이 32개, 자식 노드를 가지는 부모 노드는 60개 미만이다.
   • 불필요한 마크업 사용으로 인해 DOM 트리가 커지는 것을 막고, HTML 파일 용량이 늘어나지 않도록 해야 한다.
4. 간결한 CSS 선택자 사용
   • 스타일을 적용할 때 간결한 CSS 선택자를 사용해 최적화한다. ID 대신 클래스 선택자를 사용하여 중복되는 스타일을 묶어서 처리한다.
5. 압축(Minify)하여 사용하기
   • HTML, 자바스크립트, CSS 모두 압축해서 사용할 수 있으며, 불필요한 주석이나 공백을 제거한 다음 난독화하여 사용한다. webpack 과 같은 도구로 처리할 수 있다.

 

웹 페이지 렌더링 최적화

웹 페이지를 렌더링하기 위해서는 DOM과 CSS가 필요하다. 그러나 다양한 기능과 효과를 구현하기 위해서 자바스크립트를 많이 사용하기 때문에, 자바스크립트가 렌더링 성능에 어떤 영향을 주는지 잘 알아야한다.

또한 자바스크립트는 브라우저에서 단일 스레드로 동작하기 때문에 자바스크립트의 실행 시간은 곧 렌더링 시간과 직결된다. 렌더링은 자바스크립트의 실행 시간과 자바스크립트로 인한 DOM, CSS 변경을 다시 화면에 그리는

시간을 모두 포함한다. 렌더링 성능 최적화는 이러한 소요 시간을 단축하고 화면에 끊김 없이 그리는 것이다.

---

레이아웃 최적화

렌더링 과정에서 레이아웃은 DOM 요소들이 화면에 어느 위치에 어떤 크기로 배치될지를 결정하게 되는 계산 과정이다. 자바스크립트 코드를 통해 DOM을 변경하거나 스타일을 변경할 경우, 변경된 스타일을 반영하고 다시 레이아웃을 해야만 화면에 렌더링할 수 있다. 레이아웃은 글자의 크기를 일일이 계산하고 요소 간 관계를 모두 파악해야 하는 과정이므로 시간이 오래 걸린다.

레이아웃 최적화의 목표는 자바스크립트의 실행 과정과 렌더링이 다시 일어나는 과정에서 레이아웃에 걸리는 시간을 단축하고 레이아웃이 최대한 발생하지 않도록 하는 것이다.

---

자바스크립트 실행 최적화

자바스크립트 실행 시간이 긴 경우, 한 프레임 처리가 오래 걸려 렌더링 성능이 떨어진다. 많은 작업을 수행하는 경우 당연히 오래 걸리지만, 코드가 단순하더라도 불필요한 레이아웃으로 성능 저하가 생길 수 있다. 레이아웃을 줄일 수 있도록 DOM 및 스타일 변경을 최소화해야 한다.

---

1. 강제 동기 레이아웃 최적화
   • DOM의 속성을 변경하면 화면 업데이트를 위해 레이아웃이 일어날 수 있다. 원래 레이아웃은 비동기적으로 일어나지만, 특정 속성 값(computed property ..)을 읽을 때 강제로 동기 레이아웃을 수행한다.
   • 계산된 값을 반환하기 전에 레이아웃을 수행해야 변경 이후의 값을 반환할 수 있으므로 브라우저는 동기로 레이아웃을 수행한다.
   • 따라서 강제 동기 레이아웃을 일으키는 코드를 최대한 사용하지 않도록 한다.
2. 레이아웃 스래싱(thrashing) 피하기
   
   • 한 프레임 내에서 강제 동기 레이아웃이 여러번 일어나는 경우를 레이아웃 스래싱이라고 한다.
   • 코드를 개선하여 강제 동기 레이아웃이 일어나지 않도록 하여 레이아웃 스래싱을 막는다.
3. 가능한 한 하위 노드의 DOM을 조작하고 스타일을 변경
   • DOM을 변경하면 스타일 계산, 레이아웃, 페인트 과정이 모두 필요하며, 조작이나 스타일 변경을 하는 DOM이 상위에 있을 수록 한 프레임에 드는 시간이 길어진다.
     
     • DOM 트리 상위 노드의 스타일을 변경하면 하위 노드에 모두 영향을 미친다.
     • 변경 범위를 최소화 할수록 레이아웃 범위가 줄어든다.
4. 영향받는 노드 제한
   • DOM과 스타일을 변경하면 레이아웃 과정에서 주변의 노드도 영향을 받아 다시 레이아웃을 해야 하는 경우가 있다.
     
     • 부모-자식 관계
     • 같은 위치에 있는 노드
5. 숨겨진 노드 수정
   
   • 노드가 display: none 스타일을 가지고 있으면 DOM 조작과 스타일을 변경하더라도 레이아웃과 리페인트가 발생하지 않는다.
   • display: none 으로 숨겨진 노드를 변경할 경우 레이아웃, 리페인트가 발생하지 않아 성능에 유리하다.
   • visibility: hidden 은 보이지 않아 리페인트는 발생하지 않지만, 공간을 차지하기 때문에 레이아웃은 발생한다.

 

HTML, CSS 최적화

화면을 렌더링하기 위해서 필요한 데이터는 HTML과 CSS로, 각각 DOM 트리와 CSSOM 트리를 만들고 렌더링할 때 사용된다. DOM 트리와 CSSOM 트리를 변경하면 렌더링을 유발하고 트리가 클 수록 더 많은 계산이 필요하다. 그러므로 HTML과 CSS를 최적화하여 렌더링 성능을 향상할 수 있다.

---

1. CSS 규칙수 최소화
   • 사용하는 규칙이 적을수록 계산이 빠르므로 최소화한다.
   • 복잡한 선택자는 스타일 계산에 많은 시간이 걸리므로 사용을 피한다.
2. 노드의 클래스를 변경하면 렌더링이 발생하는데, CSS가 복잡하고 많을 수록 스타일 계산과 레이아웃이 오래 걸린다.
3. DOM 깊이 최소화
   • DOM이 작고 깊이가 얕을수록 계산이 빠르다.
   • 불필요한 래퍼(wrapper) 노드는 제거한다.
4. DOM 트리가 깊을수록, 하나의 노드에 자식 노드가 많을 수록 DOM 트리는 커진다. 그만큼 DOM을 변경했을 때 업데이트에 필요한 계산이 많아진다.

 

애니메이션 최적화

한 프레임 처리가 16ms(60fps) 내로 완료되어야 렌더링 시 끊기는 현상 없이 자연스러운 렌더링을 만들 수 있다. 자바스크립트 실행 시간은 10ms 이내에 수행되어야 레이아웃, 페인트 등의 과정을 포함했을 때 16ms 이내에 프레임이 완료될 수 있다. 애니메이션을 구현할 때 네이티브 자바스크립트 API를 사용하는 것보다 CSS 사용을 권장한다. (자바스크립트 실행의 부하를 줄이기 위해서)

---

1. requestAnimationFrame() 사용
   1. setInterval, setTimeout 과 달리 프레임을 시작할 때 호출되기 때문에 일정한 간격으로 애니메이션을 수행할 수 있다.
   2. 현재 페이지가 보이지 않을 때는(탭 이동 등) 콜백함수가 호출되지 않기 때문에 불필요한 동작을 하지 않는다.
   3. requestAnimationFrame API를 사용하면 브라우저의 프레임 속도에 맞추어 애니메이션을 실행할 수 있도록 해준다.
2. CSS 애니메이션 사용
   • 자바스크립트를 사용한 애니메이션은 성능이 나쁠 수 있다. CSS 애니메이션을 사용하면 자바스크립트를 실행할 필요가 없고, 브라우저가 애니메이션을 처리하는데 최적화되어 있어서 부드러운 애니메이션을 구현할 수 있다.
   • position: absolute 처리
   • 애니메이션 영역이 주변 영역에 영향을 주지 않도록 한다. position 을 absolute 나 fixed 로 설정하면 주변 레이아웃에 영향을 주지 않는다.
   • transform 사용composition 만 발생시키기 때문에 애니메이션에서 사용시 렌더링 속도가 향상될 수 있다.
   • 렌더링시 GPU를 사용할 수 있으므로 성능이 빠르다.
   • 스타일 속성 중 position, width, height 등과 같이 기하적 변화를 주는 속성을 변경하면 레이아웃이 발생한다. transform 을 사용한 노드는 개별 레이어로 분리(브라우저 로딩 과정의 페인트에서 설명)되기 때문에 영향받는 노드가 제한되어 레이아웃과 페인트를 줄일 수 있다.

 

맺음말

2019년에 작성된 글을 보면서 브라우저의 렌더링 과정을 다시 훓어 보면서 렌더링 엔진과 최적화의 중요성을 다시금 느낄 수 있었다.

기존 크롬의 개발자 도구의 여러 패널들을 잘 활용하지 못했는데, 이 기회에 공부할 수 있어서 좋았고,

구글의 웹 표준에 대한 다양한 논의를 찾아보면서 개발 생태계가 발전하고 있음을 느낄 수 있었다.