[모던 리액트 Deep Dive] 13장 웹페이지 성능을 측정하는 다양한 방법

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

13.1.1 create-react-app

reportWebVitals .ts 파일의 reportWebVitals 함수는 웹에서 성능을 측정하기 위한 함수다. 각각 누적 레이아웃 이동( CLS) , 최초 입력 지연(FID) , 최초 콘텐츠풀 페인트(FCP) , 최대 콘텐츠 페인팅 (LCP) , 첫 바이트까지의 시간(TTFB)을 측정하는 용도로 사용된다. 

이러한 지표의 측정을 가능케 하는 것은 web-vitals 라이브러리 덕분이다. PerformanceObserver 라는 API 를 사용하는데 브라우저에서 웹페이지의 성능을 측정하기 위해 사용된다. 

 

ReportHandler는 단순히 성능 객체인 Metric 를 인수로 받는 함수 타입으로， Metric 을 원하는 대로 다룰 수 있다. 즉， 단순히 콘솔에 출력하는 것뿐만 아니라 서버로 전송하는 등의 작업을 할 수 있다.

 

13.1.2 create-next-app

기본적으로 Next.js 는 성능 측정을 할 수 있는 메서드인 NextWebVitalsMetric 을 제공한다.

기본적인 핵심 웹 지표 외에도 디음과 같은 Next.js에 특화된 사용자 지표도 제공한다는 특징이 있다. 모든시간 단위는 밀리초(ms)다.

• Next.js-hydration 페이지가 서버 사이드에서 렌더링되어 하이드레이션하는 데 걸린 시간
• Next.js-route-change-to-render: 페이지가 경로를 변경한 후 페이지를 렌더링을 시작하는 데 걸리는 시간
• Next.js-render: 경로 변경이 완료된 후 페이지를 렌더링하는 데 걸린 시간

13.2 구글 라이트하우스

• 브라우저 확장 프로그램 설치· 브라우저의 웹 스토어에 접속해 확장 프로그램을 설치한다. 크롬,  파이어폭스
• 크롬 개발자도구: 크롬의 개발자도구에는 라이트하우스가 기본적으로 내장돼 있다.
• CLI: lighthouse 라는 npm 라이브러리를 이용하면 CLI 명령어로 지표를 수집할 수 있다.

크롬 개발자 도구를 열어 Lighthouse 탭을 클릭한다. 이때 가급적 시크릿 창으로 실행하는 것이 좋다.

 

13.2.1 구글 라이트하우스 - 탐색 모드

일반적으로 페이지에 접속했을 때부터 페이지 로딩이 완료될 때 까지의 성능을 측정하는 모드다.

 

성능

웹페이지의 성능과 관련된 지표를 확인할 수 있는 영역이다.

핵심 웹 지표인 최초 콘텐츠풀 페인트( FCP ) , 최대 콘텐츠풀 페인트( LCP) , 누적 레이아웃 이동( CLS) 외에도 3 가지 추가적인 지표가 있다.

• Time to Interactive: 페이지에서 시용자가 완전히 상호작용(인터랙센)할 수 있을 때까지 걸리는 시간을 측정한다. 여기서 상호작용에 걸리는 시간까지란 다음과 같은 것을 의미한다. 구글에서는 이 TTI 지표가 3.8초 이내면 좋음, 7.3초 이내연 보통, 그 이후는 개선이 필요한 것으로 본다. 웹 페이지가 최대한 빠르게 상호작용이 되도록 준비하려면 메인 스레드가 하는 자바스크립트 작업을 최소화하고 전체적인 자바스크립트 실행 속도 또한높일 필요가 있다.
  - 최초 콘텐츠풀 페인트로 측정되는 페이지 내 콘텐츠가 표시되는 되는 시점
  - 보여지는 페이지 요소의 대부분에 이벤트 핸들러가 부착되는 시점
  - 페이지가 유저의 상호작용에 50ms 내로 응답하는 시점

