browser-devtools

name	browser-devtools
description	Use when verifying frontend behavior at runtime — DOM validation, network inspection, performance profiling with browser DevTools
metadata	{"category":"testing","agent_type":"general-purpose"}

Browser DevTools Testing

When to Use

• E2E 테스트 실패의 근본 원인을 찾을 때
• API 호출이 예상대로 이루어지는지 검증할 때
• Core Web Vitals와 성능 지표를 측정할 때
• 접근성 문제를 런타임에서 확인할 때
• Playwright 테스트 작성 전 동작을 수동으로 탐색할 때

Prerequisites

• 브라우저에서 접근 가능한 실행 중인 앱 (로컬 또는 스테이징)
• Chrome 또는 Edge DevTools 접근 권한
• 테스트하려는 기능 또는 버그 재현 방법 파악

Workflow

1. DOM 상태 검증

// Console에서 실행
// 요소 존재 확인
document.querySelector('[data-testid="submit-button"]') !== null

// 요소 상태 확인
const btn = document.querySelector('button[type="submit"]');
console.log({
  disabled: btn.disabled,
  'aria-label': btn.getAttribute('aria-label'),
  visible: btn.offsetParent !== null
});

// 폼 데이터 확인
new FormData(document.querySelector('form')).entries().next()

2. 네트워크 탭으로 API 검증

확인 항목:

• 요청 URL과 메서드 (GET/POST/PUT)
• 요청 헤더 (Authorization, Content-Type)
• 요청 바디 (정확한 payload 형식)
• 응답 상태 코드와 바디
• CORS 헤더 존재 여부

// fetch를 인터셉트해서 로깅
const originalFetch = window.fetch;
window.fetch = function(...args) {
  console.log('fetch:', args[0], args[1]);
  return originalFetch.apply(this, args);
};

3. Performance 탭 — Core Web Vitals 측정

// CLS 측정 (layout-shift)
new PerformanceObserver((list) => {
  let cls = 0;
  list.getEntries().forEach(entry => { if (!entry.hadRecentInput) cls += entry.value; });
  console.log('CLS:', cls);
}).observe({ entryTypes: ['layout-shift'] });

// LCP 측정
new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lcp = entries[entries.length - 1];
  console.log('LCP:', lcp.startTime, 'ms');
}).observe({ entryTypes: ['largest-contentful-paint'] });

// Long Task 측정 (INP 프록시)
new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    console.log('Long task:', entry.duration, 'ms');
  });
}).observe({ entryTypes: ['longtask'] }); // Chrome 지원; 다른 브라우저는 'long-animation-frame' 사용

목표치:

• LCP ≤ 2.5s
• INP ≤ 200ms
• CLS ≤ 0.1

3-A. 재현 가능한 성능 게이트로 굳히기

브라우저 DevTools에서 병목을 찾았으면, 같은 문제를 CI에서도 다시 잡을 수 있게 반복 가능한 측정으로 굳힌다.

# Lighthouse CLI로 동일 경로를 반복 측정
npx lighthouse https://example.com --output=json --output-path=./lighthouse-report.json

확인 항목:

• Lighthouse 결과를 기준선과 비교해 임계값 이하로 떨어지면 빌드를 실패시키는지
• 번들 분석 도구로 초기 로드에 영향을 주는 큰 자산과 중복 의존성을 찾는지
• 성능 예산이 명시돼 있는지 (예: 핵심 경로 LCP/INP/CLS, 초기 JS 바이트 수, 이미지 총량)

원칙:

• 특정 빌드 도구에 과적합하지 말고, 현재 스택의 네이티브 번들 분석 도구를 사용한다
• "점수가 나빠 보인다"가 아니라 어떤 예산을 넘으면 실패인지 미리 합의한다
• 런타임 DevTools 조사와 CI 측정을 같은 사용자 플로우로 맞춘다

4. Accessibility 탭

// axe-core를 콘솔에서 실행
// (axe-core CDN 주입 후)
axe.run().then(results => {
  results.violations.forEach(v => {
    console.error(v.id, v.description, v.nodes.map(n => n.html));
  });
});

5. Playwright 테스트로 전환

DevTools에서 검증한 선택자를 Playwright 테스트로 변환:

// DevTools에서 확인한 선택자로 테스트 작성
test('submit button is accessible', async ({ page }) => {
  await page.goto('/form');
  
  const btn = page.getByRole('button', { name: 'Submit' });
  await expect(btn).toBeVisible();
  await expect(btn).toBeEnabled();
await expect(btn).toHaveAttribute('type', 'submit');
});

With Chrome DevTools MCP (Automated)

If Chrome DevTools MCP is configured, Copilot can inspect the live browser runtime directly. This mode is especially useful for:

• inspecting DOM state
• checking network requests and responses
• collecting console errors
• investigating rendering and performance bottlenecks

Example prompts:

Use Chrome DevTools MCP to inspect the network requests for /api/users
and report any 4xx or 5xx responses.

Use Chrome DevTools MCP to inspect the checkout form DOM state,
verify the submit button accessibility attributes, and summarize any issues.

When available, use automation as an accelerator for reproducing issues and gathering evidence quickly — not as a replacement for understanding the manual DevTools workflow.

Additional tips:

• Pair performance investigations with the Performance panel and references/performance-checklist.md
• Pair accessibility checks with DevTools accessibility data and references/accessibility-checklist.md
• If you are unsure about the latest DevTools workflow, fetch the current docs with Context7

How do I use Chrome DevTools to profile React rendering bottlenecks? use context7

Common Rationalizations

Rationalization	Reality
"유닛 테스트가 통과했으니 브라우저에서도 된다"	렌더링, 레이아웃, 네트워크 타이밍은 유닛 테스트로 잡을 수 없다.
"로컬에서 잘 되면 됐다"	성능 문제는 실제 네트워크 조건에서 나타난다. DevTools의 throttling을 사용한다.
"스크린샷으로 충분하다"	스크린샷은 DOM 상태, 접근성, 성능을 보여주지 않는다.

Red Flags

• 네트워크 탭을 열지 않고 API 통합 버그를 수정하려 함
• Core Web Vitals를 측정하지 않고 "빠르다"고 주장
• 접근성 오류를 브라우저에서 확인 안 함

Verification

• 핵심 사용자 플로우에서 Network 탭으로 API 호출 확인
• Lighthouse 점수: Performance ≥80, Accessibility ≥90
• Console에 오류 없음
• e2e-testing 스킬로 검증된 플로우를 자동화 테스트로 전환

Tips

• e2e-testing 스킬 이전 단계로 사용: DevTools로 먼저 탐색한 후 Playwright로 자동화한다
• references/performance-checklist.md와 references/accessibility-checklist.md를 함께 참조한다
• Chrome DevTools의 Recorder 기능으로 인터랙션을 기록하면 Playwright 코드 생성이 쉬워진다