Chrome DevTools Performance 패널

요약 — Performance 패널은 Chrome에 내장된 도구입니다(DevTools를 열고 Performance 클릭). 페이지가 로드되는 동안 브라우저가 하는 일을 스크립트, 네트워크 요청, 페인트까지 정확히 기록합니다. PageSpeed Insights와 달리 점수를 주지 않고 원시 상황을 보여 주므로 페이지가 왜 느린지 찾을 수 있습니다. 중요한 점은 Google 크롤러가 아니라 내 브라우저의 동작을 보여 준다는 것입니다. 계정 없이 무료로 사용할 수 있습니다.

Performance 패널이란?

Chrome DevTools에는 탭이 많습니다. Performance 패널은 페이지가 로드되고 실행되는 과정을 기록한 뒤 세부 내용을 파고드는 탭입니다. 파일 다운로드, JavaScript 실행, 페이지 레이아웃과 페인트 등 시간에 따른 브라우저 작업을 캡처하고 확대할 수 있는 타임라인으로 표시합니다.

차이를 이렇게 생각해 보세요. PageSpeed Insights와 Lighthouse는 시험을 실행한 뒤 점수와 할 일 목록을 주는 성적표와 같습니다. Performance 패널은 전체 페이지 로드의 보안 카메라 영상과 같습니다. 점수는 없지만 되감아서 정확히 언제 문제가 생겼는지 볼 수 있습니다.

여는 방법과 처음 보이는 내용

1. DevTools를 엽니다(페이지에서 마우스 오른쪽 버튼 클릭 → 검사, 또는 Mac에서 Cmd+Option+I / Windows에서 Ctrl+Shift+I).
2. 상단의 Performance 탭을 클릭합니다.

패널을 여는 순간 내 브라우저에서 실시간으로 측정한 세 가지 Core Web Vitals 중 두 가지인 **Largest Contentful Paint(LCP)**와 **Cumulative Layout Shift(CLS)**가 이미 표시됩니다. 페이지에서 상호작용하면 **Interaction to Next Paint(INP)**도 캡처합니다. 아무것도 기록하지 않고 로컬 Core Web Vitals 스냅샷을 얻을 수 있습니다.

페이지 로드 기록하기

전체 로드 과정을 보려면 프로파일링 시작 및 페이지 새로고침을 클릭하세요. 먼저 스크린샷 체크박스를 켜면 각 시점의 페이지 모습을 보여 주는 필름스트립도 얻을 수 있습니다. 패널은 페이지를 새로고침하고 모든 것을 기록합니다. 기록이 끝나면 스크립팅, 렌더링, 페인트를 나타내는 색상 막대, 상단의 스크린샷 스트립, 무엇이 언제 로드됐는지 보여 주는 네트워크 섹션으로 구성된 촘촘한 타임라인이 나타납니다.

처음에는 위압적으로 보입니다. 하지만 대부분의 SEO가 이곳에서 하는 일은 간단하며 고급 탭에서 단계별로 설명합니다. LCP였던 정확한 요소, 즉 페이지에서 페인트된 가장 큰 요소를 찾아 무엇을 최적화할지 알아내는 것입니다.

사람들이 오해하는 부분

Performance 패널은 Googlebot이 아니라 내 Chrome 브라우저의 동작을 보여 줍니다. Googlebot은 완전한 데스크톱 브라우저와 동일하지 않은 자체 시스템인 Web Rendering Service로 페이지를 렌더링합니다. 따라서 이 패널은 속도를 진단하고 렌더링을 이해하는 데 탁월하지만, Google이 실제로 무엇을 크롤링하고 색인할 수 있는지 확인하는 도구는 아닙니다. 그 확인에는 Google Search Console의 URL 검사 도구를 사용하세요.

플레임 차트와 Insights 사이드바를 읽는 방법, LCP 요소를 찾는 방법, 느린 휴대전화를 모의하도록 스로틀링하는 방법, Lighthouse 및 WebPageTest와의 차이까지 전체 안내를 보려면 고급 탭으로 전환하세요.

요약 — Performance 패널은 Chrome DevTools에 내장된 로컬 프로파일러입니다. 열면 실시간 로컬 LCP/CLS를 보여 주고, 상호작용하면 INP도 표시합니다. 프로파일링 시작 및 페이지 새로고침을 누르고 스크린샷을 켜면 전체 로드를 기록할 수 있습니다. 메인 스레드 작업의 플레임 차트, FPS/CPU 타임라인, 네트워크 워터폴, 분석 탭(Bottom-up, Call Tree, Event Log)을 읽을 수 있고, Insights 사이드바에서는 LCP를 네 가지 하위 부분으로 나누며 렌더링 차단 요청, 강제 리플로, 서드파티 비용을 지적합니다. 정확한 LCP 요소를 찾는 가장 빠른 내장 방법입니다. 세 가지는 분명히 구분해야 합니다. 첫째, Googlebot의 Web Rendering Service가 아니라 내 브라우저를 프로파일링합니다. 둘째, 기록된 트레이스는 실험실 근거이며, 패널이 선택적으로 실제 사용자 CrUX 필드 데이터를 함께 보여 줄 수 있어도 그 필드 오버레이는 로컬 트레이스와 같은 측정이 아닙니다. 셋째, 예전의 독립형 Performance Insights 패널은 Chrome 132에서 제거됐으며 그 기능은 현재 이 패널의 Insights 탭에 있습니다. 스로틀링 배수는 절대 벤치마크가 아니라 내 컴퓨터를 기준으로 합니다.

Performance 패널의 정확한 역할

Google의 설명은 명확합니다. “Use the Performance panel to analyze your website’s performance” (번역) “Performance 패널을 사용해 웹사이트 성능을 분석하세요”, “The Performance panel lets you record CPU performance profiles of your web applications” (번역) “Performance 패널에서는 웹 애플리케이션의 CPU 성능 프로필을 기록할 수 있습니다”(Chrome DevTools 문서). 프로파일러이므로 일정 시간 동안 브라우저가 수행한 모든 작업의 트레이스를 기록한 뒤 살펴봅니다.

