S4) Unit 8. [최적화]캐시 & Tree Shaking & Lighthouse

📣  캐시 사용하기

𝟭. 캐시

✔️ 다운로드 받은 데이터나 값을 미리 복사해 놓는 임시 장소

➰ 데이터에 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우 사용

 

𝟮. 캐시를 이용한 요청 과정

1. 첫 번째 요청에서 캐시를 사용한다.

➰ 서버에서 응답을 보내줄 때 이미지 파일과 함께 헤더에 Cache를 작성해서 보낸다.

=> 해당 이미지 파일이 60초동안 유효하다는 것을 의미

HTTP/1.1 200 OK
Content-Type: image/jpeg
Cache-Control: max-age=60
Content-Length: 34012

// 응답 결과를 캐시에 저장

 

2. 두 번째 요청부터는 캐시를 우선 조회하게 된다.

➰ 캐시에 데이터가 존재하면서 아직 60초가 지나지 않아 유효하다면 캐시에서 해당하는 데이터를 가져와서 사용한다.

➰ 유효 시간이 60초가 지났다면 서버에서 다시 이미지를 받아오게 된다.

 

𝟯. 캐시의 효과

1️⃣ 캐시가 유효한 시간 동안 네트워크 리소스를 아낄 수 있다.

2️⃣ 파일을 다시 받아올 필요가 없기 때문에 브라우저 로딩이 빨라진다.

3️⃣ 로딩이 빨라진 만큼 빠른 사용자 경험 제공이 가능하다.

 

𝟰. 캐시 검증 헤더와 조건부 요청

✔️ 캐시 유효 시간은 지났지만, 서버에서 다시 받아와야하는 파일이 캐시에 저장되어 있는 파일과 완전히 동일한 경우 

=> 똑같은 파일을 다시 받아올 필요 없이 서버의 파일과 캐시의 파일이 동일한지 확인해서 재사용

=> 이런 상황에서 사용할 수 있는 HTTP 헤더(캐시 검증 헤더, 조건부 요청 헤더)

 

1️⃣ 캐시 검증 헤더 

✔️ 캐시에 저장된 데이터와 서버의 데이터가 동일한지 확인하기 위한 정보를 담은 응답 헤더

➰ Last-Modified : 데이터가 마지막으로 수정된 시점을 의미하는 응답 헤더로, 조건부 요청 헤더인 If-Modified-Since 와 묶어서 사용

➰ Etag : 데이터의 버전을 의미하는 응답 헤더로, 조건부 요청 헤더인 If-None-Match 와 묶어서 사용

 

2️⃣ 조건부 요청 헤더

✔️ 캐시의 데이터와 서버의 데이터가 동일하다면 재사용하게 해달라는 의미의 요청 헤더

➰  If-Modified-Since : 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인하고, 수정되지 않았다면 캐시된 리소스를 사용한다.

➰  If-None-Match : 캐시된 리소스의 ETag 값과 현재 서버 리소스의 ETag 값이 같은지 확인하고, 같으면 캐시된 리소스를 사용한다.

---

📣  트리쉐이킹

𝟭. 트리쉐이킹이란?

✔️ 나무를 흔들어 잔가지를 털어내듯 불필요한 코드를 제거하는 것을 의미

➰ 불필요한 코드들을 찾아내어 제거하면 웹 사이트 성능 최적화에 큰 도움이 된다.

 

1️⃣ JavaScript 파일의 크기

✔️ 웹 사이트에 인터랙션이 많아진 만큼 JS의 비중이 높아졌다는 것을 의미

➰ 크기가 훨씬 커진 JavaScript 파일이 늘어난 요청 횟수만큼 더 오가는 것이니, 네트워크 리소스 소모도 그만큼 커진다.

➰ 파일이 오고 가는 동안 화면 표시가 늦어진다는 것을 뜻하고, 네트워크 속도가 느린 환경에서는 더 느려진다.

=> 트리쉐이킹을 통해 파일 크기를 가능한 줄이는 것이 최적화에 도움이 된다.

 

2️⃣ JavaScript 파일의 실행 시간

✔️ 코드 실행까지 거쳐야 하는 과정이 많기 때문에 JavaScript는 다른 리소스에 비해서 실행까지 상대적으로 많은 시간을 소모한다.

➰ JavaScript 파일의 크기가 커진 만큼, 파일의 실행 시간 또한 증가하기 때문에 몇 배의 시간을 파일 실행에만 사용할 수도 있다.

=> 그만큼 이탈률은 그만큼 커지기 때문에 트리쉐이킹을 통한 최적화가 필요하다.

 

𝟮. JavaScript 트리쉐이킹이란?

1️⃣ 필요한 모듈만 import 하기

✔️ import 구문을 사용해서 라이브러리를 불러와서 사용할 때, 라이브러리 전체를 불러오는 것이 아니라 필요한 모듈만 불러오면 번들링 과정에서 사용하는 부분의 코드만 포함시키기 때문에 트리쉐이킹이 가능하다.

import { useState, useEffect } from 'react'
// import React from 'react' 보다 위처럼 하자.

 

2️⃣ Babelrc 파일 설정하기

✔️ Barbelrc 파일에 다음과 같은 코드를 작성해주면 ES5로 변환하는 것을 막을 수 있다.

➰ Babel : 자바스크립트 문법이 구형 브라우저에서도 호환이 가능하도록 ES5 문법으로 변환하는 라이브러리

➰ ES5문법은 import를 지원하지 않기 때문에 commonJS 문법의 require로 변경시키는데, 이 과정은 트리쉐이킹에 큰 걸림돌이 된다.

{
  “presets”: [ 
    [
      “@babel/preset-env”,
      {
	    "modules": false
      }
    ]
 ]
}

 

