12장. 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표

핵심 웹 지표(Core Web Vital)란?

• 웹사이트에서 뛰어난 사용자 경험을 제공하는 데 필수적인 지표를 일컫는 용어
• 구글에서 핵심 웹 지표로 꼽는 지표는
  • 최대 콘텐츠풀 페인트(LCP: Largest Contentful Part)
  • 최초 입력 지연(FID: First Input Delay)
  • 누적 레이아웃 이동(CLS: Cumulative Layout Shit)
• 핵심까지는 아니지만, 특정 문제를 진단하는 데 사용될 수 있는 지표는
  • 최초 바이트까지의 시간(TTFB: Time To First Byte)
  • 최초 콘텐츠풀 페인트(FCP: First Contentful Paint)

최대 콘텐츠풀 페인트(LCP)

• 페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에서 가장 큰 이미지 또는 텍스트를 렌더링하는 데 걸리는 시간
• 뷰포트 : 사용자에게 현재 노출되는 화면
• 뷰포트 내부에서 ‘큰 이미지와 텍스트’
  • <img>
  • <svg> 내부의 <image>
  • poster 속성을 사용하는 <video>
  • url()을 통해 불러온 배경 이미지가 있는 요소
  • 텍스트와 같이 인라인 텍스트 요소를 포함하고 있는 블록 레벨 요소 (<p>, <div> 등이 포함됨)
• 즉, 최대 콘텐츠풀 페인트란 사용자의 기기가 노출하는 뷰포트 내부에서 가장 큰 영역을 차지하는 요소가 렌더링되는 데 얼마나 걸리는지를 측정하는 지표
• 좋은 점수란 해당 지표가 2.5초 내로 응답이 오는 것이다. 4초 이내로 응답이 온다면 보통, 그 이상이 걸리면 나쁨으로 판단됨

개선 방안

• 텍스트는 언제나 옳다. 가능한 한 해당 영역은 텍스트로 채워라.
• 이미지는 어떻게 불러오는 것이 좋을까?
  • <img> : 내부의 리소스는 HTML 파싱이 미처 완료되지 않더라도 프리로드 스캐너가 병렬적으로 리소스를 다운로드하므로 최대 콘텐츠풀 페인트 요소를 불러오기에 적절한 방법이다.
  • <svg> 내부의 <image> : <svg> 내부의 <image>가 로딩되는 순서는 자바스크립트 리소스의 다운로드가 완료된 후에야 이미지를 다운로드한다. 즉, 프리로드 스캐너에 의해 발견되지 않아 병렬적으로 다운로드가 일어나지 않는다. 이는 결국 최대 콘텐츠풀 페인트 점수에도 악영향을 미치므로 이러한 방식은 삼가는 것이 좋다.
  • <video>의 poster : 프리로드 스캐너에 의해 조기에 발견되어 <img>와 같은 성능을 나타낸다.
  • background-image : CSS에 있는 리소스는 항상 느리다. 브라우저가 해당 리소스를 필요로 하는 DOM을 그릴 준비가 될 때까지 리소스 요청을 뒤로 미루기 때문이다.

그 밖에 조심해야 할 사항

• 이미지 무손실 압축
• loading=lazy 주의 : 리소스를 중요하지 않음으로 표시하고 필요할 때만 로드하는 전략. 그저 로딩 속도만 늦출 뿐 지표 점수에는 도움이 되지 않는다.
• fadein과 같은 각종 애니메이션
• 클라이언트에서 빌드하지 말 것
• 최대 콘텐츠풀 리소스는 직접 호스팅 : 다른 출처(origin)에서 이렇게 정제한 이미지를 가져오는 것은 최적화에 별로 좋은 영향을 미치지 않는다. 왜냐하면 이미 연결이 맺어진 현재 출처와는 다르게, 완전히 새로운 출처의 경우에는 네트워크 커넥션부터 다시 수행해야 하기 때문이다.

최초 입력 지연(FID)

