Performance Craft
A dropped frame is a design defect the user feels before they can name it. This
skill treats the frame budget as a design material: know the budget, spend it on
what the philosophy values, and degrade in the order that does the least visual
damage.
The budget
Frame time = 1000 / refresh rate: 8.3ms at 120Hz, 16.6ms at 60Hz — minus the
platform's own compositing overhead. Design for the display the audience has:
ProMotion phones and most gaming displays are 120Hz; never hardcode 60. Measure
before and after any motion work — profilers, not vibes (DevTools Performance /
Instruments' Animation Hitches / engine profilers).
Which reference to load
| Situation |
Load |
| Web: CSS/JS/canvas/WebGL animation, scroll jank, layout thrash |
references/web-rendering.md |
| Apple: SwiftUI/UIKit hitches, Metal, ProMotion, battery/thermals |
references/apple-silicon.md |
| Game engines, particles at scale, and the degradation ladder |
references/budgets-and-degradation.md |
Non-negotiables
- Animate compositor-friendly properties (transform, opacity — and their platform
equivalents) unless a measured reason says otherwise.
- Timing from delta-time or the platform's frame callback, never a hardcoded
1/60 assumption.
- Always-on ambient animation must be provably cheap: paused off-screen, GPU-only,
and off the performance cores / not preventing CPU idle.
prefers-reduced-motion (and platform equivalents) is also the low-power path —
wire them together.
- When the budget is blown, cut by the degradation ladder — never ship the stutter,
and never fix it by cutting the design's primary feedback motion first.
1---2name: performance-craft3description: Performance Craft4---56# Performance Craft78A dropped frame is a design defect the user feels before they can name it. This9skill treats the frame budget as a design material: know the budget, spend it on10what the philosophy values, and degrade in the order that does the least visual11damage.1213## The budget1415Frame time = 1000 / refresh rate: **8.3ms at 120Hz, 16.6ms at 60Hz** — minus the16platform's own compositing overhead. Design for the *display the audience has*:17ProMotion phones and most gaming displays are 120Hz; never hardcode 60. Measure18before and after any motion work — profilers, not vibes (DevTools Performance /19Instruments' Animation Hitches / engine profilers).2021## Which reference to load2223| Situation | Load |24|---|---|25| Web: CSS/JS/canvas/WebGL animation, scroll jank, layout thrash | `references/web-rendering.md` |26| Apple: SwiftUI/UIKit hitches, Metal, ProMotion, battery/thermals | `references/apple-silicon.md` |27| Game engines, particles at scale, and the degradation ladder | `references/budgets-and-degradation.md` |2829## Non-negotiables3031- Animate compositor-friendly properties (transform, opacity — and their platform32 equivalents) unless a measured reason says otherwise.33- Timing from delta-time or the platform's frame callback, never a hardcoded34 1/60 assumption.35- Always-on ambient animation must be provably cheap: paused off-screen, GPU-only,36 and off the performance cores / not preventing CPU idle.37- `prefers-reduced-motion` (and platform equivalents) is also the low-power path —38 wire them together.39- When the budget is blown, cut by the degradation ladder — never ship the stutter,40 and never fix it by cutting the design's primary feedback motion first.