[TIL] Day70 #Optimization #Lighthouse

Beanxx·2022년 8월 4일

TIL

목록 보기

70/120

2022.08.04(Thurs)

[TIL] Day70
[SEB FE] Day71

☑️ Optimization

➰ 최적화: 주어진 조건으로 최대 효율을 낼 수 있도록 하는 것
➰ 최적화 in 웹개발: 주어진 조건 아래에서 최대한 빠르게 화면을 표시하도록 만드는 것

📎 최적화 필요성 / 효과

이탈률 감소 ⬇️
- 이탈이란? 방문자가 웹 사이트 첫 페이지에서 아무런 상호작용하지 않고 종료하는 것
- 화면 불러오는 시간이 길어지면 사용자가 페이지를 이탈할 확률 높아짐
전환율 증가 ⬆️
- 전환율이란? 회원가입, 상품 구매, 게시글 조회, 다운로드 등의 행위을 한 방문자의 비율
- 이탈률이 줄어들면, 전환율이 높아질 확률도 커짐
수익 증대 ⬆️
- 이탈률 감소, 전환율 증가 → 트래픽 증대 / 회원 수 증가 → 수익 증대
사용자 경험(UX) 향상 ⬆️
- 페이지 로딩이 빠를수록 UX 향상

☑️ Optimization 기법

화면 렌더링시 HTML 파일 → DOM 트리, CSS 파일 → CSSOM 트리를 결합하여 사용
→ 두 트리 중에서 하나라도 변경되면 리렌더링 유발!
→ 트리 크기가 크기 복잡할수록 더 많은 계산 필요!
→ 리렌더링에 소모되는 시간도 길어짐

🔹 HTML 최적화

DOM 트리 가볍게 만들기
- DOM 트리가 깊을수록, 자식 요소가 많을수록 DOM트리 복잡도 커짐 ⬆️
- 복잡도가 클수록 DOM 트리가 변경되었을 때 계산해야 하는 것도 많아짐 ⬆️
- ✔️ 불필요하게 깊이를 증가시키는 요소가 있다면 삭제하기!
인라인 스타일 사용 ❌
- 인라인 스타일은 계속해서 리플로우를 발생시켜 렌더링 완료 시점 늦춤
- 인라인 스타일은 웹 표준에 맞지 않으므로 지양!

🔹 CSS 최적화

사용하지 않는 CSS 제거하기
- 요소 삭제시, CSS 코드도 함께 삭제
간결한 Selector 사용하기
- Selector가 복잡할수록 스타일 계산과 레이아웃에 시간을 더 많이 소모

🔹 리소스 로딩 최적화

HTML 파일에서 JS 파일을 불러올 땐 <script> 요소, CSS 파일을 불러올 땐 <link> 요소 사용
👉 파일을 불러오는 위치가 어디인가에 따라서 렌더링 완료 시점이 달라질 수 있음

CSS 파일 불러오기
- CSSOM 트리는 CSS 코드를 모두 해석해야 구성 가능함
  ⇒ CSSOM 트리를 빠르게 구성할 수 있도록 HTML 문서 최상단에 배치하는 것이 좋음 👍
```
<head>
	<link href="style.css" rel="stylesheet" />
</head>
```
JavaScript 파일 불러오기
- <script> 요소를 만나는 순간 해당 스크립트 실행
  → <script> 요소 이전까지 생성된 DOM까지만 접근
  → <script> 요소를 HTML 코드 중간에 넣는다면, 화면이 의도한 대로 표시되지 않게 됨
- 스크립트 실행이 완료되기 전까지 DOM 트리 생성 중단 → 중단 시간만큼 렌더링 완료 시간 delay
  ⇒ JS파일은 DOM 트리 생성 완료 시점인 HTML 문서 최하단에 배치하는 것이 좋음 👍
```
<body>
    ...
 	// body 직전에 작성하는 것이 good
 	<script src="script.js" type="text/javascript"></script>
</body>
```

🔹 브라우저 이미지 최적화

페이지 대부분의 용량은 이미지 파일과 같은 미디어 파일이 차지

이미지 스프라이트
: 여러 개의 이미지를 모아 하나의 스프라이트 이미지를 만들고, background-position 속성을 사용해 이미지 일정 부분만 클래스 등으로 구분하여 사용하는 방법
- 클라이언트에서 서버 요청이 증가할수록 로딩 시간은 점점 늘어남
  ⇒ 웹 페이지 로드에 필요한 서버 요청 수를 줄이기 위해 이미지 스프라이트 기법 사용 가능
