프론트엔드 성능측정

 실제로 사용자의 40%가 3초 동안 기다리게 되면 사이트를 이탈하는 것으로 나타났다. 월마트에서는 페이지 속도를 100ms까지 개선하면 수익이 1% 증가한다는 사실을 발견했다. 물론 웹사이트의 로딩 속도가 프론트보다는 백엔드에 많이 의존적인 것은 사실이지만 최근에는 꼭 그런 것 만은 아니다.

 

 웹 애플리케이션이 시간이 지남에 따라 복잡해 지면서 늘어가는 비동기 통신, 복잡해진 UI등으로 이전과는 다른 무거운 애플리케이션들이 형성되면서 사용자에게 직접적으로 직면하는 프론트엔드에게도 성능이 중요해지고 있다.

하지만 이 속도라는 것은 사람마다 체감하는 것이 다르고 이를 판단해서 최적화하기란 쉬운일은 아니다. 그렇다면 프론트엔드에서 성능을 측정하는 가장 보편적인 지표와 이를 해석하는 방법은 무엇이 있을까?

 

Google Webvitals

 WebVitals는 Google에서 제공하는 대표적인 웹 품질 지표이다. 각 지표마다 구글이 3단계의 특정 기준을 제시하고 있고 좋음, 개선 필요, 좋지않음으로 나뉜다. 크롬에 존재하는 개발자도구 창의 lighthouse나 https://pagespeed.web.dev/ 를 통하여 손쉽게 측정할 수 있는 것이 특징이다.

 

 Web vitals 중 중요하다고 여겨지는 세 개의 특정 지표가 있는데 현재 LCP(Largest Contentful Paint), FID(First Input Delay), CLS(Cumulative Layout Shift)가 그 주인공이다. Core Web vitals를 구성하는 메트릭은 시간에 따라 변하는 것이 특징이다. 2020년 기준으로 UX의 세가지 로딩, 상호작용, 시각적 안정성에 중점을 두고 있다.

 

LCP(Largest Contentful Paint)

 LCP는 페이지의 메인 컨텐츠가 로드 되었을 가능성이 있을 때 페이지 로드 타임라인에 해당 시점을 표시한다. 사용자가 감지하는 로딩 속도를 측정할 수 있는 Core WebVitals이다. 초기에는 FMP(First Meaningful Paint)와 SI(Speed Index)를 중심으로 측정하였지만 이는 주관적이라 잘못된 경우가 많았고 복잡했다. 따라서 단순하게 LCP는 메인 컨텐츠가 로드되는 시기를 측정하기보다 가장 큰 요소가 렌더링된 시기를 확인하는 메트릭이다.

 

 LCP는 가장 큰 요소인 <main>이나 <section>뿐만 아니라 제목과같은 페이지가 처음 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지나 텍스트 블록의 렌더링 시간을 측정한다. 구글에서는 2.5초 이하의 LCP점수가 좋은 사용자 경험을 제공한다고 제시한다.

최대 풀 페인트에 고려되는 요소는 img, video, url배경요소, 텍스트노드 또는 기타 인라인 수준 텍스트 하위 요소를 포함하는 블록레벨 element가 있다. 요소를 제한함으로써 측정도 단순해진다. 브라우저가 첫 번째 프레임을 그리는 즉시 최대 콘텐츠 요소를 식별하는 largest-contentful-paint 유형의 PerformanceEntry를 디스패치한다. 이후 최대 컨텐츠풀 요소가 변경될 때마다 다른 PerformanceEntry를 디스패치한다.

Web Vitals LCP

 

 각 element는 사용자에게 표시되고 난 후에 최대 컨텐츠 풀로 간주될 수 있다. 아직 로드 되지 않은 이미지나 폰트 차단기간동안 제공되는 웹 글꼴을 사용하는 텍스트 노드는 간주될 수 없다. 새로운 요소가 DOM에 추가될 경우 새 요소가 현 최대 컨텐츠풀 요소보다 클 경우 새 PerfomanceEntry가 보고되지만 최대 컨텐츠 풀이 제거되고 이보다 더 큰요소가 렌더링되지 않을 때는 기존 최대 컨텐츠 풀이 유지된다.

LCP는 서버응답 시간이나 렌더링 차단의 JS및 CSS, 리소스 로드시간, 클라이언트 렌더링 등에 대해 영향을 받으므로 이를 개선하기 위해서는 해당 사항들을 점검할 필요가 있다.

 

Optimize Largest Contentful Paint

최대 콘텐츠풀 페인트 최적화

 

 

