KEY TAKEAWAYS
  • The test compares the same homepage with three hero-rendering modes.
  • 3D was actually active in all 20 WebGL trials.
  • These laboratory measurements establish neither conversion gains nor performance on all devices.

The question: how much motion should a site use?

Animation should support understanding while letting visitors reach content quickly. For this site, we ran a benchmark on 13 September 2026 comparing three variants of the same homepage. Measurements concern primary content rendering, layout stability and main-thread long tasks.

The Core Web Vitals thresholds published by web.dev provide general reference points. Field evaluation considers, among other things, the 75th percentile of visits. Our small local sample is not a field report and does not replace measurement on visitors’ devices. It examines an implementation choice in a documented environment.

Identical content, three variants

The static variant shows a CSS-drawn ring without ring animation. The second animates the same visual using a CSS transform. The third progressively replaces that fallback with WebGL rendered in a worker, off the main thread. Text, links, dimensions and other components remain shared.

The worker limits rendering to approximately twenty frames per second and receives visibility and pause state. In the delivered site, mobile defaults to the lightweight variant; reduced-motion preference uses static rendering. The benchmark forces each variant so it can be compared in both profiles.

The protocol actually executed

We executed ten navigations per variant and profile, for sixty observations, in Chrome 153 on one Mac against a local Next.js production server. The desktop profile uses a 1440 × 1000 viewport, 10 Mib/s download bandwidth, configured 40 ms latency and no CPU slowdown. Mobile uses 390 × 844, 1.6 Mib/s, 150 ms and 4× CPU slowdown.

Network cache is disabled. Measurement ends 3.5 seconds after the load event. Variants run in static, CSS and WebGL order, first on desktop and then under mobile emulation. This non-random order and browser reuse may introduce warm-up effects. The mobile profile is emulation, not a physical phone.

What the observations show

Observed desktop median LCP was 272 ms for static, 220 ms for CSS and 222 ms for WebGL. Under the mobile profile, respective medians were 822, 834 and 864 ms. The table also shows the interval between the 25th and 75th percentiles to expose dispersion. These descriptive differences do not establish that a variant is intrinsically faster.

WebGL rendering was active at the end of all twenty relevant trials. Median observed main-thread blocking was zero in all six groups, although some mobile observations contained long tasks. Maximum recorded CLS reached approximately 0.054. Raw data lets readers inspect each trial instead of considering medians alone.

Keep the limitations with the numbers

LCP here concerns the main text, not when the 3D animation becomes visible. Reported blocking sums the portion of long tasks exceeding 50 ms during our observation window; it is not Lighthouse TBT calculated over its own window. This protocol does not measure INP, GPU consumption, battery use or sustained smoothness.

A local server reduces the contribution of real infrastructure. Network and CPU emulation cannot reproduce every device characteristic. We ran neither a statistical causal-effect test nor a conversion experiment with prospects. Lighthouse, CrUX and actual visits should be analysed separately using their respective methods.

The resulting design decision

We retain the desktop 3D scene with a CSS fallback and motion controls, while favouring lightweight mobile animation. This choice considers readability, resources and touch use; it does not rely on a conversion promise derived from this benchmark.

To reproduce the trial, homepage variants are accessible with visual=static, visual=2d and visual=3d parameters. Code and protocol accompany project delivery. The downloads below contain all sixty observations, metadata and descriptive statistics. Later site updates may change results.

Profile / variantTrialsMedian LCPLCP P25–P75Median blockingMaximum CLS
Desktop / Static10272 ms260–299 ms0 ms0
Desktop / CSS10220 ms216–224 ms0 ms0
Desktop / WebGL10222 ms216–228 ms0 ms0
Emulated mobile / Static10822 ms813–835 ms0 ms0.054
Emulated mobile / CSS10834 ms820–852 ms0 ms0.054
Emulated mobile / WebGL10864 ms842–900 ms0 ms0.054
Benchmark data — 60 observationsCSVJSON & protocol

Sources & methodology

web.dev — seuils Core Web VitalsMise à jour 7 mai 2025 / Updated 7 May 2025 · Référence technique ; antérieure au benchmark / Technical reference; predates the benchmark

This insight combines cited publications with editorial analysis. Illustrative examples are not client results. Vendor features and terms may change.

i.
INKWAY

AI consulting, engineering and adoption. Perspectives connecting technology with business needs.

Our editorial approach
Explore how we can help with this topic