라이트하우스 6.0에서 바뀐 성능 지표변화

지난 번역 글에서 라이트하우스의 향상된 기능들이 업데이트될 것이라고 소개하였다.

그리고 최근 5월에 이르러 라이트하우스 6.0이 정식으로 릴리즈되었고 최신 크롬 84에도 적용될 예정이다. 바로 써보고 싶은 사람은 크롬 나이틀리 빌드(카나리아)를 다운로드하자.

라이트하우스의 간단 소개

라이트하우스는 웹페이지의 성능 측정과 개선을 위한 도구로, 크롬 개발자 도구에서 볼 수 있다. 우리가 만든 웹이 좀 더 빠르게 로딩되고, 사용자와 빠르게 상호작용할 수 있도록 각종 성능 지표와 개선 포인트를 가이드한다.

이런 성능 측정 도구가 중요한 것은 두말하면 잔소리일 것이다. 지금 당장 콘솔 로그를 써서 여러분의 페이지 성능을 개선해 보려고 하면 바로 와 닿을 것이다. 라이트하우스가 제공하는 각종 기능이 다양한 측면에서 적절한 정보를 제공하는 것에 감사하게 될지도 모른다.

또한 라이트하우스는 단지 크롬 개발자 도구에서만 사용할 수 있는 것이 아니다. 라이트하우스 Node CLI는 CI에서 성능 테스트를 자동화할 수 있도록 지원한다.

npm install -g lighthouse
lighthouse https://www.example.com --view

브라우저 확장 프로그램을 통해서도 사용할 수 있는데 크롬과 파이어폭스에서 사용할 수 있다. 내부 동작 방식은 다소 다르지만, 파이어폭스에서 라이트하우스라니 신박하다.

새로운 버전에서 변경된 것들

이번 6.0의 릴리즈 노트를 보면 많은 부분이 변화되었다. 공식 블로그의 글에 따르면 다음이 주요 업데이트 항목이다.

• 새로운 성능 지표
• 성능 가중치 조정
• 라이트하우스 CI
• 크롬 개발자 도구에서 이름이 변경됨
• 모바일 에뮬레이션
• 브라우저 확장 프로그램
• 성능 예산
• 소스 위치 링크 기능
• 소스 맵이 있는 경우 미사용된 자바스크립트 모듈 표시

어느새 크롬 개발자 도구에서 Audits 탭의 이름이 Lighthouse로 이름이 바뀌었다. 크롬 81버전에서부터 벌써 적용이 되었는데, 라이트하우스의 중요성과 위상이 보다 올라갔다고 생각한다.

이 글은 각 항목을 모두 다루지는 않고 성능 지표와 관련된 것들만 다룬다.

새로운 성능 지표의 등장

웹 기술이 발전하고 변화하면서 웹 페이지에서 중요하게 여기는 기준들 또한 필연적으로 변하게 된다.

성능을 측정하는 기준, 즉 성능 지표는 웹 페이지의 성능을 합리적으로 나타낼 수 있어야 한다. 페이지의 빠르고 느림, 상호작용의 빠르고 느림을 숫자로 표시하고 숫자들을 적절한 색깔을 입히고 그림으로 표시한다. 라이트하우스는 그동안 다양한 지표들을 개발하고 가이드를 제시해왔다.

FMP가 없어졌다

그런 측면에서 이번 업데이트에서 FMP(First Meaningful Paint)가 없어진 것은 환영할 만한 변화라고 생각한다. 기준 자체가 너무 모호한 데다 과학적으로, 정량적으로 측정하기 매우 어려운 항목이기 때문에 표준화하기가 힘든 지표였다. 몇 해 전에 필자가 한 강연에서도 페이지의 FMP를 개선하는 것을 다루었다. 그러나 의미 있는 렌더링이라는 것이 개발자마다, 프로젝트 소유주에 따라, 서비스에서 중요하게 생각하는 것에 따라서 모두 달라질 수 있다. FMP가 알려주는 숫자가 빠르다고 하더라도 사용자는 페이지가 느리다고 느낄 수 있는 것이다. 이러한 불일치는 FMP가 성능 지표로 사용되기는 부적합하며 대체할 수 있는 새로운 지표가 필요한 이유다.

대신, 라이트하우스의 알파 버전에서 예고한 것과 같이 새로운 3가지 지표 LCP, CLS, TBT가 등장하였다.

LCP(Largest Contentful Paint)

LCP는 이름만 봐도 그 기준이 명확하다는 것을 알 수 있다. 페이지가 로딩되는 동안 가장 큰 영역이 렌더링 되는 시점을 성능 지표로 삼는다. 화면에서 가장 큰 엘리먼트가 그려지는 시점이 얼마나 빠른지를 나타내는 성적이며 FMP보다 더 정확한 기준이라고 할 수 있다.