• Speed Index: 페이지가 로드되는 동안 콘텐츠가 얼마나 빨리 시각적으로 표시되는지를 계산한다. 라이트하우스는 브라우저에서 로드되는 페이지를 실시간으로 캡처하고 Speedline 라이브러리를 사용해 캡처된 이미지를 분석해 speed index를 계산한다. 구글에서는 이 지표가 3.4초 이내면 좋음, 5.8초 이내면 보통， 그 이후는 느리다고 판단한다.
• Total Blocking Time: 메인 스레드에서 특정 시간 이상 실행되는 작업， 즉 긴 작업이 수행될 때마다 메인 스레드가 차단된 것으로 간주한다. 메인 스레드가 차단됐다고 표현하는 이유는 브라우저가 이렇게 길게 실행되는 작업 때문에 무언가 다른 작업을 수행할 수 없기 때문이다. 이렇게 메인 스레드에서 실행하는 작업이 50ms 이상 걸리면 이를 긴 작업이라고 간주하고 이렇게 실행되는 긴 작업을 모아서 Total Blocking Time(총 차단 시간)이라고 한다. 이 총 치단 시간은 긴 작업을 모아서 각각의 긴 작업의 시간에서 50ms를 뺀 다음, 이를 모두 합해 계산한다. 이 총 치단 시간은 모든 긴 작업을 대상으로 하는 것이 아니고 최초에 사용지에게 무언가 콘탠츠를 보여줬을 때(최초 콘텐츠풀 페인트. FCP)부터 상호 작용까지 걸리는 시간(TTI)사이의 작업만 대상으로 한다. 즉, 사용자가 무언가 작업이 진행되고 있지 않다는 것을 눈치 챌 수 있는 시간을 대상으로만 총 차단 시간을 구하게 된다.

접근성

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

 

권장사항

권장사항에는 보안， 표준 모드， 최신 라이브러리， 소스 맵 등 다양한요소들이 포함돼 있다. 이러한 권장사항들을 간단하게 살펴보면 다음과 같다.

 

• CSP가 XSS 공격에 효과적인지 확인:
  - XSS : Cross Site Scripting 의 약자로 개발자가 아닌 제3자가 삽입한 스크립트를 통해 공격하는 기법
  - CSP : Content Security Policy 의 약자로 웹 사이트에서 호출할 수 있는 컨텐츠를 제한하는 정책을 말한다. 이 제한 정책에는 이미지, 스타일, 스크립트와 같은 정적인 콘텐츠 뿐만 아니라， 주소， 도메인 등의 정보도 포함된다.