사람들이 이 도구들을 계속 혼동하므로 먼저 유사 도구와의 차이를 정리할 가치가 있습니다.

• Lighthouse / PageSpeed Insights는 자동 감사를 실행해 점수와 우선순위가 있는 권장사항을 제공합니다(PSI는 실제 CrUX 필드 데이터도 추가). 점수형, 자동형, 판단이 반영된 도구입니다.
• **WebPageTest**는 원격 실제 기기에서 페이지를 실행하고, 기록과 공유가 가능한 결과를 남기며, 다단계 스크립팅을 지원합니다. 원격이고 공유 가능하며 철저합니다.
• Performance 패널은 내 로컬 브라우저의 원시 대화형 트레이스를 제공합니다. 점수, 계정, 원격 컴퓨터가 없습니다. 더 깊고 유연하지만 해석은 직접 해야 합니다.

기록된 트레이스 자체는 그 순간의 브라우저, 기기, 네트워크 하나를 포착한 로컬 실험실 근거입니다. 하지만 이를 둘러싼 패널은 순수 실험실 도구만은 아닙니다. 재설계 후에는 실제 사용자의 CrUX 필드 지표도 로컬 결과 옆에 선택적으로 표시할 수 있습니다. 로컬 실험실, 원격 실험실, 실제 사용자 필드를 구분하세요. 이 구분은 웹 성능 도구 클러스터 전체의 중심이며 아래 오해의 핵심입니다.

간단한 역사: 지금 보고 있는 패널을 구분하기 위해

이 패널은 오래전부터 있었습니다. Chrome DevTools 팀의 Elizabeth Sweeny와 Paul Irish는 “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years,” (번역) “Chrome DevTools의 Performance 패널은 어떤 형태로든 거의 15년 동안 개발자가 런타임 성능을 측정하고 최적화하는 데 도움을 줬습니다”, “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today” (번역) *“‘Timeline’이라는 패널에서 시작해 오늘날 여러분이 아는 Performance 패널로 발전했습니다”*라고 설명합니다(2024년 이후의 성능 도구). 그 과정에서 “Lighthouse was launched in 2016 to help spot optimization opportunities more easily,” (번역) “최적화 기회를 더 쉽게 찾도록 돕기 위해 2016년에 Lighthouse가 출시됐고”, “The experimental Performance Insights panel was released in 2022 to test new ways of surfacing performance insights.” (번역) “성능 인사이트를 표시하는 새로운 방법을 시험하기 위해 2022년에 실험적인 Performance Insights 패널이 출시됐습니다.”

마지막 내용은 최신성을 판단하는 데 중요합니다. 독립형 Performance Insights 패널은 실험이었고 지금은 사라졌습니다. Google의 안내에는 “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead” (번역) *“Performance Insights 패널은 지원 중단됐으며 Chrome 버전 132부터 DevTools에서 제거됐습니다. 대신 Performance > Insights 탭을 사용하는 것이 좋습니다”*라고 명시돼 있습니다(지원 중단 안내). 별도의 “Performance Insights” 패널을 보여 주는 튜토리얼이나 스크린샷은 Chrome 132 이전의 오래된 자료입니다. 인사이트는 이제 일반 Performance 패널 안의 사이드바에 있습니다.

패널 열기와 실시간 지표 화면

DevTools를 열고 상단 탭에서 Performance를 선택하세요. Google의 설명처럼 “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics,” (번역) “Performance 패널을 열면 로컬 Largest Contentful Paint(LCP) 및 Cumulative Layout Shift(CLS) 지표를 즉시 캡처해서 보여 줍니다”, “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)” (번역) “페이지에서 상호작용하면 Performance 패널은 로컬 Interaction to Next Paint(INP)도 캡처합니다”(개요 문서). 이 시작 화면은 Rick Viscomi가 “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance” (번역) *“로컬 Core Web Vitals 성능의 실시간 보기를 제공하도록 완전히 재설계한 Performance 패널 시작 페이지”*라고 설명한 재설계의 일부입니다(DevTools에서 로컬 및 실제 사용자 Core Web Vitals 모니터링). 따라서 아무것도 기록하기 전에 이미 로컬 Core Web Vitals 전체를 볼 수 있습니다.

트레이스 기록: 런타임과 로드

두 가지를 기록할 수 있으며 그 차이가 중요합니다.

• 런타임 성능 — 페이지가 이미 로드됐고 실행 중의 동작(애니메이션, 느린 상호작용, 스크롤 끊김)을 프로파일링하려는 경우입니다. Google은 “Runtime performance is how your page performs when it is running, as opposed to loading” (번역) *“런타임 성능은 로드될 때가 아니라 페이지가 실행 중일 때의 성능입니다”*라고 설명합니다(런타임 성능 분석).
• 로드 성능 — 새로운 탐색부터 전체 과정을 보려는 경우입니다. 프로파일링 시작 및 페이지 새로고침을 클릭하세요. 먼저 스크린샷을 켜면 시각 프레임의 필름스트립을 트레이스와 함께 볼 수 있습니다.

LCP, 레이아웃 이동, 렌더링 차단 스크립트 같은 SEO 작업에는 거의 항상 스크린샷을 켠 로드 기록을 사용합니다.

