라이트하우스 성능 지표 살펴보기

아주 조금만 더 알아보기🔎

라이트하우스에 대해 들어보셨나요? 라이트하우스는 구글에서 제공하는 오픈소스로 웹 사이트의 품질을 측정하는 자동화 도구입니다. 웹 페이지의 성능, 접근성, SEO, PWA , Best Practices 항목으로 수를 매겨주며 개선 사항을 안내합니다.

라이트하우스를 이미 사용해 본 사람들은 알겠지만 Lighthouse의 Performance audits에서 소개하는 내용들은 뭔가 와 닿지 않는 모호함들이 존재합니다. (저만 그럴수도 있습니다.) 또한, 라이트하우스의 친절함(?) 덕분에 각 지표들의 측정 방법을 구체적으로 알지 않아도 개선점을 파악할 수 있고 좋은 점수를 받을 수 있습니다. 이 글은 그런 저의 개인적인 모호함을 해결하기 위해 찾았던 내용을 정리했습니다.

라이트하우스 5? 6? 7?

라이트 하우스는 대부분의 소프트웨어가 그렇듯 시간이 지남에 따라 계속해서 발전하고 변화합니다. 작성일 기준(21.5.11) Lighthouse는 7.4버전이 최신 버전인데요. 라이트하우스의 버전에 따라 살펴보는 지표와 기준, 가중 또한 달라집니다. 저희가 살펴볼 성능 지표는 5에서 6으로 변화할 때 지표의 내용이 변경했고, 7에서는 크게 변화가 없었습니다.

변경되는 기준은 지표가 갖는 모호함을 없애는데에 중점이 있을 수도 있고, 라이트 하우스 팀에서 더 나은 사용성을 위해 새롭게 지표를 추가할 수도 있습니다. 또한, 이미 추가된 지표들 또한 각각 가중치가 다르게되며 주기적으로 피드백을 수집해 변경된다고 합니다.

아무튼, 결론은 현재 Lighthouse는 총 6개의 지표를 갖고 성능을 파악하고 있습니다. 각각 줄여서 FCP, SI, LCP, TTI, TBT, CLS 6가지가 존재하는데요. 좋은 점수를 받기 위해서는 LCP랑 TBT가 가장 중요해 보이는데요. 이제 각각의 지표들이 어떤 것을 의미하는지, 어떻게 측정되는지 살펴보겠습니다.

First Contentful Paint

FCP는 페이지 로드가 시작된 후 뷰포트내의 의미있는 콘텐츠 일부가 처음 화면에 렌더링 될 때까지의 시간을 측정합니다. 단어 그대로 해석하면 의미가 됩니다.

FCP는 사용자가 화면에서 무슨 일이 일어나고 있구나 라고 인지하는 시점을 알려주는 아주 중요한 지표입니다. iframe 요소는 측정되지 않으며, 측정하는 대상이 canvas나 svg의 경우 배경색이 하얀색이 아닌 경우 이 측정 요소에 포함이 됩니다.

2초 이내에 화면에 인지할 수 있는 변화가 일어나야 좋은 점수를 받을 수 있습니다. FCP는 SEO에도 영향을 미치기 때문에 좀 더 주의깊게 봐야하는 지표 중 하나입니다.

Speed Index

Speed Index는 뷰포트내의 콘텐츠가 눈에 띄게 채워지는 속도를 보여주는 페이지 로드 성능을 측정합니다. 이 내용은 그림을 통해 살펴보는 것이 이해가 좀 더 쉬울 수 있습니다.

A 사이트와 B 사이트를 예시로 비교해 보겠습니다. A 사이트는 B사이트에 비해 빠르게 대부분의 정보를 나타냅니다. 이렇게 된 이유는 로딩이 오래걸리는 이미지를 레이지 로딩해 글 컨텐츠를 우선적으로 보여줘서 일 수도 있고 여러 이유가 있을 수 있지만, 여기서 중요한 내용은 “결국 더 넓은 영역의 컨텐츠를 빠르게 보여줬다는 것” 입니다. 이 그림에서 Speed Index는 어떻게 계산할까요?

오랜만의 적분이 반가우신 분도 있겠지만, 정리해보면 그래프의 윗 영역의 너비가 Speed Index를 나타내게 됩니다. 여기서 단위는 ms로 1219는 1.2s를 의미하게 됩니다.

이 결과를 기준으로 4.3s안에 들어오면 양호한 상태가 됩니다.

Largest Contentful Paint

LCP 는 뷰포트의 컨텐츠 중 가장 큰(넓은) 영역을 차지하는 이미지나 텍스트 요소가 처음 로딩되는 시점을 의미합니다. 가장 큰 영역을 차지하는 요소를 페이지의 주요 콘텐츠로 판단하며, 이 지표를 기준으로 사용자 중심의 페이지 로드 속도를 판단하고 있습니다.

