Google Lighthouse

Lighthouse란?

• 구글에서 개발된 오픈소스 사이트 성능 측정 도구
• 웹페이지의 성능, 접근성, PWA, SEO 등을 검사하여 품질 검사 진행
• 검사할 사이트의 url만 있으면 Chrome DevTools부터 CLI, 노드 모듈 등 다양한 경로를 통해 사용가능
• 공식 사이트 소개

 

 

 

검사 항목

1. Performance (웹 성능)

- 화면에 콘텐츠가 표시되는데 시간이 얼마나 걸리는지, 표시된 후 사용자와 상호작용하기 까진 얼마나 걸리는지, 화면에 불안정한 요소는 없는지

 

2. Accessibility (웹 접근성)

- 대체 텍스트를 잘 작성했는지, 배경색과 콘텐츠 색상의 대비가 충분한지, 적절한 WAI-ARIA 속성을 사용했는지

 

3. Best Practices (웹 표준 모범 사례)

HTTPS 프로토콜을 사용하는지, 사용자가 확인할 확률은 높지 않지만 콘솔 창에 오류가 표시 되지는 않는지 

 

4. SEO (검색 엔진 최적화)

애플리케이션의 robots.txt가 유효한지, <meta> 요소는 잘 작성되어 있는지, 텍스트 크기가 읽기에 무리가 없는지 

 

5. PWA (Progressive Web App, 모바일 애플리케이션 작동 확인)

앱 아이콘을 제공하는지, 스플래시 화면이 있는지, 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지

*점수가 아닌 체크리스트로 확인

 

 

 

모바일 버전 daum.net을 lighthouse로 성능 측정한 결과

웹 성능에 직결되는 Performance 항목 

1. First Contentful Paint (FCP)

• 사용자가 페이지에 접속했을 때 브라우저가 DOM 컨텐츠의 첫 번째 부분을 렌더링하는 데 걸리는 시간을 측정
  👉 사용자가 감지하는 페이지의 로딩속도를 측정
• 우수한 사용자 경험을 제공하려면 FCP가 1.8초 이하여야 
• 페이지의 이미지와 <canvas> 요소, SVG 등 모두 DOM 콘텐츠로 구분되며 <iframe> 요소의 경우 이에 포함되지 않음

 

 

2. Largest Contentful Paint (LCP)

• 뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정
• 주요 콘텐츠가 유저에게 보이는 시간까지를 가늠할 수 있음

 

LCP time(in seconds)	Color-coding
0-2.5	Green (fast)
2.5-4	Orange (moderate)
Over 4	Red (slow)

<표> LCP 점수 해석 기준

 

 

 

3. Speed Index

• 페이지를 로드하는 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는 지 측정
• 측정 방식
  1. 브라우저의 페이지 로딩과정을 각 프레임마다 캡쳐
  2. 프레임 간 화면에 보이는 요소들을 계산
  3. Speedline Node.js module을 이용하여 Speed Index 점수를 그래프의 형태로 표현

 

Speed Index(in seconds)	Color-coding
0–3.4	Green (fast)
3.4–5.8	Orange (moderate)
Over 5.8	Red (slow)

<표> Speed Index 점수 해석 기준

 

 

 

 

4. Time to interactive (TTI)

• 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간을 측정
• 측정 기준
  1. 페이지에 FCP로 측정된 컨텐츠가 표시되어야
  2. 이벤트 핸들러가 가장 잘 보이는 페이지의 엘리먼트에 등록
  3. 페이지가 0.05초안에 사용자의 상호작용에 응답
• TTI 점수는 아카이브된 HTTP 데이터를 기반으로 백분위 단위로 점수를 측정

TTI metric(in seconds)	Color-coding
0–3.8	Green (fast)
3.9–7.3	Orange (moderate)
Over 7.3	Red (slow)

<표> TTI 점수 해석 기준

 

 

 

 

5. Total Blocking Time (TBT)

*대부분의 사용자는 0.05초가 넘는 작업에는 응답이 올때까지 계속 키보드를 두드리거나 마우스를 클릭하기 때문에 페이지가 느리다고 인식하기 때문에 이를 개선하기 위한 지표가 TBT

 

• 페이지가 유저와 상호작용하기까지의 막혀있는 시간을 측정
• FCP와 TTI 사이에 긴 시간이 걸리는 작업들을 모두 기록하여 TBT를 측정

여러 개의 작업 중에서 50ms(0.05초)를 초과하는 작업만 긴 작업으로 간주하여 TBT로 측정됨

*따라서 위 그림에 따르면 메인스레드에서 작업을 실행하는 데 소요된 총 시간은 560ms(0.56)초이지만 TBT로 측정되는 것은 345ms(0.345초)

 

 

 

 

6. Cumulative Layout Shift (CLS)