트레이스에는 기록 창 안에서 일어난 일만 포함됩니다. 창 밖의 상호작용이나 나중에 실행되는 지연 로드 작업처럼 캡처하지 않은 것은 존재하지 않는 것이 아니라 관찰하지 못한 것입니다. 나 또는 다른 사람이 나중에 재현하거나 비교할 트레이스를 원한다면 다음을 기록해 두세요. Chrome 버전과 날짜(라벨, 단축키, 정확한 UI는 릴리스마다 달라짐), 스크린샷 사용 여부, CPU/네트워크 스로틀링 설정, 고급 페인트/CSS 계측 및 JavaScript 샘플링 옵션을 기본값으로 뒀는지 여부입니다. 각각은 세부 정보와 오버헤드를 추가하므로 설정이 다른 트레이스끼리는 직접 비교할 수 없습니다.

트레이스 읽기

기록에는 여러 트랙이 층층이 표시됩니다. 주요 항목은 다음과 같습니다.

• 플레임 차트/Main 트랙. 핵심 영역입니다. Google은 “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time,” (번역) “DevTools는 시간에 따른 메인 스레드 활동의 플레임 차트를 보여 줍니다. x축은 시간에 따른 기록을 나타냅니다”, “Use the Main track to view activity that occurred on the page’s main thread” (번역) *“Main 트랙을 사용해 페이지의 메인 스레드에서 발생한 활동을 봅니다”*라고 설명합니다(기능 참조). 시간은 왼쪽에서 오른쪽으로 흐르고 각 시점 아래에 쌓인 막대가 호출 스택입니다. 막대가 넓을수록 작업 실행 시간이 깁니다. 시간이 어디에 쓰였는지 알 수 있습니다. 중첩은 무엇이 무엇을 언제 호출했는지 보여 주는 트레이스 구조이지만, 상위 작업이 더 넓은 사용자 경험 문제를 일으켰다는 증거 자체는 아닙니다. 가설의 출발점으로 삼고 확인하세요.
• FPS 차트. 끊김을 빠르게 파악합니다. Google은 “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience” (번역) *“FPS 위에 빨간 막대가 보이면 프레임 속도가 너무 낮아 사용자 경험을 해칠 가능성이 있다는 뜻입니다”*라고 설명합니다(런타임 문서). 목표는 매끄러운 60 FPS이며 빨간 막대는 거친 구간을 표시합니다.
• CPU 차트는 기록 중 메인 스레드가 얼마나 바빴는지 보여 줍니다.
• Network 트랙은 모든 요청의 워터폴로, 무엇이 언제 어떤 순서로 로드됐는지 보여 줍니다. 렌더링 차단 리소스도 여기 나타납니다.
• Timings 트랙은 앱에서 발생시키는 사용자 지정 performance.mark() 측정을 보여 줍니다.

플레임 차트 아래의 세 분석 탭은 같은 데이터를 서로 다른 방식으로 나눕니다.

• Bottom-up — “Bottom-up 탭을 사용해 합계 기준으로 직접 가장 많은 시간을 차지한 활동을 봅니다.” “어떤 단일 함수가 시간을 잡아먹는가?”에 가장 적합합니다.
• Call Tree — “Call Tree 탭을 사용해 가장 많은 작업을 일으킨 루트 활동을 봅니다.” “어떤 최상위 작업이 이 모든 것을 시작했는가?”에 가장 적합합니다.
• Event Log — 같은 이벤트를 시간순으로 표시합니다.

Insights 사이드바

진단 측면에서 재설계의 가장 유용한 추가 기능은 제거된 독립형 Performance Insights 패널의 후속인 Insights 사이드바입니다. 플레임 차트를 직접 뒤지지 않아도 이름이 붙은 구체적인 문제를 표시합니다. SEO에 가장 중요한 항목은 다음과 같습니다.

• LCP 분석. Google은 LCP를 첫 바이트까지의 시간, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연이라는 네 가지 하위 부분으로 나눕니다(LCP 분석 인사이트). 단순히 느리다는 사실이 아니라 왜 느린지(서버, 늦게 로드되는 이미지, 렌더링 차단 등) 알려 줍니다.
• 렌더링 차단 요청 — 첫 페인트를 지연시킨 CSS/JS입니다(렌더링 차단 인사이트).
• 강제 리플로 — 브라우저가 레이아웃을 다시 계산하기 위해 스크립트를 멈춰야 했던 지점입니다.
• 서드파티 비용 — 임베드, 태그, 위젯이 유발한 비용입니다.

이 항목들이 자동으로 표시되므로 Insights 사이드바는 Performance 패널에서 Lighthouse의 “수정할 사항” 경험에 가장 가까운 기능입니다. 동시에 각 인사이트 뒤의 원시 트레이스까지 내려갈 수 있습니다.

각 인사이트를 증거가 아니라 안내된 가설로 다루세요. 잠재적 문제를 식별하고 관련 트레이스 맥락으로 연결하지만, 항목에 표시가 붙었다고 해서 그것이 원하는 결과의 원인이거나 수정하면 해결된다는 증거는 아닙니다. 고객이나 팀원에게 인사이트가 그 원인이라고 말하기 전에 트레이스 자체와 수정 전후의 재기록으로 확인하세요.

CPU 및 네트워크 스로틀링과 흔한 함정

개발용 컴퓨터는 일반적인 휴대전화보다 훨씬 빠르므로 내게 즉시 열리는 페이지가 실제 사용자에게는 고통스러울 수 있습니다. 스로틀링은 CPU 감속 배수와 네트워크 프로필(Slow 4G 등)로 더 약한 조건을 모의합니다.

주의점은 Google의 설명에 그대로 나옵니다. “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability” (번역) “스로틀링은 컴퓨터의 성능을 기준으로 합니다. 예를 들어 2x 감속 옵션은 CPU를 평소 성능보다 2배 느리게 작동시킵니다”(기능 참조). 즉 “4x 감속”은 절대 벤치마크가 아닙니다. 빠른 노트북의 4x와 느린 노트북의 4x는 같은 결과가 아닙니다. 컴퓨터 간 비교 가능한 표준이 아니라 상대적인 다이얼입니다. DebugBear의 상세 DevTools 안내는 두 번째 실용적 용도도 지적합니다. 기록 자체를 느리게 만들어 빽빽한 이벤트 묶음을 읽기 쉽게 할 수 있습니다.

