Unit8 회고

YEN J·2022년 12월 5일

Code States TIL Tree Shaking lighthouse optimization section4 최적화 기법 캐시 관리

code states

목록 보기

41/43

[최적화]Optimization

🔆 Optimization

최적화란❓
: 주어진 조건으로 최대 효율을 낼 수 있도록 하는 것

컴퓨터 공학에서의 최적화
: 가능한 적은 리소스를 소모하면서 가능한 한 빠르게 원하는 결과를 얻을 수 있도록 하는 것

웹 개발에서의 최적화
: 주어진 조건 아래에서 최대한 빠르게 화면을 표시하도록 만드는 것

최적화의 필요성 및 효과

이탈률 감소
전환율 증가
수익 증대
사용자 경험(UX) 향상

🔆 Optimization 기법

1️⃣ 최적화 기법

🚀 HTML, CSS 코드 최적화하기

HTML 최적화 방법
- DOM 트리 가볍게 만들기
  - 불필요한 요소 제거
- 인라인 스타일 사용 지양
CSS 최적화 방법
- 사용하지 않는 CSS 제거
- 간결한 셀렉터 사용

🚀 리소스 로딩 최적화하기

CSS 파일 불러오기
- HTML 문서 최상단에 배치
  - <head> 요소 안에서 불러오기
JavaScript 파일 불러오기
- DOM 트리 생성 완료 시점인 HTML 문서 최하단에 배치
  - <body> 요소 닫히기 직전에 불러오기

🚀 브라우저 이미지 최적화하기

이미지 스프라이트
- 이미지 스프라이트 기법
  : 여러 개의 이미지를 모아 하나의 스프라이트 이미지로 만들고 CSS의 background-position 속성을 사용해 이미지 일정 부분만 클래스 등으로 구분하여 사용하는 방법
  - 하나의 이미지를 사용하되 원하는 이미지가 있는 부분에 맞춰 width, height, background-position 속성을 주어 아이콘 생성
- 장점
  - 네트워크 로딩 시간 감소
  - 관리가 용이
아이콘 폰트 사용하기
- 아이콘 사용이 많을 시, 이미지가 아닌 아이콘 폰트로 용량 감소
- Font Awesome 사용하기(대표적인 아이콘 글꼴 서비스)
  - CDN으로 사용하기
    - 발급받은 키트를 HTML파일 <head> 요소에 넣어준 뒤 원하는 아이콘을 찾아 사용 환경에 맞는 코드를 복사&붙여넣기
  - Font Awesome 모듈 설치하기
    - 라이브러리처럼 설치 후 사용하는 방법
    - 사이트에서 원하는 아이콘의 정보를 확인 후 알맞게 불러와 사용
    - 아이콘 이름은 camelCase로 작성
WebP 또는 AVIF 이미지 포맷 사용하기
- 용량이 적은 이미지 포맷
- 단점
  - 모든 브라우저에서 호환되지는 ❌
- 극복 방안
  - HTML <picture> 태그를 이용하여 브라우서 호환에 맞게 분기
    - <picture>: img 요소의 다중 이미지 리소스를 위한 컨테이너 정의 시 사용하는 태그
    - 접속한 브라우저에서 <source> 태그 내 srcset에 정의한 포맷을 지원하지 않는다면 <source> 태그는 무시

🚀 CDN 사용하기

CDN(Content Delivery Network)
- 콘텐츠를 빠르고 효율적으로 제공하기 위해 설계
- 유저가 가까운 곳에 위치한 데이터 센터(서버)의 데이터를 가져오는 네트워크
  → 데이터가 전달 되기 위해 거쳐야하는 서버의 갯수 감소
  → 로딩 속도 개선

2️⃣ 캐시 관리

캐시(Cache)🗄
: 다운로드 받은 데이터나 값을 미리 복사해놓은 임시 장소

서버에서 응답 시 헤더에 Cache-Control을 작성해 전송

Cache-Control: max-age=60: 해당 파일이 60초 동안 유효하다는 의미

캐시 유효 시간 동안 같은 데이터를 반복해 받아올 필요❌

브라우저 캐시 활용 시 효과

캐시 유효 시간 동안 네트워크 리소스 절약 가능