• 감지된 JavaScript 라이브러리 : 페이지에서 감지되는 자바스크립트 라이브러리를 말한다. jQuery, Next.js, React, Lodash, create-react-app 등이 나타나며， 버전까지 특정할 수 있는 경우 버전까지 확인할 수 있다.
• HTTPS 사용:HTTP 대신 보안이 더 강력한 HTTPS를 사용하는지 확인한다.
• 페이지 로드 시 위치정보 권한 요정 방지하기: 사용자의 동의 없이 페이지 로드 시 사용자의 물리적 위치를 알 수 있는 메서드인 window.navigator.geolocation.getCurrentPosition(), window.navigator.geolocation.watchPosition() 을 실행하는지 확인한다. 물론 이 두 함수가 호출된다고 해서 바로 사용자의 위치 정보를 가져올 수 있는 것은 아니며. 브라우저에서 한번 물어보는 절차를 거치게 된다. 그러나 다짜고짜 페이지 로드 시 요청하는 것은 사용자의 특별한 액션 없이 가져오는 것이므로 반드시 사용자의 액션 이후에 실행돼야 한다.
• 페이지 로드 시 알림 권한 요청 방지하기 : 위치 정보와 마찬가지로 사용자 동의 없이 페이지 로드 시 웹 페이지 알림을 요청하는 Notification.requestPermission() 을 실행하는지 확인한다. 이 함수도 마찬가지로 브라우저에서 사용자에게 알림 허용 여부를 다시 한번 확인하지만 반드시 사용자액션이 있을 때만 호출하는 것이 좋다.
• 알려진 보안 취약점이 있는 프런트엔드 자바스크립트 라이브러리를 시용하지 않음 :  보안 취약점이 존재하는 자바스크립트 라이브러리를 사용하는지 확인한다.
• 시용자가 비밀번호 입력란에 붙여넣을 수 있도록 허용: 일부 시용자는 복잡한 비밀번호를 별도의 애플리케이션에 관리해 외우지 않고 복사/붙여넣기 방식으로 비밀번호를 입력한다. 이것은 보안 관점으로 봤을 때 타당한 접근 방식이나 웹페이지에서 이를 허용하지 않는다면 무용지물이다. 반드시 비밀번호 입력란은 붙여넣기가 가능해야 한다.
• 이미지를 올바른 가로세로 비율로 표시 : 이미지의 실제 크기와 표시되는 크기 사이의 비율이 일치하는지 확인한다.
• 이미지가 적절한 해상도로 제공됨 : 이미지를 선명하게 보일 수 있도록 크기에 맞는 해상도의 이미지를 제공하는지 확인한다.
• 페이지에 HTML Doctype 있음: 과거 웹 표준이 제대로 정착되지 않았을 때 웹페이지는 넷스케이프 브라우저와 인터넷 익스플로러용 두 가지 버전으로 따로 만들어졌다. 이후 표준이 제정되면서 이 흔란은 멈추게 됐는데， 이 표준을 준수해 웹페이지가 작성됐다고 의미하는 것이 바로 Doctype 이다. 이 Doctype 이 선언되지 않았다면 표준을 준수하지 않은 것으로 간주돼 호환 모드로 렌더링하게 되는데 이는 불필요한 작업이다. 따라서 웹페이지 첫 번째 줄에 <!DOCTYPE html> 을 선언해 이러한호환모드 실행을 막는 것이 좋다.
• 문자 집합을 제대로 정의함 : 서버가 HTML 파일을 전송할 때 문자가 어떻게 인코딩돼 있는지 지정하지 않으면 브라우저는의 각 바이트가 나타내는 문자를 알 수 없게 된다. 따라서 적절하게 charset을 지정해야 한다. 대부분의 웹페이는 <head>의 최상단에 <meta charset="utf-8" />를 삽입해 UTF-8로 인코딩됐다고 명시한다.
• 지원 중단 API 사용하지 않기 : 더 이상 지원하지 않는 API 는 잠재적으로 보안 취약점이 될 수 있으므로 사용하지 않는 것이 좋다.
• 콘솔에 로그된 브라우저 오류 없음 : 콘솔에 에러가 기록되는 것은 시용자에게 영향을 미치지 않을 수도 있지만 분명 웹페이지에 문제가 있다는 사실에는 변함이 없다. 따라서 콘솔에 에러가 기록되지 않게 해야 한다.
• Chrome Devtools 의 Issues 패널에 문제없음 : 크롬 개발자 도구에는 문제(lssues) 라는 탭이 있는데, 이 탭에는 웹페이지에 대한 여러 가지 문제점을 알려준다. 여기서 기록된 문제가 있다면 확인해 조치하는 것이 좋다.
• 페이지에 유효한 소스 맵이 있음 : 소스 맵은 압축되어서 읽기 어려원진 소스코드를 원본 소스코드로 변환할 수 있도록 도와주는 파일로 이 소스맵이 있으면 개발자가 디버깅하는 데 큰 도움이 된다. 따라서 디버깅을 해야 하는 상황이라면 소스 맵이 있는 것이 좋지만， 반대로 그럴 필요가 없는 경우에는 별도로 제공하지 않아도 된다.
• font-display: optional을 사용하는 폰트가 미리 로드됨 : 앞서 언급한 폰트를 불러오는 방법 중 하나로 개발자가 원하는 임의의 폰트를 보여줄 수도 있으면서 동시에 사용자에게 버벅거림 없는 렌더링을 보장할 수 있는 가장 효과적인 방법이다.

검색 엔진 최적화

웹페이지가 구글과 같은 검색엔진이 쉽게 웹페이지 정보를 가져가서 공개할 수 있도록 최적화돼 있는지를 확인하는 것을 의미한다. 검색엔진에 최적화돼 있을수록 검색 엔진의 검색결과 우선순위에 높게 나타나며 ， 시용자가 유입될 가능성이 높아지므로 이러한 검색엔진 최적화를 위한 다양한 요소들을 확인하고 점검할 필요가 있다.

13.2.2 구글라이트하우스 - 기간모드

기간 모드는 실제 웹페이지를 탐색하는 동안 지표를 측정하는 것이다. 기간 모드 시작을 누른 뒤 성능 측정을 원하는 작업을 수행한 다음， 기간 모드를 종료하면 그 사이에 일어난 작업들에 대한 지표를 다음과 같이 확인할 수 있다 

여기서 확인할 수 있는 지표들은 크게 성능과 권장사항으로， 앞서 탐색 모드와 크게 다르지 않다.

 

흔적

흔적이라는 이름은 View Trace 를 번역한 것으로， 웹 성능을 추적한 기간을 성능 탭에서 보여준다. 상세하게 시간의 흐름에 따라 어떻게 웹페이지가 로딩됐는 지를 보여준다.

 

트리랩

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

