[JS] 구글에게 점수따는 족보, lighthouse에 대하여 알아보자.

블로그를 하거나, 웹사이트 관리자라면 SEO(Search Engine Optimization)에 관한 이야기를 한 번쯤은 들어본 적이 있을것이다. SEO는 간단하게 말하자면, 구글에게 좋은 점수를 따는 방법이다. 좋은 점수를 딸수록 검색어 순위에서 올라가고, 점수를 따지 못하거나 구글의 기준을 넘지 못하면 검색어 순위가 내려가거나 검색에서 제외된다.

 

크롬 개발자들은 각 웹사이트마다 점수화하여, 얼마나 사용자 친화적인지, 얼마나 속도가 빠른지, 얼마나 접근성이 좋은지, 또한 SEO에 얼마나 최적화되어있는지에 대하여 보고서를 만들어주는 앱을 만들었으니, 이것이 lighthouse되겠다.

 

이번 포스팅에서는 lighthouse에 대하여 가볍지만, 웹 개발자 입장에서 가볍지 않게 들어가보자.

 

---

1. Lighthouse?

'F12'를 의도적으로, 혹은 의도치 않게 눌러본 사람들은 '크롬 개발자 도구'의 Lighthouse라는 탭을 본 적이 있을 것이다. 이 것이 웹페이지 성능 측정기인 lighthouse이다.

 

Lighthouse는 특정 기준에 맞추어, 웹 사이트 혹은 웹앱을 분석해주고 보고서를 생성해주는 툴이다. 구체적으로, Lighthouse에는 5가지 채점기준이 있다.

 

    - 성능(Performance)

    - 접근성(Accessibility)

    - 최상의 접근방법(Best Practice)

    - 검색엔진 최적화(SEO)

    - 웹 앱 관련 최적화(Progressive Web App)

 

사용자 혹은 웹 페이지 관리자는 검토받고자 하는 항목을 선택하여 검사를 받을 수 있으며, 각 항목을 0부터 100까지 점수로 수치화하고, 미흡사항 몇 검토사항들을 보고서 형식으로 받을 수 있다.

 

이번 포스팅에서는 필자의 블로그 메인 페이지를 lighthouse에게 검사를 맡아보자. 미리 핑계를 대자면, html, css는내 잘못일 수 있어도, JS 관련은 내 잘못이 아닐 가능성이 크다. JS는 잘못 건드리면 블로그 자체가 무너질 수 있기 때문에 일부러 함부로 건드리지 않는 것이다.

 

2. Performance

필자 블로그의 Performance 점수

성능(Performance)는 말 그대로 웹 페이지 성능에 관련된 지표를 의미한다. 세부 평가 항목으로 다음과 같은 6가지 항목들이 존재한다.

 

• First Contentful Paint : 처음 웹 페이지 로드 시 걸린 시간. 보통 초기 DOM 컨텐츠 렌더링 시간을 의미한다.
• Time to Interactive : 웹 페이지와 상호작용이 가능해질 때까지 걸린 시간. 초기 JS 다운로드 및 실행 시간을 의미한다.
• Speed Index : 웹 페이지의 컨텐츠가 모두 보일 때까지 걸린 시간.
• Total Blocking Time : 웹 페이지에서 다른 작업으로 인하여 사용자 경험을 막은 총 시간과 페이지 지연 시간
• Largest Contentful Paint : 웹 페이지의 메인 콘텐츠를 표시하는데 걸린 시간
• Cumulative Layout Shift : 웹 페이지에서 레이아웃이 변경되는 총 시간.

위 6가지 세부 성능지표 모두 웹 페이지 html, css, js 로딩 시간과 관련이 있으며, 사용자 경험과 직결되는 요소이니만큼 이 점수에 굉장히 신경써야 한다. 검사를 진행하면 어떻게 개선할 수 있는 지 짚어준다. 예를 들면, 불필요한 자바스크립트는 lazy load 혹은 inline을 사용하거나, 컨텐츠 캐시 지속시간을 늘린다던가, 이미지의 폭, 높이를 명시적으로 지정해달라고 한다. 이에 대한 자세한 설명은 보고서를 받아보면 알 수 있다. (필자의 블로그는 티스토리 자체의 한계에 의하여 발생한 문제라 어떻게 조치할 수 없다...)

 

