성능개선 (core-web-vitals & Lighthouse)

이번엔 웹서비스의 성능지표 core web vitals를 공부해보고 lighthouse의 성능지표에는 무엇이 있는지 알아보겠습니다.

웹 성능 개선을 고려해야하는 이유

웹 성능은 객관적인 측정치(로딩 시간, 초당 프레임 수, 상호작용에 반응할 수 있게 되는 시간)와 유저의 주관적인 경험(콘텐츠의 로딩 시간이 얼마나 길게 느껴지는지)이 포함됩니다.

 

우리는 웹 성능 개선을 왜 고려해야할까요?

웹성능 지표는 비지니스에도 많은 영향을 주기 때문입니다. 일반적으로 빠른 로딩은 좋은 사용자경험(UX)을 제공하고 반대로 사용자가 웹사이트에 들어갔을 때 하얀 화면을 노출시키거나 로딩이나 지연이 길게 발생하면 사용자는 자연스럽게 이탈하게 됩니다.

아래는 2017년 Google 모바일 부문 글로벌 제품 리드인 Daniel An이 말한 Think with Google 기사에서 발췌한 웹페이지 로딩 시간과 사용자 이탈율에 대한 내용입니다.

아래 자료에 따르면 페이지 로딩 시간이 1초에서 3초로 증가하면 이탈율이 32%로 증가하고, 10초로 증가하면 증가율이 123%로 기하급수적으로 늘어나는것을 보실 수 있습니다.

 

 

실제로 pinterest는 페이지 로드 시간을 40% 감소시켜서 검색엔진을 통해 유입된 트래픽 및 가입자 전환율이 15%나 증가하는 결과를 얻었고, 이와 반대로 BBC는 사이트가 로딩하는 데 걸리는 매 초마다 10%의 사용자 감소를 확인하기도 하였습니다.

또한 2021년부터는 Google에서 웹 성능 지표(코어 웹 바이탈)가 검색엔진 순위에 영향을 미친다고 발표했습니다.

이처럼 많은 기업들이 웹 성능이 비지니스에 영향을 미친다는 것을 데이터로 보여주고 있고 웹 성능개선이 SEO까지 영향을 주기 때문에 프론트엔드 개발자는 웹 성능지표를 항상 확인하고 개선해야하는 과제가 있습니다.

 

자세한 내용은 해당 링크를 확인해보시면 좋을 것 같습니다. 

 

 

Core web vitals란?

코어 웹 바이탈이란 웹 사이트가 검색 엔진 결과에 표시되는 위치에 영향을 미치는 세 가지 웹 성능 측정값입니다.

유저의 경험을 좌우하는 여러 요소 중 가장 기본이자 핵심 지표로 보기 때문에 코어 라는 단어를 붙여 부릅니다.

다시 말해 코어 웹 바이탈은 웹페이지의 유저들의 사용 경험을 측정하는 구글의 표준화된 측정 항목 집합입니다.

코어 웹 바이탈은 아래 세가지 영역에 대한 지표를 생성하여 사용자 경험 문제를 식별합니다.

• LCP
• FID
• CLS

 

LCP - 페이지 로딩 성능 (Loading Performance)

• 최대 컨텐츠 렌더링 시간 LCP, Largest Contentful Paint
  • 웹 페이지가 완전히 로드되는데 걸리는 시간을 측정하는 것이 아닌, 뷰포트 내에서 가장 큰 컨텐츠가 로드되는 시간이며
  • 좋은 사용자 경험을 위해서는 2.5초 이내에 LCP를 유지해야합니다.
  • 대부분의 사용자가 이 목표를 달성할 수 있도록 모바일과 데스크톱 기기별로 분류된 페이지 로드의 75번째 백분위수를 측정하는 것이 좋습니다.

INF - 상호작용 (Interaction to Next Paint)

