Busy main thread: left freezes, transform keeps going
Click the button. The red box (animating left, which needs layout on the main thread) freezes for a second. The green box (animating transform, handed to the compositor) keeps sliding. 100cqw is the lane's width (a container query unit, Topic 9.6), because translate percentages refer to the box itself.
Smooth animation means producing a new frame every 16ms or so; animating transform and opacity lets the browser skip layout and paint and move ready-made layers on the compositor, will-change hints at this ahead of time, and prefers-reduced-motion lets you tone motion down for people it makes ill.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Rewrite this animation so it doesn't trigger layout: @keyframes drop { from { top: -50px; } to { top: 0; } } on an absolutely positioned toast.
Make a .spinner that spins forever, but for reduced-motion users stops spinning and pulses its opacity slowly instead.
Write JavaScript that slides a .panel 200px to the right with the Web Animations API (0.3s), but makes the change instantly when the user prefers reduced motion. Log "moved" when it's done.
Explain it without notes
Why are transform and opacity the preferred properties to animate?
What is the compositor thread, and why does it keep some animations smooth while JavaScript is busy?
What does will-change do, and what are the risks of overusing it?
What is layout thrashing and how do you avoid it?
How should a site respond to prefers-reduced-motion: reduce?
Preview
Console
Nothing logged yet.