• 사용자가 페이지와 처음 상호 작용할 때부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시작을 측정
• 사용자가 얼마나 빠르게 웹페이지와의 상호작용에 대한 응답을 받을 수 있는지 측정하는 지표
• 최초의 입력 하나에 대해서만 그 응답 지연이 얼마나 걸리는지 판단
• 메인 스레드가 바쁜 경우, 자바스크립트 실행 환경은 ‘싱글 스레드’이기 때문에 자바스크립트가 이벤트 리스너와 같은 다른 작업을 실행할 수 없어 지연이 발생한다. 즉, 이벤트가 발생하는 시점에 최대한 메인 스레드가 다른 작업을 처리할 수 있도록 여유를 만들어 둬야 사용자에게 빠른 반응성을 보장할 수 있다.
• 구글은 사용자 경험을 크게 4가지로 분류해 정의하는데, 이를 RAIL이라고 한다.
  • Response : 사용자의 입력에 대한 반응 속도. 50ms 미만으로 이벤트를 처리할 것
  • Animation : 애니메이션의 각 프레임을 10ms 이하로 생성할 것
  • Idle : 유휴 시간을 극대화해 페이지가 50ms 이내에 사용자 입력에 응답하도록 할 것
  • Load : 5초 이내에 콘텐츠를 전달하고 인터랙션을 준비할 것
• 정리하자면, 최초 입력 지연이란 화면이 최초에 그려지고 난 뒤, 사용자가 웹페이지에서 클릭 등 상호작용을 수행했을 때 메인 스레드가 이 이벤트에 대한 반응을 할 수 있을 때까지 걸리는 시간을 의미한다.
• 메인 스레드가 처리해야 하는 다른 작업이 많을수록 느려진다.
• 이벤트 핸들러가 완료되는 데 걸리는 시간은 측정하지 않는다. 만약 이벤트 핸들러의 실행 시간을 측정하고 싶다면 Event Timing API를 사용하는 것이 좋다.
• 좋은 점수를 얻기 위해서는 100ms 이내로 응답이 와야 하며, 300ms 이내인 경우 보통, 그 이후의 경우에는 나쁨으로 처리된다.

개선 방안

• 실행에 오래 걸리는 긴 작업을 분리 : 몇 가지 대안을 연구해야 한다.
  • 꼭 웹페이지에서 해야 하는 작업인가
  • 긴 작업을 여러 개로 분리하기 : 단순히 실행이 오래 걸릴 것 같은 작업을 분리하는 것뿐만 아니라 웹페이지 최초 로딩에 필요하지 않은 내용을 나중에 불러오는 것도 포함된다. 이러한 리소스는 리액트의 Suspense와 lazy를, 혹은 Next.js의 dynamic을 이용해 나중에 불러오게 할 수 있다.
• 자바스크립트 코드 최소화
  • 크롬 개발자 도구로 들어가서 커버리지를 클릭한다. 현재까지 웹 페이지에서 사용되지 않은 코드가 얼마나 있는지 확인할 수 있다.
  • 또 한가지 살펴볼 만한 것은 폴리필(polyfill)이다. 폴리필이란 브라우저에서 지원하지 않는 기능을 사용하기 위해 웹페이지에서 직접 구현하고 집어넣는 코드를 의미한다.
  • 폴리필의 크기는 제법 크기 때문에, 폴리필을 집어넣기 전에는 반드시 두가지를 먼저 확인해봐야 한다.
  • 폴리필이 필요한 환경인가?
  • 꼭 필요한 폴리필인가?