또 실제로 불러왔지만 사용되지 않은 리소스의 바이트 크기를 확인할 수 있다.

 

13.2.3 구글 라이트하우스 - 스냅샷

스냅샷 모드는 탐색 모드와 매우 유사하지만 현재 페이지 상태를 기준으로 분석한다는 점이 다르다. 즉，현재 상태에서 검색엔진의 최적 화， 접근성 ， 성능 등을 분석할 수 있다.

 

13.3 WebPageTest

WebPageTest 는 웹사이트 성능을 분석하는 도구로 가장 널리 알려진 도구다. WebPageTest 에서 제공하는 분석 도구는 크게 다섯 가지로 나뉜다. 한국과 어느 정도 거리가 먼 서버를 기준으로 테스트하기 때문에 앞서 크롬 개발자 도구에서 테스트했을 때보다 성능 지표가 좋지 않을 가능성이 매우 높다.

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

먼저 https://www. webpagetest.org/ 에 접속한 디음， Site Performance 를 선택 한 뒤 분석을 원하는 웹사이트 주소를 입력한다. 그러고 나서 Start Test를 누르면 테스트가 시작되며 ， 다소간의 시간이 흐른 후에 테스트가 완료된다.

 

13.3.1 Performance Summary

 

 

 

WebPageTest 의 성능 테스트는 총 3번 이뤄지기 때문에 3개의 서로 다른 결과를 확인할 수 있다.

 

Opportunities & Experiments: 웹사이트에 대한 평가를 총 3 가지로 나눠서 보여준다.

• Is it Quick: 웹사이트가 충분히 빠른지를 평가한다. 여기서 빠름을 나타내는 것은 최초 바이트까지의 시간(TTFB)이 짧은지， 콘텐츠 렌더링이 즉각적으로 일어나는지， 최대 콘텐츠풀 페인트(LCP) 시간이 합리적인지를 확인한다.
• Is it Usable : 웹시이트의 사용성과 시각적인 요소를 확인한다. 콘텐츠 누적 이동(CLS)을 최소화하고 있는지， 상호작용을 빠르게 할 수 있는지， 접근성 이슈가 있는지， 클라이언트 사이드에서 과도하게 HTML 을 많이 렌더링하는지 등을 점검한다.
• Is it Resilient: 보안 취약성을 점검한다. 렌더링을 블로킹하는 제3자 라이브러리가 존재하는지， 실질적인 위협이 되는 보안 위험 요소가 있는지를 나타낸다.

Observed Metrics : 최초 바이트까지의 시간， 렌더링 시작에 소요되는 시간， 최초 콘텐츠풀 페인트 등 측정할 수 있는 다양한 시간 지표에 대해 나타낸다. 추가로 시간의 흐름에 따라 웹페이지가 어떤 식으로 렌더링됐는지도 알 수 있다. 그림을 보면 0.1 초 단위로 스크린샷을 찍고 있는데， 특정 스크린샷에 네모 박스가 있는 것을 확인할 수 있다. 각 색깔별 의미는 다음과 같다.

• 주횡색 실선: 웹사이트의 모습이 변경된 경우
• 주황색 점선: 웹사이트의 모습이 변경됐고 레이아웃 이동도 일어난 경우
• 빨간색 실선: 최대 콘텐츠풀 페인트
• 빨간색 점선: 최대 콘텐츠풀 페인트와 동시에 레이이웃 이동도 일어난 경우

Individual Runs: 기본적으로 WebPage est는 3 번의 테스트를 돌려서 평균값을 보여주는데， 각 실행별로 어떠한 결과를 보여주는지 확인할 수 있다.

 

13.3.2 Opportunities & Experiments

