[웹성능최적화] 1. Web Vital?

Wendy·2022년 11월 7일

학습기록

목록 보기

19/20

웹성능 최적화 스터디를 위해 공부한 내용들을 정리.

1. 성능 측정

대표적으로 두가지
1. Web Vitals -> 실제 유저들의 접속 데이터
2. Light House -> 실험 데이터

https://fs.hubspotusercontent00.net/hubfs/4790854/CWV%20vs%20Lighthouse%20Infographic/CWV%20vs%20Lighthouse%20Infographic.pdf

web-vitals가 구글에서 수집한 실제 접속 결과의 75퍼센트를 기준으로 판단한 결과라고 한다면,
light house는 개발자가 직접 테스트 할 수 있도록 하는 도구라고 이해할 수 있을 것 같다.

1. (Core) Web Vitals

https://web.dev/vitals/
https://web.dev/defining-core-web-vitals-thresholds/

구글이 제시하는 웹 품질 평가 지표이다.
web vitals에서 가장 중요하게 지켜야 하는 3가지를 묶어 Core Web Vitals 라고 한다.
이 점수가 잘 나와야 구글 검색 결과에서 유리하다.

사이트의 전반적인 성능을 분류하기 위해 해당 페이지 또는 사이트에 대한 모든 방문의 75번째 백분위수 값을 사용한다.

Largest Contentful Paint(최대 콘텐츠풀 페인트, LCP)

https://web.dev/lcp/
https://web.dev/optimize-lcp/ (최적화)
측정: 로딩 성능
평가: good < 2.5s / poor > 4.0s

페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간
고려대상 : img, svg 내부의 image, video, url을 통해 로드된 배경이미지, 텍스트노드, 텍스트 하위 요소를 포함하는 블록
이미지라면 min(가시적크기, 기본크기), 텍스트라면 모든 텍스트 노드를 포함하는 가장 작은 직사각형
현재 최대 콘텐츠풀 요소가 뷰포트에서 제거(또는 DOM에서 제거)되더라도 이보다 더 큰 요소가 렌더링되지 않는 이상, 해당 요소가 최대 콘텐츠풀 요소로 유지
새 성능 항목을 계산하고 디스패치하는 성능 오버헤드를 낮게 유지하기 위해 요소의 크기나 위치를 변경해도 새 LCP 후보가 생성되지 않으며 오직 뷰포트에서 요소의 처음 크기와 위치만 고려

개선안

느린 서버응답 -> 서버최적화, CDN 사용, 캐시 사용, link 연결시 우선순위 조정
렌더링을 차단하는 JS/CSS 최적화
느린 리소스 로드 시간 -> 이미지 최적화, 중요한 리소스 우선 로드, 파일 압축,
환경(네트워크, 장치) 기반으로 컨텐츠 제공
클라이언트 측 렌더링 -> 서버 사이드 렌더링 활용

First Input Delay(최초 입력 지연, FID) (lighthouse 에서는 TBT 사용)

https://web.dev/fid/
https://web.dev/optimize-fid/ (최적화)

측정: 상호 작용
평가: good < 100ms / poor > 300ms

일반적으로 입력 지연(입력 대기 시간이라고도 함)은 브라우저의 메인 스레드가 다른 작업을 하고 있어 사용자에게 아직은 응답할 수 없기 때문에 발생
이벤트 처리에서 "지연" 부분만 측정하며 이벤트 처리 시간 자체나 브라우저에서 이벤트 핸들러를 실행한 후 UI를 업데이트하는 데 걸리는 시간은 측정하지 않음
페이지에서 일부 콘텐츠를 렌더링했지만 아직 안정적으로 상호 작용할 수 없는 상태이므로 일반적으로 긴 최초 입력 지연은 First Contentful Paint(최초 콘텐츠풀 페인트, FCP)와 Time to Interactive(상호 작용까지의 시간, TTI, 5초 이상의 idle time) 사이에 발생
FID 개선 지침은 총 차단 시간(TBT)을 개선하는 지침과 동일
열악한 FID의 주요 원인은 과도한 JavaScript 실행

개선안

긴 작업(50ms 초과) 세분화
클라이언트 측에서 후처리해야 하는 데이터의 양을 최소화
타사 스크립트(광고 등)의 우선순위 조정
가능한 부분에서 메인스레드 대신 웹워커 활용
js 최적화
개발자도구 Performance > Timing 섹션의 LCP 마커를 참고해 테스트 가능

Cumulative Layout Shift(누적 레이아웃 시프트, CLS):

https://web.dev/cls/
https://web.dev/optimize-cls/ (최적화)

측정: 시각적 안정성
평가: good < 0.1 / poor > 0.25

페이지의 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동에 대해 가장 큰 레이아웃 이동 점수 버스트
세션 기간으로 알려진 레이아웃 이동 버스트는 하나 이상의 개별 레이아웃 이동이 빠르게 연속해서 이루어지는 경우를 뜻합니다. 이때 각 레이아웃 사이 간격은 1초 미만이며, 총 기간은 최대 5초입니다.
가장 큰 버스트는 해당 기간 내 모든 레이아웃 이동에 대해 누적 점수가 최대인 세션 기간입니다
레이아웃 이동은 기존 요소가 시작 위치를 변경할 때만 발생. 신규 항목의 등장만으로는 문제가 없고, 신규 항목의 등장으로 기존 요소의 위치가 변경되면 문제가 됨
예상된 이동은 계산 제외 (사용자 입력 후 500밀리초 이내에 발생하는 레이아웃 이동)

계산 방식

점수 = impact fraction (영향분율) * distance fraction (이동분율)
영향분율: (이동 전 + 이동 후 - 중복) /전체 영역
이동분율: max(수평이동거리, 수직이동거리) / 프레임

개선안:

이미지, 영상, iframe, 광고 등의 자리에 크기(비율) 지정 (혹은 저화질/배경색/스켈레톤 사용)
폰트 최적화

2.Light House

https://web.dev/lighthouse-performance/

여러가지 환경을 가정하여(장비, 네트워크 등) 여러가지 주제에 대해 (성능, 접근성 등) 여러 상태를 테스트 해 볼수 있음(페이지의 로드, 화면의 변화나 인터렉션 속도 등)

각 카테고리에 대한 매트릭스로 점수 산정

항목

Mode

(https://github.com/GoogleChrome/lighthouse/blob/HEAD/docs/user-flows.md)

Navigation - 단일 페이지 로드 테스트. v9.6 이전에는 이 옵션만 있었고, 지금도 디폴트
Timespan - 시간을 주고 화면의 변화, 인터렉션등을 발생시켜 테스트
Snapshot - 특정 상태의 화면을 테스트

Device

device / mobile

분석 결과

Metrics - 점수를 결정하는 검사 지표
스크린샷 - 페이지가 로드되는 흐름
OPPORTUNITIES(기회) - 리소스 관점 (로딩성능 최적화)
DIAGNOSTICS(진단) - 페이지 실행 관점 (렌더링 최적화)
passed audits - 통과한 항목
Runtime setting - 검사할때 사용된 환경 요약

3. 다음시간에

최적화의 방법들
우리 사이트 평가 및 업그레이드
web-vitals를 측정하는 git 자동화

Wendy

개발 공부중!

다음 포스트