구글 라이트하우스(Google Lighthouse) 리포트 보는 법 정리(개발자 기획자 마케터 필수)

우선 사용할 줄 아는 척하려면 일단 이게 뭔지, 실행시키면 어떻게 생겼는지 알아야 한다. 이 글에서는 사이트 성능을 구체적으로 개선하는 방법이 아니라 구글 라이트하우스로 측정한 리포트의 각 요소들이 어떤 정보를 제공하는지, 왜 이런 리포트의 점수 결과가 좋게 나와야 하는지 등을 정리해볼 것이다. 

 

✐ 라이트하우스 리포트 내용을 구체적으로 개선해보는 글

 

구글 라이트하우스는 웹사이트를 개발하는 모든 개발자들이 사이트 성능을 개선하기 위해 알아야 하는 툴이다. 무료이고 사용하기 엄청 쉬워서 당장 내가 개발한 사이트가 뭐가 문젠지 뭘 개선해야 하는지 원클릭에 알아볼 수 있다. 라이트하우스는 크롬 익스텐션으로 추가하는 방법과, 개발자 도구를 활용하는 방법이 있는데, 나는 크롬 익스텐션을 추가했다.

 

크롬 익스텐션에 라이트하우스 검색한다.

 

구글에 "구글 라이트하우스" 라고 치면 이렇게 확장 프로그램을 설치할 수 있는 페이지가 나온다. 설치를 하고 크롬 url 검색창 옆에 주황색 등대 모양 확장 프로그램 아이콘을 추가해주면 사용 준비 끝이다. 바로 성능을 측정하고 싶은 사이트로 들어가서, 즐겨찾기 추가 한 라이트하우스 아이콘을 클릭해 "Generate Reports" 버튼을 클릭한다.

 

크롬 익스텐션 실행

 

내가 테스트로 라이트하우스로 성능을 측정해 볼 사이트는, 초기 세팅부터 혼자 머리 박아가면서 작업했지만 최적화를 한번도 고려해보지 않은 내부용 대시보드 사이트다. 상단에 있는 등대 아이콘을 클릭하면 이런 화면이 약 10초가량 뜨면서 테스트가 시작된다. 

 

라이트하우스 로딩화면. 원래 이렇게 흐리다.

 

 

그리고 조금 기다리면 리포트가 뜬다. 

 

라이트하우스 리포트

 

상단의 점수가 엄청 최악일 것 같아서 불안했는데 생각보다는 점수가 잘 나왔다ㅎ 그래도 각 평가 항목에서 70점대를 100점에 가깝게 올려주어야 회사에서구글에서 좋아하고 방문자들이 머무르고 싶어 하는 사이트가 될 수 있다. 

 

 

맨 하단으로 스크롤을 내려 보면 런타임 설정이 나오는데, 장치에 "에뮬레이트 된 모토 G4"라고 나온다. 구글 라이트하우스는 기본적으로 퍼포먼스나 접근성, 검색 결과 순위 등을 매길 때 사이트의 모바일 버전을 기준으로 테스트한다. 5년 전까지만 해도 모바일에서 UX 수준이 떨어지는 현상은 데스크탑에 비해서 크게 중요하게 생각하지 않았(다고 하)는데, 지금은 아무리 데스크톱 브라우저에서 엄청나게 속도가 빨라도 모바일에서 거북이면 검색 결과 상위에 오를 수가 없게 됐다.

 

자 다시 맨 위의 점수로 돌아와서, 4가지의 점수 중 가장 중요한 요소는 바로 퍼포먼스다. 구글 입장에서는 사이트 속도가 빨라야 검색결과를 상위에 올려줄 명확한 이유가 있다. 사용자 입장에서는 구글에서 검색을 했더니 속도가 느린 사이트만 제공하더라 하는 경험을 몇 번 맞닥뜨리고 나면 다음부터는 빙이나 네이버로 갈아탈 것이기 때문이다. 

 

라이트하우스 > 성능

 

리포트로 돌아와 성능에 대한 리포트를 보자. 내가 개발한 사이트의 경우에는 엄청나게 많은 양의 사진이 있는 것도 아니고, 글이 많은 것도 아니지만 3초마다 데이터를 실시간으로 받아온다는 점, 그에 따라 새로 차트를 업데이트한다는 점이 특이사항이다. 내 경우 76점밖에 받지 못했는데, 웹사이트에 콘텐츠가 너무 많은 경우에는 성능 점수가 10~20 점으로 어쩔 수 없이 매우 낮아지는 경우도 있다고 한다. 

 

한편 구글에서는 성능 점수를 판단하는 데 점수 아래에 있는 6개 측정 항목 중, "가장 큰 콘텐츠가 포함된 페인트(Largest Contentful Paint, LCP)"와 "총 차단 시간(Total Blocking Time, TBT)"에 가중치를 높게 둔다. 참고

 

구글에서 알려주는 성능점수 가중치 표

 

가중치는 낮아도 사용자 경험에 중요한 것들이 있다. 먼저 "첫 번째 콘텐츠가 있는 페인트(First Contentful Paint, FCP)"다. 유저가 사이트에 접속하고서 2~3초 넘게 브라우저의 아무 변화도 보지 못한다면 이탈률이 늘어나는 것은 시간문제다. 사이트가 주로 어떤 정보를 줄 수 있는지 사용자에게 빨리 피드백을 하는 것이 중요하기 때문에 의미 있는 콘텐츠를 우선적으로 보여주는 것이 중요하다. 두 번째론 "인터랙티브 시간(Time To Interactive, TTI)"이다. 단순히 내용을 알아보는 것보다는, 사용자는 직접 화면을 클릭하고 원하는 인터랙션을 수행하기 때문에, 화면에 돔이 그려졌다고 해도 버튼이 클릭되지 않는다면 뭔가 잘못 만들어진 사이트라고 느끼기 쉽다. 

 

