一键在 Manus 中运行任何 Skill

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.

在 Manus 中运行

星标56

分支0

更新时间2026年6月7日 02:23

来源

rogie

rogie/figui3

打开 GitHub 仓库查看创作者相关仓库

安装命令

下载

在 Manus 中运行

SKILL.md

readonly

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

Mount the smallest deterministic fixture that reproduces the performance risk.
Warm up once before measuring.
Use browser APIs inside page.evaluate: performance.now(), PerformanceObserver, requestAnimationFrame, getBoundingClientRect, and document.fonts.ready when relevant.
Repeat enough times to reduce noise; assert on median or bounded worst case, not one sample.
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.

同仓库更多 Skills

同仓库

css-render-performance

rogie/figui3

Guides CSS rendering and layout performance tests for component UIs. Use when checking selector cost, layout thrash, paint work, animation smoothness, CSS containment, computed styles, or visual regressions caused by CSS changes.

2026-06-0756

js-runtime-performance

rogie/figui3

Guides JavaScript runtime performance testing for frontend components. Use when profiling event handlers, DOM update loops, memory leaks, timers, animation frames, pointer/keyboard interactions, or regressions in vanilla JS component code.

2026-06-0756

web-component-performance

rogie/figui3

Guides performance testing for native Web Components and custom elements. Use when measuring custom element registration, upgrade cost, connected/disconnected callbacks, attributeChangedCallback churn, Shadow DOM work, slots, or fig-* component scalability.

2026-06-0756

a11y

rogie/figui3

Guides accessibility review and implementation for FigUI3 web components and playground examples. Use when the user mentions accessibility, a11y, ARIA, screen readers, keyboard navigation, focus rings, labels, roles, disabled states, contrast, dialogs, menus, or form control semantics.

2026-06-0656

css-component-testing

rogie/figui3

Guides CSS and layout tests for FigUI3 components. Use when validating component CSS, nested selectors, tokens, interaction states, computed styles, layout boxes, or visual regressions.

2026-06-0156

web-component-testing

rogie/figui3

Guides real-browser tests for FigUI3 custom elements. Use when adding or debugging tests for fig-* web components, attribute/property contracts, value synchronization, event payloads, disabled behavior, or custom element registration.

2026-06-0156

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

Mount the smallest deterministic fixture that reproduces the performance risk.
Warm up once before measuring.
Use browser APIs inside page.evaluate: performance.now(), PerformanceObserver, requestAnimationFrame, getBoundingClientRect, and document.fonts.ready when relevant.
Repeat enough times to reduce noise; assert on median or bounded worst case, not one sample.
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.