알고 있어야 하는 점

위에서 간단히 언급했듯이 가장 큰 영역을 차지한다고해서 모든 요소를 측정하는 것은 아닙니다. 설명에 따르면

라고 제한합니다. 작업을 좀 더 단순하게 처리하기 위해 제한했으며 이후 추가 요소가 생길수 있따고 합니다.

그리고 LCP에서의 Largest에 해당하는 크기는 뷰포트 바깥 영역, 즉 overflow 된 영역은 크기에 포함되지 않습니다. 또한, 이미지를 원본 크기보다 작게 나타낸 경우 작은 크기가 사용되며 원본보다 크게 표현한 경우 원본의 크기를 보고 계산한다고 합니다.

LCP는 2.5초 이내에 마무리 되어야 양호한 사이트라고 라이트하우스를 통해 인정 받을 수 있습니다.

Time To Interactive

TTI는 페이지가 완전히 사용자와 상호 작용할 수 있는 상태가 되는데 걸리는 시간을 의미합니다. 이 지표를 살펴 보기전에 우선 살펴봐야 하는 내용이 있습니다. 바로 Long Task 입니다.

Long Task

Long Task는 이름에서도 알 수 있듯이 긴 작업을 의미합니다. 다시 말해서, 오랜 기간동안 메인 스레드를 독점해서 UI가 고정되도록 하는 JS 코드를 의미합니다. 이렇게 오랜 기간동안 메인 스레드를 독점하고 있으면 사용자는 페이지가 로드되었지만 클릭이나 입력이 불가능해집니다.

RAIL Model에서 제안하는 응답 속도를 따라 Long Task는 50ms 를 기준으로 잡고 더 오래걸리는 작업을 모두 Long Task로 분류하게 됩니다.

다시 돌아와서..

TTI는 이 Long Task를 기준으로 사용자와 완전히 상호작용하는 시점을 계산하게 됩니다. 여기서는 계산 기준을 살펴보도록 하겠습니다.

TTI 측정 방법. quiet window의 마지막 Long Task를 기준으로 측정한다.

시작 시점은 위에서 살펴 본 FCP 입니다. 사용자가 로딩이 되고 있다 라고 처음 인지하는 시점이 될 것 입니다.
최소 5초 이상의 quiet window를 찾습니다. 여기서 말하는 quiet window는 long task가 존재하지 않고 진행중인 Get 요청이 두 개 이상 존재하지 않는 상태를 의미합니다.
더 이상 Long Task가 존재하지 않으면 quiet window 이전의 가장 마지막 Long Task를 찾습니다. 이 Long Task 가 종료된 시점이 TTI 입니다. 만약 LCP 이후 Long Task가 없다면 LCP 시점이 TTI가 됩니다.

즉, 마지막 Long Task가 마무리 되면 메인 스레드를 오래 점유하는 작업들이 끝났다는 것을 의미하고 사용자와 완전히 상호 작용할 수 있다고 판단하게 됩니다.

TTI는 3.8초 이내에 마무리 되어야 라이트하우스에서는 양호하다고 판단하게 됩니다.

Total Blocking Time

TBT는 TTI와 비슷한 측정 기준을 갖고 있는데요. 페이지가 클릭, 키보드 입력 같은 사용자와 상호작용하지 못했던 시간의 총 합을 측정합니다. 여기서 말하는 차단 시간(Blocking Time)은 위에서 언급한 Long Task로 인해 메인 스레드가 오랫동안 점유되어 사용자와 상호작용 하지 못하는 시간을 의미합니다. FCP와 TTI 사이에 일어난 작업만을 기준으로 합니다.

여기 메인 스레드에 작업이 점유하고 있는 타임라인 예시를 살펴보겠습니다.

각각 5개의 태스크는 짧게는 30ms 길게는 250ms가 걸리는 작업입니다. Long Task의 기준에 따르면 50ms를 초과하는 Long Task는 250ms, 90ms, 155ms를 갖는 세 개의 태스크입니다.

Blocking time은 작업에서 Long Task의 기준이 되는 50ms를 뺀 값을 모두 더하게 됩니다. 이 예시에서는 345ms가 TBT가 됩니다.

TBT는 TTI와는 다르게 페이지가 안정적이게 상호작용 할 수 있는 시점을 알려주는 것이 아닌 안정적이게 되기까지 사용자가 얼마나 상호작용하지 못하는지 시간의 총합을 나타내줍니다. web.dev의 예시처럼 실제 51ms의 작업이 10개 들어있다면 TTI는 좋지 않은 점수를 받겠지만 TBT의 점수는 매우 좋을 것 입니다. 두 지표를 균형적으로 파악하고 문제를 해결해야 합니다.