이 글에 따르면 LCP에 해당하는 엘리먼트는 다음과 같다.

• img 엘리먼트
• svg 내부의 image 엘리먼트
• video 엘리먼트
• 백그라운드 이미지가 있는 엘리먼트
• 텍스트를 포함하는 블록 레벨 엘리먼트

페이지 로딩 중에 가장 큰 컨텐츠는 계속 바뀔 수 있다. 다음 그림을 보면 페이지 로딩 중에도 LCP 후보가 계속 바뀌는 것을 볼 수 있다.

(출처: https://web.dev/lcp/#examples)

LCP 기준에서 빠른 페이지의 가이드는 페이지 로딩 시작부터 2.5초 이내에 가장 큰 컨텐츠가 렌더링 되는 것이다. (출처: https://web.dev/vitals)

이 지표는 기준이 간단하기 때문에 표준화할 수 있다. W3C의 웹 성능 워킹 그룹에서 진행 중이며 Largest Contentful Paint API 스펙도 만들어지고 있는데, API를 통해서 편리하게 성능 변화 추이를 기록할 수 있을 것이라 기대된다.

CLS(Cumulative Layout Shift)

CLS는 컨텐츠가 화면에서 얼마나 많이 움직이는지를 수치화 지표다. 이 지표는 사용자 중심의 성능 지표로서 컨텐츠가 화면에서 이리저리 움직이는 것이 불편을 초래할 수 있기 때문에 제공하는 자료다.

CLS는 처음 봤을 때 성능과 다소 무관한 지표라고 생각했다. 그러나 특정한 경우에서는 CLS 지표가 떨어지는 것이 큰 문제가 될 수도 있다. 예를 들어 보자. 사용자가 로딩이 완료될 즈음에 구매 취소 버튼을 누르려고 했는데, 그 순간 뒤늦게 페이지 상단에 광고가 끼어들게 된다면 어떻게 될까? 사용자가 누르려고 했던 취소 버튼은 아래로 이동할 것이고, 잘못된 영역(운이 좋지 않다면 구매 버튼)을 누르게 된다.

다음 예와 같이 글을 읽고 있는 도중에 컨텐츠가 아래로 이동해 버리면 사용자는 혼란스러울 것이다. (출처: https://web.dev/cls/)

CLS 기준에서 페이지가 흔들리지 않는 편안한(안정적인) 비주얼을 가지는 기준은 다음과 같다. (출처: https://web.dev/cls/)

CLS를 계산하는 원리에 대해서 더 궁금하다면 이 유튜브 영상을 참고하자.

TBT(Total Blocking Time)

TBT는 페이지 로딩 중 반응성이 얼마나 좋은가를 나타낸다. 로딩 중에도 사용자의 입력에 잘 반응하는 페이지와 그렇지 않은 페이지는 사용자 입장에서 성능을 좌우하는 중요 기준이 된다. 이 기준은 입력 반응성이 떨어질 정도로 메인 스레드가 멈추는 시간을 누적한 값이다.

긴 작업이 계속 수행될수록 입력 반응성은 떨어지며 라이트하우스는 메인 스레드에서 수행되는 50ms 이 넘는 작업을 모두 기록한다. 50ms가 넘는 작업이 반복될수록 키보드 두드리고 마우스를 쥐고 있는 사용자에게 페이지가 느리다고 인식하게 만든다.

(출처: https://web.dev/tbt/)

TBT 기준에서 입력 반응성을 유지하며 사용자에게 불편함을 주지 않기 위한 가이드는 300ms 이하이다. 로딩 중에 오래(50ms가 넘는) 걸리는 작업을 다 합쳐도 300ms 이하로 유지하기를 권장한다.

TBT를 줄일 방법은 성능 최적화 기법에서 알려진 다음과 같은 것들이다.

• 리소스 용량 줄이기
• 자바스크립트 실행 시간 줄이기
• 렌더 블로킹 리소스 줄이기

실제 최적화 사례

최근 Dooray!에서 DOMContentLoaded 속도를 빠르게 하기 위해서 최적화 작업을 진행하였다. 다양한 기법을 사용하여 개선하였는데 결국 알고보면 TBT도 개선되는 결과로 이어진다.

페이지 로딩 중 메인 컨텐츠에서 초기화 및 로딩될 필요 없는 JS 모듈이 로딩되는 부분을 개선

마무리

보다 정확한 성능 측정과 적절한 개선 가이드를 제시하기 위해서 성능 지표는 앞으로도 계속해서 변화할 것이다. LCP(Largest Contentful Paint), CLS(Cumulative Layout Shift), TBT(Total Blocking Time)을 사용하여 더 나은, 더 빠른, 더 안정적인 웹페이지를 구축하는 데 도움이 되었으면 한다.