OnlineCBT
Measure rendering work before applying optimizations
A browser processes style, layout, painting and compositing work. Layout determines geometry; paint produces visual content; compositing combines layers. A change may trigger several stages, and the exact cost depends on the page and browser.
Compare two animations
/* Can change layout geometry repeatedly. */
.panel--layout { transition: width 200ms ease; }
/* Often avoids changing normal-flow geometry. */
.panel--visual { transition: transform 200ms ease; }
.panel--visual:hover { transform: translateX(0.5rem); }Transform is often a better fit for a purely visual movement, but it does not resize the layout space. Choosing it changes semantics as well as cost. Do not substitute a transform when neighboring content genuinely needs to reflow.
Use developer tools
- Record the actual interaction in the Performance panel.
- Look for long tasks, repeated layout and paint events.
- Inspect large paint regions and expensive effects.
- Change one suspected cause, record again and compare under similar conditions.
Use a representative device or throttled environment. A single smooth desktop recording does not prove mobile performance.
Hardware acceleration is not a magic switch
Adding translateZ(0) or will-change to every element can increase layer memory and management cost. Use will-change sparingly for a measured need and remove temporary hints when no longer useful. Large blur effects, huge images and excessive layers can outweigh a small animation improvement.
Read/write layout interaction
JavaScript that repeatedly writes styles and immediately reads geometry can force synchronous layout. Batch related reads and writes where practical. CSS alone is not responsible for every rendering delay; inspect scripts, fonts, images and third-party work too.
Practice
Build a small hover movement, record width-based and transform-based variants, and compare layout/paint activity. Keep the variant that meets the actual layout requirement and performs well. Record the test conditions rather than reporting an unsupported “GPU optimized” claim.
हिन्दी संकेत: पहले profile करें। हर element पर will-change लगाने से performance बेहतर होना जरूरी नहीं।