• 다음 페인트와의 상호작용 INF, Interaction to Next Paint
• 사용자가 페이지를 방문하는 전체 기간에 발생하는 모든 클릭, 탭, 상호작용의 지연 시간을 관찰하여 사용자의 상호작용에 대한 페이지의 전반적인 응답성을 평가하는 측정항목입니다.
• TBT(Total Blocking Time)나 TTI(Time to Interactive)도 영향을 줄 수 있지만 이러한 항목들은 현장 측정이 불가능하거나 사용자 중심 결과를 반영하지 않아서 코어 웹 바이탈 항목에 속하진 않습니다.

CLS - 사용자 관점에서 본 페이지의 시각적 안전성 (Visual Stability)

• 레이아웃 변경횟수 CLS (Cumulative Layout Shift)
• 좋은 사용자 환경 제공을 위해서는 CLS가 0.1이하로 유지되어야합니다.

Lighthouse란?

구글에서 개발한 웹페이지 품질을 개선하는데에 사용할 수 있는 오픈 소스 자동화도구입니다.

성능, 접근성, 프로그레시브 웹 앱, SEO 등에 대한 검사를 해서 성능지표를 확인할 수 있고 개선해야되는 부분을 확인할 수 있습니다.

이는 실험실 지표를 제공하는 무료 도구이며 실험실이 아닌 실제 사용자 경험과 관련된 데이터를 제공받고 싶다면 PageSpeed나 real user monitoring(RUM) 도구인 cloudflare, datadog 등 을 활용할 수 있습니다.

Lighthouse 사용방법

개발자도구를 켜서 Lighthouse탭을 누르면 원하는 모드와 Categories를 선택하여 사용할 수 있습니다.

 

Lighthouse의 Performance

Lighthouse의 Performance 카테고리에는 다음과 같은 성능지표를 확인할 수 있습니다.

이는 탭에서 바로 확인할 수도 있지만 json이나 gist로 저장해두고 Lighthouse Report Viewer 사이트에서 언제든지 이전 결과를 확인하고 팀원에게 공유할 수 있습니다. 

 

 

Performance Metric과 가중치 점수

현재 우리가 사용하고 있는 lighthouse 10은 성능 측정 항목은 위 5가지 metric으로 정의되며 해당 Metric들의 점수가 가중평균으로 계산되어서 총 성능점수에 영향을 미칩니다.

Lighthouse 8에서는 TTI(Time to Interactive, 상호작용 시간)이 포함되어있었지만 이는 네트워크 요청 및 장기 작업에 지나치게 민감해서 측정 항목의 변동성이 크다는 이유로 Lighthouse 10에서는 삭제되었습니다.

이러한 점수는 A/B테스트 또는 광고의 변경사항, 인터넷 트래픽 라우팅 변경사항, 다양한 기기에서 테스트함에 있어서 발생하는 성능차이로 변동될 가능성이 있습니다. 

 

 

FCP ( First Contentful Paint - 10% )

FCP는 사용자가 페이지로 이동한 후 브라우저에서 첫 번째 DOM 콘텐츠를 렌더링하는 데 걸리는 시간을 측정합니다. 페이지의 이미지, 흰색이 아닌 <canvas> 요소, SVG는 DOM 콘텐츠로 간주됩니다

가장 먼저 찍히는 FCP는 다른 항목들의 점수 및 전체 점수에 큰 영향을 줄 수 있습니다.

Google은 웹페이지의 성능을 평가하는 데 도움이 되도록 FCP 측정값을 세 가지 그룹으로 분류합니다:

• 양호: 1.8초 이하 (녹색)
• 개선 필요: 1.8초에서 3.0초 사이 (주황색)
• 불량: 3.0초 이상 (빨간색)

LCP (Largest Contentful Paint - 25%)

core web vitals에서 다뤘던 LCP입니다.

LCP가 이미지인 경우 타이밍을 4단계로 나눌 수 있고 가장 오래 걸리는 단계를 알면 LCP를 최적화하는데 도움이 될 수 있습니다.

LCP 단계