• 최초 바이트까지의 시간(TTFB) 을 점검한다. 최초로 응답하는 바이트가 빠르면 빠를수록 렌더링을 빠르게 하는 데 도움이 된다.
• 렌더링을 블로킹하는 자바스크립트가 있는지 확인한다. 렌더링을 방해하는 자바스크립트가 적으면 적을수록 렌더링을 하는 데 수월하다.
• 렌더링을 블로킹하는 CSS가 있는지 확인한다. CSS 또한 잘못된 위치에 잘못 선언돼 있으면 렌더링을 막을 수 있다.
• 최초 콘텐츠풀 페인트가 2.5초 이내인지 확인한다. 사용자가 콘텐츠를 볼 수 있는 시점은 빠를수록 좋다. 만약 이 지표가 느리다면 어떻게 개선하면 좋을지 제안해 준다.
  - 주요 영역 내에 게으른 로딩되는 이미지가 있는지 확인한다. 이미지에 대한 게으른 로딩 (loading=lazy)이 항상 좋은 것은 아니다. 사용자에게 보여지는 영역에 있는 이미지는 빠르게 로딩되는 것이 좋다.
  - 주요 영역 외에 이미지가 게으르게 로딩되는지 확인한다. 뷰포트 이외의 영역에 있는 이미지는 지연 로딩해 다른 급한 리소스를 먼저 로딩하는 것이 좋다.
  - 문자의 노출을 지연시키는 커스텀 폰트가 있는지 확인한다. 만약 font-display=block과 같은 형식으로 폰트를 불러온다면 해당 폰트가 로딩될 때까지 문자가 보이지 않을 것이다 이는 사용자 경힘을 해칠 수 있으묘로 폰트가 로딩되기 전까지는 기본 폰트를 시용하는 것이 좋다.
  - 제3자 호스트에서 폰트를 불러오는지 확인한다. 이제 폰트는 캐싱되지 않으므로 제3자 호스트에서 폰트를 불러오는 것은 크게 이점이 없다. 웹사이트와 동일한 곳에서 폰트를 호스팅하거나, rel=preload 로 브라우저에 최우선 리소스임을 알려주거나, rel=preconnect 로 미리 해당 오리진에 연결할 수 있게끔 하는 것이 좋다.
  - 실제로 시용하지 않는 리소스를 rel=preload 로 불러오지 않는지 확인한다. preload 는 앞서 설명한 것처럼 브라우저의 최우선 리소스로 지정되기 때문에 꼭 필요한 리소스에만 사용하는 것이 좋다.
  - HTTP 리다이렉트되는 리소스가 없어야 한다. 리다이렉트는 추가적인 네트워크 요청을 유발하기 때문에 성능에 좋지 못하다. 가능한 한 모든 리소스는 리다이렉트되지 않고 바로 리소스를 반환해야 한다.
  - 최초로 다운로드받은 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다. 최초로 받은 HTML과 최종 결과물 사이에 차이가 클수록 최종 결과물을 그리기 위해 자바스크립트가 많은 힘을 쏟았다는 것을 의미한다. 이는 싱글 페이지 애플리케이션에서 특히 두드러지게 문제점으로 지적된다.
• Is it Usable
  - 이미지 비율 부재로 인한 레이이웃 이동 가능성 여부를 확인한다. 이미지의 비율이 없을 경우 브라우저는 이미지가 로딩되기 전까지 해당 이미지의 크기를 알 수 없어 결과적으로 레이아웃 이동이 발생하게 된다. 이미지가 있다면 미리 적당한 width 와 height 를 지정하는 것이 좋다.
  - 어떤 이유에서건 메인 스레드가 장시간 멈춰 있어서는 안된다. 메인 스레드가 어떤 이유에서건 장시간 막혀 있게 된다면 페이지 콘텐츠와 상호작용하는 것이 어려워진다. 가능한 한 실행되는 자바스크립트의 크기를 줄이는 것이 좋다.
  - meta: viewport 가 적절하게 삽입돼 있어야 한다. meta : viewport는 사용자가 볼 수 있는 영역인 뷰포트를 제어하는 속성이다. 이는 사용자가 접속한 디바이스에 따라 달라지는데, 브라우저의 해당 페이지의 면적 및 비율은 어떻게 제어할지를 정의한다. <meta name="viewport" content = "width=device-width ， initial-scale=1" /> 이는 너비는 디바이스에 맞게， 최초 확대 축소 수준은 1.0( 기본)으로 하겠다는 뜻이다. 이는 모바일 기기에서 해당 웹페이지를 접속할 때 크기를 정할 수 있는 좋은 단서가 된다.
  - 접근성 이슈가 있는지 확인한다. 접근성 관련 문제가 있다면 무엇이 문제인지 어떻게 수정해야 하는지 힌트를 준다.
  - 최초로 다운로드받은 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다. 접근성 측면에서 또한 마찬가지로 최대한 HTML은 빠르게 완성돼 있는 것이 좋다. 자바스크립트로 완성되는 HTML이 많아질수록 스크린 리더가 해당 콘텐츠를 읽는 데 걸림돌이 될 것이다.