FID(First input Delay)

 LCP는 화면에 최대 컨텐츠가 페인트되는 지에 따라 측정되는 반면 사용자가 해당 픽셀들과 상호작용하기 위해 측정되는 요소는 FID라고 한다. FID는 사이트의 상호작용성과 반응성을 측정하는 매트릭이다.

 

실제로 유저가 사용하는 것은 페인트가 아닌 상호작용이기 때문에 FID또한 굉장히 중요한 매트릭으로 여겨진다.

 

FID란 사용자가 처음 상호작용할 떄부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 처리를 시작하기까지의 시간을 뜻한다. 사용자가 페이지에 접속하고 해당 엘리먼트에 클릭을 하면 이 클릭이 이벤트 핸들링을 하기까지의 시간인 것이다.

Web Vitals FID

 

 입력 지연은 보통 브라우저의 메인 쓰레드가 다른일을 하고있기 때문에 입력이 들어와도 응답을 줄 수 없어 발생한다. 위 이미지와 같이 메인쓰레드에 이미 다른 태스크가 존재하기 때문에 해당 시점에 인풋에 대한 이벤트를 받는다해도 브라우저는 메인 쓰레드에 존재하는 태스크를 종료한 후에 이에 대한 응답을 반환할 수 있게 되는 것이다. 즉 FID는 이벤트가 수신된 시점과 메인 스레드가 다음 유후 상태에 들어간 시점사이의 델타를 측정하는 것이다.

 

 RAIL 성능 모델중 FID는 R에만 중점을 둔다.

 

 

 CLS(Cumulative Layout Shift)

 CLS는 말그대로 페이지의 전체 수명동안 발생하는 모든 예기치 않은 레이아웃에 대해 가장 큰 레이아웃 에대한 이동 점수를 뜻한다. 레이아웃 이동은 렌더링된 프레임이 다른 위치로 변경될 때마다 발생한다. 하나 이상의 개별 레이아웃 이동이 빠르게 연속해져서 이루어지는 기간을 세션기간이라고 하는데 이 세션기간에 대해서 누적 점수가 최대인 세션 기간을 CLS로 측정한다.

 

 이러한 레이아웃간의 이동이 항상 좋지 않은 것은 아니다. 하지만 이 이동이 좋지 않을 경우는 사용자가 예상하지 않은 경우이다. 링크 클릭, 버튼 누르기와 같은 응답으로 발생하는 레이아웃 이동은 사용자에게 그 관계가 명확하게 보이는 한 괜찮다. 이러한 애니메이션 전환은 점진적이고 자연스럽게 이동해야 하고 사용자가 그 상황을 인지하는데 사용자 경험을 향상 시키는 효과를 불러일으킨다.

 

레이아웃 이동 점수는 렌더링된 두 프레임 사이 뷰포트의 크기와 뷰포트 내 불안정 요소의 움직임을 살핀다.

layout shift score = impact fraction * distance fraction

이 CLS를 개선하기 위해서는 이미지나 비디오 요소에 크기속성을 포함하고 레이아웃 변경을 트리거하는 속성의 애니메이션 보다는 전환 애니메이션을 사용하는 것이 CLS를 향상시키는 방법이다.

 

이 외에도 아래의 요소들과 함께 더 많은 프론트엔드 성능 지표들이 존재한다. 앞서 말한대로 Core Web Vitals 세 가지는 웹 트렌드 영향에 따라 얼마든지 교체될 수 있다. 또한 모든 점수들이 높게 나온다고 꼭 성능이 좋은 것 또한 아니다. 이러한 지표들은 어디까지나 객관적인 성능을 나타낸 것이고 사용자마다 애플리케이션마다 중점을 두는 지표들이 달라질 수 있을 것이다. 이러한 지표들을 어디까지나 절대적인 기준으로 갖지 않고 애플리케이션의 특성에 맞게 개발하는 것이 중요할 것이다.

 

 

FID - First Input Delay

CLS - Cumulative Layout Shift

FCP - First Contentful Paint

TTFB - Time to First Byte

FCP - First Contentful Paint

SI - Speed Index

LCP - Largest Contentful Paint

TTI - Time to Interactive

TBT - Total Blocking Time

CLS - Cumulative Layout Shift

FMP - First Meaningful Paint

LCP - Largest Contentful Paint

참고자료

성능 최적화\

성능 최적화

Web Vitals 소개: 건강한 사이트를 위한 필수적인 측정항목

Web Vitals 소개: 건강한 사이트를 위한 필수적인 측정항목

웹사이트는 얼마나 빨라야 할까요?

웹사이트는 얼마나 빨라야 할까요?

[프론트엔드] 성능 최적화 정리

[프론트엔드] 성능 최적화 정리