- 👍 이미지 스프라이트 기법을 사용하면 1번의 이미지 요청으로 개별 이미지를 사용할 수 있기 때문에 네트워크 로딩 시간을 줄일 수 있음
- 👍 특정 스프라이트 이미지 파일만 관리하면 되므로 관리가 용이함
아이콘 폰트 사용하기
1. CDN으로 사용: Font Awesome 가입시 키트 발급 → HTML 파일에서 <head> 요소에 삽입
2. Font Awesome 모듈 설치
```
# 핵심 패키지 설치 
$ npm i --save @fortawesome/fontawesome-svg-core

# Font Awesome React 구성 요소 설치
$ npm i --save @fortawesome/react-fontawesome@latest
```
  ✋ 클래스명을 직접 붙이거나 Font Awesome 문서를 참고하여 아이콘 스타일링 가능

WebP / AVIF 이미지 포맷 사용하기
- WebP / AVIF 사용시 JPEG/PNG보다 용량 대폭 감소
- But, 비교적 최근에 등장한 이미지 포맷이므로 모든 브라우저에서 호환 ❌
  ⇒ <picture> 태그를 이용하여 각 브라우저 호환에 맞도록 분기 대체 가능
  - <picture>: img 요소의 다중 이미지 리소스를 위한 Container 정의시 사용
```

<picture>
	<source srsset="logo.webp" type="image/webp">
	<img src="logo.png" alt="logo">
</picture>
```

🔹 캐시 사용

➰ 캐시: 다운로드 받은 데이터나 값을 미리 복사해 놓는 임시 장소
🫧 데이터 접근 시간이 오래 걸리거나 다시 값을 계산하는 시간을 절약하고 싶은 경우에 사용
⇒ 캐시를 사용하면 매번 리소스 다운로드 받을 필요 없이 캐시에서 꺼내와 재사용하면 되므로 네트워크 리소스는 물론 로딩 시간을 줄일 수 있음

✨ Front에서 캐시를 사용하려면 HTTP 요청을 보낼 때 조건부 요청 헤더를 작성하여 캐시를 재사용해도 되는지 확인해주면 됨

If-Modified-Since: 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인. 수정되지 않았으면 캐시된 리소스 사용
If-None-Match: 캐시된 리소스의 ETag 값과 현재 서버 리소스의 ETag 값이 같은지 확인하고, 같으면 캐시된 리소스 사용

✋ 보통 두 종류 헤더 동시 사용

🔹 CDN 사용

Content Delivery Network

세계 곳곳에 분포한 서버에 콘텐츠 저장
👉 CDN은 유저가 가까운 곳에 위치한 데이터 센터(서버)의 데이터를 가져옴 ⇒ 데이터 전달을 위해 거쳐야 하는 서버 개수 크게 감소 → 로딩 속도 fast

🌲 Tree Shaking

: 나무를 흔들어 잔가지를 털어내듯 불필요한 코드를 제거하는 것

🔸 트리쉐이킹을 하면 좋은 이유

JS 파일 크기
- 점점 인터랙션이 화려해질수록 파일 크기 ⬆️ → HTTP 요청 수 또한 증가 ⬆️ → 네트워크 리소스 소모 ⬆️
- ✔️ 트리쉐이킹을 통해 파일 크기를 가능한 줄이는 것이 최적화에 도움!
JS 파일 실행 시간
- JS는 코드 실행까지 거처야 하는 과정이 많으므로 다른 리소스에 비해 실행까지 상대적으로 많은 시간 소모
  ⇒ Tree Shaking을 통한 최적화 필요

🌿 JS Tree Shaking 수행 방법

필요한 모듈만 import

import { useState, useEffect } from 'react'

Babelrc 파일 설정
- Babel: JS 문법이 구형 브라우저에서도 호환 가능하도록 ES5 문법으로 변환하는 라이브러리
- ES5문법은 import 지원 ❌ → require로 변경 ⇒ 트리쉐이킹에 걸림돌🪨
  - require는 export되는 모든 모듈을 불러오기 때문!
```
{
  “presets”: [ 
    [
      “@babel/preset-env”,
      {
	    "modules": false // true 설정 -> 항상 ES5 문법으로 변환하므로 주의!~!
      }
    ]
 ]
}
```

sideEffects 설정

Webpack은 sideEffects를 일으킬 수 있는 코드의 경우, 사용하지 않는 코드라도 트리쉐이킹 대상에서 제외시킴