이곳의 실험실 데이터와 Google이 순위에 사용하는 필드 데이터

SEO가 흔히 실수하는 지점입니다. Performance 패널의 수치, 즉 실시간 지표와 모든 기록은 그 순간 내 컴퓨터와 내 네트워크에서 얻은 실험실 데이터입니다. Google의 실제 Core Web Vitals 순위 신호는 실제 사용자의 CrUX 필드 데이터(실제 Chrome 사용자의 28일 집계)에서 나오며 Search Console과 PageSpeed Insights에서 볼 수 있습니다. 완벽한 로컬 기록이 필드 점수 통과를 보장하지는 않습니다. 실제 사용자는 하나의 테스트보다 더 느린 기기, 더 나쁜 네트워크, 더 다양한 조건을 사용합니다.

재설계된 패널은 둘을 연결합니다. 업데이트 후에는 실제 사용자 CrUX 필드 데이터를 로컬 결과 바로 옆에 표시해 “방금 측정한 내용”과 “실제 사용자가 경험하는 내용”을 비교할 수 있습니다. 필드 오버레이를 사용할 수 있으면 URL과 오리진 수준, 모바일과 데스크톱 사이를 전환할 수 있고 UI는 사용 중인 데이터 기간도 표시합니다. 비교하는 트레이스와 이 조건을 맞추세요. 그래도 필드 정보를 반영한 환경 설정(CrUX를 바탕으로 패널이 권장하는 스로틀링 프리셋)은 선택한 실제 사용자 세그먼트를 근사할 뿐입니다. 하나의 로컬 기록은 기반 모집단 분포를 재현하거나 순위 결과를 예측하지 못합니다. 이 오버레이는 로컬 트레이스와 Google의 순위 신호가 서로 다른 수치라는 점을 가장 분명하게 상기시키는 내장 기능입니다. 실험실과 필드의 전체 설명은 웹 성능 도구 허브와 관련 Core Web Vitals 및 CrUX 설명을 보세요.

기술 SEO에서 제가 사용하는 방법

저는 수년간 Performance 패널을 사용해 왔습니다. 독립적인 최종 산출물로 쓰기보다 점수만으로 부족해 실제 동작을 확인해야 할 때 찾는 도구입니다. 구체적인 용도 몇 가지를 소개합니다.

정확한 LCP 요소 찾기. 이 패널에서 SEO에 가장 유용한 단일 기법이며 제가 무대에서도 가르친 절차입니다. 제 Page Experience Update(TMC, 2021년 6월) 자료의 단계는 다음과 같습니다. Performance > “스크린샷” 선택, “프로파일링 시작 및 페이지 새로고침” 클릭, 타이밍 그래프에서 LCP 찾기, 노드 클릭 — 이것이 LCP 요소입니다. DevTools는 Google이 Largest Contentful Paint로 계산할 정확한 요소를 알려 주므로 무엇을 최적화할지 알 수 있습니다. Seer Interactive의 Richie Lauridsen도 Search Engine Journal에서 같은 기법을 설명합니다. “LCP 플래그 위에 마우스를 올리면 페이지 로드 중 Largest Contentful Paint로 표시된 콘텐츠를 실제로 볼 수 있습니다”(SEO 문제 해결에 Chrome DevTools를 사용하는 3가지 방법). 서로 독립적인 두 글이 같은 절차에 도달한다는 점은 일회성 요령이 아니라 표준 워크플로라는 뜻입니다.

사람들에게 렌더링을 설명하기. 제 JavaScript SEO 가이드에서는 이 패널로 렌더링 파이프라인을 눈에 보이게 합니다. “Chrome DevTools의 ‘Performance’ 탭에서 테스트를 실행하면 로딩 차트를 볼 수 있습니다.” 다운로드, HTML 파싱, JS 실행, 레이아웃, 페인트 순으로 차트를 살펴보면 Googlebot 렌더링이 완전한 브라우저 페인트의 모든 동작을 수행하지 않는다는 점을 고객과 동료에게 설명할 수 있습니다. 이는 JS SEO 문제 진단의 핵심입니다.

그 밖에도 렌더링을 차단하는 서드파티 발견과 레이아웃 이동 진단에 사용합니다. 네트워크 워터폴은 첫 페인트를 막는 요소를 보여 주고, 트레이스와 CLS 지표는 무엇이 언제 이동했는지 보여 줍니다.

반드시 이해해야 할 Googlebot 오해

함정은 이렇습니다. “내 Performance 패널에서 제대로 보이니 Googlebot도 제대로 보겠지.” 그렇게 결론 내릴 수 없습니다. 이 패널은 모든 기능을 갖춘 로컬 Chrome을 프로파일링합니다. Googlebot은 최신이지만 동일하지는 않은 Chromium 빌드인 Web Rendering Service로 렌더링합니다. 완전한 브라우저가 지원하는 모든 것을 지원하지 않고 동작도 다릅니다. 상태를 유지하지 않고 권한 요청을 거부하는 등의 차이가 있습니다(크롤링 및 렌더링 참조). Performance 패널은 렌더링 동작을 이해하고 진단하는 데 탁월하지만 실제 크롤링 및 색인 가능 여부를 확인하는 도구를 대신하지 못합니다. 그 확인에는 Search Console의 URL 검사 도구나 원시 가져오기를 사용하세요.

짧은 구분 참고 사항

