Streaming vs. Preload: A Transparent Lighthouse Comparison
Why this test?
When you build an audio comparison player, you’re always balancing two competing goals:
- Instant, synchronized playback (especially for A/B comparisons)
- Low network payload (fast load, low data usage, stable performance on real devices)
We ran two independent Lighthouse-based measurements to make the trade-offs visible and comparable.
What we tested (and what we didn’t)
Test subjects
- The Studio Player on our site
- Competitor demo page (name intentionally anonymized)
Important context
- The competitor does not provide waveform visualizations. Any graphics on their page are unrelated to waveform rendering (e.g., cover art / page visuals).
- The Studio Player does load waveform/analysis data (JSON) to render waveforms.
Tools / data sources
- PageSpeed Insights (Mobile): overall performance metrics and “enormous network payload” detection
- Lighthouse Desktop Trace: network transfers observed during the navigation run (Chrome trace events)
Limitations
- Lighthouse traces can show transferred bytes, but they are not a perfect model of peak memory usage. Still, preloading many full audio files is inherently memory-intensive because large buffers must be held/managed by the browser and media pipeline.
1) PageSpeed Insights (Mobile): Performance & payload profile
| The Studio Player (Mobile PSI) | Competitor (Mobile PSI) | |
|---|---|---|
| Performance score | 74 | 58 |
| FCP | 2.3 s | 1.7 s |
| LCP | 3.7 s | 2.3 s |
| TBT | 360 ms | 4,670 ms |
| CLS | 0.000 | 0.016 |
| Speed Index | 5.4 s | 13.9 s |
Mobile PSI payload highlight
- Competitor is flagged with: “Avoid enormous network payloads — Total size was 59,303 KiB” (~58 MB) during the PSI run.
- The Studio Player run (in that Mobile PSI report) is not flagged with an “enormous payload” warning.
2) Lighthouse Desktop Trace: What was actually transferred
This section is derived from the provided Lighthouse trace files. It summarizes network bytes observed during navigation.
| The Studio Player (Desktop trace) | Competitor (Desktop trace) | |
|---|---|---|
| Requests observed | 115 | 57 |
| Total transferred | 16,486.4 KiB (~16.1 MiB) | 232,487.5 KiB (~227.0 MiB) |
| Audio transferred | 1,280.0 KiB (~1.25 MiB) | 231,571.4 KiB (~226.2 MiB) |
| Audio share of total | ~7.8% | ~99.6% |
Largest transfers (Desktop trace)
The Studio Player
- Waveform/analysis JSON: ~12,122.9 KiB (~11.8 MiB)
- Audio streaming (lossless): tokenized endpoint delivering audio/flac (~768 KiB + ~512 KiB observed)
- Additional page assets (e.g., WP/Elementor JS) in the ~100–500 KiB range
Competitor
- Multiple large audio/mpeg (MP3) files transferred during navigation (tens of MiB per file)
- No waveform payload exists (by design): the network footprint is dominated by preloaded audio files
Architecture differences (what the data indicates)
The Studio Player: stream once, keep channels in sync
- No compressed “comparison MP3 pairs” are preloaded. Instead, we stream lossless audio.
- In this test run, the audio was delivered as audio/flac via a tokenized streaming endpoint.
- Multi-channel approach: our comparison playback is designed around a single multi-channel (e.g., 8‑channel) lossless FLAC stream. That means the comparison sources live inside the same synchronized media stream, rather than being separate files that need to be aligned after the fact.
- Why that matters: synchronization is handled inherently by the media stream’s timeline. JavaScript is used to control playback and UI state, but it does not need to continuously “fight drift” between multiple independently buffered audio files. This avoids a category of CPU overhead that can appear when you try to keep multiple separate decoders perfectly aligned.
- Waveform visualization is delivered separately as analysis JSON and can be optimized independently (resolution, channels, caching).
Competitor: preload multiple compressed files, then synchronize
- File-based delivery: direct MP3 assets.
- Eager loading: the trace shows many large MP3 files transferred during a single navigation run.
- Synchronization model: when comparison sources are separate files, synchronization is achieved by coordinating them in JavaScript (start alignment, buffering management, potentially drift correction). This is feasible, but the approach tends to be both payload-heavy and memory-intensive because large decoded/buffered audio segments must be managed for each file.
Conclusion: Why streaming beats preload for scalable comparison players
Preloading full audio files is a brute-force way to guarantee “everything is ready”, but it comes with hard costs:
- Network payload explodes as soon as you have multiple tracks and variants (mix vs rec, etc.).
- Memory pressure increases because large audio buffers must be held/managed by the browser and media pipeline. Lighthouse isn’t a perfect memory profiler, but loading hundreds of megabytes of audio necessarily has memory implications.
- Scalability suffers: adding more examples increases the initial cost linearly (or worse).
Streaming + a multi-channel lossless design keeps the experience responsive and the footprint controlled:
- You can buffer enough to start instantly (even on weaker networks) without downloading everything.
- A single multi-channel stream keeps sources aligned by design, reducing the need for CPU-expensive “sync logic” between independent files.
- Waveforms remain a separate, optimizable layer: you can keep the visual quality while independently shrinking analysis payload over time.
Bottom line:
The measured data shows the competitor’s approach is dominated by upfront audio payload, while The Studio Player keeps audio transfer small and controlled—while providing waveform visualization and streaming lossless multi-channel audio for reliable synchronization.