브라우저 로딩 속도 개선

빠른 사용자 경험 제공 가능

💡 캐시 검증 헤더와 조건부 요청 헤더
: 캐시 유효 시간 종료 후 같은 파일을 받아오는 경우 캐시 파일과 서버 파일을 비교 후 동일할 경우 재사용할 수 있도록 돕는 HTTP 헤더

캐시 검증 헤더
: 캐시에 저장된 데이터와 서버의 데이터가 동일한지 확인하기 위한 정보를 담은 응답 헤더
- Last-Modified: 데이터가 마지막으로 수정된 시점을 의미하는 응답 헤더로 조건부 요청 헤더인 If-Modified-Since와 함께 사용
- ETag: 데이터의 버전을 의미하는 응답 헤더로 조건부 요청 헤더인 If-None-Match와 함께 사용
조건부 요청 헤더
: 캐시에 저장된 데이터와 서버의 데이터가 동일할 경우 재사용을 요청하는 요청 헤더
- If-Modified-Since: 캐시된 리소스의 Last-Modified 값 이후 서버 리소스 수정 여부 확인 뒤 수정되지 않았다면 캐시된 리소스 사용
- If-None-Match: 캐시된 리소스의 ETag 값과 현재 서버의 ETag 값의 일치 여부 확인 후 동일할 경우 캐시된 리소스 사용
보통 두 종류를 동시에 사용

3️⃣ Tree Shaking

트리쉐이킹(Tree Shaking)🌳
: 나무를 흔들어 잔가지를 털어내듯 불필요한 코드를 제거하는 것

JavaScript 트리쉐이킹의 필요성

JavaScript 파일의 크기 증대

웹 사이트의 인터랙션↑ → JavaScript의 비중↑

JavaScript 파일 요청 횟수 역시 증가

JavaScript 파일 실행 시간 증가

JavaScript 파일 실행 과정
: 다운로드 후 압축 해제 → JavaScript 코드 파싱 → DOM 트리 생성 → 컴파일 → 코드 실행

JavaScript 파일 실행은 CPU에 크게 영향 받음

모바일 환경에서 그 영향이 크게 부각(사양이 각기 다르므로)

JavaScript 트리쉐이킹
: 웹팩 4버전 이상 사용 시 ES6 모듈(import, export)을 대상으로 기본적인 트리쉐이킹 제공

JavaScript 트리쉐이킹 수행 방법

필요한 모듈만 import 하기
Babelrc 파일 설정하기
- Babel: 자바스크립트 문법이 호환 가능하도록 ES5 문법으로 변환하는 라이브러리
  - ES5 문법은 import 지원❌, commonJS 문법의 require로 변경
    → 트리쉐이킹의 걸림돌
    - require는 export 되는 모든 모듈을 불러옴
- Babelrc 파일에 modules 값을 false로 설정 시 ES5로 변환하는 것을 방지
sideEffects 설정하기
- Package.json 파일에서 sideEffects를 false로 설정해 사이트 이펙트가 생기지 않을 것이므로 웹팩에서 이 코드를 제외시켜도 된다는 것을 알려줌
- 특정 파일의 경로를 작성하여 특정 파일에서 사이트 이펙트가 발생하지 않을 것임을 알려줄 수도 있음
ES6 문법을 사용하는 모듈 사용하기
- ES6 문법을 사용하는 모듈 사용 시 필요한 부분만 import하여 사용 가능

4️⃣ Lighthouse

Lighthouse🏠
: 구글에서 개발한 오픈소스로 사이트를 검사하여 성능 측정을 할 수 있는 도구이자 웹 페이지의 품질을 개선할 수 있는 자동화 툴

다양한 지표를 이용하여 웹 페이지의 성능 검사 뿐만 아니라 개선책도 제공

Lighthouse 시작하기
🚀 Chrome 개발자 도구에서 실행하기

크롬에서 검사하고자 하는 페이지의 url을 입력
개발자 도구 열기
lighthouse 탭을 클릭
Generate report를 클릭, 특정 지표만 선택하여 검사 가능(Categories 이용)
30-60초간 검사 실시 후 개발자 도구 내에 리포트 생성

🚀 Node CLI에서 실행하기