// sideEffects false 설정 -> 코드를 제외시켜도 됨을 웹팩에게 알림
{
  "name": "tree-shaking",
  "version": "1.0.0",
  "sideEffects": false
	// "sideEffects": ["./src/components/NoSideEffect.js"]
}

ES6 문법을 사용하는 모듈 사용
- ES5 문법 일부만 사용하는 경우 → ES6를 지원하는 다른 모듈 사용하는게 트리쉐이킹에 유리함

📎 Lighthouse

: 구글에서 개발한 오픈소스로서 웹 페이지의 품질을 개선할 수 있는 자동화 툴
👉 성능, 접근성, PWA, SEO 등을 검사하여 사용자는 어떤 웹페이지든 품질 검사 가능

🔹 Chrome 개발자 도구에서 실행

크롬으로 검사하고 싶은 페이지 url에 접속하여 개발자 도구 open
lighthouse 탭 클릭
Analyze page load 클릭하고 결과 확인해보기

🔹 Node CLI에서 실행

Lighthouse 전역 모듈로 설치
```
$ npm install -g lighthouse
```

검사 실행

# Naver 사이트 검사 실행
$ lighthouse https://www.naver.com/

모든 옵션 확인
```
$ lighthouse --help
```

🔶 Lighthouse 분석 결과 항목

Performance: 웹 성능 측정
- 화면에 콘텐츠가 표시되는데 걸리는 시간
- 표시된 후 사용자와 상호작용하기까지의 시간
- 화면에 불안정한 요소는 없는지
Accessibility: 웹 페이지가 웹 접근성을 잘 갖추고 있는지 확인
- 대체 텍스트를 잘 작성했는지
- 배경색과 콘텐츠 색상 대비가 충분한지
- 적절한 WAI-ARIA 속성을 사용했는지
Best Practices: 웹 페이지가 웹 표준 모범 사례를 잘 따르고 있는지 확인
- HTTPS 프로토콜을 사용하는지
- 콘솔창에 오류가 표시되지는 않는지
SEO: 웹페이지가 검색 엔진 최적화가 잘 되어있는지 확인
- 앱의 robots.txt가 유효한지
- <meta> 요소는 잘 작성되어 있는지
- 텍스트 크기가 읽기엔 무리 없는지
PWA (Progressive Web App): 해당 웹 사이트가 모바일 앱으로서도 잘 작동하는지 확인 (체크리스트로 확인)
- 앱 아이콘을 제공하는지
- Splash 화면이 있는지
- 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지

🔶 Metrics

First Contentful Paint (FCP): 성능(Performance) 지표 추적 메트릭
- 사용자가 페이지 접속시 브라우저가 DOM 컨텐츠 첫번째 부분을 렌더링하는 데 걸리는 시간 측정
  ⇒ 사용자가 감지하는 페이지 로딩속도 측정 (1.8s ⬇️ 👍)
Largest Contentful Paint (LCP): Viewport를 차지하는 가장 큰 콘텐츠의 render 시간 측정
👉 주요 콘텐츠가 유저에게 보이는 시간 가늠 가능
LCP time(in seconds) Color-coding
0-2.5 Green 🟢 (fast)
2.5-4 Orange 🟠 (moderate)
Over 4 Red 🔴 (slow)
Speed Index: 성능 지표 추적 메트릭
👉 페이지 로드 동안 얼마나 빨리 컨텐츠가 시각적으로 표시되는지 측정
Speen Index (in seconds) Color-coding
0-3.4 Green 🟢 (fast)
3.4-5.8 Orange 🟠 (moderate)
Over 5.8 Red 🔴 (slow)
Time to interactive(TTI): 페이지가 로드되는 시점부터 사용자와의 상호작용이 가능한 시점까지의 시간 측정
👉 페이지가 완전히 상호 작용 가능하기까지의 시간 측정
```
[기준]

- 페이지에 FCP로 측정된 컨텐츠 표시되어야 함
- 이벤트 핸들러가 가장 잘 보이는 페이지의 엘리먼트에 등록
- 페이지가 0.05초안에 사용자의 상호작용에 응답
```
TTI metric (in seconds) Color-coding
0-3.8 Green 🟢 (fast)
3.8-7.3 Orange 🟠 (moderate)
Over 7.3 Red 🔴 (slow)
Total Blocking Time(TBT): 페이지가 유저와 상호작용하기까지의 막혀있는 시간 측정
- FCP ~ TTI 사이에 긴 시간이 걸리는 작업들을 모두 기록하여 TBT 측정
Cumulative Layout Shift(CLS): 사용자에게 컨텐츠가 화면에서 얼마나 많이 움직이는지(불안정한지) 수치화한 지표

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

