JS_최적화(Optimization)/Lighthouse로 성능 분석해보기

코드를 구현할 때 어떻게 하면 더 적은 비용, 적은 시간을 들여 원하는 결과를 얻을 수 있을지 고민하는 코드 최적화 과정은 꼭 필요한 과정이라는 생각이 든다.

최적화의 필요성 및 효과

- 이탈율 감소
- 전환율 증가
웹 사이트를 방문한 사용자 중 회원가입, 상품 구매 등 다른 활동으로 연결된 방문자의 비율
- 수익 증대
- UX(사용자 경험)향상

최적화 기법

JS에서 최적화를 하기 위해서는 여러 방법이 있다

1. JavaScript 파일은 HTML의 body부분에서, css는 HTML의 header 부분에서 불러온다.

간략하게 정리하자면 
CSS 파일이 header 부분에 들어가는 이유는 화면을 랜더링 할 때 필요한 CSSOM 트리를 가능한 빠르게 구성할 수 있도록 하기 위해서다.
JS가 body 하단에 작성 되는 이유는 스크립트 실행이 완료된 후(DOM 트리 생성이 완료된 후) JS 파일을 다운로드 해야 렌더링시간이 빨라지기 때문이다.

css Link를에 선언하고 js script를에 선언하는 이유(JS)

2. DOM 트리에서 불필요하게 깊이를 증가시키는 요소, 사용하지 않는 CSS 등 불필요한 요소 정리하기

// 수정 전
<div>
	<ol>
		<li> 첫 번째 </li>
		<li> 두 번째 </li>
		<li> 세 번째 </li>
	</ol>
</div>

// 수정 후 : 불필요한 div 요소 제거
<ol>
	<li> 첫 번째 </li>
	<li> 두 번째 </li>
	<li> 세 번째 </li>
</ol>

3. HTML에서 인라인 스타일 사용하지 않고 CSS 파일로 작성하는 것을 지향해야 하며 CSS 셀렉터 작성 시 간략하게 작성해야 한다.

4. 캐시 사용하기

캐시(Cache)는 다운로드 받은 데이터나 값을 미리 복사해 놓는 임시 장소를 뜻하며, 데이터에 접근하는 시간이 오래 걸리는 경우나 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 

캐시에 저장된 정보가 유효한 시간 내에서는 똑같은 데이터를 다시 받아올 필요가 없지만 유효시간이 끝난 경우에 같은 파일을 다시 받아와야 하는 경우가 생긴다.

이런 경우 서버의 파일과 캐시의 파일이 동일한지 확인해서 재사용 할 수 있도록 하는 HTTP 헤더들이 존재한다.
-> 캐시 검증 헤더와 조건부 요청 헤더

- 캐시 검증 헤더
캐시에 저장된 데이터와 서버의 데이터가 동일한지 확인하기 위한 정보를 담은 응답 헤더
Last-Modified : 데이터가 마지막으로 수정된 시점을 의미하는 응답 헤더로, 조건 헤더인 If-Modified-Since와 묶어서 사용한다.
Etag : 데이터의 버전을 의미하는 응답 헤더로, 조건부 요청 헤더인 If-None-Match와 묶어서 사용합니다.

- 조건부 요청 헤더
캐시의 데이터와 서버의 데이터가 동일하다면 재사용하게 해달라는 의미의 요청 헤더
If-Modified-Since : 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인하고, 수정되지 않았다면 캐시된 리소스를 사용한다.
If-None-Match : 캐시된 리소스의 ETag 값과 현재 서버 리소스의 ETag 값이 같은지 확인하고, 같으면 캐시된 리소스를 사용한다.

5. 트리쉐이킹(Tree Shaking)

트리쉐이킹이란 말 그대로 나무를 흔들어 잔가지를 털어내 듯 불필요한 코드를 제거하는 것을 의미한다.
시간이 지날 수록 자바스크립트 파일의 용량이 커지는 만큼 실행 시간도 증가하고 있다. 실행 시간이 증가한다는 것은 그만큼 이탈율이 커질 수 있다는 것이기 때문에 이를 줄이기 위해서 트리쉐이킹을 통한 최적화가 필요하다.

1. 필요한 모듈만 import 하기
import 구문을 사용해서 라이브러리를 불러올 때, 라이브러리 전체가 아닌 필요한 모듈만 불러오면 불필요한 코드를 제거할 수 있다
2. Babelrc 파일 설정하기
Babel은 js 문법이 구형 브라우저에서도 호환이 가능하도록 ES5 문법으로 변환하는 라이브러리다.
하지만 ES5는 import를 지원하지 않기 때문에 require를 사용해야 하는데, 이는 export되는 모든 모듈을 불러오기 때문에 트리쉐이킹이 불가해진다.
이 것을 막기 위해 Babelrc 파일에 아래와 같이 입력함으로써 ES5로 변환하는 것을 막을 수 있다.