• Is it Resilient
  - 렌더링을 막는 제 3자 라이브러리 요청이 없어야 한다. 기본적으로 외부에서 불러오는 자바스크립트와 css 등의 리소스는 페이지 렌더링을 막는다. 타사 요청은 또한 웹 페이지의 성능이 이 타사 응답 성능에 의존하게 만들어 버리므로 특히 위험하다.
  - Synk에서 검출된 보안 위협이 없어야 한다. 자바스크립트 라이브러리에 보안 위협이 존재하는지 확인해주는 도구다. 모든 라이브러리가 그렇듯이 외부 이용자가 사용하게 되는 라이브러리에는 보안 취약점이 반드시 없어야 한다.
  - 모든 요청은 HTTP가 아닌 HTTPS를 거쳐야 한다. HTTPS는 데이터의 무결성을 담보하고, 사용자의 개인정보를 보호하며, 보안 위협으로부터 지켜주므로 반드시 HTTPS를 사용해야 한다.
  - 최초로 다운로드한 HTML과 최종 결과물 HTML 사이에 크기 차이가 적어야 한다. HTML 의존이 자바스크립트에 의존적일수록 자바스크립트 에러와 제3자 네트워크 요청 실패 등으로 인한 페이지 렌더링 실패 가능성이 높아진다. 가능한 한 HTML은 완성된 채로 다운로드돼야 한다.
  

13.3.3 Filmstrip

웹사이트를 마치 필름을 보는 것처럼 시간의 흐름에 따라 어떻게 웹사이트가 그려졌는지, 또 이때 어떤 리소스가 불러와졌는지 볼 수 있는 메뉴다. 렌더링을 가로 막는 리소스나 예상보다 일찍 실행되는 스크립트 등을 확인할 수 있다.

 

아래쪽 창에 나열된 리소스들 중 왼쪽에 주황색 X 표시가 있는 것은 렌더링을 블로킹하는 리소스라는 뜻이다.

위 결과에 총 5개(2~5, 8번)가 보이는데, 이는 async나 defer로 불러오지 않는 <script/>일 가능성이 크다. 실제로 웹사이트를 가면 동기식으로 보내는 스트립트가 존재하는 것을 볼 수 있다.

여기서 유일한 HTML 리소스는 1번으로, 1번의 크기가 매우 작은 것을 볼 수 있다. 그리고 가운데 녹색 세로 선은 최초 컨텐츠풀 페인트를 의미하는데, 11번 리소스의 실행이 다 끝난 이후에 렌더링이 시작됐음을 알 수 있다. (16초경 마지막 파란선이 렌더링이 끝난 지점)

이를 통해 해당 웹사이트는 싱글 페이지 애플리케이션으로 추측할 수 있고 서버 사이드 렌더링을 수행한다면 성능 향상을 기대할 수 있다.

... 생략

 

13.3.4 Details

Filmstrip 에서 보여준 내용을 자세하게 보여주는 영역이다. 각 요청에 대한 상세한 설명과 Filmstrip 메뉴에서 제대로 설명해 주지 않았던 각종 실선과 그림과 관련된 설명이 덧붙여져 있으니 Filmstrip 에서 제대로 이해하지 못한 내용이 있다면 여기에서 확인하면 좋다.

 

13.3.5 Web Vitals

최대 콘텐츠풀 페인트(LCP) , 누적 레이아웃 이동(CLS) , 총 블로킹 시간(TBT) 에 대한 자세한 내용을 확인 할 수 있다. 최대 콘텐츠풀 페인트의 경우시간의 흐름에 따라 최대 콘텐츠풀 페인트가 어떻게 변화했는지 확인할 수 있으며， 누적 레이아웃 이동은 어떤 요소가 레이아웃 이동에 영향을 미쳤는지 상세하게 확인할 수 있다. 핵심 웹 지표에 대한 관심이 많다면 이 메뉴를 참고하자.

 

13.3.6 Optimizations

최적화와 관련된 메뉴로， 리소스들이 얼마나 최적화돼 있는지 나타낸다.

• Keep- Alive 설정으로 서버와의 연결을 계속 유지하고 있는지
• Gzip으로 리소스를 압축하고 있는지
• 이미지를 적절하게 압축했는지
• Progressive JPEG으로 JPEG 이미지를 렌더링하고 있는지
  (JPEG을 완벽한 픽셀로 위에서부터 아래까지 서서히 로딩하는 기법이 아니라 전체 이미지를 블러 처리했다가 서서히 또렷 해지는 기 법을 말한다.)