Speen 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.8-7.3	Orange 🟠 (moderate)
Over 7.3	Red 🔴 (slow)

✋ Opportunities 항목을 확인하면 각 Metric별 문제 확인 가능

💡 Opportunities

Opportunities 항목을 확인하면 각 Metric별 문제 확인 가능!

🙌 Naver 웹사이트 확인해보기

🔹 Server images in next-gen formats

: 이미지 포맷을 맞춰줘🙏

🧙✨ 해결방안

화면에 표시되는 사이즈와 실제 이미지 용량 일치하기
그럼 용량은 어떻게 줄이지? → imgix와 같은 이미지 cdn 사용하기

🔹 Reduce unused JavaScript

: 사용하지 않는 JavaScript 코드를 줄여줘 🙏

✋ 사용하지 않는 JS 로드시 불필요하게 대역폭 증가, FCP 지연 → 전체 페이지 성능 느려짐

🧙✨ 해결방안

Code Spliting(코드 분할) 적용
- React.lazy() & Suspense를 사용하여 지금 당장 필요한 코드가 아니면 따로 분리시키고, 나중에 필요할 때 불러와서 사용하기 ⇒ 페이지 로딩 속도 개선!
dead coe 제거: 현재 페이지에서 사용하지 않는 JS 코드 제거 👉 Tree Shaking 사용해보기

🔹 Reduce unused CSS

: 사용하지 않는 CSS 삭제해줘 🙏

🧙✨ 해결방안

PurgeCSS라는 postcss 라이브러리를 통해 사용하지 않는 CSS 삭제 가능

# postcss-purgecss 라이브러리 설치
$ yarn add -D @fullhuman/postcss-purgecss@3.0.0 postcss@7.0.35

// postcss.config.js 파일 추가해주기
const purgecss = require('@fullhuman/postcss-purgecss');

module.exports = {
  plugins: [
    purgecss({
      content: ['./src/**/*.vue', './public/index.html'],
      css: ['**/*.css'], 
      whitelistPatterns: [
        /-(leave|enter|appear)(|-(to|from|active))$/,
        /^(?!(|.*?:)cursor-move).+-move$/,
        /^router-link(|-exact)-active$/,
        /data-v-.*/,
      ],
      defaultExtractor(content) {
        const contentWithoutStyleBlocks = content.replace(
          /<style[^]+?<\/style>/gi,
          ''
        );
        return (
          contentWithoutStyleBlocks.match(/[A-Za-z0-9-_/:]*[A-Za-z0-9-_/]+/g) ||
          []
        );
      }, 
    }),
  ],
};

🔹 Eliminate render-blocking resources

: 렌더링을 방해하는 리소스를 제거해줘🙏

✋ Render blocking?
: 브라우저가 외부 리소스를 다운로드하고 파싱하는 동안 페이지 콘텐츠를 파싱/렌더링하지 않기 때문에 페이지 표시 속도 저하 ⬇️

🧙✨ 해결방안

<link rel=”preload”> 적용 → CSS를 비동기적으로 요청

🔹 Avoid multiple page redirects

: 여러 페이지 리디렉션을 피해줘🙏

✋ 리디렉션은 페이지 로드 전에 추가 지연을 발생시킴

🧙✨ 해결방안

리디렉션을 최대한 피하는 것을 목표로 해야하지만 피할 수 없는 경우 목표를 가능한 하나로 제한하기

Beanxx

FE developer

이전 포스트

[TIL] Day69 #TDD

다음 포스트

[TIL] Day70 #Optimization #Lighthouse

TIL

☑️ Optimization

📎 최적화 필요성 / 효과

☑️ Optimization 기법

🔹 HTML 최적화

🔹 CSS 최적화

🔹 리소스 로딩 최적화

🔹 브라우저 이미지 최적화

🔹 캐시 사용

🔹 CDN 사용

🌲 Tree Shaking

🌿 JS Tree Shaking 수행 방법

📎 Lighthouse

🔹 Chrome 개발자 도구에서 실행

🔹 Node CLI에서 실행

🔶 Lighthouse 분석 결과 항목

🔶 Metrics

💡 Opportunities

🔹 Server images in next-gen formats

🔹 Reduce unused JavaScript

🔹 Reduce unused CSS

🔹 Eliminate render-blocking resources

🔹 Avoid multiple page redirects

[TIL] Day69 #TDD

[TIL] Day71 #AWS

0개의 댓글