• 사용자에게 컨텐츠가 화면에서 얼마나 많이 움직이는지(불안정한 지)를 수치화한 지표
• 화면에서 이리저리 움직이는 요소(불안정한 요소)가 있는 지를 측정가능
• 참고 영상 (Annie Sullivan :: Understanding Cumulative Layout Shift :: #PerfMatters Conference 2020)

 

 

 

 

다음 웹페이지(daum.net)의 opportunity 개선 필요 항목 분석

 

 

1. Serve images in next-gen formats (차세대 포맷을 이용하여 이미지 제공)

- Image formats like WebP and AVIF often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.

👉 PNG나 JPEG 같은 이미지 파일 형식 대신에 압축률이 더 좋은 WebP, AVIF 같은 포맷을 사용하여, 이미지 다운로드 속도 향상 및 데이터 사용량을 감소시킨다.

 

- AVIF, WebP 포맷으로 이미지 제공해야 하는 이유?

• AVIF와 WebP는 이전의 JPEG와 PNG에 비해 우수한 압축 및 품질 특성을 가진 이미지 포맷이므로, 이러한 포맷으로 이미지를 인코딩하면 로딩 속도가 빨라지고 셀룰러 데이터를 덜 소모한다.
• AVIF는 크롬, 파이어폭스 및 오페라에서 지원되며 동일한 품질 설정을 가진 다른 형식에 비해 파일 크기가 작다.
• WebP는 크롬, 파이어폭스, 사파리, 엣지, 오페라의 최신 버전에서 지원되며 웹 상의 이미지에 대해 더 나은 손실 및 무손실 압축을 제공한다.

 

 

 

2. Defer offscreen images (보이는 화면 바깥의 이미지는 나중에 로딩)

- Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive.

👉 현재 보이는 화면 밖에 존재하거나 숨겨진 이미지는 사용자의 TTI(페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간)를 줄일 수 있도록, 제일 중요한 리소스가 로딩된 후에 레이지로딩*한다.

 

*레이지로딩: 느린 로딩 또는 지연된 로딩 기법이라고도 한다. 어플리케이션 레벨에서 메모리를 효율적으로 관리하기 위해 오브젝트의 인스턴스를 한번에 모두 메모리에 생성하지 않고, 필요 시 생성하는 기법

 

 

 

 

3. Reduce unused JavaScript (사용되지 않는 JS파일 줄이기) - LCP

- Reduce unused JavaScript and defer loading scripts until they are required to decrease bytes consumed by network activity.

👉  사용되지 않는 자바스크립트 파일을 줄이고, 네트워크 활동에 의해 사용되는 바이트(bytes)를 줄일 수 있도록 필요한 순간에 스크립트를 불러올 수 있도록 한다.

 

- 불필요한 자바스크립트에 의해 페이지가 느려지는 이유

• 자바스크립트가 렌더링 차단(render-blocking) 중인 경우, 브라우저는 페이지 렌더링에 필요한 다른 모든 작업을 진행하기 전에 스크립트를 다운로드, 구문 분석(parse), 컴파일 및 평가(evaluate)해야 한다.
• 자바스크립트가 (렌더 차단이 아닌) 비동기적(asynchronous)인 경우에도 코드는 다운로드되는 동안 다른 리소스에 필요한 대역폭을 차지하며, 이는 성능에 상당한 영향을 미친다. 네트워크를 통해 필요없는 코드를 보내는 것은 무제한 데이터 요금제가 없는 모바일 사용자들에게도 부담이 된다.

 

- 사용되지 않는 JavaScript 탐지

• Chrome DevTools의 Coverage 탭에서는 사용되지 않는 코드를 한 줄씩 분석할 수 있다.
• Puppeteer의 탐지 범위 클래스(The Coverage class in Puppeteer)는 사용되지 않는 코드를 탐지하고 사용된 코드를 추출하는 프로세스를 자동화하는 데 도움이 됩니다.

 

- 사용하지 않는 코드 제거 지원을 위한 빌드 툴

• 본인이 사용하는 번들러에서 사용하지 않는 코드를 더 쉽게 방지하거나 제거할 수 있는 기능을 지원하는지 확인한다.

• Code Splitting
• Unused Code Elimination
• Unused Imported Code 

 

 

 

4. Reduce initial server response time (초기 서버 응답시간 단축) - FCP, LCP

- Keep the server response time for the main document short because all other requests depend on it.

👉 다른 모든 요청이 메인 문서(main document)에 의존하므로, 메인 문서에 대한 서버 응답 시간을 단축시킨다.

 

- 느린 서버 응답 시간이 성능에 영향을 미침

• 브라우저가 서버가 기본 문서 요청에 응답할 때까지 600ms 이상 기다리게 되면, 성능 검사 시 실패로 간주한다. 사용자는 페이지를 로드하는 데 시간이 오래 걸리는 것을 좋아하지 않으며, 느린 서버 응답 시간은 긴 페이지 로드의 원인 중 하나이다.
• 사용자가 웹 브라우저에서 URL로 이동할 때 브라우저는 해당 콘텐츠를 가져오기 위해 네트워크 요청을 수행한다. 서버가 요청을 수신하고 페이지 내용을 반환한다.
• 서버는 사용자가 원하는 모든 내용이 포함된 페이지를 반환하기 위해 많은 작업을 수행해야 할 수 있다. 예를 들어 사용자가 자신의 주문 기록을 보는 경우, 서버는 데이터베이스에서 각 사용자의 기록을 가져온 후 해당 내용을 페이지에 삽입해야 한다.
• 이러한 작업을 가능한 한 빨리 수행하도록 서버를 최적화하는 것은 사용자가 페이지 로드를 기다리는 시간을 줄이는 방법이 될 수 있다.

 

- 서버 응답 시간을 개선하는 방법

• 서버 응답 시간을 개선하기 위한 첫 번째 단계는 페이지 내용을 반환하기 위해 서버가 완료해야 하는 핵심적인 작업를 식별한 후 각 작업에 걸리는 시간을 측정하는 것이다.
• 그 중 가장 오래 걸리는 작업을 확인한 후 작업 속도를 높일 수 있는 방법을 찾아야 한다.

 

- 서버 응답 속도를 높이는 방법

• 서버의 응용프로그램 로직을 최적화하여 페이지를 더 빠르게 준비합니다. 서버 프레임워크를 사용할 경우, 이 프레임워크에 이 작업을 수행하는 방법에 대한 권장사항을 확인한다.
• 서버가 데이터베이스를 쿼리하는 방법을 최적화하거나 더 빠른 데이터베이스 시스템으로 마이그레이션합니다.
• 더 나은 메모리 또는 CPU를 사용할 수 있도록 서버 하드웨어를 업그레이드합니다.