3️⃣ SideEffects 설정하기

✔️ 웹팩은 사이드 이펙트를 일으킬 수 있는 코드의 경우, 사용하지 않는 코드라도 트리쉐이킹 대상에서 제외시킨다.

➰ package.json 파일에서 sideEffects를 설정하여 사이드 이펙트가 생기지 않을 것이므로 코드를 제외시켜도 됨을 웹팩에게 알려준다.

{
  "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란?

✔️ 사이트를 검사하여 성능 측정을 할 수 있는 도구

➰ 구글에서 개발한 오픈소스로서 웹 페이지의 품질을 개선할 수 있는 자동화 툴

➰ 성능, 접근성, PWA, SEO 등을 검사하며 이를 이용해 사용자는 어떤 웹페이지든 품질 검사를 할 수 있다.

 

𝟮. Lighthouse 시작하기

1️⃣ Chrome 개발자 도구에서 실행하기

1. 크롬에서 검사하고 싶은 페이지의 url을 클릭한다.

2. 개발자 도구를 연다.

3. lighthouse 탭을 클릭한다.

    ㄴ (1) Generate report를 클릭하거나 Categories에서 특정한 지표만 선택하여 검사할 수도 있다.

    ㄴ (2) 대략 30-60초간 검사가 실행되고 리포트가 해당 페이지의 개발자 도구내에 생성된다.

 

2️⃣ Node CLI에서 실행하기

1. -g 옵션을 사용하여 Lighthouse를 전역 모듈로 설치한다.

npm install -g lighthouse

2. 검사를 실행한다.

lighthouse <url>

3. Lighthouse의 모든 옵션을 볼 수 있다.

lighthouse --help

 

𝟯. Lighthouse 분석 결과 항목

1️⃣ Performance

✔️ 웹 성능을 측정한다.

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

 

2️⃣ Accessibility

✔️ 웹 페이지가 웹 접근성을 잘 갖추고 있는지 확인한다.

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

 

3️⃣ Best Practices

✔️ 웹 페이지가 웹 표준 모범 사례를 잘 따르고 있는지 확인한다.

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

 

4️⃣ SEO

✔️ 웹 페이지가 검색 엔진 최적화가 잘 되어있는지 확인한다.

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

 

5️⃣ PWA(Progressive Web App)

✔️ 웹 사이트가 모바일 애플리케이션으로서도 잘 작동하는지 확인한다.

➰ 앱 아이콘을 제공하는지, 스플래시 화면이 있는지, 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지 등을 점수가 아닌 체크리스트로 확인한다.

 

𝟰. Lighthouse 의 Performance 측정 메트릭

1️⃣ First Contentful Paint(FCP)

✔️ 성능 지표를 추적하는 메트릭

➰ 사용자가 페이지에 접속했을 때 브라우저가 DOM 컨텐츠의 첫 번째 부분을 렌더링하는 데 걸리는 시간을 측정한다.

➰ 사용자가 감지하는 페이지의 로딩속도를 측정할 수 있으며, 우수한 사용자 경험을 제공하려면 FCP가 1.8초 이하여야 한다.

➰ 첫 번째 렌더링 시점을 측정하는 것이 아닌 주요 콘텐츠 로딩이 완료된 시점을 측정하는 것을 목표로 한다면 LCP 지표로 확인할 수 있다.

 

2️⃣ Largest Contentful Paint(LCP)

✔️ 뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정한다.

➰ 주요 콘텐츠가 유저에게 보이는 시간까지를 가늠할 수 있다.

 

3️⃣ Speed Index

✔️ 성능 지표를 추적하는 메트릭

➰ 페이지를 로드하는 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는 지를 측정한다.

➰ 라우저의 페이지 로딩과정을 각 프레임마다 캡쳐하고, 프레임 간 화면에 보이는 요소들을 계산한다.

➰ 그 후 Speedline Node.js module을 이용해서 Speed Index 점수를 그래프의 형태로 나타낸다.

 

4️⃣ Time to interactive(TTI)

✔️ 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간을 측정한다.

➰ 페이지가 완전히 상호 작용 가능하기까지의 시간을 측정한다.

➰ 상호 작용 가능의 기준

    ㄴ 페이지에 FCP로 측정된 컨텐츠가 표시되어야 한다.

    ㄴ 이벤트 핸들러가 가장 잘 보이는 페이지의 엘리먼트에 등록된다.

    ㄴ 페이지가 0.05초안에 사용자의 상호작용에 응답한다.

➰ TTI 점수는 아카이브된 HTTP 데이터를 기반으로 백분위 단위로 점수를 측정한다.

 

5️⃣ Total Blocking Time(TBT)

✔️ 페이지가 유저와 상호작용하기까지의 막혀있는 시간을 측정한다(0.05초가 넘는 작업)

➰ FCP와 TTI 사이에 긴 시간이 걸리는 작업들을 모두 기록하여 TBT를 측정한다.

 

6️⃣ Cumulative Layout Shift(CLS)

✔️ 사용자에게 컨텐츠가 화면에서 얼마나 많이 움직이는지(불안정한 지)를 수치화한 지표

➰ 화면에서 이리저리 움직이는 요소(불안정한 요소)가 있는 지를 측정할 수 있다.

 

𝟱. 개선 방향 잡기

✔️ Opportunities 항목을 확인하면 각 메트릭별 문제를 확인할 수 있다.

➰ 각 항목을 열어보면 해당 문제에 대한 상세 설명과 함께 어떤 코드, 어떤 화면에서 문제 상황을 발견했는지 확인할 수 있기 때문에 최적화의 방향을 잡기 좋다.