❓ Lighthouse(라이트하우스)란?
Lighthouse는 구글에서 개발한, 웹 페이지의 품질을 개선할 수 있는 오픈 소스 형태의 자동화 도구이다. 어떤 웹 페이지든 (그것이 공개되었든, 인증이 필요하든) 사용할 수 있다.
Lighthouse is an open-source, automated tool for improving the quality of web pages.
📈 Lighthouse로 확인할 수 있는 지표
Lighthouse는 성능을 측정하기 위해서 다음의 메트릭을 사용한다.
(이외에도 부가 항목이 존재하지만 자세한 설명은 생략한다. 다음 링크에서 확인할 수 있다.)
- First Contentful Paint
- FCP
- 사용자가 특정 웹 페이지로 이동했을 때, 브라우저가 첫 번째 DOM의 콘텐츠를 렌더링하는 데 걸리는 시간
- First Meaningful Paint
- FMP
- 사용자가 페이지를 불러오기 시작하면서 스크롤을 내리지 않은 채 제일 먼저 볼 수 있는 영역에 존재하는 주요한 콘텐츠를 렌더링하는 데 걸리는 시간
- Lighthouse 버전 6.0 이후로 사용되지 않는다. (작은 차이에도 매우 민감하게 측정되어 일관성 없는 결과를 초래하였기 때문이다.)
- Speed Index
- 웹 페이지를 불러올 때, 콘텐츠가 시각적으로 표시되는 데까지 걸리는 시간
- First CPU Idle
- 웹 페이지가 최소한으로 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
- Lighthouse 버전 6.0 이후로 사용되지 않는다. (Time To Interactive와 측정 기준이 유사했지만 의미 있는 결과값을 보이지 못했다.)
- Time To Interactive
- 웹 페이지가 완전히 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
- Max Potential First Input Delay
- FID
- 사용자가 웹 사이트와 처음 상호작용(버튼 클릭)할 때부터 브라우저가 실제로 해당 상호작용에 응답할 수 있을 때까지 걸리는 가장 긴 시간
- (즉, 최악의 경우를 측정)
- Total Blocking Time
- TBT
- 웹 페이지가 사용자 입력에 응답하지 못하도록 차단된 총 시간
- = 로딩 중 메인 스레드가 긴 시간동안 중단되어 응답을 받을 수 없을 정도로 걸린 시간
- Largest Contentful Paint
- LCP
- 뷰포트에서 가장 큰 콘텐츠 요소가 화면에 렌더링 될 때까지 걸리는 시간
서술한 건 8개지만 Lighthouse 버전 6.0부터 사용되지 않는 메트릭를 제외하면 총 6개라고 볼 수 있다.
그렇지만 이게 전부가 아니다. 여기에서 하나 더 추가된 지표가 있다. 그건 바로 Cumulative Layout Shift(CLS) 메트릭이다.
- Cumulative Layout Shift
- CLS
- 이미지/광고의 느린 로딩, 비동기 동작, 동적 DOM 변경 등으로 웹 페이지의 레이아웃이 얼마나 변하는 지 측정한 값
- 사용자가 잘못된 클릭을 하도록 유발하는 시각적 불안정성을 체크하는 지표
💡 Lighthouse 사용법
1. npm
$ npm install -g lighthouse
$ lighthouse https://www.example.com --view2. Chrome Extension
3. Chrome DevTool
2020년 5월 19일 Lighthouse 버전 6.0 배포 이후 Chrome 웹 브라우저 내부의 개발자 도구에서 Lighthouse를 이용할 수 있게 되었다.
Option. Lighthouse-CI
Lighthouse는 CI를 제공하고 있다.
CLI로 웹 사이트의 성능을 측정하는 테스트를 실행한다.
또한, 테스트 결과를 업로드할 수 있을 뿐만 아니라 대시보드를 통해 해당 결과 데이터를 시각화해서 보여주는 Node.js 서버를 가동하는 역할을 한다.
자세한 건 아래의 링크를 참조하자.
Lighthouse-CI
👀 Lighthouse Report를 살펴보자
// web.dev 살펴보기
$ lighthouse https://web.dev/ --view --preset experimental
// daum 살펴보기
$ lighthouse https://www.daum.net/ --view --preset experimental🔍 Lighthouse 결과 항목 분석
1. Performance
Lighthouse는 실제 속도가 어떻든 간에, 화면에 콘텐츠가 얼마나 빨리 표시되고 사용자는 얼마나 빠르게 해당 콘텐츠를 인식하는 지에 더욱 초점을 맞추고 있다.
참고 : Lighthouse Performance Scoring
- Lighthouse 6
| Audit | Weight |
|---|---|
| First Contentful Paint | 15% |
| Speed Index | 15% |
| Largest Contentful Paint | 25% |
| Time to Interactive | 15% |
| Total Blocking Time | 25% |
| Cumulative Layout Shift | 5% |
- Lighthouse 5
| Audit | Weight |
|---|---|
| First Contentful Paint | 20% |
| Speed Index | 27% |
| First Meaningful Paint | 7% |
| Time to Interactive | 33% |
| First CPU Idle | 13% |
2. Accessibility
Lighthouse는 웹 애플리케이션의 접근성을 검사한다. <img> 태그에 alt 속성이 있는지, <html> 태그에 lang 속성이 있는지, 배경색과 전경색의 대비가 충분한지와 같은 항목을 확인한다.
참고 : Lighthouse Accessibility Scoring
참고2 : 접근성이란?
3. Best Practices
Lighthouse는 웹 페이지가 웹에 대한 표준 모범 사례를 따르고 있는지 확인한다. 웹 애플리케이션을 가동할 때 콘솔에 오류가 출력되진 않는지, 더는 사용하지 않는 API를 호출하고 있지 않은지, HTTPS를 통해 해당 페이지에 접근할 수 있는지와 같은 항목을 확인한다.
4. SEO
Lighthouse는 웹 페이지가 검색 엔진에 대해 최적화된 순위 결과를 가지고 있는지 확인한다. 각 사용자가 자신의 디바이스를 이용하여 웹 페이지에 접근하였을 때 그들이 콘텐츠를 읽는 데에 무리가 없는 글꼴 크기를 사용하는지, 웹 페이지의 robots.txt 파일이 유효한지, 올바른 상태 코드를 사용하는 지와 같은 일부 SEO 모범 사례를 확인한다.
참고 : Webmaster Guidelines
5. Progressive Web App
Lighthouse는 Progressive Web App을 정의하는 일련의 기준에 따라 웹 페이지를 확인한다. 이 검사는 해당 웹 페이지가 항목을 따르고 있는지 측정하여 점수를 부여하는 것이 아니다. 웹이 HTTP를 HTTPS로 리다이렉션하는지, 응답 코드는 명확한지, 3G 네트워크에서도 로딩이 빠르게 이루어지는 지와 같은 여부를 검사하여 합격 또는 실패를 부여한다.
참고 : What makes a good Progressive Web App?
🙏 친절한 Lighthouse
웹 사이트의 성능을 개선하는 데에 관심이 많다면 web.dev를 주기적으로 살펴보자. 급변하는 웹 생태계에 맞춰서 Lighthouse는 웹 사이트의 성능 측정 방법을 수시로 논의하고 개편한다. web.dev는 해당 개편안 뿐만 아니라, 개편안 측정에 활용한 검사 항목, 각 항목 별 비중의 변화까지 문서로 공유한다. 저들이 새롭게 업데이트한 Lighthouse를 사용해서 각 웹 사이트의 성능을 높이는 방법에 대한 지침 역시 제공한다.
그뿐만 아니라, Lighthouse 라는 도구 자체도 굉장히 친절한 구성을 띄고 있다. Report를 보면 바로 알 수 있다. 검사 별로 좋지 않은 성능 값이 측정된 항목에 대해 원인과 수정 방안을 제시한다. Learn more. 을 통해 상세한 설명이 적힌 문서를 확인할 수도 있다.
이토록 편리하고 친절하지만 Chrome 개발자 도구 저 구석에 숨어있는 탓에 Lighthouse는 생각보다 많은 개발자에게 낯설기만 하다. 그래서 나는 바로 오늘, Lighthouse를 사용하는 방법과 Lighthouse로 얻을 수 있는 웹 사이트 성능 측정 보고서를 분석하는 방법을 설명했다.
더는 낯설어하지 말고 위에 서술한 세 가지의 사용 방법 중 가장 쉽고 빠른 걸 선택해서 자신이 개발한 웹 사이트의 성능 점수를 확인해보는 건 어떨까?
물론, 생각보다 결과는 처참할지도 모르지만... (나 역시 그런 경험을 했었다.)
하지만 두려워 말자. 처참한 성능을 가지고 있는 웹 사이트와 함께 그 장소에서 언제까지나 머무르는 게 목적이고 올바른 길이였다면 Lighthouse는 세상에 나오지도 않았을 것이다. 혹여나 해당 도구가 세상에 나왔더라도 내가 여러분에게 Lighthouse를 사용하는 방법을 소개하는 일은 없었을 것이다. (모두에게 불필요한 요소를 굳이 시간 들여 설명하는 건 리소스 낭비에 불과하다.)
우리는 개발할 때 성능이 중요하단 사실을 이미 알고 있다. 사용자에게 고성능 애플리케이션을 제공하는 게 올바른 길이라는 것도 아주 잘 안다. 그러나 성능을 챙기면서 개발하는 건 영 어색하고 어렵다. 아주 세심한 작업이 필요하기 때문이다. 그래서 그동안 머리로는 이해하고 있었지만 손가락은 성능 개선을 위한 코드를 작성하는 걸 회피한 걸지도 모른다.
그렇게 여러 개발자는 성능 개선 앞에서 일자무식이 되었고 고성능을 위한 요소를 하나하나 꼼꼼히 챙기지도 못하게 되어버리고 만다. 그 상황에서 나름대로 침착을 유지하려 안간힘을 쓰는 개발자의 사고에 혼란을 끼얹으면 어떨까? 가령 서비스 개발 마감 기한이 다가온다거나...
시간에 쫓기지 않아도 평범한 사람의 뇌가 프로그램의 성능을 해치게 될 유의사항을 단 한 개도 놓치지 않고 확인한다는 건 불가능에 가까운데, 저렇게 된다면 정말 '성능이고 뭐고 간에 대충 만들어서 돌아가게 해놓고 나중에 고치자' (안 고침) 라는 심리만 남게 되리라.
인간은 도구를 사용하는 동물이다. 그러니 뇌 하나만 쓰려고 애쓰지 말고, 다른 똑똑한 인간이 만들어 놓은 편리하고 친절한 도구를 사용해보자. 막상 개발하다보면 급하게 배포하느라 바빠서 성능을 잘 챙기지 못할 수도 있지만, 최종적으로 production 스테이지에 애플리케이션을 배포하기 전, Lighthouse로 성능 측정 보고서를 받아본 다음 약간의 개선 작업을 진행하는 건 그리 어려운 일도 아니지 않은가. 안 그런가?
불편하겠지만 습관으로 만들자. 낯선 것을 받아들이고 몸이 친숙하게 생각하도록 꾸준히 학습하자. 웹 어셈블리 언어를 사용해 코어 구간을 새롭게 개발하여 성능을 최적화하란 것도 아니지 않은가. 쉬운 것부터 차근차근 성능을 개선해나가자. 그럼 언젠가 성능이라는 녀석을 조금 더 개선하기 위해 욕심을 내서 또 다른 지식을 학습하기 시작하는 자신의 모습을 볼 수 있으리라.
안녕하세요 lighthouse에 대해 질문이 있는데요 lighthouse https://www.daum.net/ --view --preset experimental 이렇게 노드상에서 쳤을때 m.daum.net으로 빠져서 잡더라구요 PC만 테스트 하고 싶은데 방법이 있을까요?