크롬 개발자 도구 성능 탭 활용
ℹ️이 콘텐츠에는 광고가 포함되어,판매 발생 시 수익이 발생합니다.(네이버 쇼핑 커넥트, 아마존 어필리에이트, 애드센스 등)웹사이트의 성능을 정확하게 평가하려면 단순한 속도 점수보다, 브라우저가 실제로 렌더링과 스크립트를 어떤 순서로 처리하는지를 살펴보는 것이 더 중요합니다.
크롬 개발자 도구 성능 탭은 페이지 로딩 과정과 사용자 상호작용에 따른 성능 저하를 시각적으로 분석할 수 있는 도구입니다. 렌더링 지연, 자바스크립트 실행 순서, LCP·FCP·CLS와 같은 Core Web Vitals 지표까지 모두 한 화면에서 확인할 수 있어, 실제 사용자가 체감하는 성능을 측정하는 데 매우 유용합니다.
이 글에서는 성능 탭의 기록 모드, 새로고침 방식, 스냅샷 분석 방법 등을 단계 별로 살펴보고, 실무에서 병목 현상을 진단하는 구체적인 활용법을 정리했습니다.
Ⅰ. 성능 탭 개요 및 측정 전 준비
성능 탭은 페이지 로딩, 스크립트 실행, 레이아웃 계산, 렌더링 등 브라우저 내부 동작을 모두 기록합니다. 다만 측정 환경이 일정하지 않으면 결과가 달라지므로, 테스트 전 아래 설정을 권장합니다.
|
설정 항목 41307_325a76-01> |
설명 41307_cca534-25> |
|---|---|
|
캐시 사용 중지 41307_00d8eb-e0> |
첫 방문자 기준의 데이터를 얻기 위해 체크합니다. 41307_0dea8f-46> |
|
CPU 감속 41307_c1e428-b7> |
실제 모바일 기기 환경을 시뮬레이션할 때 유용합니다. 41307_928891-d7> |
|
네트워크 감속 41307_6b77f6-fd> |
4G·3G 속도 환경에서 로딩 성능을 재현할 수 있습니다. 41307_44ada4-f2> |
|
Recording mode 확인 41307_d76809-4f> |
Record / Record + Reload 중 테스트 목적에 맞게 선택합니다. 41307_d1565e-7c> |
Ⅱ. 크롬 개발자 도구 성능 탭 활용
크롬 개발자 도구 성능 탭은 사용 목적에 따라 페이지 로딩 분석, 상호작용 성능 분석, 스냅샷 스냅샷·부분 구간 분석으로 3가지 접근 방식이 존재합니다.
|
방식 41307_55f618-5b> |
단축키 41307_d3d3c2-de> |
캐시 무효화 여부 41307_2ea976-1f> |
|---|---|---|
| 41307_136c16-b8> |
|
❌ 캐시 유지 41307_8cb6f2-99> |
|
①일반 새로고침 + [캐시 사용 중지] 체크 41307_832949-83> |
|
✅ 캐시 무시 41307_163668-f2> |
| 41307_0069a6-d5> |
|
✅ 캐시 무시 + 로딩 기록 41307_edaca9-6d> |
| 41307_934fe9-b9> |
|
✅ 캐시 무시 41307_9fe947-ca> |
브라우저 캐시를 그대로 사용합니다. 페이지 재로딩 속도는 빠르지만, 캐시된 리소스가 그대로 유지됩니다.
일반 새로고침은 실제 사용자의 재방문 환경과 동일한 조건입니다. 따라서 서버 요청 횟수는 줄어들지만, 변경된 리소스가 반영되지 않을 수 있습니다.


DevTools가 열린 동안에만 캐시를 무시합니다. 실질적으로 Hard Reload와 유사하지만, 서비스 워커나 메모리 캐시는 남아 있을 수 있습니다.
데스크탑과 모바일 모두에서,
서비스 워커는 “디스크(저장 공간)”에 저장되고,
메모리 캐시는 “RAM(실행 공간)”에 일시적으로 저장됩니다.
페이지를 새로고침하지 않고, 현재 열린 페이지에서 일어나는 동작(스크롤, 클릭, 애니메이션 등)을 실시간으로 기록합니다. 즉, “지금 보고 있는 화면에서 일어나는 이벤트”를 캡처하는 용도입니다.
주로 렌더링 지연, 자바스크립트 실행, 사용자 인터랙션 지연 등을 분석할 때 사용합니다.
“Record”는 그 순간부터 기록을 시작하기 때문에, 무언가 ‘행동’을 직접 해야 데이터가 쌓입니다.
(단순히 눌러 놓기만 하면, 정지 상태 화면은 기록할 게 없습니다.)
페이지를 새로고침하면서 동시에 기록을 시작합니다. 즉, “사이트가 처음 로드 될 때 어떤 과정으로 렌더링되는가”를 측정하는 용도입니다. LCP, FCP, CLS 등 Core Web Vitals를 정확하게 측정하려면 반드시 이 방법을 써야 합니다. 결국 ②기록보다는 ③기록 및 새로고침을 주로 사용하게 됩니다.
단순 Record 기능보다 병목 원인을 파악하는 데에는 “Record + Reload” 방식이 훨씬 효과적입니다.
이 기능은 페이지 로딩이 시작되는 순간부터 모든 렌더링·스크립트 실행 과정을 자동으로 기록하므로,
어떤 리소스나 스크립트가 실제 화면 표시를 지연 시키는지 명확히 확인할 수 있습니다.