//Barbeirc 파일

{
  “presets”: [ 
    [
      “@babel/preset-env”,
      {
	    "modules": false
        // true로 설정하면 항상 ES5 문법으로 변환함
      }
    ]
 ]
}

3. sideEffects 설정하기
웹팩은 사이드 이팩트를 일으킬 수 있는 코드의 경우, 사용하지 않는 코드라도 트리쉐이킹 대상에서 제외시킨다.
그렇기 때문에 아래와 같이 사이드 이팩트가 발생하지 않을 것을 미리 알려준다면 트리쉐이킹 대상이 되어 필요없는 코드를 제거할 수 있다

//package.json파일

//애플리케이션 전체에서 사이드 이펙트가 발생하지 않을 것이라고 말해주는 것

{
  "name": "tree-shaking",
  "version": "1.0.0",
  "sideEffects": false
}

// 혹은
//특정 파일에는 사이드 이팩트가 발생하지 않을 것이라고 말해주는 것
{
  "name": "tree-shaking",
  "version": "1.0.0",
  "sideEffects": ["./src/components/NoSideEffect.js"]
}

4. ES6 문법을 사용하는 모듈 사용하기
ES5문법을 일부만 사용하는 경우라면 ES6문법으로 통일 시키는 것이 좋다.
ES6 문법을 사용하는 모듈을 사용하면 해당 모듈에서도 필요한 부분만 import 해서 사용하지 않는 코드는 빌드할 때 제외할 수 있기 때문이다.

 

Lighthouse

실제로 운영되는 사이트의 성능검사와 그에 대한 개선책도 확인할 수 있는 크롬 오픈소스인 Lighthouse가 있다.

마침 노래를 듣고 있던 youtube의 성능검사를 진행해봤다.
점수가 높은 편으로 나와 있는 것을 알 수 있었다.

89점인 Performance는 웹 성능을 측정한 점수이다. 화면에 콘텐츠가 표시되는데 시간이 얼마나 걸리는지 등을 확인한다.
78점인 Accessibility는 웹 페이지가 접근성을 잘 갖추고 있는지 확인한다. 대체 텍스트, 적절한 WAI-ARIA 속성을 사용했는지 등을 확인한다.
83점인 Best Practices는 웹 페이지가 웹 표준 모범 사례를 잘 따르고 있는지 확인한다. HTTP 프로토콜을 사용하는지, 콘솔창에 오류가 표시되지 않는지 등을 확인한다.
75점인 SEO는 웹 페이지가 검색 엔진 최적화가 잘 되어 있는지 확인한다.
PWA(Progressive Web App)항목은 웹 사이트가 모바일 어플리케이션으로도 잘 작동하는지 확인한다. 앱 아이콘, 스플래시 화면을 제공하는지, 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지 등을 확인한다.
이 항목은 점수가 아닌 체크리스트로 확인된다.

성능검사 바로 밑에 METRICS 항목에서는 아래와 같은 6가지 항목으로 Performance를 측정한 지표를 보여준다

First Contentful Paint (FCP) : 페이지에 접속했을 때 브라우저가 DOM의 첫 번째 부분을 랜더링하는데 걸리는 시간을 측정한다. 우수한 사용자 경험을 제공하려면 FCP 가 1.8초 이하여야 한다. 
Largest Contentful Paint(LCP) : 뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정한다.
점수가 0~2.5면 Green(fast), 2.5~4면 Orange(moderate), 4이상이면 Red(slow)로 구분한다
Speed Index : 페이지를 로드하는 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는지를 측정한다.
점수가 0~3.4면 Green(fast), 3.4~5.8면 Orange(moderate), 5.8이상이면 Red(slow)로 구분한다
Time to interactive (TTI) : 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간을 측정한다.
점수가 0~3.8면 Green(fast), 3.8~7.3면 Orange(moderate), 7.3이상이면 Red(slow)로 구분한다
Total Blocking Time (TBT) : 페이지가 유저와 상호작용하기까지의 막혀있는 시간을 측정한다.
Cumulative Layout Shift(CLS) : 사용자에게 컨텐츠가 화면에서 얼마나 많이 불안정한지를 수치화한 지표

Lighthouse는 웹 성능 최적화 뿐 아니라 웹 접근성, 웹 표준, SEO관련 항목도 확인하고 해결책을 제시 해준다. 이를 이용해 개선 해 볼 수 있을 것이다.
이 개선점은 하단으로 내려가면 확인 할 수 있고 각 항목마다 해당 문제에 대한 상세 설명과 어떤 코드, 어떤 화면에서 문제 상황을 발견했는지도 확인할 수 있다.

---

출처

https://developer.chrome.com/docs/lighthouse/performance/