Browser Rendering Pipeline

• · BR2 — Batch DOM reads before DOM writes in any code touching layout in a loop, to avoid forced synchronous layout thrashing.
• · BR3 — Stay within the frame budget (≈16.7ms per frame for 60fps): profile any continuous-motion interaction and ensure per-frame work (JS + style + layout + paint) fits.
• · BR4 — Use will-change sparingly and temporarily, applied just before an animation starts and removed after it ends — not left on indefinitely across the whole page.
• · BR5 — Minimize DOM node count and depth for frequently-updated regions, since layout cost scales with the number of elements whose geometry must be recomputed.
• · BR6 — Avoid triggering layout during scroll handlers — scroll-linked effects should read layout-dependent values once (or via IntersectionObserver/requestAnimationFrame throttling), not on every scroll event.

• · DevTools Performance panel first. Don't guess which stage is expensive — record a trace during the janky interaction and look at the flame chart: purple (layout), green (paint), or is it mostly yellow (JS)?
• · Element-count sanity check: for any frequently-updated UI region, count the DOM nodes — thousands of nodes updating together is a virtualization candidate regardless of how "simple" each node's markup looks.
• · The will-change audit: grep for will-change — is it applied to a bounded set of soon-to-animate elements and removed after, or left on broadly/permanently (wasting GPU memory)?
• · Scroll-handler audit: any addEventListener('scroll', ...) reading getBoundingClientRect() or similar without requestAnimationFrame throttling is a jank suspect.
• · CSS-first check: before reaching for a JS animation library/loop, ask if a CSS transition/animation/@keyframes achieves the same effect — it usually performs better with less code.

• · Ver anti-patrones específicos del dominio en el pack.

• [ ] Continuous/interactive animations use only transform/opacity. (BE1)
• [ ] No read-write-read-write layout thrashing patterns in loops. (BE2)
• [ ] Scroll-linked effects throttled via rAF or replaced with IntersectionObserver. (BE4)
• [ ] Large lists (>~100-200 items) virtualized. (BE5)
• [ ] will-change applied narrowly and temporarily, not left on broadly. (BE3)
• [ ] CSS transitions/animations preferred over JS style-mutation loops where expressible. (BE6)

• Rendering Performance
• Inside look at modern web browser (series)

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• webCSS Triggers (reference of which properties trigger layout/paint/composite)community-maintained reference, concept originally documented by Paul Lewis & Paul.
• blogInside look at modern web browser (series)Chrome Developers
• webRendering PerformanceGoogle / web.dev