2024-04-20.md

DIL: 모던 리액트 딥 다이브, 7주차-5

스터디: 월간 CS, https://github.com/monthly-cs/2024-03-modern-react-deep-dive
오늘 진행: 개인공부

DIL-week7-5_2024-04-20

| DIL 주차 | 범위 | 내용 | 오늘차 진도 | | -------- | ---------- | --------------------------------------------------------------------------------------- | ----------- | | 7주차 | 12장, 13장 | 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표, 웹 페이지의 성능을 측정하는 다양한 방법 | 816~873p |

오늘 읽은 내용을 markdown으로 간단히 메모

웹 페이지의 성능을 측정하는 다양한 방법

create-next-app

NextWebVitalsMetric

| 지표 | 내용 | 시간 | | ------------------------------ | ------------------------------------------------------------ | ------------------ | | Next.js-hydration | 서버사이드에서 랜더링되어 하이드레이션하는 데 걸리는 시간 | 하이드레이션 | | Next.js-route-change-to-render | 페이지가 경로를 변경한 후 페이지를 랜더링하는 데 걸리는 시간 | 페이지 전환 | | Next.js-render | 경로 변경이 완료된 후 페이지를 랜더링하는 데 걸리는 시간 | 전환에 따른 랜더링 |

Google Lighthouse

구글에서 제공하는 웹 서비스 측정 도구, 오픈 소스로 운영 중
핵심 웹 지표 뿐만 아니라 접근성, PWA, SEO 등 측정 및 점검
방법
1. 크롬 익스텐션: 크롬, 파폭
2. 크롬 개발자 도구: 내장
3. CLI: lighthouse 패키지

Lighthouse - Navigation, 탐색모드

페이지에 접속했을 때부터 페이지 로딩이 완료될 때까지의 성능

| 구분 | 한글 | 내용 | | ------------------- | ---------------- | ----------------------------------------------------------------------------- | | Performance | 성능 | 핵심 웹 지표: FCP, LCP, CLS 그 외: TTI, Speed Index, Total Blocking Time | | Accessibility | 접근성 | 대체 문자, HTML + CSS 대안 삽입 | | Best Practice | 권장사항 | 보안, 표준 모드, 최신 라이브러리, 소스 맵 | | SEO | 검색 엔진 최적화 | 문서 크롤링, robots.txt 유효, meta 데이터 | | Progressive Web App | PWA | |

TTI, Time to Interactive
- 페이지에서 사용자가 상호작용할 수 있을 때까지 걸리는 시간 측정 | TTI | 기준 결과 | | ------- | --------- | | >3800ms | 좋음 | | >7300ms | 보통 | | ≤7300ms | 나쁨 |
Speed Index
- 페이지가 로드되는 동안 콘텐츠가 얼마나 빨리 시각적으로 표시되는지 계산
  - 어떻게? - 브라우저가 로드되는 페이지 실시간 캡쳐 - Speedline 라이브러리를 사용해 캡쳐된 이미지 분석 | Speed Index | 기준 결과 | | ----------- | --------- | | >3400ms | 좋음 | | >5800ms | 보통 | | ≤5800ms | 나쁨 |
Total Blocking Time
- 긴 작업 ⇒ 메인 스레드에서 특정 시간(50ms) 이상 실행되는 작업 ⇒ 메인 스레드가 차단된 것으로 간주
- 총 차단 시간은?
  - 긴 작업을 전부 모아서 각각의 작업에서 50ms를 뺀 후 합함
- 대상은?
  - FCP부터 TTI 사이의 작업
  - 즉, 최초 사용자에게 콘텐츠를 보여줬을 때부터, 상호 작용까지 걸리는 시간 사이의 작업
    - 사용자 입장 ⇒ 화면에 뭔가 있는데? 페이지가 안 움직인다 (사용자가 무언가 작업이 진행되고 있지 않다는 것을 눈치챌 수 있는 시간)

접근성

웹 접근성은, 신체적으로 불편한 사람들이 일반적인 사용자와 동등하게 웹페이지를 이용할 수 있도록 보장하는 것
- 스크린 리더 지원
  - 대체 문자, HTML + CSS 대안 삽입

권장사항

CSP, Content Security Policy가 XSS, Cross-Site Scripting에 효과적인가
- 제 3자 삽입 스크립트 공격에 취약한 요소 ex) eval, dangerouslySetInnerHTML 등
  - unsafe-inline, unsafe-eval
