Open code, practice, and notes →
Download source with English comments · for reading
Motion · 26 Observing Renders and Performance
Series contents · Technology map
Stage: Validating a Motion System · Editable example · Storage ID: motion-step-26
Goals and learning outcomes
- Learning outcome: Explain the role of Render cost. Input case: 20 and 100 cards.
- Deliverable: A record of render counts and frame distributions. Connect your rationale for handling Measurement to the code.
Prerequisites
Prepare the results of the Detecting preferences and Preserving content exercises from Unit 25, “Reduced Motion Policy”.
Key concepts and explanations
Render cost
React renders and animation frames are different work. Observe the two metrics separately.
Measurement
Increasing the card count can change layout cost. Do not automatically conclude that something is faster.
Practice setup
First check the execution scope guidance on the example screen. The following describes the environment needed to extend the assignment in a separate project. The existing motion-01·02·03 examples are limited examples based on Motion JS animate. For React layout, AnimatePresence, and hooks exercises, install motion in a separate local React project and import from motion/react. Do not assume JSX runs directly in the editor; preserve CSP and isolation.
The linked example is a starting point. It does not implement every task below. Complete work beyond its supported scope in a separate project.
Practice tasks
- In src/day-26.tsx of a separate exercise project, record reordering with Profiler and Performance. Use the existing Unit 1·14·28 examples only as starting points.
- Input condition: 20 and 100 cards. Baseline: 20 cards. Run under the baseline condition, then record observations and errors in notes/day-26.md.
- Variable to change: Card count; new value: 100 cards. Run again with the same input path. Deliverable to save: A record of render counts and frame distributions. Hypothesis to test: Measured costs and bottlenecks may change. Compare it with the actual results and record whether they agree and the causes of any differences.
Variables to observe
| Variable | Baseline | Change | Expected change / hypothesis |
|---|---|---|---|
| Card count | 20 cards | 100 cards | Measured costs and bottlenecks may change. |
Predictions in this table are not measured results. Change one condition at a time and record why the actual result differs.
Completion criteria
- Required deliverable: A record of render counts and frame distributions. You have results for both the baseline and changed conditions, allowing a comparison of 2 conditions, and have recorded the input values and execution environment.
- Your explanation of the differences between the two conditions connects both concepts: Render cost and Measurement. For unexpected items, give at least 1 cause or reason they remain unresolved.
Self-check
- Which processing stage does Render cost affect in this exercise? Input case: 20 and 100 cards.
- Variable to change: Card count. Hypothesis to test: Measured costs and bottlenecks may change. Did the actual results agree with the hypothesis? Explain your evidence in terms of Measurement.
Official references
Linked example and execution scope
Example source · Runtime environments and limits
Interactive Observing Renders and Performance experiment with cleanup of the resources used.
Source code and records are not overwritten automatically. Resetting an existing example also preserves your notes.
Next learning
Previous: Reduced Motion Policy · Next: Remounting and State Restoration