원클릭으로 Manus에서 모든 스킬 실행

js-runtime-performance

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.

Manus에서 실행

스타56

포크0

업데이트2026년 6월 7일 02:23

출처

rogie

rogie/figui3

GitHub 저장소 열기 Creator 저장소 보기

설치 명령

다운로드

Manus에서 실행

SKILL.md

readonly

name	js-runtime-performance
description	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.

JS Runtime Performance

Measure JavaScript cost through real user-facing paths. For FigUI3, that usually means interactions on fig-* elements in Playwright, not isolated functions.

What To Check

Event handlers stay short during pointer drag, key repeat, input, and resize.
Attribute/property updates avoid redundant DOM writes.
Repeated mount/unmount cycles clean listeners, timers, observers, and animation frames.
Expensive parsing or serialization does not run on every frame.
Overlay and picker positioning does not do repeated forced layout work.
Component registration and upgrade do not block page boot unexpectedly.

Test Pattern

Reproduce the user path with real DOM and real events.
Warm up once, then measure repeated runs.
Collect timings with performance.now() around the smallest meaningful operation.
For leak risks, mount/unmount repeatedly and count retained DOM/listeners through observable public effects.
Assert behavior first, then assert timing or bounded operation counts.

Instrumentation Ideas

Wrap public methods or callbacks temporarily inside page.evaluate to count calls.
Count emitted input and change events during interactions.
Use requestAnimationFrame loops to detect frame starvation.
Use console timing only for manual investigation; tests should return structured values to Playwright.

Fix Preferences

Batch DOM writes before layout reads.
Cache parsed static data, but invalidate when public attributes/properties change.
Prefer one listener on a stable root over many per-child listeners when behavior allows.
Cancel timers, observers, and frame callbacks in disconnectedCallback.

Avoid

Optimizing private code paths that do not affect measured UI behavior.
Adding debounce/throttle that changes input vs change semantics.
Hiding slow work behind setTimeout without proving user-perceived latency improves.

이 저장소의 다른 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

frontend-performance-testing

rogie/figui3

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.

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

JS Runtime Performance

Measure JavaScript cost through real user-facing paths. For FigUI3, that usually means interactions on fig-* elements in Playwright, not isolated functions.

What To Check

Event handlers stay short during pointer drag, key repeat, input, and resize.

Attribute/property updates avoid redundant DOM writes.

Repeated mount/unmount cycles clean listeners, timers, observers, and animation frames.

Expensive parsing or serialization does not run on every frame.

Overlay and picker positioning does not do repeated forced layout work.

Component registration and upgrade do not block page boot unexpectedly.

Test Pattern

Reproduce the user path with real DOM and real events.

Warm up once, then measure repeated runs.

Collect timings with performance.now() around the smallest meaningful operation.

For leak risks, mount/unmount repeatedly and count retained DOM/listeners through observable public effects.

Assert behavior first, then assert timing or bounded operation counts.

Instrumentation Ideas

Wrap public methods or callbacks temporarily inside page.evaluate to count calls.

Count emitted input and change events during interactions.

Use requestAnimationFrame loops to detect frame starvation.

Use console timing only for manual investigation; tests should return structured values to Playwright.

Fix Preferences

Batch DOM writes before layout reads.

Cache parsed static data, but invalidate when public attributes/properties change.

Prefer one listener on a stable root over many per-child listeners when behavior allows.

Cancel timers, observers, and frame callbacks in disconnectedCallback.

Avoid

Optimizing private code paths that do not affect measured UI behavior.

Adding debounce/throttle that changes input vs change semantics.

Hiding slow work behind setTimeout without proving user-perceived latency improves.