각 단계에서 걸리는 시간을 줄인다면 성능 점수도 올라간다. 구글에서 검색결과 순위에 '페널티를 먹이는' 기준은 명확하게 나온 것이 없지만, 대체적으로 이 점수가 70점 이상이면 개선은 필요하나 나쁘지 않은 수준이라고 한다. 그래도 90점 이상으로 늘리면 UX가 좋다는 의미로 받아들여 구글 검색 알고리즘의 선택을 받을 확률이 높아진다.

 

구글 라이트하우스 리포트 > 성능 > oppertunities

 

조금 아래로 내려보면 라이트하우스의 최대 장점이라고 할 수 있는, 명확한 성능 개선 방법을 제안하는 부분이 나온다. 성능도 개선하고 싶고 이로 인해 SEO도 개선하고 싶은데 뭘 해야 할지 모르겠는 사람들에게는 최고의 해결책이다. 내 경우에는 초기 서버 응답 시간을 단축해야 하고, 사용하지 않는 자바스크립트를 줄이고, 렌더링을 차단하는 리소스를 제거하라는 등의 해결책을 제안 받았다.

 

구글 라이트하우스 리포트 > 성능 > Diagnostics

 

그다음으로는 성능에는 큰 영향을 주지는 않지만 개발자들이 개선하면 좋을 것들에 대한 진단 사항들이 나온다. 특히 빨간 세모로 된 항목들은 고쳐 주는 것이 좋다. 위와 같은 경우에는 이미지의 가로, 세로 길이를 명시하라는 진단이 나왔다. width만 정해주면 height까지 자동으로 지정되길래 별 생각이 없었는데 딱 걸렸다. 앞으로 둘 다 명시해야겠다는 다짐을 한다.

 

 

마지막으로는 테스트에서 패스한 항목들을 보여준다. 신경 써서 최적화를 한 부분은 거의 없었으니, 아마 Vue3 프레임워크 또는 웹팩의 자체 기능으로 최적화를 해 주었거나, 아니면 애초에 페이지 자체의 콘텐츠가 그리 무겁지 않아서일 확률이 높다. 추후 Vue3에서 어떤 방식으로 최적화를 해주는지 한 번 정리해봐야겠다.

 

구글 라이트하우스 리포트 > 접근성

 

성능 다음으로는 접근성에 대한 리포트가 나온다. 여기서는 다양한 사용자들이 어려움 없이 사이트를 이용할 수 있는 여러 접근성 규칙을 따르지 않는 요소들을 집어서 알려준다. 다양한 사람들이란 인터넷 상에서 장애인, 고령자 등을 포함한 모든 웹사이트 사용자를 칭한다. 시력이 좋지 않거나 오디오를 들을 수 없는 사람들도, 이미지나 오디오의 내용을 읽을 수 있도록 콘텐츠를 제공해야 한다. 

 

 

내가 개발한 사이트의 경우 메뉴 바에서 선택한 메뉴는 검정에 가까운 회색으로, 선택하지 않은 메뉴 이름은 연한 회색으로 작업을 했더니 연한 회색으로 처리한 부분이 웹 접근성 기준에 미치지 못하고 있어 반드시 수정이 들어가야 한다. 또 라벨링이 들어가야 하는 곳에 라벨을 누락한 부분도 있다. 이미지에 alt 속성을 추가해야 하는 것처럼 input 태그에도 라벨을 붙여야 한다. alt나 label 속성은 스크린 리더와 같은 보조 기술들에게 꼭 필요한 속성인 뿐만이 아니라 크롤러를 위해서도 필요하다. 

 

라이트하우스 > Best Practices

 

Best Practices는 웹사이트가 대체적으로 보안과 관련한 조건들이 충족되고 있는지를 알려준다. HTTPS를 사용하는지, 동일 출처 정책은 잘 지켜지고 있는지, deprecated 되거나 보안에 취약한 라이브러리를 사용하는지 등의 요건을 충족할수록 점수가 올라간다. 내 경우에는 브라우저 에러가 콘솔에 찍히고 있다는 점이 개선점으로 제안되었다. 

 

라이트하우스 > SEO

 

마지막은 SEO이다. 구글의 검색 결과 순위와 SEO 점수는 완벽히 대응한다고 할 수 없다. 기본적인 요건을 갖추고 있느냐에 대한 점수인 거지 해당 페이지 내의 콘텐츠가 어느 정도의 퀄리티를 가지는지, 검색어에 잘 걸리는 키워드를 사용하고 있는지 등 딥한 내용은 하나도 고려하고 있지 않다. 위에만 봐도 도큐먼트에 메타 정보가 없다는 식으로 개선점을 제안하는 것을 보면, 콘텐츠와 상관없이 프로그래머가 기본적으로 작업해 주면 되는 조건을 요구하고 있음을 알 수 있다. 

 

이상으로 구글 라이트하우스 읽는 법을 알아보았다. 개발자뿐 아니라 기획자나 마케터도 함께 이 툴을 활용하면서 기본적으로 웹사이트의 사용자 경험과 구글 SEO를 개선할 수 있다. 아쉬웠던 점은 아무래도 처음 웹사이트에 진입하는 시점에 대해서 테스트한 결과다 보니, 가비지 콜렉팅이라던지 캐시에 대한 내용은 없었다는 점이다. 그럼에도 불구하고 사용자 입장에서는 웹사이트에 처음 들어왔을 때 어떤 경험을 하는지가 앞으로의 행동에 큰 영향을 미치기 때문에 라이트하우스에서 기본적으로 제안해 주는 조건들은 개선을 하는 것이 좋을 것이다.