• 타사 자바스크립트 코드 실행의 지연 : 타사 스크립트는 대부분 웹페이지 로드에 중요한 자원이 아니므로 <script>의 async와 defer를 이용해 지연 불러오기를 하는 것이 좋다.
  • defer : 해당 스크립트를 다른 리소스와 함께 병렬로 다운로드한다. 이 스크립트의 실행은 페이지가 완전히 로딩된 이후에 맨 마지막에 실행된다.
  • async : 해당 스크립트를 다른 리소스와 함께 병렬로 다운로드한다. async 리소스의 다운로드가 완료되어 버리면 다른 리소스의 다운로드가 완료되는 것을 기다리지 않고 바로 실행한다.
  • 둘 다 없는 경우 : script를 만나는 순간 다운로드가 우선되며, 다운로드가 완료되면 코드 실행이 우선된다. 다른 작업은 다운로드와 실행이 끝날 때까지 미뤄진다.
  • 만약 실제 사용자의 뷰포트 위치에 따라 불러와야 하는 컴포넌트라면 Intersection Observer를 이용해 뷰포트에 들어오는 시점에 불러오는 것이 좋다.

누적 레이아웃 이동(CLS)

• 페이지의 생명주기 동안에 발생하는 모든 예기치 않은 이동에 대한 지표를 계산하는 것
• 이 지표가 낮을수록, 즉 사용자가 겪는 예상치 못한 레이아웃 이동이 적을수록 더 좋은 웹사이트다.
• 사용자의 가시적인 콘텐츠에 영향을 미쳐야 하기 때문에 뷰포트 내부의 요소에 대해서만 측정하며, 뷰포트 밖의 요소에 대해서는 측정하지 않는다.
• 이 점수를 계산할 때 포함되는 내용은
  • 영향분율 : 레이아웃 이동이 발생한 요소의 전체 높이와 뷰포트 높이의 비율
  • 거리분율 : 레이아웃 이동이 발생한 요소가 뷰포트 대비 얼마나 이동했는지 를 곱해서 최종 점수를 계산한다.
• 클라이언트에서 미치 노출이 예상되는 부분을 HTML로 자리 잡아두는 것이 누적 레이아웃 지표에 큰 도움이 된다는 점을 알 수 있다.
• 0.1 이하인 경우 좋음, 0.25 이하인 경우 보통이며 그 외에는 개선이 필요한 나쁜 점수로 보고된다.

개선 방안

• 삽입이 예상되는 요소를 위한 추가적인 공간 확보
• 폰트 로딩 최적화
  • 폰트로 인해 발생할 수 있는 문제는 크게 두 가지다.
  • FOUT(flash of unstyled text) : HTML 문서에서 지정한 폰트가 보이지 않고 대체 기본 폰트로 보이고 있다가 뒤늦게 폰트가 적용되는 현상
  • FOIT(flash of invisible text) : HTML 문서에서 지정한 폰트가 보이지 않고, 기본 폰트도 없어서 텍스트가 없는 채로 있다가 뒤늦게 폰트가 로딩되면서 페이지에 렌더링되는 현상
  • 사용자 기기의 기본 폰트 이외에 다른 폰트로 웹페이지를 보여주고 싶다면 다음과 같은 점을 유념해야 한다.
  • <link>의 preload 사용 : rel=preload는 페이지에서 즉시 필요로 하는 리소스를 명시하는 기능이다. preload로 지정된 요소는 웹페이지의 생명주기에서 초기에 불러와야 하는 중요한 리소스로 간주되므로 브라우저는 리소스를 더 빠르게 사용할 수 있도록 준비해준다. 따라서 rel=preload로 스타일이나 폰트를 지정하면 페이지의 렌더링을 가로먹거나 레이아웃을 방해할 가능성이 줄어든다.
  • font-family
  • fallback : 이 옵션을 사용하면 100ms간 텍스트가 보이지 않고, 그 이후에 폴백 폰트로 렌더링한다. 그리고 3초 안으로 폰트가 로딩된다면 해당 웹 폰트로 전환하고, 그렇지 않다면 폴백 폰트를 계속 사용한다.
  • optional : 100ms간 텍스트가 보이지 않고, 그 이후에 폴백 폰트로 렌더링한다. 그러나 0.1초 이내로 폰트가 다운로드돼 있거나 캐시돼 있지 않다면 폴백 폰트를 사용한다. 브라우저가 네트워크 상태를 파악해 일정 기간 폰트를 다운로드하지 못한다면 연결을 취소한다.