Lighthouse 설치, -g 옵션을 사용하여 Lighthouse를 전역 모듈로 설치 권장
```
npm install -g lighthouse
```
검사 실행
```
lighthouse <url>
```
모든 옵션 보기
```
lighthouse --help 
```

Lighthouse 노드 모듈을 이용해 동적으로 프로그래밍하여 페이지 검사 리포트 생성 가능
→ 이를 이용해 성능 테스트 자동화 가능

Lighthouse 분석 결과 항목

Performance
- 웹 성능 측정
Accessibility
- 웹 접근성 확인
Best Practices
- 웹 표준 모범 사례를 잘 따르고 있는지 확인
SEO
- 검색 엔진 최적화가 잘 되어있는지 확인
PWA(Progressive Web App)
- 해당 웹 사이트가 모바일 애플리케이션으로서도 잘 작동하는지 확인

Lighthouse의 Performance 측정 메트릭

First Contentful Paint: 성능 지표를 추적하는 메트릭
- 사용자가 감지하는 페이지 로딩속도를 측정
  - 일부 콘텐츠의 첫 번째 렌더링 시점 측정
- FCP가 1.8초 이하여야 우수한 사용자 경험 제공 가능
Largest Contentful Paint
- 뷰포트를 차지하는 가장 큰 콘텐츠의 렌더 시간 측정
  - 주요 콘텐츠가 유저에게 보이기까지의 시간 측정 가능
- LCP 점수 해석
  
  LCP time(in seconds) Color-coding
  0-2.5 Green(fast)
  2.5-4 Orange(moderate)
  Over 4 Red(slow)
Speed Index: 성능 지표를 추적하는 메트릭
- 페이지를 로드하는 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는지 측정
- Lighthouse의 Speed Index 측정 과정
  : 브라우저 페이지 로딩과정을 각 프레임마다 캡쳐
  → 프레임 간 화면에 보이는 요소들을 계산
  → Speedline Node.js module을 이용하여 Speed index 점수를 그래프의 형태로 나타냄
- Speed Index 점수 해석
  
  Speed Index(in seconds) Color-coding
  0-3.4 Green(fast)
  3.4-5.8 Orange(moderate)
  Over 5.8 Red(slow)
Time to interactive
- 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간 측정
  - 시간 측정 기준
    - 페이지에 FCP로 측정된 컨텐츠가 표시되어야 함
    - 이벤트 핸들러가 가장 잘 보이는 페이지의 엘리먼트에 등록됨
    - 페이지가 0.05초 안에 사용자의 상호작용에 응답
- TTI 점수 해석
  
  TTI metric(in seconds) Color-coding
  0-3.8 Green(fast)
  3.9-7.3 Orange(moderate)
  Over 7.3 Red(slow)
Total Blocking Time
- 페이지가 유저와 상호작용하기까지의 막혀있는 시간 측정
  - 50ms(0.05초)를 초과하는 작업은 긴 작업으로 간주
Cumulative Layout Shift
- 사용자에게 컨텐츠가 화면에서 얼마나 많이 움직이는지(불안정한지)를 수치화한 지표
  - CLS를 통해 화면에서 이리저리 움직이는 요소(불안정한 요소)가 있는지 측정 가능

LCP time(in seconds)	Color-coding
0-2.5	Green(fast)
2.5-4	Orange(moderate)
Over 4	Red(slow)

Speed Index(in seconds)	Color-coding
0-3.4	Green(fast)
3.4-5.8	Orange(moderate)
Over 5.8	Red(slow)

TTI metric(in seconds)	Color-coding
0-3.8	Green(fast)
3.9-7.3	Orange(moderate)
Over 7.3	Red(slow)

💡 개선 방향 잡기

Opportunities 항목을 통해 각 메트릭별 문제 확인 가능
- 각 항목을 열어보면 해당 문제에 대한 상세 설명과 문제 상황을 발견한 코드와 화면 확인 가능
  → 최적화의 방향 잡기에 적합
Lighthouse는 웹 성능 최적화 뿐만 아니라 웹 접근성, 웹 표준, SEO 관련 항목도 확인 후 해결책 제시

YEN J

이전 포스트

Optimization

다음 포스트