3. Accessibility

접근성(Accessibility)은 말 그대로 웹 페이지 접근성 관련된 항목을 수치로 나타낸 것이다. 굵직한 평가항목은 따로 없지만, 변수 이름 지정, 클린 코드, 소수자 배려 등을 검사하여 미흡한 부분을 검사하고, 권장사항을 알려준다. 예를 들면 다음과 같은 세부 검사사항들이 있다.

 

• 변수 이름이 잘 명명되었거나 필수 attribute가 존재하는가? (ex. html img 태그의 alt attribute, iframe의 title...)
• 소수자 혹은 불편한 사람들도 웹 페이지 사용과 상호작용이 가능한가? (ex. 웹 사이트 확대 시 레이아웃 유지 여부, 구분이 가능한 색깔 사용 여부, 스크린 리더 최적화 여부, 기본 언어 설정 여부...)
• html 필수 태그가 존재하는가? (ex. title 존재 여부, li의 부모로써의 ul과 ol 존재 여부...)

이 항목 평가사항의 경우 수정하는데 어렵지 않지만, 웹 페이지 제작 시 간과하기 쉬운 부분이기도 하다. 따라서, 완성도 높은 웹사이트를 만들기 위해선 이 항목의 세부사항을 모두 지키는 것을 목표로 해야 한다.

 

티스토리 블로그의 경우 썸네일의 alt 태그가 존재하지 않는 부분과 확대 시 레이아웃 깨짐 부분만 빼면 접근성 관련해서는 좋은 점수를 받고 있다고 할 수 있다.

 

4. Best Practices

최상의 접근 방법, 혹은 베스트 프랙티스는 웹 사이트가 최신 기술을 사용하여 결함 혹은 취약점이 존재하지 않는지, 혹은 미지원 라이브러리는 대체하였는지, 또는 여러 강력한 보안 정책을 활용하는지에 관한, 웹 사이트 신뢰도와 관련된 평가 항목이다. 이에 관하여 좋은 점수를 받기 위해선 deprecated된 API나 라이브러리는 과감하게 버리거나, https를 지원하거나, 여러 웹 해킹 기법들을 방어할 수 있어야 한다. 예를 들면 다음과 같은 세부사항들이 있다.

 

• 취약점이 알려진 특정 버전 JS 라이브러리를 사용하는가? (티스토리 블로그의 경우 jQuery@3.2.1 라이브러리를 사용한다. 문제는 이 버전에 대한 취약점이 3개씩이나 있어 안전하지 않다!)
• 강력한 보안 정책을 사용하는가? (https 사용 여부, 패스워드 폼에 '붙여넣기' 가능 여부, CSP(Content Security Policy) 사용 여부, XSS 필터링 여부 등등...)
• HTML에서 올바른 방법으로 렌더링 되는가? (HTML doctype 지정 여부, 올바른 charset 지정 여부 등등...)

이 항목 평가사항의 경우 보안 및 신뢰와 관련된 항목이기에, 이에 대하여 낮은 점수를 받았다면 즉시 보안 패치를 하거나, 웹 사이트 설계를 다시 해야 한다. 따라서, 성능 만큼 중요한 지표라 할 수 있다.

 

티스토리 블로그의 경우 jQuery를 제발, 제발 제발 버렸으면 좋겠다. 보안도 안 좋고 성능도 별로인 이걸 요즘 시대에 촌스럽게 누가써!!!!! (구글 애드센스만 따면 바로 이사갈거다.)

 

5. SEO

SEO는 구글이나 네이버 같은 검색 엔진 관련해서 검색 결과에 최적화되어 있는지에 대한 점수이다. SEO에게 높은 점수를 받으려면 UX가 좋아야 하며, 성능과 더불어 인기도 등등 여러 항목들에서 종합적으로 높은 평가를 받아야 한다.

 