• 적절한 이미지 크기 설정
  • width, height 지정
  • 만약 사용자 뷰포트 너비에 맞춰 다른 이미지를 제공하고 있는 경우, 즉 반응형 이미지를 사용하고 싶다면 srcset 속성을 사용하는 것이 좋다.

최초 바이트까지의 시간(TTFB)

• 브라우저가 웹페이지의 첫 번째 바이트를 수신하는데 걸리는 시간
• 최초의 응답이 오는 바이트까지가 얼마나 걸리는지 측정하는 지표
• 600ms 이상이 걸릴 경우 개선이 필요한 것으로 간주된다.
• 서버 사이드 렌더링을 하고 있는 애플리케이션에서 주의 깊게 봐야 할 지표다.
• 최초 바이트까지의 시간을 개선하려면
  • 서버 사이드 렌더링을 수행하고 있다면 로직을 최적화해 페이지를 최대한 빨리 준비시켜야 한다. 서버 사이드 렌더링 시에 API 호출이 필요하다면 이 호출 또한 최적화할 필요가 있다.
  • 웹페이지의 주된 방문객의 국적을 파악해 최대한 해당 국적과 가깝게 서버를 위치시키는 것이 좋다.
  • 리액트 서버 사이드 렌더링이라면 스트리밍 API를 사용하는 것이 좋다. 스트리밍을 사용할 경우 완성된 영역부터 조각조각 받을 수 있어 최초 바이트까지의 시간을 단축할 수 있다.

최초 콘텐츠풀 페인트(FCP)

• 페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정한다.
• 1.8초 이내에 이뤄진다면 좋음, 3.0초 이내는 보통, 그 이후는 개선이 필요한 것으로 보고된다.
• 개선하려면 다음 사항을 고려해야 한다.
  • 최초 바이트까지의 시간(TTFB)을 개선
  • 렌더링을 가로막는 리소스 최소화
  • Above the Fold에 대한 최적화 : 웹에서는 최초에 스크롤을 굳이 하지 않아도 보이는 영역을 말한다. 이 영역은 최대한 사용자에게 빠르게 무언가를 보여줘야 하는 영역이므로 게으른 로딩을 하거나 스크립트(리액트의 useEffect와 같이)에 의존해 요소가 렌더링되는 것을 피해야 한다.
  • 페이지의 리다이렉트 최소화
  • DOM 크기 최소화

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

애플리케이션에서 성능 확인하기

create-react-app

• reportWebVitals 함수는 웹에서 성능을 측정하기 위한 함수다.
• 누적 레이아웃 이동(CLS), 최초 입력 지연(FID), 최초 콘텐츠풀 페인트(FCP), 최초 콘텐츠 페인팅(LCP), 첫 바이트까지의 시간(TTFB)을 측정하는 용도로 사용된다.
• 브라우저의 웹페이지 성능을 측정할 수 있는 이유는 PerformanceObserver라는 API를 사용하기 때문이다.
• PerformanceObserver는 웹페이지에서 다양한 성능을 측정할 수 있도록 도와주는 API

create-next-app

• 성능 측정을 할 수 있는 메서드인 NextWebVitalsMetric을 제공한다.
• Next.js에 특화된 사용자 지표도 제공한다.
  • Next.js-hydration : 페이지가 서버 사이드에서 렌더링되어 하이드레이션하는 데 걸린 시간
  • Next.js-route-change-to-render : 페이지가 경로를 변경한 후 페이지를 렌더링을 시작하는 데 걸리는 시간
  • Next.js-render : 경로 변경이 완료된 후 페이지를 렌더링하는 데 걸린 시간

구글 라이트하우스