• 리소스 캐시 정책이 올바르게 수립돼 있는지
• 리소스가 CDN( Content Delivery Network) 을 거치고 있는지

13.3.7 Content

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

 

13.3.8 Domains

Domains 메뉴에서는 Content 메뉴에서 보여준 애셋들이 어느 도메인에서 왔는지를 도메인별로 묶어서 확인할 수 있다. 그리고 해당 도메인별로 요청한 크기는 어느 정도인지도 확인할 수 있다. 웹사이트의 성격에 따라 다르지만 중요 리소스는 웹사이트와 같은 곳에서 요청할수록 도메인 연결에 소요되닌 비용을 줄일 수 있다.

 

13.3.9 Console Log

console.log 자체도 부하가 발생히는 작업이므로 가급적 console.log를 기록하는 일은 없어야 한다.

 

13.3.10 Detected Technologies

웹사이트를 개발하는 데 사용된 기술을 확인할 수 있는 메뉴다. 평소에 관심이 있거나 신기한 웹사이트가 있었다면 이 메뉴를 활용해 어떻게 만들었는지 짐작해 볼 수 있다.

 

13.3.11 Main-thread Processing

먼저 이 메뉴의 하위 항목인 Processing Breakdown 에서는 메인 스레드가 어떤 작업을 처리했는지 확인할 수 있다. 여기서는 리소스를 기다리는 idle time, 즉 유휴시간은 집계에 포함하지 않는다. 메인 스레드의 작업을 크게 스크립트 실행 (Scripting) , 레이아웃(Layout) ， 리소스 로딩 (Loading) ， 페인팅 (Painting) , 기타의 총 다섯 가지로 분류해서 알려준다.

또한 실제로 어떠한 작업을 하고 있었는지 상세하게 확인할 수 있다. 함수 실행， HTML 파싱， 페인팅， 스크립트 분석 등 다양한 요소 등을 확인할 수 있으니 웹사이트 로딩을 위해 메인 스레드가 무슨 일을 확인하는지 알고 싶다면 이 메뉴를 참고하면 된다.

Timing Breakdown에서는 유휴 시간을 포함해 메인 스레드의 작업을 확인할 수 있다.

 

13.3.12 Lighthouse Report

구글 라이트하우스 리포트를 확인할 수 있다. 크롬 개발자 도구에서 확인할 수 있는 라이트하우스 도구와 다르게 개발자의 브라우저가 아닌 원격지의 다소 일반적인 모바일 기기의 브라우저에서 측정된다는 것 외에는 별다른 차이가없다.

 

13.3.13 기타

• WebPageTest 외부에서 제공하는 서비스로， 링크를 클릭하면 모두 외부 페이지로 이동한다.
• Image Analysis : 유영한 이미지 & 비디오 클라우드 서비스 업체인 Cloudinary로 연결되며 ， 해당 웹사이트에 어떠한 이미지가 있는지， 그리고 이 이미지들이 최적화된다면 리소스를 어느 정도 아낄 수 있는지 보여준다.
• Request Map : 웹사이트에서 요청이 어떻게 일어나고 있는지를 시각화 도구로 보여준다. 각 리소스의 크기와 특정 리소스가 다른 리소스를 불러오는 등의 요청 관련 연쇄 작용을 확인할 수 있다. 만약 큰 사이즈의 요청이 연쇄 작용의 너무 뒤에서 일어난다면 이러한 요청을 가급적 빠르게 호출할 수 있도록 앞당기는 것도 도움이 될 것이다.
• Data Cost: 각 국가별로 가장 저렴한 요금제를 기준으로 이 웹사이트를 로딩했을 때 실제로 얼마나 가격이 드는지 확인할 수 있는 웹사이트다. 우리나라의 경우 데이터 가격이 상대적으로 저렴한 편에 속한다.
• Security Score: 유명한 보안업체인 Snyk에서 제공하는 기능으로 해당 사이트의 보안 취약점에 대해 알려준다. 사이트에서 취약한 라이브러리를 사용하는지 보안과 관련된 적절한 정책이 수립됐는지 등을 확인할 수 있다.

13.4 크롬 개발자 도구

13.4.1 성능 통계

 

Insights

Insights 에서는 성능을 측정하는 기간 동안 발생한 이벤트 중 눈여겨봐야 할 내용을 시간의 흐름에 따라 모아서 보여준다.

