<!-- Generated from models/_canonical by scripts/build-model-variants.js. Edit the canonical source, not this file. Behavioural profile for GLM: scripts/model-profiles.json -->

#Task boundary

1. Implement only what the task names; no extra abstractions or files.
2. English-only comments and identifiers.
3. Stop when the checklist passes.

---

#Purpose

Rules for keeping the browser's rendering work cheap. The measurable target is INP under 200 ms and animations that hold their frame budget.

The frame budget is the whole constraint: at 60 Hz a frame is 16.7 ms, and the browser needs part of that for itself. Roughly 10 ms of your work per frame is the ceiling. Exceed it and frames are dropped, which users perceive as jank.

---

#The pipeline, and where to stop

JavaScript → Style → Layout → Paint → Composite

Every stage you avoid is time saved. Which stages run depends on what property you changed:

Animate transform and opacity and nothing else. Composite runs on the GPU, off the main thread, and holds 60fps under load that would drop frames if layout were involved.

css
/* Layout on every frame — janky */
.slide { transition: left 300ms; }

/* Compositor only — smooth */
.slide { transition: transform 300ms; will-change: transform; }

Use will-change sparingly and remove it after the animation. Each hint promotes an element to its own layer and consumes GPU memory; applying it broadly makes things worse.

---

#Avoid layout thrash

Reading a layout property after writing one forces the browser to recompute layout synchronously, in the middle of your loop.

ts
// Forced synchronous layout on every iteration — O(n) layouts
for (const el of items) {
  el.style.height = el.offsetHeight + 10 + "px";   // read after write, repeatedly
}

// Batch: all reads, then all writes — one layout
const heights = items.map((el) => el.offsetHeight);
items.forEach((el, i) => { el.style.height = heights[i] + 10 + "px"; });

Layout-forcing reads include offsetTop, offsetHeight, clientWidth, scrollTop, getBoundingClientRect() and getComputedStyle(). In the DevTools Performance panel they appear as purple "Recalculate Style / Layout" bars inside a script block — that pattern is the signature.

Prefer ResizeObserver and IntersectionObserver over polling geometry: they deliver measurements without forcing layout.

---

#Render less

1. Virtualise long lists. Rendering 10,000 rows is slow regardless of how cheap each row is. @tanstack/virtual or equivalent renders the visible window plus a small overscan.
2. Paginate rather than rendering everything and hiding most of it with CSS — display: none still costs DOM nodes and memory.
3. content-visibility: auto lets the browser skip rendering off-screen sections entirely; pair it with contain-intrinsic-size so the scrollbar does not jump.
4. CSS containment (contain: layout paint) scopes recalculation to a subtree, so a change inside a widget cannot force layout of the whole page.
5. Keep the DOM shallow. Deep trees make every style recalculation more expensive.

In React specifically: state placed too high re-renders subtrees that do not care, and index keys make React reuse the wrong DOM nodes. Both show up as rendering cost with no obvious cause. → Frontend/react

---

#Keep interaction responsive

INP measures the worst interaction latency users experience: input → processing → next paint.

1. Never block the main thread with a long task. A 300 ms synchronous handler is 300 ms of unresponsive UI. Break long work with scheduler.yield(), or move it to a web worker.
2. Mark non-urgent updates so typing stays responsive:

tsx
const [query, setQuery] = useState("");
const deferred = useDeferredValue(query);      // list lags; input does not

1. Debounce or throttle high-frequency handlers (input, scroll, resize, mousemove). Use requestAnimationFrame for anything that updates visuals.
2. Add { passive: true } to scroll and touch listeners so the browser does not wait to discover whether you will call preventDefault().
3. Respond immediately, even if the work is not finished: show a pending state on the first frame rather than after the work completes.
4. Honour prefers-reduced-motion — for accessibility, and because it removes work. → Testing/accessibility

---

#Measure, do not guess

1. DevTools Performance panel with 4–6× CPU throttling. Look for long tasks (> 50 ms), forced synchronous layout, and frames exceeding the budget.
2. React Profiler for component render counts and durations — but confirm against the browser profile, since the cost is often in layout, not in React.
3. Field data (web-vitals) for INP and CLS at p75, segmented by device class. A desktop profile does not represent a mid-range Android phone.
4. Reproduce on a real low-end device before and after. Throttling approximates; hardware is the truth. → Performance/optimization

---

#Anti-patterns

---

#Checklist

• Animations use only transform and opacity
• will-change is applied narrowly and removed after use
• DOM reads and writes are batched; no forced synchronous layout in loops
• Geometry is observed with ResizeObserver/IntersectionObserver, not polled
• Long lists are virtualised
• Off-screen content is not rendered, or uses content-visibility
• CSS containment scopes recalculation for independent widgets
• The DOM is shallow and no hidden content is rendered unnecessarily
• No task on the main thread exceeds 50 ms
• Heavy computation runs in a web worker
• Non-urgent updates are deferred so input stays responsive
• High-frequency handlers are throttled and use requestAnimationFrame
• Scroll and touch listeners are passive
• Interactions show feedback on the first frame
• prefers-reduced-motion is honoured
• Profiling is done with CPU throttling and verified on a real low-end device
• INP is tracked in the field at p75, segmented by device class