• 별도의 애플리케이션 코드 수정이나 배포, 수집 없이도 지표를 수집할 수 있다.
• 핵심 웹 지표뿐만 아니라 접근성, PWA, SEO 등 웹 페이지를 둘러싼 다양한 요소들을 측정하고 점검할 수 있다.
• 탐색 모드 : 페이지에 접속했을 때부터 페이지 로딩이 완료될 때까지의 성능을 측정하는 모드 (성능, 접근성, 권장사항, 검색 엔진 최적화)
• 기간 모드 : 실제 웹페이지를 탐색하는 동안 지표를 측정하는 것(흔적, 트리맵)
• 스냅샷 모드 : 탐색 모드와 유사하지만 현재 페이지 상태를 기준으로 분석한다. 페이지 로딩이 아닌 특정 페이지 특정 상태를 기준으로 분석하고 싶을 때 사용한다.

성능

• 웹페이지의 성능과 관련된 지표를 확인할 수 있는 영역이다.
• 핵심 웹 지표인 최초 콘텐츠풀 페인트(FCP), 최초 콘텐츠 페인팅(LCP), 누적 레이아웃 이동(CLS) 이외에도 3가지 추가적인 지표가 있다.
• Time to Interactive : 페이지에서 사용자가 완전히 상호작용(인터렉션)할 수 있을 때까지 걸리는 시간. 상호작용에 걸리는 시간이란
  • 최초 콘텐츠풀 페인트로 측정되는 페이지 내 콘텐츠가 표시되는 시점
  • 보여지는 페이지 요소의 대부분에 이벤트 핸들러가 부착되는 시점
  • 페이지가 유저의 상호작용에 50ms 내로 응답하는 시점
  • 이 TTI 지표가 3.8초 이내면 좋음, 3.7초 이내면 보통, 그 이후는 개선이 필요한 것으로 본다.
• Speed index : 페이지가 로드되는 동안 콘텐츠가 얼마나 빨리 시각적으로 표시되는지를 계산한다. 이 지표가 3.4초 이내면 좋음, 5.8초 이내면 보통, 그 이후는 느리다고 판단한다.
• Total Blocking Time : 메인 스레드에서 특정 시간 이상 실행되는 작업, 즉 긴 작업이 수행될 때마다 메인 스레드가 차단된 것으로 간주한다. 메인 스레드에서 실행하는 작업이 50ms 이상 걸리면 이를 긴 작업이라고 간주하고, 이렇게 실행되는 긴 작업을 모아서 Total Blocking Time(총 차단 시간)이라고 한다. 이 시간은 최초에 사용자에게 무언가 콘텐츠를 보여줬을 때(최초 콘텐츠풀 페인트,FCP)부터 상호작용까지 걸리는 시간(TTI) 사이의 작업만 대상으로 한다.

접근성

• 웹 접근성 : 장애인 및 고령자 등 신체적으로 불편한 사람들이 일반적인 사용자와 동등하게 웹페이지를 이용할 수 있도록 보장하는 것

권장사항

• 웹사이트를 개발할 때 고려해야 할 요소들을 얼마나 지키고 있는지 확인
• 보안, 표준모드, 최신 라이브러리, 소스 맵 등
• CSP가 XSS 공격에 효과적인지 확인
  • XSS(Cross Site Scripting) : 개발자가 아닌 제3자가 삽입한 스크립트를 통해 공격하는 기법
  • CSP(Content Security Policy) : 웹 사이트에서 호출할 수 있는 컨텐츠를 제한하는 정책
• 감지된 JavaScript 라이브러리
• HTTPS 사용
• 페이지 로드 시 위치정보 권한 요청 방지하기
• 페이지 로드 시 알림 권한 요청 방지하기
• 알려진 보안 취약점이 있는 프런트엔드 자바스크립트 라이브러리를 사용하지 않음
• 사용자가 비밀번호 입력란에 붙여넣을 수 있도록 허용
• 이미지를 올바른 가로세로 비율로 표시
• 이미지가 적절한 해상도로 제공됨
• 페이지에 HTML Doctype 있음
• 문자 집합을 제대로 정의함
• 지원 중단 API 사용하지 않기
• 콘솔에 로그된 브라우저 오류 없음
• Chrome Devtools의 issues 패널에 문제 없음
• 페이지에 유효한 소스 맵이 있음
• font-display : optional을 사용하는 폰트가 미리 로드됨