Performance 패널과 Performance monitor를 혼동하지 마세요. Performance monitor는 기록된 트레이스 대신 CPU 사용량, JS 힙, DOM 노드 같은 실시간 지표를 라이브 스트립으로 보여 주는 별도의 소형 DevTools 기능입니다. 이름은 비슷하지만 다른 도구입니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• 도구의 역할: Chrome DevTools Performance 패널은 내장된 로컬 프로파일러입니다. DevTools → Performance에서 엽니다. 페이지가 로드되고 실행되는 방식을 기록하며 점수는 만들지 않습니다. 기록된 트레이스는 로컬 실험실 근거이지만 패널에서 CrUX 필드 데이터를 함께 선택적으로 볼 수 있습니다.
• 도구 비교: Lighthouse/PageSpeed Insights = 점수가 있는 자동 감사(+ CrUX 필드 데이터), WebPageTest = 원격 실제 기기 실험실, Performance 패널 = 내 브라우저의 원시 대화형 트레이스.
• 실시간 지표: 열면 로컬 LCP와 CLS를 보여 주고, 상호작용하면 로컬 INP도 추가합니다. 기록 없이 로컬 Core Web Vitals 전체를 볼 수 있습니다.
• 기록: 런타임(페이지가 이미 실행 중)과 로드(프로파일링 시작 및 페이지 새로고침, 필름스트립을 보려면 스크린샷 켜기)로 나뉩니다.
• 트레이스 읽기: 메인 스레드 작업의 플레임 차트(넓은 막대 = 긴 작업), FPS 차트(빨간색 = 끊김, 목표 60 FPS), CPU 차트, Network 워터폴, Timings와 Bottom-up / Call Tree / Event Log 분석 탭이 있습니다.
• Insights 사이드바(독립형 Performance Insights 패널을 대체했으며 독립형은 Chrome 132에서 제거): LCP를 4가지 하위 부분으로 분석하고, 렌더링 차단 요청, 강제 리플로, 서드파티 비용을 보여 줍니다. 각 인사이트는 원인의 증거가 아니라 안내된 가설로 보고, 트레이스와 수정 전후 재기록으로 확인하세요.
• 스로틀링은 절대 벤치마크가 아니라 내 컴퓨터 기준입니다. 빠른 노트북의 “4x”는 느린 노트북의 “4x”와 같지 않습니다.
• 실험실 ≠ 필드: 기록된 트레이스는 실험실 데이터이고 Google은 실제 사용자 CrUX 필드 데이터를 순위에 사용합니다. 재설계 후 CrUX를 로컬 결과 옆에서 URL/오리진, 폼 팩터, 기간에 맞춰 볼 수 있지만 실제 사용자 세그먼트의 근사치이지 재현은 아닙니다.
• SEO 용도: 정확한 LCP 요소 찾기(Patrick의 슬라이드 절차와 SEJ Richie Lauridsen의 설명이 일치), 렌더링 차단 서드파티 발견, 레이아웃 이동 진단, 렌더링 설명.
• 깨야 할 오해: Googlebot의 Web Rendering Service가 아니라 내 브라우저를 보여 줍니다. 크롤링 가능성은 DevTools가 아니라 URL 검사로 확인하세요.

공식 문서

Chrome DevTools 팀의 1차 출처 문서입니다.

Chrome / Google

• Performance 패널 개요 — 도구의 역할, 여는 방법, 실시간 로컬 LCP/CLS/INP 지표.
• 런타임 성능 분석 — 기록, 플레임 차트, FPS/CPU, 런타임과 로드의 구분.
• Performance 기능 참조 — Main 트랙, Bottom-up, Call Tree, Event Log, 스로틀링 정의.
• Performance Insights(지원 중단 안내) — 독립형 패널은 Chrome 132에서 제거됐으므로 Performance > Insights를 사용해야 함.
• LCP 분석 인사이트 — LCP를 TTFB, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연으로 분리.
• 렌더링 차단 요청 인사이트 — 첫 페인트를 지연하는 CSS/JS 식별.
• DevTools에서 로컬 및 실제 사용자 Core Web Vitals 모니터링 — 재설계된 시작 페이지와 CrUX 필드 데이터 오버레이에 관한 Rick Viscomi의 설명.
• 2024년 이후의 Performance 도구 — Timeline에서 Performance로 이어지는 역사와 Lighthouse/Insights의 위치에 관한 Elizabeth Sweeny와 Paul Irish의 설명.
• 400% 빨라진 Performance 패널 — 엔지니어링 심층 분석. 패널이 활발히 투자되고 릴리스마다 바뀐다는 근거.
• Performance monitor — 기본 Performance 패널이 아니라 별도의 실시간 지표 스트립(구분용).

Bing / Microsoft

• Chrome/Edge DevTools Performance 패널에 관한 Bing 전용 문서는 없습니다. 검색 엔진 제품이 아니라 브라우저 도구이기 때문입니다. Chromium 기반 Edge에는 거의 동일한 Performance 패널이 있는 DevTools가 포함되므로 여기의 내용은 Edge에도 적용됩니다.

출처 인용문

Chrome DevTools 팀과 업계 실무자의 공식 발언입니다. 각 Chrome 링크는 출처의 인용 구절로 바로 이동하는 딥 링크입니다.

Chrome DevTools — 패널의 역할과 읽는 방법

