Skip to main content

frontend-performance-testing

Guides browser-based performance testing for HTML, CSS, JavaScript, and UI interactions. Use when measuring frontend performance, adding Playwright perf tests, checking regressions, profiling load/render/interaction cost, or discussing performance budgets.

소스 정보

저장소
rogie/figui3
최근 소스 활동
2026년 6월 7일 02:23
감지된 SKILL.md 언어
영어
스타
70
포크
1

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
frontend-performance-testing
description
Guides browser-based performance testing for HTML, CSS, JavaScript, and UI interactions. Use when measuring frontend performance, adding Playwright perf tests, checking regressions, profiling load/render/interaction cost, or discussing performance budgets.
# Frontend Performance Testing Use real browsers for performance checks. In this repo, prefer Playwright because `playwright.config.ts` already boots `bun server.ts` and runs against Chromium. ## What To Measure - Load readiness: time to fixture boot, first usable UI, and custom element definitions. - Interaction latency: click, keyboard, pointer drag, slider movement, picker open/close. - Render cost: layout, style recalculation, paint, animation frames, and DOM update loops. - Bundle/build changes: output size and runtime behavior after `bun build`. - Regressions under scale: repeated components, large option lists, nested controls, and overlay stacks. ## Test Pattern 1. Mount the smallest deterministic fixture that reproduces the performance risk. 2. Warm up once before measuring. 3. Use browser APIs inside `page.evaluate`: `performance.now()`, `PerformanceObserver`, `requestAnimationFrame`, `getBoundingClientRect`, and `document.fonts.ready` when relevant. 4. Repeat enough times to reduce noise; assert on median or bounded worst case, not one sample. 5. Keep budgets local and named after the scenario, not global magic numbers. ## Playwright Guidance - Put stable performance checks near `tests/figui` unless they need a separate fixture. - Fail on page errors and unexpected console errors before trusting timing data. - Use `test.slow()` for intentionally heavier regression scenarios. - Capture traces only for failing or investigative runs; do not turn every perf test into a trace artifact. - Prefer `expect.poll` for readiness, then measure a synchronous scenario. ## Budget Rules - Budgets should catch meaningful regressions without flaking on normal machine variance. - Use relative comparisons when possible: changed implementation vs baseline path in the same page. - Avoid hard sub-millisecond thresholds. - Document what user-facing lag the budget protects. ## Avoid - jsdom performance conclusions. - Network-dependent timing assertions. - Screenshot diffs as a proxy for performance. - Microbenchmarks that skip the actual DOM/CSS/component path.
GitHub에서 보기