라이트하우스 6 기준으로 총 300ms를 넘지 않아야 양호한 평가를 받을 수 있습니다.

Cumulative Layout Shift

CLS는 사용자가 예상하지 못한 레이아웃을 경험하는 빈도를 정량화해서 시각적인 안정성을 판단합니다. 예상하지 못한 레이아웃은 어떤걸 의미할까요? 신문사나 유머 사이트들을 통해 갑자기 광고가 떠 읽던 글이 아래로 쭉 밀려서 내려가거나 너비 영역이 줄어들면서 글을 읽기 힘들어지 경험이 있을 것 입니다. 여기 한 가지 사례를 더 살펴보겠습니다.

web.dev에서 제공하는 예시인데요. go back을 누르고 싶었던 사용자는 갑작스럽게 나온 팝업때문에 예상치 못한 주문을 하게됩니다.(마우스 연기가 인상적입니다.) 이런 사용성은 사용자들의 실수를 유발할 수 있고 실망스러운 경험을 제공할 수 있습니다.

이제 CLS의 점수에 해당하는 Layout Shift Score의 계산법을 살펴보겠습니다.

layout shift score = impact fraction * distance fraction

Layout Shift Score는 impact fraction과 distance fraction 두 값을 곱해서 계산하게 됩니다. 각각 어떤 의미일까요?

impact fraction

impact fraction은 불안정한 요소가 두 프레임 사이의 영역에 미치는 영향을 측정합니다. 말이 조금 어렵죠? 예시를 살펴보겠습니다.

이 이미지는 뷰포트에 절반을 차지하는 글이 작성된 요소가 존재합니다. 하지만, 다음 프레임에서 이 요소가 25% 아래로 이동되게 됩니다. 빨간색 점선은 즉 전체 뷰포트에서 75%(너비 50% + 이동 거리 25%)에 영향을 미치게 됩니다. 이 0.75라는 비율이 impact fraction 값이 됩니다.

distance fraction

다음으로, distance fraction은 불안정한 요소가 이동한 거리를 측정합니다. 이 거리는 뷰포트에서 수평 또는 수직으로 가장 많이 이동한 거리를 너비 또는 높이로 나눈 값이 됩니다. 여기서도 예시를 하나 살펴보겠습니다.

아까 사용했던 그림입니다. 위 요소에서 가장 큰 뷰포트 치수는 높이이고, 불안정한 요소는 25%를 이동하게됩니다. 이 예시에서는 0.25가 distance fraction이 됩니다.

요소가 여러개 존재했을 때는 위에서 설명했던 것처럼 가장 많이 이동한 거리를 기준으로 계산하게 됩니다. web.dev에서는 좀 더 복잡한 예시들도 설명해주는데요.

이 예시에서는 Click Me가 새롭게 중간에 추가되어 초록색 영역이 하단으로 밀린 것을 확인할 수 있습니다. 여기서 빨간색 점선 영역이 impact fraction, 화살표로 이동한 거리만큼이 distance fraction이 됩니다.

이 두 값을 곱해 나온 결과로 CLS를 판단하게 됩니다.

값을 기준으로 0.1 이하일 경우 양호한 상태를 가졌다고 볼 수 있습니다. 이 지표는 라이트 하우스 6에서 새롭게 추가 되었는데요. 사실 모든 레이아웃의 이동이 나쁜 것은 아니라고 명시하며 “사용자가 예상하지 못한” 이란 이동을 측정하는 것이 핵심이라고 하고 있습니다. 라이트하우스 지표중 가장 낮은 비중을 갖고 있지만 절대 얕봐서는 안되는 지표 중 하나입니다.

마무리

지금까지 6가지 라이트 하우스의 성능 지표와 지표 측정 방법을 알아봤습니다. 단순히 글을 읽는 것보다 어떻게 측정하는지 살펴보는 것이 저는 개인적으로 훨씬 이해가 잘 되어서 이렇게 한번 정리를 하게 되었습니다. 사실상 web.dev의 내용들을 잘게 잘게 종합한 것이지만 쉬운 버전으로 읽어주셨으면 좋겠습니다. 구체적인 내용들은 아래 참고한 내용에 들어가서 직접 살펴보는 것을 추천드립니다. 읽어주셔서 감사합니다!

추가로, 라이트하우스의 성능 지표 외 구글의 Web-vitals과 살펴보지 않은 기준 FID(First Input Delay) 또한 TTI와 함께 어떤 차이점이 있는지 이 기회에 한번 알아 보는 것을 추천합니다.

참고한 내용

라이트하우스 성능 지표 살펴보기

댓글