• “Use the Performance panel to analyze your website’s performance.” (번역) “웹사이트 성능은 Performance 패널로 분석하세요.” / “The Performance panel lets you record CPU performance profiles of your web applications.” (번역) “Performance 패널을 이용하면 웹 애플리케이션의 CPU 성능 프로필을 기록할 수 있습니다.” — Chrome DevTools 문서. 인용문으로 이동
• “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics.” (번역) “Performance 패널을 열면 로컬 Largest Contentful Paint(LCP) 및 Cumulative Layout Shift(CLS) 지표를 즉시 캡처해서 보여 줍니다.” / “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP).” (번역) “페이지에서 상호작용하면 Performance 패널은 로컬 Interaction to Next Paint(INP)도 캡처합니다.” 인용문으로 이동
• “Runtime performance is how your page performs when it is running, as opposed to loading.” (번역) “런타임 성능은 로드될 때가 아니라 페이지가 실행 중일 때의 성능입니다.” / “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time.” (번역) “DevTools는 메인 스레드 활동을 시간 흐름에 따른 플레임 차트로 표시합니다. x축은 기록의 시간 흐름을 나타냅니다.” 인용문으로 이동
• “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience.” (번역) “FPS 위에 빨간 막대가 보이면 프레임 속도가 너무 낮아 사용자 경험을 해칠 가능성이 있다는 뜻입니다.” 인용문으로 이동
• “Use the Main track to view activity that occurred on the page’s main thread.” (번역) “Main 트랙을 사용해 페이지의 메인 스레드에서 발생한 활동을 봅니다.” / “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” (번역) “Bottom-up 탭을 사용해 합계 기준으로 직접 가장 많은 시간을 차지한 활동을 봅니다.” / “Use the Call tree tab to view which root activities cause the most work.” (번역) “Call Tree 탭을 사용해 가장 많은 작업을 일으킨 루트 활동을 봅니다.” 인용문으로 이동
• “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability.” (번역) “스로틀링 정도는 컴퓨터 능력에 따라 달라집니다. 예를 들어 2x 감속을 선택하면 CPU가 평소보다 2배 느리게 작동합니다.” 인용문으로 이동

Chrome DevTools — 역사와 최신성 참고 사항

• “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years.” (번역) “Chrome DevTools의 Performance 패널은 어떤 형태로든 거의 15년 동안 개발자가 런타임 성능을 측정하고 최적화하는 데 도움을 줬습니다.” / “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today.” (번역) “‘Timeline’이라는 패널에서 시작해 오늘날 여러분이 아는 Performance 패널로 발전했습니다.” — Chrome DevTools 팀 Elizabeth Sweeny와 Paul Irish. 인용문으로 이동
• “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead.” (번역) “Performance Insights 패널은 지원이 중단되어 Chrome 132부터 DevTools에서 삭제됐습니다. 이제 Performance > Insights 탭을 사용하는 것이 권장됩니다.” 인용문으로 이동
• “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.” (번역) “로컬 Core Web Vitals 성능의 실시간 보기를 제공하도록 완전히 재설계한 Performance 패널 시작 페이지.” — Chrome 팀 Rick Viscomi. 글 읽기

업계 — SEO 워크플로

• “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.” (번역) “LCP 플래그 위에 마우스를 올리면 페이지 로드 중 Largest Contentful Paint로 표시된 콘텐츠를 실제로 볼 수 있습니다.” — Seer Interactive Richie Lauridsen, Search Engine Journal. 글 읽기

Patrick Stox — 패널 사용법

• “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” (번역) “Chrome DevTools의 ‘Performance’ 탭에서 테스트를 실행하면 로딩 차트를 볼 수 있습니다.” — Googlebot 렌더링이 완전한 브라우저 페인트와 어떻게 다른지 설명하기 위해 제 Ahrefs JavaScript SEO 가이드에서 사용한 표현입니다.

어떤 성능 도구를 선택해야 할까요?

Performance 패널은 여러 선택지 중 하나이며 잘못 고르면 시간이 낭비됩니다. 빠른 결정 방법은 다음과 같습니다.

점수가 필요합니까, 진단이 필요합니까?

• 순위 관련 점수/통과 여부 판정 → 필드 데이터가 필요합니다. PageSpeed Insights 또는 Search Console의 Core Web Vitals 보고서(CrUX)를 사용하세요. Performance 패널은 이를 제공하지 않습니다.
• 페이지가 느린 이유에 대한 진단 → 계속합니다.

페이지에 공개적으로 접근할 수 있습니까?

• 아니요(로그인 뒤, 스테이징, localhost) → Performance 패널 또는 DevTools의 Lighthouse를 사용하세요. 브라우저에 있는 대상을 그대로 실행합니다. PSI와 WebPageTest에는 공개 URL이 필요합니다.
• 예 → Performance 패널과 원격 도구 모두 사용할 수 있습니다. 계속합니다.

공유 가능하고 실제 기기에서 반복 가능한 결과가 필요합니까?

• 예(고객 보고서, 실제 하드웨어, 과거 추세) → WebPageTest.
• 아니요, 지금 동작 원리만 보면 됨 → Performance 패널.

구체적으로 무엇을 찾고 있습니까?

• “어떤 요소가 내 LCP인가?” → Performance 패널: 스크린샷 켜기 → 프로파일링 시작 및 페이지 새로고침 → 타이밍 그래프에서 LCP 노드 클릭.
• “첫 페인트를 차단하거나 서드파티 시간을 잡아먹는 것은 무엇인가?” → Performance 패널 → Insights 사이드바(렌더링 차단 요청, 서드파티 비용).
• “우선순위가 있는 수정 할 일 목록” → Lighthouse / PageSpeed Insights.
• “Googlebot이 실제로 무엇을 크롤링/렌더링할 수 있는가?” → 이 패널이 아님. Search Console의 URL 검사 도구를 사용하세요.

경험칙은 이렇습니다. 필드 도구는 문제가 있는지와 순위에 영향을 미치는지 알려 주고, Performance 패널은 정확한 함수, 요청, 요소 수준에서 왜 문제가 생겼는지 알려 줍니다.

Performance 패널 치트 시트

열기

트레이스 읽기

LCP 요소 찾기(SEO 절차)

1. 스크린샷을 켭니다.
2. 프로파일링 시작 및 페이지 새로고침을 클릭합니다.
3. 타이밍 그래프에 표시된 LCP를 찾습니다.
4. 노드를 클릭하면 DevTools가 정확한 LCP 요소를 보여 줍니다.

빠른 사실/실수 방지