- CSP가 엄격하지 않으면 비슷한 도메인으로 공격할 수 있다
페이지에서 감지되는 JavaScript 라이브러리, 알려진 보안 취약점이 있는 JS 라이브러리 확인
HTTPS 확인
페이지 로드 시, 권한 요청 방지 ⇒ 다짜고짜 x, 사용자 액션 시에 권한요청&실행
- 위치정보: window.navigator.geolocation.getCurrentPosition(), watchPosition()
- 알림: Notification.requestPermission()
비밀번호 input 복붙 허용
이미지
- 가로세로비율 일치 확인
- 이미지 해상도
페이지 HTML Doctype
과거에는 웹 표준이 아직 완전히 정착되지 않았고, 다양한 웹 브라우저들이 독자적으로 렌더링 엔진을 개발하여 호환성 문제가 빈번히 발생했습니다. 이러한 상황에서는 DOCTYPE 선언이 매우 중요했는데, 이전의 HTML 버전들과 각 브라우저의 렌더링 엔진을 올바르게 구동하기 위해 DOCTYPE 선언이 필요했습니다. ex) 넷스케이프(Netscape)와 익스플로러(Internet Explorer)가 주요 웹 브라우저로 사용되었습니다. HTML5가 등장하기 전까지는 다양한 HTML 버전들이 존재했고, 각각의 DOCTYPE 선언이 사용되었습니다. 예를 들어, HTML 4.01 Transitional, HTML 4.01 Strict, XHTML 1.0 Transitional, XHTML 1.0 Strict 등이 있었습니다. 이러한 DOCTYPE 선언들은 해당하는 버전의 규격에 따라 문서가 작성되었음을 브라우저에게 알려주었습니다. 그러나 HTML5의 등장으로 DOCTYPE 선언이 훨씬 간소화되었고, 대부분의 경우에는 단순히 **<!DOCTYPE html>**만 사용하면 되게 되었습니다
```
{/* HTML5 이전 doctype 예시 */}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/html4/loose.dtd">

{/* HTML5 이후 간소화 */}
**<!DOCTYPE html>**
```
charset, 문자 집합 정의
- 브라우저가 각 바이트가 나타내는 문자를 알 수 있게 하기 위해 지정
```
<head>
  <meta charset="utf-8" /> {/* UTF-8로 인코딩 */}
</head>
```
지원 중단 API가 있나
브라우저 콘솔에 에러 로그가 찍히나
크롬 개발자 도구에 Issue 사항이 있나
유효한 소스맵
- 압축된 소스코드를 원본 소스코드로 변환하기 위해 사용할 파일
font-display: optional 폰트가 미리 로드됨(개발자가 원하는 임의 폰트 ⇒ 버벅거림 없는 랜더링)

검색엔진 최적화

웹페이지가 구글과 같은 검색엔진이 웹페이지 정보를 가져가서 공개할 수 있도록 최적화
- 문서 크롤링, robots.txt 유효, meta 데이터

Lighthouse - Timespan

실제 웹 페이지를 탐색하는 동안의 지표 측정

| 구분 | 한글 | 내용 | | -------------------------------------------- | -------- | --------------------------------------------------------------------------- | | Performance | 성능 | 핵심 웹 지표: FCP, LCP, CLS | | 그 외: TTI, Speed Index, Total Blocking Time | | Best Practice | 권장사항 | 보안, 표준 모드, 최신 라이브러리, 소스 맵 | | View Trace | 흔적 | 시간에 흐름에 따른 웹 페이지 로딩 상세 | | Tree Map | 트리맵 | 페이지를 불러올 때 로딩한 리소스를 모아볼 수 있음, 데이터 크기, 리소스 비율 |

Tree Map
- 각 리소스와 크기
- 각 리소스에서 사용하지 않은 바이트 크기

Lighthouse - Snapshot

현재 페이지 상태를 기준으로 분석

WebPageTest

웹사이트 성능 분석 도구 - 테스트하는 서버가 머므로 참고(미국/인도/캐나다/독일)

| 분석 도구 | 기능 | | ----------------- | -------------------------------------------------------------- | | Site Performance | 웹 사이트 성능 분석 | | Core Web Vitals | 웹 사이트 핵심 웹 지표 확인 | | Lighthouse | 구글 라이트하우스 | | Visual Comparison | 2개 이상의 사이트 동시에 실행, 시간 흐름에 따른 로딩 과정 비교 | | Traceroute | 네트워크 경로 확인 |

Performance Summary
- Opportunities & Experiments - Is It Quick: TTFB, 콘텐츠 랜더링, LCP - Is It Usable - Is It Resilient
run 3 times: Individual Runs
기능
- TTFB 점검
- TBT, Total Blocking Time, 랜더링 블로킹 확인: CSS, 자바스크립트
- FCP가 2.5초 이내인지 확인
개선 방안 제공
- 주요 영역 기준, lazy-loading 여부 확인
- 폰트 로딩으로 인한 문자 노출 지연 확인
  - 폰트 캐싱과 3자 호스트 / https://wicki.io/posts/2020-11-goodbye-google-fonts/
    - CDN에 캐시되어 있는 지 여부와 관계 없이, 모든 웹 사이트에 대해 다시 다운로드
  - rel=preload, rel=preconnect로 미리 오리진에 연결
- 리소스 preload 확인
- HTTP 리다이렉트 리소스 여부
  - 추가적인 네트워크 요청을 유발하기 떄문에 성능에 좋지 않음. ⇒ 가능한한 모든 리소스는 리다이렉트 되지 않고 바로 반환해야함
- 최초 다운로드 HTML와 최종 결과물 HTML 사이의 크기 비교
- Snyk 검출 보안 위협 확인
Filmstrip
Optimizations
- Keep-Alive: 서버와 연결 유지
- Gzip 리소스 압축
- 이미지 압축
- Progressive JPEG 랜더링 (블러 랜더링)
- 리소스 캐시 정책, CDN

크롬 개발자 도구

performance insights에 throttling 설정 있음
forced style recalculation: 많은 리소스 소요, 최초 로딩 시에 일어나지 않는 것이 좋다

정리

npm 라이브러리~크롬 개발자 도구까지 다양한 방법으로 성능을 측정하는 방법이 있다.
- 측정 도구는 달라도, 어떤 점을 고쳐야하는 지 탐색하는 목적
  - HTML, 자바스크립트, CSS 기본 → 성능 개선과 관련하여 지켜야 할 철칙 준수
- 성능을 개선하고, 애플리케이션에서 병목 지점을 찾기
참고자료
- https://blog.webpagetest.org/
- https://web.dev/
- https://developer.chrome.com/docs/devtools/overview?hl=ko
- https://developer.chrome.com/docs/lighthouse/overview?hl=ko