웹사이트의 성능은 사용자들에게 첫인상으로 또는 다시는 사이트에 돌아오지 않게 되는 중요한 요소일 수 있다.
개발을 시작하기 전에도 느린 응답이나 이벤트 처리가 생기면 잘 처리가 되더라도 불편하다는 인식을 가지게 되었다. 개발 이후에는 서비스의 성공과도 연결될 수 있다는 생각에 성능 개선에 관심을 가지게 되었다.
lighthouse로 성능을 측정하고 개선을 진행해보기도 하며 다양한 지표와 시점들을 보게 되었고 이를 정리해보고자 한다.
TTFB (Time to first byte)
TTFB는 브라우저가 페이지를 요청하고 첫번째 byte를 받는 사이의 시간을 의미한다.
- DNS 검색과 HTTPS로 연결되는 경우 TCP 핸드쉐이크, SSL 핸드쉐이크 연결을 구축하는 시간도 포함한다.
- TTFB는 핵심 웹 성능 지표가 아니다, CSR은 빈 페이지를 받아 빠르지만 SSR은 이보다는 느리더라도 좋은 FCP, LCP 값을 가지기 때문이다.
- 좋은 사용자 경험을 위해 800ms 이하여야 한다.
FCP (First contentful paint)
FCP는 브라우저가 첫번째 컨텐트 bit(text, image, video, canvas, non-empty SVG)를 돔에 렌더링 하는 시간을 의미한다. 유저에게 페이지가 실제로 로딩 중이라는 피드백을 제공할 수 있게 된다.
- iframes 내용은 제외된다.
- 웹폰트 펜딩을 포함한 텍스트는 포함한다.
- 유저는 페이지 콘텐츠 소비를 시작할 수 있는 첫 번째 시간이다.
- 좋은 사용자 경험을 위해 1.8s 이하여야 한다.
- 개선 방법
LCP (Largest Contentful Paint)
LCP는 페이지의 메인 콘텐츠가 로드되었을 가능성이 있을 때 페이지 로드 타임라인에 표시된 시점, 가장 큰 콘텐츠를 기준으로 한다.
- 사용자가 감지하는 로드 속도의 지표로 중요한 역할을 한다.
- 즉 LCP가 빠르다면 사용자가 해당 페이지를 사용할 수 있다고 인지하는데 도움이 된다.
- 좋은 사용자 경험을 위해서는 2.5s 이하여야 한다.
- 느린 LCP가 발생하는 요소
- 느린 서버 응답 시간
- 렌더링 차단 JavaScript 및 css
- 느린 리소스 로드 시간
- 클라이언트 사이드 렌더링
- 개선 방법
FID (First Input Delay)
사용자가 링크를 클릭하거나, 버튼 클릭, JavaScript 기반 컨트롤을 사용하는 등 처음으로 상호 작용할 때부터 해당 상호작용에 대한 응답으로 브라우저가 실제로 인터렉티브한 동작을 시작하기까지의 시간을 의미한다.
- 지연 부분만 측정하여 이벤트 처리 시간 자체나 UI 업데이트하는 데 걸리는 시간은 측정하지 않는다.
- 좋은 사용자 경험을 위해 100ms 이하여야 한다.
- 입력 지연은 브라우저의 메인 스레드가 다른 작업을 하고 있어 사용자에게 응답할 수 없어 발생한다.
- 실제 사용자가 필요하기 때문에 개발 환경에서 측정할 수는 없다.
- 2024년 3월에 INP (Interaction to Next Paint)로 대체 보류 중인 지표이다.
TTI (Time to Interactive)
TTI는 페이지가 로드되기 시작한 시점부터 주요 하위 리소스가 로드되고 사용자 입력에 신속하고 안정적으로 응답할 수 있는 시점까지의 시간을 말한다.
- FCP가 시작된 시점부터 사용자가 인터렉티브한 작업이 가능한 시점의 시간
- 좋은 사용자 경험을 위해 5s 미만이어야 한다.
- SSR과 같은 기술로 빠른 속도로 페이지가 인터렉티브 해 보이게는 가능하지만 실제로는 인터렉티브 하지 않습니다. 메인 스레드가 차단되었거나 이러한 요소를 제어하는 JS 코드가 로드되지 않았기 때문입니다.
- FCP와 TTI 사이를 최소화하기 위해 최대한의 노력을 기울여야 한다.
- 개선 방법
FID와 TTI의 차이점
FID 첫 사용자 입력에 대한 지연 시간을 TTI는 입력 응답에 안정적인 시점을 말하기에 다릅니다.
위의 이미지처럼 메인 스레드에 긴 작업이 점유중일 때 입력에 빠르게 응답할 수 없는 상황에서 지연이 일어난다.
처음에는 FID와 TTI와 연관이 있을 것이라고 생각하였으나 이는 다르고 TBT와 관련이 있어 개발 환경에서 TBT를 개선하면 FID 또한 개선된다.
CLS (Cumulative Layout Shift)
CLS는 페이지의 전체 라이프사이클 동안 발생하는 모든 예기치 않은 레이아웃 이동에 대해 가장 큰 레이아웃 이동에 대한 점수를 의미한다.
- 좋은 사용자 경험을 위해 CLS 점수가 0.1 이하여야 한다.
- 영향받은 비율과 이동 거리 비율을 통해 계산된다.
TBT (Total Blocking Time)
TBT는 페이지가 마우스 클릭, 화면 탭, 키보드 입력과 같은 사용자 입력에 응답하지 못하도록 차단된 총시간을 측정한다.
- FCP와 TTI 사이의 모든 50ms 이상 실행되는 작업의 차단 부분을 더하여 계산된다.
- 좋은 사용자 경험을 위해 200ms 이하여야 한다.
- 코드 스플리팅, 사용하지 않는 코드 제거, 효율적인 JS 로드로 점수를 향상할 수 있다.
SI (Speed Index)
SI는 페이지 로드 중에 콘텐츠가 시각적으로 표시되는 속도를 측정하는 성능 측정 항목
- 뷰포트 크기에 따라 달라진다.
- 페이지가 시각적으로 완료될 때까지 100ms 간격으로 페이지 완성 비율을 계산한다.
- 좋은 사용성을 위해 3.4s 미만여야 한다.
- 메인 스레드 작업을 최소화하거나 자바스크립트 실행 시간을 단축시키고 FOIT에 유의하여 개선할 수 있다.
Next.js에서 web vitals( TTFB, FCP, LCP, FID) 확인하기
- _app.tsx에서 아래 코드와 같이 작성해 준다
// _app.tsx
export function reportWebVitals(metric: NextWebVitalsMetric) {
console.log(metric);
}- 각 내용을 확인할 수 있다. (참고로 value는 duration을 의미하며 밀리세컨드이다.)
Optimizing: Analytics | Next.js
Using Pages Router Features available in /pages
nextjs.org
마치며
각 지표들을 확인해 보며 웹 성능을 측정하기 위한 다양한 기준들을 살펴보았다. Lighthouse 내용과 web vitals를 확인하니 어떤 부분에 문제가 있는지 빠르게 캐치할 수 있었다. 개선 방법은 다양하고 상황에 맞는 방법을 찾는 것이 개발자에게 필요한 역량일 것이라고 생각이 된다.
참조
'프론트엔드' 카테고리의 다른 글
| 가비지 컬렉션(garbage collection) (0) | 2023.08.11 |
|---|---|
| 브라우저 렌더링 과정 - (리플로우와 리페인트) (0) | 2023.07.03 |
| REST API (0) | 2023.05.25 |