• 기록된 트레이스는 로컬 실험실 데이터이며, 패널에서 필드 데이터를 함께 선택적으로 볼 수 있어도 Google이 순위에 사용하는 CrUX 필드 데이터는 아닙니다.
• 내 브라우저를 프로파일링하며 Googlebot의 Web Rendering Service는 아닙니다.
• 독립형 Performance Insights 패널은 Chrome 132에서 제거됐고, 인사이트는 현재 이 패널의 Insights 탭에 있습니다.
• 스로틀링 배수는 절대 벤치마크가 아니라 내 컴퓨터 기준입니다.
• 무료이고 내장돼 있으며 계정이 필요 없습니다. Chromium Edge에도 같은 패널이 있습니다.
• Performance monitor는 이 패널이 아니라 실시간 지표 스트립을 보여 주는 다른 기능입니다.

Performance 패널 프로파일링 패스

깔끔하고 유용한 기록을 만드는 방법입니다.

• 확장 프로그램이 메인 스레드 트레이스를 오염시키므로 확장 프로그램을 끈 시크릿 창에서 테스트합니다.
• 로드 기록 전에 스크린샷을 켜서 필름스트립을 만듭니다.
• 나중 기록과 재현 및 비교할 수 있도록 Chrome 버전, 날짜, 스로틀링 설정, 고급 페인트/CSS/샘플링 계측 사용 여부를 기록합니다.
• 로드 성능을 진단할 때 이미 로드된 페이지에서 “기록”만 누르지 말고 프로파일링 시작 및 페이지 새로고침으로 전체 로드 과정을 기록합니다.
• 중급 휴대전화를 근사하려면 CPU 스로틀링(흔히 4x)과 네트워크 스로틀링을 적용하되, 배수가 내 컴퓨터 기준임을 기억합니다.
• 로컬 기록에는 변동이 있으므로 여러 번 기록하고 한 번의 실행을 절대적 사실이 아니라 표본으로 봅니다.
• Insights 사이드바를 열고 LCP 분석부터 읽습니다. 서버, 리소스 로드, 렌더링 지연 원인을 가리킵니다.
• 절차에 따라 LCP 노드를 클릭해 실제 LCP 요소를 확인합니다.
• Network 트랙에서 렌더링 차단 CSS/JS와 무거운 서드파티 요청을 확인합니다.
• 발견한 내용을 PageSpeed Insights/Search Console CrUX 필드 데이터와 대조합니다. 좋은 로컬 트레이스가 필드 점수 통과를 보장하지 않습니다.
• 크롤링/색인 가능성 질문에는 URL 검사로 전환합니다. Performance 패널은 “Googlebot이 무엇을 보는가?”에 답하지 않습니다.

Performance 패널과 주변 도구

Performance 패널은 로컬 실험실 진단 도구입니다. 다른 도구와의 관계는 다음과 같습니다.

• Chrome DevTools Performance 패널 — 이 글의 도구입니다. 로컬, 실험실, 원시 트레이스이며 페이지가 왜 느린지와 LCP 요소를 정확히 찾는 데 가장 적합합니다.
• Lighthouse — DevTools 안에서도 실행되며 점수와 우선순위 수정 목록을 제공하는 자동 감사입니다.
• PageSpeed Insights — 위에는 CrUX 필드 데이터, 아래에는 Lighthouse 실험실 실행을 제공합니다. 공개 URL만 가능하며 경쟁사에도 사용할 수 있습니다.
• Chrome UX Report(CrUX) — Google이 실제 순위에 사용하는 실제 사용자 필드 데이터 세트입니다. 이제 패널이 로컬 결과 옆에 오버레이할 수 있습니다.
• WebPageTest — 원격 실제 기기 테스트, 공유 가능한 결과, 다단계 스크립팅.
• Google Search Console — Core Web Vitals 보고서 — 필드 데이터로 대규모 실패 페이지 그룹을 보여 줍니다.
• Search Console — URL 검사 — “Googlebot이 무엇을 크롤링하고 렌더링할 수 있는가?”에 맞는 도구입니다. Performance 패널이 아닙니다.
• Microsoft Edge DevTools — Edge/Bing 중심 워크플로에서 사용할 수 있는 동일한 Chromium Performance 패널입니다.

이 도구들이 어떻게 맞물리는지, 실험실과 필드의 차이, Google이 어느 것을 순위에 사용하는지는 웹 성능 도구 허브에서 시작하세요.

트레이스를 낭비하는 Performance 패널 실수

한 번의 기록을 필드의 진실로 취급하기

Performance 패널은 하나의 로컬 브라우저, 기기, 네트워크 프로필, 캐시 상태, 여정을 기록합니다. 병목을 설명하는 데 사용한 뒤 CrUX 또는 RUM으로 그 병목이 얼마나 흔한지 판단하세요.

재현 가능한 상호작용 없이 기록하기

끝을 정하지 않은 트레이스는 관련 없는 활동으로 채워집니다. 로드 또는 상호작용을 정의하고 같은 상태에서 시작하며 이를 캡처할 만큼만 기록하세요.

네트워크 및 프레임 트랙 없이 플레임 차트만 읽기

긴 작업은 최초 원인이 아니라 결과일 수 있습니다. 책임을 정하기 전에 메인 스레드 작업을 요청, 상호작용, 스크린샷, 페인트와 맞춰 보세요.

강한 스로틀링을 적용하고 수치를 벤치마크라고 부르기

스로틀링은 병목을 드러내는 데 도움이 되지만 결과는 실험실 시나리오입니다. 수정 전후 비교에는 동일한 설정을 유지하고 결과를 공유할 때 설정을 표시하세요.

일반적인 Performance 패널 문제 해결

트레이스가 너무 복잡해서 읽기 어렵습니다