검색 엔진 최적화

• 웹페이지가 구글과 같은 검색엔진이 쉽게 웹페이지 정보를 가져가서 공개할 수 있도록 최적화돼 있는지를 확인하는 것을 의미
• 검색엔진에 최적화돼 있을수록 검색 엔진의 검색결과 우선순위에 높게 나타나며, 사용자가 유입될 가능성이 높아진다.

흔적

• 상세하게 시간의 흐름에 따라 어떻게 웹페이지가 로딩됐는지를 보여준다

트리맵

• 페이지를 불러올 때 함께 로딩한 모든 리소스를 함께 모아서 볼 수 있는 곳
• 웹페이지의 전체 자바스크립트 리소스 중 어떠한 파일이 전체 데이터 로딩 중 어느 정도를 차지했는지를 비율로 확인할 수 있으며, 실제 불러온 데이터의 크기를 확인할 수도 있다.
• 로딩한 리소스에서 사용하지 않은 바이트의 크기를 확인할 수 있는데, 이는 실제로 불러왔지만 사용되지 않은 리소스를 의미한다.

WebPage Test

• WebPage Test에서 제공하는 분석 도구
  • Site Performance : 웹사이트의 성능 분석을 위한 도구
  • Core Web Vitals : 웹사이트의 핵심 웹 지표를 확인하기 위한 도구
  • Lighthouse : 구글 라이트하우스 도구
  • Visual Comparison : 2개 이상의 사이트를 동시에 실행해 시간의 흐름에 따른 로딩 과정을 비교하는 도구
  • Traceroute : 네트워크 경로를 확인하는 도구
• 한국과 어느 정도 거리가 먼 서버를 기준으로 테스트하기 때문에 크롬 개발자 도구에서 테스트했을 때보다 성능 지표가 좋지 않을 가능성이 매우 높다.

측정 결과 페이지는

• Opportunities & Experiments : 웹 사이트에 대한 평가를 총 3가지로 나눠서 보여준다.
  • Is it Quick : 웹사이트가 충분히 빠른지를 평가한다. 여기서 빠름을 나타내는 것은 최초 바이트까지의 시간(TTFB)이 짧은지, 콘텐츠 렌더링이 즉각적으로 일어났는지, 최대 콘텐츠풀 페인트(LCP) 시간이 합리적인지를 확인한다.
  • Is it Usable : 웹사이트의 사용성과 시각적인 요소를 확인한다. 콘텐츠 누적 이동(CLS)을 최소화하고 있는지, 상호작용을 빠르게 할 수 있는지, 접근성 이슈가 있는지, 클라이언트 사이드에서 과도하게 HTML을 많이 렌더링하는지 등을 점검한다.
  • Is it Resilient : 보안 취약성을 검증한다.
• Observed Metrics : 최초 바이트까지의 시간, 렌더링 시작에 소요되는 시간, 최초 콘텐츠풀 페인트 등 측정할 수 있는 다양한 시간 지표에 대해 나타낸다.
• Individual Runs : 기본적으로 WebPageTest는 3번의 테스트를 돌려서 평균값을 보여주는데, 각 실행별로 어떠한 결과를 보여주는지 확인할 수 있다.

Opportunities & Experiments