• TTFB (Time to Frist byte) : 사용자가 페이지 로드를 시작한 시점부터 브라우저가 HTML 문서 응답의 첫 바이트를 수신할 때까지의 시간
• 로드 지연 : TTFB와 브라우저가 LCP 리소스 로드를 시작하는 시점 사이의 델타
• 로드 시간 : LCP 리소스 자체를 로드하는데 걸리는 시간
• 렌더링 지연 : LCP요소가 완전히 렌더링될 때까지 LCP리소스 로드가 완료되는 시점 사이의 델타

TTB(Total Blocking Time - 30%)

마우스 클릭, 화면 탭 또는 키보드 누름과 같은 사용자 입력 페이지가 응답하지 못하도록 차단된 총 시간을 의미합니다.

FCP와 TTI사이의 모든 Long Task 블로킹 타임을 추가하여 계산합니다.

50ms를 초과하여 실행되는 모든 작업은 장기 작업이고 Lighthouse가 70ms의 Long Task를 감지하면 차단되는 시간은 20ms입니다.

• 양호 : 200밀리초 이하
• 개선 필요: 200밀리초~600밀리초 사이 (주황색)
• 불량: 600밀리초 이상 (빨간색)

CLS (Cumulative Layout Shift - 25%)

예기치 않은 레이아웃 변경은 여러면에서 사용자 환경에 지장을 줄 수 있습니다.

텍스트가 갑자기 이동하거나 이미지가 뒤늦게 렌더링되면서 레이아웃이 변경되는 경우 사용자가 위치를 놓치거나 잘못된 링크나 버튼을 클릭하게 되는 상황이 발생할 수 있습니다.

이러한 변경의 원인으로는 크기를 알 수 없는 이미지나 동영상, 초기 대체값보다 크거나 작게 렌더링되는 글골, 자동으로 크기가 조절되는 서드파티 광고 또는 위젯등이 있습니다.

SI (Speed Index - 10%)

페이지 로딩 중 콘텐츠가 시각적으로 표시되는 속도를 측정한 값입니다. 리로드 되는 페이지의 비디오를 캡쳐하여 프레임 간의 속도를 계산합니다.

• 양호 : 3.4초 이하
• 개선 필요: 3.4초~5.8초 사이 (주황색)
• 불량: 5.8초 이상 (빨간색)

 

View Treemap

JS 번들사이즈의 그래픽 표현과 사용하지 않는 리소스의 정보 등 을 확인할 수 있습니다. 

 

naver 메인페이지의 treemap을 확인해보면 vite bundle visualizer와 같이 번들 사이즈를 확인해볼 수 있고 개발자도구의 coverage에서 볼 수 있는 것 과 같이 해당 번들에서 사용되지 않는 부분의 비율과 크기 정보를 확인할 수 있습니다.

 

Diagnostics

애플리케이션 성능에 관련한 추가 정보로 성능점수에 간접적인 영향을 미칠 수 있는 정보를 보여줍니다.

오른쪽 상단에 관련된 것들을 필터링하여 볼 수 있습니다.

아래와 같이 LCP element에 대한 정보, 사용하지 않는 JS파일, render-blocking resource, Minify CSS 등 성능에 영향을 미칠 수 있는 정보들을 상세히 확인할 수 있습니다.

 

마치며

이렇게 웹 성능에서 중요한 영향을 미치는 Core Web Vitals와 이를 측정해볼 수 있는 Lighthouse를 알아보았습니다. 

이론적인 것을 충분히 다졌으니 다음 포스트에서는 직접 성능을 측정해보고 개선해보는 시간을 가져보겠습니다 :)

 

 

Reference

https://www.cloudflare.com/ko-kr/learning/performance/what-are-core-web-vitals/

https://web.dev/articles/cls?hl=ko    

https://web.dev/articles/lcp?hl=ko  

https://web.dev/articles/inp?hl=ko

https://developer.chrome.com/docs/lighthouse/performance/speed-index