가능성이 높은 원인: 확장 프로그램, 백그라운드 탭 또는 지나치게 긴 기록이 관련 없는 작업을 추가합니다. 해결: 깨끗한 프로필을 사용하고 백그라운드 활동을 닫은 뒤 정의된 하나의 여정을 캡처합니다. 확인: 관련 상호작용 또는 로드가 트레이스의 짧고 알아볼 수 있는 구간을 차지합니다.

상호작용은 느린데 뚜렷한 이벤트가 없습니다

가능성이 높은 원인: 기록에 입력부터 페인트까지의 전체 구간이 포함되지 않았거나 잘못된 트랙이 펼쳐져 있습니다. 해결: 정확한 클릭, 탭, 키 입력을 다시 기록하고 Interactions와 메인 스레드 작업을 점검합니다. 확인: 선택한 이벤트에 입력 지연, 처리, 표시 작업이 나타납니다.

실행할 때마다 결과가 크게 달라집니다

가능성이 높은 원인: 캐시 상태, 네트워크 변동, 백그라운드 작업 또는 테스트 설정이 다릅니다. 해결: 새로고침 모드, 스로틀링, 뷰포트, 여정을 표준화한 뒤 여러 번 실행합니다. 확인: 전체 소요 시간이 달라도 같은 병목이 나타납니다.

패널의 실험실 Vitals는 양호하지만 Search Console은 나쁩니다

가능성이 높은 원인: 로컬 트레이스가 실제 사용자나 더 긴 여정을 대표하지 않습니다. 해결: CrUX 또는 RUM을 세분화하고 영향을 받는 기기와 상호작용을 재현한 뒤 패널로 진단합니다. 확인: 트레이스가 필드 집계와 모순되는 것이 아니라 느린 세그먼트를 설명합니다.

트레이스 기반 수정이 효과가 있었음을 입증하기

반복 여정 테스트

실행할 테스트: 변경 전후에 동일한 캐시, 뷰포트, 스로틀링 설정으로 같은 로드 또는 상호작용을 기록합니다. 예상 결과: 대상 요청, 작업 또는 렌더링 단계가 일관되게 짧아집니다. 실패 해석: 실행 간 변동이나 다른 병목이 결과를 설명합니다. 모니터링 기간: 여러 기록에서 즉시 확인. 롤백 조건: 오류, 누락된 작업 또는 더 나빠진 시각적 동작이 나타남.

메인 스레드 테스트

실행할 테스트: 두 트레이스에서 선택한 메인 스레드 작업과 그 하위 작업을 비교합니다. 예상 결과: 제거하거나 지연한 작업이 이름만 바뀌거나 더 앞쪽으로 이동한 것이 아니라 중요 구간에서 사라집니다. 실패 해석: 구현이 같은 비용을 다른 곳으로 옮겼습니다. 모니터링 기간: 즉시. 롤백 조건: 사용자 동작 주변의 전체 차단 시간이 증가함.

필드 인계 테스트

실행할 테스트: 실험실 결과가 개선된 후 변경한 템플릿 또는 상호작용을 RUM에서 모니터링합니다. 예상 결과: 의도한 세그먼트의 해당 필드 지표와 귀속이 개선됩니다. 실패 해석: 로컬 시나리오가 대표성이 없었습니다. 모니터링 기간: 트래픽이 들어오는 동안 RUM, 롤링 필드 기간 동안 CrUX. 롤백 조건: 필드 성능 또는 작업 완료율이 지속해서 악화됨.

직접 풀어보기: Chrome DevTools Performance 패널

Performance 패널의 역할, 읽는 방법, 역할이 아닌 것에 관한 다섯 가지 짧은 질문입니다. 각각 답을 고른 뒤 확인하세요.

시간을 들일 가치가 있는 자료

제 글

• JavaScript SEO: 알아야 할 내용 — Performance 탭의 로딩 차트를 사용해 Googlebot 렌더링이 완전한 브라우저 페인트와 어떻게 다른지 설명합니다.
• SEO 및 개발자를 위한 Google PageSpeed Insights — DevTools의 원시 트레이스를 보완하는 점수형 필드+실험실 도구입니다.
• 기술 SEO 초보자 가이드 — 더 큰 그림에서 성능과 렌더링의 위치를 설명합니다.

제 발표

• Page Experience Update(TMC, 2021년 6월) (SlideShare) — 단계별 “DevTools에서 LCP 요소를 보는 방법” 절차가 포함돼 있습니다.
• 페이지 경험의 다음 단계(SMX Next 2021) (SlideShare) — 같은 시기의 제 페이지 경험 발표입니다.

업계 자료

• Performance 패널 개요 (Chrome for Developers) — 역할, 여는 방법, 실시간 지표를 다루는 표준 시작점입니다.
• 런타임 성능 분석 (Chrome for Developers) — 플레임 차트, FPS/CPU, 기록 안내.
• DevTools에서 로컬 및 실제 사용자 Core Web Vitals 모니터링 (Rick Viscomi, Chrome) — 재설계된 시작 페이지와 CrUX 필드 데이터 오버레이.
• 2024년 이후의 Performance 도구 (Sweeny & Irish, Chrome) — Timeline에서 Performance로 이어지는 역사와 Lighthouse/Insights의 관계.
• SEO 문제 해결에 Chrome DevTools를 사용하는 3가지 방법 (Richie Lauridsen, Search Engine Journal) — LCP 찾기 기법을 포함한 SEO 관점의 가장 가까운 기존 글.
• DevTools Performance 탭으로 사이트 속도 프로파일링 (DebugBear) — 강제 리플로 디버깅, 레이어 분석, 명확히 보기 위한 스로틀링을 다룬 가장 깊이 있는 비 SEO 기술 안내.
• 웹 성능 디버깅을 위한 Chrome DevTools (Web Performance Calendar, 2025) — 재설계 이후 패널 워크플로에 관한 최신 커뮤니티 관점.

변경 내역