• 최초 바이트까지의 시간(TTFB)을 점검한다.
• 렌더링을 블로킹하는 자바스크립트가 있는지 확인한다.
• 렌더링을 블로킹하는 CSS가 있는지 확인한다.
• 최초 콘텐츠풀 페인트가 2.5초 이내인지 확인한다.
• 주요 영역에 게으른 로딩되는 이미지가 있는지 확인한다.
• 주요 영역 외에 이미지가 게으르게 로딩되는지 확인한다.
• 문자의 노출을 지연시키는 커스텀 폰트가 있는지 확인한다.
• 제3자 호스트에서 폰트를 불러오는지 확인한다.
• 실제로 사용하지 않는 리소스를 rel=preload로 불러오지 않는지 확인한다.
• HTTP 리다이렉트되는 리소스가 없어야한다.
• 최초로 다운로드받은 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다.
• Is it Usable
  • 이미지 비율 부재로 인한 레이아웃 이동 가능성 여부를 확인한다.
  • 어떤 이유에서건 메인 스레드가 장시간 멈춰 있어서는 안 된다.
  • meta: viewport가 적절하게 삽입돼 있어야 한다.
  • 접근성 이슈가 있는지 확인한다.
  • 최초로 다운로드받은 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다.
• Is it Resilient
  • 렌더링을 막는 제3자 라이브러리 요청이 없어야 한다.
  • Snyk에서 검출된 보안 위협이 없어야 한다.
  • 모든 요청은 HTTP가 아닌 HTTPS를 거쳐야 한다. HTTPS는 데이터의 무결성을 담보하고, 사용자의 개인정보를 보호하며, 보안 위협으로부터 지켜주므로 반드시 HTTPS를 사용해야 한다.
  • 최초로 다운로드한 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다.

Filmstrip

• 웹사이트를 마치 필름을 보는 것처럼 시간의 흐름에 따라 어떻게 웹사이트가 그려졌는지, 또 이때 어떤 리소스가 불러와졌는지 볼 수 있는 메뉴다.
• Filmstrip의 그래프를 직접 확인하면 어떤 것이 성능에 영향을 미치는지, 개선점은 무엇이 있는지를 확인할 수 있다.

Details

• Filmstrip에서 보여준 내용을 자세하게 보여주는 영역

Web Vitals

• 최초 콘텐츠 페인팅(LCP), 누적 레이아웃 이동(CLS), 총 블로킹 시간(TBT)에 대한 자세한 내용을 확인할 수 있다.

Optimizations

• 리소스들이 얼마나 최적화돼 있는지 나타낸다.
• 확인 가능한 내용은
  • Keep-Alive 설정으로 서버와의 연결을 계속 유지하고 있는지
  • Gzip으로 리소스를 압축하고 있는지
  • 이미지를 적절하게 압축했는지
  • Progressive JPEG으로 jPEG 이미지를 렌더링하고 있는지
  • 리소스 캐시 정책을 올바르게 수립돼 있는지
  • 리소스가 CDN(Content Delivery Network)을 거치고 있는지

Content

• 웹사이트에서 제공하는 콘텐츠, 애셋을 종류별로 묶어 통계를 보여준다.
• 애셋 종류별 크기와 로딩 과정을 확인할 수 있으며, 시간의 흐름에 따라 렌더링을 거치면서 또 어떻게 애셋을 불러오는지도 확인할 수 있다.

Domains

• Content 메뉴에서 보여준 애셋들이 어느 도메인에서 왔는지를 도메인별로 묶어서 확인할 수 있다.
• 해당 도메인별로 요청한 크기는 어느 정도인지도 확인할 수 있다.

Console Log

• 사용자가 웹페이지에 접속했을 때 console.log로 무엇이 기록됐는지를 확인할 수 있다.

Detected Technologies

• 웹사이트를 개발하는 데 사용된 기술을 확인할 수 있는 메뉴

Main-thread Processing

• Processing Breakdown : 메인 스레드가 어떤 작업을 처리했는지 확인할 수 있다. 메인 스레드의 작업을 크게 스크립트 실행, 레이아웃, 리소스 로딩, 페인팅, 기타의 총 다섯 가지로 분류해서 알려준다.
• Timing Breakdown : 유휴 시간을 포함해 메인 스레드의 작업을 확인할 수 있다.

Lighthouse Report

• 구글 라이트하우스 리포트를 확인할 수 있다.

기타