• 핵심 웹 지표: 핵심 웹 지표인 최초 콘텐츠풀 페인트 (FCP). 최대 콘텐츠풀 페인트(LCP). 그리고 Dom Content Loaded가 언제 일어났는지 보여준다. 최대 콘텐츠풀 페인트의 경우 마우스를 가져다 대면 어떤 요소가 최대 콘텐츠풀 페인트인지 확인할수있다.
• Performance Measure: User Timing APl로 측정한 지표들을 확인할 수 있다. 만약 Next. js로 제작된 애플리케이션이라면 이 API 를 사용한 흔적을 볼 수 있다
• Long Task : Performance Insight 의 Insights 탭에서 가장 주목해야 할 것 중 하나다. 이 작업은 메인 스레드에서 실행되는 데 오랜 시간으로 분류된 긴 작업을 의미한다. 

메인 메뉴

시간의 흐름에 따라 화면이 얼마나 그려졌는지 점검하면서 원하는 대로 페이지가 렌더링됐는지 점검할 수 있다. Layout Shifts 영역은 레이아웃 이동이 일어날 경우 기록된다. 이 시점에 실행된 스크립트를 살펴보면 무엇이 누적 레이아웃 이동을발생시키는지 확인할 수 있다.

Network 에서는 성능 측정 기간 동안 발생한 네트워크 요청을 모두 확인할 수 있다.

Renderer 에서는 렌더러가 어떤 작업을 하고 있는지 확인할 수 있다. 

Timing은 앞에서도 언급한 User Timing API 와 관련된 기록이 남아 있다. 만약 측정하고 싶은 기록이 있다면 다음과 같이 코드를작성하면 된다.

 

13.4.2 성능

 

메뉴

성능 탭에서 시용할 수 있는 메뉴를 확인할 수 있다. 원을 선택하면 성능 측정이 시작되며， 다시 누르면 성능 측정이 종료된다. 새로 고침 버튼을 클릭하면 다른 성능 측정과 마찬가지로 페이지 로드부터 종료 시점까지 성능 측정이 일어난다. 그 외에도 의도적으로 스로틀링을 적용하거나， 측정 프로필을 저장 및 불러오는 기능도 포함돼 있다.

 

요약

측정 기간의 CPU, 네트워크 요청 ，스크린샷， 메모리 점유율 등을 요약해서 볼 수 있다. 이 요약 탭이 중요한 이유는 바로 드래그를 통해 시점을 선택할 수 있다는 점이다. 드래그를 통해 원히는 시점을 선택하면 해당 시점과 관련된 정보만 하단에 노출된다. 이를 활용해 원하는 시점 의 정보를 더욱 상세하게 확인할 수 있다.

 

네트워크

성능 측정 기간 동안에 발생한 모든 네트워크 요청을 확인할 수 있다.

• 파란색 : HTML
• 보라색: CSS
  노란색: 자바스크립트
• 초록색: 이미지
• 회색: 기타
• 폰트
• JSON 등

위에 있는 요청이 우선순위가 높은 요청이다. 그래프를 읽는 방법은 다음과 같다.

• 왼쪽 선은 연결을 시작되기 위한 기간을 나타낸다.
• 대표 색상의 막대 그래프 중 색이 더 연한 왼쪽은 요청을 보내고 최초 바이트가 오기까지의 대기 시간을 의미한다.
• 대표 색상의 막대 그래프 중 색이 진한 오른쪽은 콘텐츠를 다운로드하는 데 걸리는 시간을 의미한다.
• 그리고 마지막에 거의 안 보이는 오른쪽 선은 메인 스레드의 응답을 기다리는 시간인데 이는 네트워크의 소요 시간에 포함하지 않는다.

Web vitals

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

 

소요 시간과 기본

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

성능 탭과 함께 이용하면 좋은 메뉴가 하단 그래프다. 이 그래프는 자바스크립트 힙의 변화, 노드, 리스너 등의 변화를 그래프로 볼 수 있는 영역이다. 마찬가지로 이 그래프를 클릭하면 해당 영역에서 발생했던 이벤트가 선택되며 어떤 함수의 실행이나 스크립트 등으로 인해 이러한 변화가 있었는지 짐작해 볼 수 있다. 또한 긴 작업의 영향을 받는 동안 내부적으로 어떠한 변화가 있었는지도 추측할 수 있으므로 긴 작업 간에 힙의 소모가 커지거나 리스너, 노드 등의 개수가 지나치게 많이진다면 한번 이를 토대로 검토해 보는 것이 좋다.