다른 평가항목과 조금 다르게, SEO는 정량적인 성격보다 정성적인 성격이 더 강하다. 따라서, SEO에 대한 생각은 모두가 다르고, 모두가 각자만의 노하우로 웹 사이트를 꾸려 나가야 한다. 다만, SEO에서 기본 점수를 받는 방법은 웹 사이트 공통으로 적용될 수 있다. 예를 들면 다음과 같다.

 

• HTML에서 내용 및 구조에 따른 시맨틱 태그를 사용하는가? (div 대신 section, aside, span 대신 h1, h2 여부 등등...) 
• 웹 사이트의 사이트맵 혹은 태그를 검색 엔진이 쉽게 얻을 수 있는가? (/sitemap.xml, 혹은 /tag.xml 존재 여부, robots.txt 설정 여부 등등...)
• 웹 사이트의 메타 정보가 제대로 담겨 있는가? (HTML의 head에 metadata 존재 여부, Apple 관련 기기 대응 여부 등등...)

특히, div를 남발하는 대신 주제 별로 section 태그를 사용하여 나누거나, 사이드바일 경우 aside 태그를 사용하거나, 헤더 관련은 header 태그, 꼬릿말 관련은 footer 태그를 사용하여 SEO에서 좋은 점수를 받을 수 있다. 또한, 제목은 h1 태그, 소제목은 h2 태그를 사용하여 각 단락마다 중요도를 구분한다면 더 좋은 점수를 받을 수 있다. 반대로 h1 태그를 남발하거나, h2 태그를 남발할 경우 검색 엔진이 키워드를 잡지 못하여 SEO에서 좋은 점수를 받을 수 없다.

 

티스토리의 경우 SEO 관련 항목은 점수를 잘 받을 수 있다. 다만 이미지의 alt 태그를 빠뜨란 항목이 몇몇 존재하고, h1 태그가 여러 군데 사용되어서 100점을 받기에는 힘든 구조이다.  (진짜 구글 애드센스만 따면 바로 이사갈거다.)

 

6. Progressive Web Application

PWA는 구글이 새로 제시한 웹 패러다임이다. PWA란 앱의 성격을 띄고 있지만, 웹의 장점만을 따 속도와 편의성 두 마리의 토끼를 모두 잡을 수 있는 웹 앱이다. 네이티브 앱보다 설치가 쉬우며, 설치 링크 쉽게 공유할 수 있다. 다만, 네이티브 앱보다 안정성은 떨어진다. 구글 관련 웹사이트에 들어가면, PWA 설치 권유를 받은 경우가 한 번쯤은 있을 것이다.

아마 이러한 아이콘을 본 적이 있을 것이다. 이것이 PWA이다.

PWA 관련 평가 지표는 얼마나 웹 앱이 네이티브 앱과 웹의 특징을 조화롭게 합쳤냐는 항목이 주를 이룬다. 이를테면 다음과 같은 항목들이 존재한다.

• 네트워크 상태와 무관하게 웹 앱이 동작하는가?
• 검색 엔진 색인이 가능하고, 다른 앱과 상호작용이 가능한가?
• 앱이 다른 기기(태블릿, 모바일, 임베디드 화면...) 에서도 반응형으로 동작하는가?
• 기존 오래된 브라우저에서도 웹 앱이 작동을 하는가?

아직 많은 한국 웹사이트가 PWA를 도입하지 않았지만, 앞으로 웹과 네이티브 앱의 통합된 생태계은 계속해서 확장할 것이라 생각한다. 티스토리 블로그는 아직 도입하지 않아 이 평가항목이 무의미하다.

---

이상으로 구글의 좋은 웹사이트 답지인 lighthouse에 대하여 알아보았다. 아직 미완성이고, 오픈소스이기에 Lighthouse의 지표를 절대적으로 믿기에는 아직 미흡한 구석이 군데군데 존재한다. 하지만, 웹 사이트에 대한 평가를 가볍게 받고 싶을 때에는 충분히 좋은 이정표를 제공해준다고 생각한다. 자신의 사이트에 대한 정량적, 정성적 평가를 받고싶다면, 크롬 개발자 도구(F12)를 눌러 지금 바로 시작해보자! (다만, 웹사이트가 새로고침되기에 웹에서 작업하던 것들은 저장을 하고 lighthouse를 실행하자... 필자가 이거 많이 당했다.)