• Image Analysis : Cloudinary로 연결되며, 해당 웹사이트에 어떠한 이미지가 있는지, 그리고 이 이미지들이 최적화된다면 리소스를 어느 정도 아낄 수 있는지 보여준다.
• Request Map : 웹사이트에서 요청이 어떻게 일어나고 있는지를 시각화 도구로 보여준다.
• Data Cost : 각 국가별로 가장 저렴한 요금제를 기준으로 이 웹사이트를 로딩했을 때 실제로 얼마나 가격이 드는지를 확인
• Security Score : 해당 사이트의 보안 취약점에 대해 알려준다.

크롬 개발자 도구 - 성능 통계 탭

• Performance Insights : 웹사이트의 성능을 자세하게 확인할 수 있는 도구
• 한 가지 눈에 띄는 것은 Throttling인데, 이는 고의로 네트워크와 CPU 속도를 지연시키는 기능이다. 속도를 고의로 지연시켜 개발자의 최신 디바이스 성능이 아닌, 일반적인 모바일 사용자의 상대적으로 열악한 환경을 재현할 수 있다.

Insights

• 성능을 측정하는 기간 동안 발생한 이벤트 중 눈여겨봐야 할 내용을 시간의 흐름에 따라 모아서 보여준다.
• 핵심 웹 지표 : 핵심 웹 지표인 최초 콘텐츠풀 페인트(FCP), 최초 콘텐츠 페인팅(LCP), Dom Content Loaded가 언제 일어났는지 보여준다.
• Performance Measure : User Timing API로 측정한 지표들을 확인할 수 있다.
• Long Task : 메인 스레드에서 실행되는 데 오랜 시간으로 분류된 긴 작업을 의미한다.
• Render blocking CSS : 렌더링을 막는 CSS. 이를 조치할 수 있는 방안은
  • 중요하지 않은 스타일이라면 link rel=”preload” as “style”로 스타일을 비동기적으로 요청한다.
  • 미디어 쿼리를 활용해 디바이스에 필요한 스타일만 불러온다.
  • CSS 내부의 띄어쓰기, 줄바꿈 등을 압축해 최대한 크기를 줄인다.
• Forced Style recalculation : 이미 스타일이 한번 계산된 이후에 어떠한 이유로 스타일이 다시금 계산되는 작업이 강제로 발생했음을 의미한다.

메인 메뉴

• 성능을 측정하는 기간 동안 무슨 일이 일어나는지 확인할 수 있는 다양한 기능을 제공한다.

크롬 개발자 도구 - 성능 탭

네트워크

• 성능 측정 기간 동안에 발생한 모든 네트워크 요청을 확인할 수 있다.
• 네트워크 요청은 각 색깔에 따라 어떠한 종류의 요청인지 확인할 수 있다.
  • 파란색 : HTML
  • 보라색 : CSS
  • 노란색 : 자바스크립트
  • 초록색 : 이미지
  • 회색 : 기타
  • 폰트
  • JSON 등
• 위에 있는 요청이 우선순위가 높은 요청이다.
• 그래프를 읽는 방법은
  • 왼쪽 선은 연결을 시작되기 위한 기간을 나타낸다.
  • 대표 색상의 막대 그래프 중 색이 더 연한 왼쪽은 요청을 보내고 최초 바이트가 오기까지의 대기 시간을 의미한다.
  • 대표 색상의 막대 그래프 중 색인 진한 오른쪽은 콘텐츠를 다운로드하는 데 걸리는 시간을 의미한다.
  • 그리고 마지막에 거의 안 보이는 오른쪽 선은 메인 스레드의 응답을 기다리는 시간인데, 이는 네트워크의 소요 시간에 포함하지 않는다.

Web vitals

• 핵심 웹 지표 시점을 확인할 수 있는 영역

소요 시간과 기본

• 시간의 흐름에 따라 메인 스레드의 작업은 어떻게 이뤄졌는지, 또 자바스크립트 힙 영역은 어떻게 변화하는지 등을 확인할 수 있다.