Analysis of publicly documented MotionScore concepts, observable browser rendering dimensions, and SoraLabs research boundaries.
Scope of this document
This document analyzes publicly available information about MotionScore for research and attribution purposes. It is not a reproduction of MotionScore's internal implementation or scoring algorithm. Where Motion Audit introduces additional metrics, formulas, thresholds, or calibration methods, those are independently developed and experimentally validated by SoraLabs.
The implementation provenance rules and permitted public inputs are defined in the Measurement Provenance and Methodology Boundaries page. Third-party artifacts are not used as implementation specifications or calibration oracles.
Attribution and Independent Implementation
SoraLabs Motion Audit uses the publicly documented S-to-F grading hierarchy from MotionScore by Motion.dev (https://score.motion.dev/methodology) with permission.
The project independently derives its technical quantitative model from browser rendering architecture, W3C web-platform specifications, Chromium compositor behavior, GPU memory and graphics-system principles, and empirical benchmarking.
The permitted MotionScore reference is limited to the documented grading hierarchy and its conceptual rendering categories. SoraLabs does not reuse proprietary source code, internal closure heuristics, unpublished assets, or MotionScore output as a calibration oracle.
Motion Audit's quantitative auditing rules, scoring model, calibration parameters, and TypeScript implementations are developed independently by SoraLabs.
MotionScore publicly documents an S-to-F grading framework for evaluating animation performance according to rendering characteristics. The following section summarizes the publicly documented concepts referenced from https://score.motion.dev/methodology and does not reproduce MotionScore's internal implementation.
[PUBLIC] Documented by MotionScore (score.motion.dev/methodology)
Public documentation on https://score.motion.dev/methodology outlines an S-to-F qualitative hierarchy reflecting how deeply animations disturb the browser's render pipeline:
| Tier | Classification | Pipeline Cost | Documented Conceptual Description |
|---|---|---|---|
| S | Compositor-only | Lowest | Executed off the main thread on the Compositor Thread (e.g., CSS/WAAPI transform, opacity, filter, clip-path). |
| A | Main-thread composite | Low | Compositing occurs off-thread, but animation ticks originate on the main thread (JS/WAAPI drivers). |
| B | Measure before Composite | Moderate | Geometric measurement occurs prior to delegating to compositor execution (e.g., FLIP layout transitions). |
| C | Paint-triggering | High | Visual invalidation requires rasterization passes (e.g., background-color, box-shadow, border-radius, CSS variables). |
| D | Layout-triggering | Very High | Geometry recalculation (reflow) disrupts neighboring DOM nodes (e.g., width, height, top, left, flex/grid changes). |
| F | Thrashing | Critical | Alternating DOM reads and writes defeat browser batching, triggering synchronous style/reflow cycles. |
Contextual Invalidation Disclaimer
These classifications describe the conceptual hierarchy documented by MotionScore and should not be interpreted as universal browser guarantees. Actual rendering behavior can vary by property, browser version, GPU driver, DOM structure, and execution context.
[RESEARCH] SoraLabs Investigation & Research Areas
To evaluate web motion rigorously without assuming unpublished third-party scoring formulas, SoraLabs references the qualitative hierarchy on score.motion.dev/methodology while grounding its quantitative engine in four technical research dimensions:
Animation Execution Pipeline:
[PUBLIC] Qualitative distinction between compositor, paint, and layout operations as documented on score.motion.dev/methodology.[OBSERVED] Observable CDP traces (Animation.animationStarted, style recalculations, paint rects).[IMPLEMENTATION] Calibrated Blink pipeline stage cost vector (: Compositor = 0, CSS Variable = 15, Paint = 20, Layout = 50), bounded per-animation (max 75 pts penalty) and aggregated via Amdahl bottleneck coupling ().Scroll-Driven Mechanics:
[PUBLIC] Distinction between off-thread declarative scroll timelines and synchronous script listeners.[OBSERVED] Main-thread event latency, passive flag compliance, and animation frame synchronization.[IMPLEMENTATION] Logarithmic listener contention saturation (), non-passive blocking stall penalty ( pts), and NIST P75 concurrency interpolation.Layout Thrashing & Mutation Patterns:
[PUBLIC] Concept of interleaved read/write mutations causing pipeline stalls.[OBSERVED] Chromium Blink Document::UpdateStyleAndLayoutTree call stacks in Performance profiles and forced reflow getters (offsetHeight, getBoundingClientRect).[IMPLEMENTATION] Calibrated base penalty (, ), consecutive reflow burst detection via Hash-Set clustering with 8-frame budget exhaustion (), invalidation scope factor ( for root containers like html/body/#root), per-selector intra-frame chain repetition and distinct selector saturation, and framework hydration mount phase allowance ( pts).GPU Texture & Memory Pressure:
[OBSERVED] Compositor layer quad bounds (LayerTree.layerTreeDidChange), layer counts, and DPR-aware texture and layer estimates.[IMPLEMENTATION] Theoretical raw uncompressed RGBA8888 texture estimate () alongside Chromium cc::TileManager discrete tile pooling with a pre-raster lookahead horizon ( viewport), evaluated via piecewise operational band interpolation against power-of-two GPU memory pools.Real-world execution cost diverges substantially based on geometric and temporal context:
[OBSERVED] Large raster invalidations bottleneck GPU fragment fillrate. Repainting a full-screen background is vastly heavier than repainting an icon.[IMPLEMENTATION] Clamped paint surface scaling ratio () relative to a baseline interactive component viewport footprint.[OBSERVED] Offscreen elements ticking animations consume main-thread execution time and power unnecessarily.[IMPLEMENTATION] Selective offscreen mutation penalty () targeting Layout and Paint modifications, while leaving off-thread compositor animations unpenalized () to prevent double-penalization with GPU VRAM auditing.[RESEARCH] ([IMPLEMENTATION] Google RAIL instantaneous perception duration discount factor ( for micro-interactions ).[IMPLEMENTATION] Effective concurrency balancing sustained load against peak bursts () alongside NIST percentile distribution mapping.Built by Axyl. A performance auditing toolkit for motion-heavy web interfaces.
Last updated: 10/11/2026