Performance Optimization of an Electron‑Based Taobao Live PC Streaming Client

Taobao Live's PC streaming client, built on Electron, has been in production for over a year. Users reported slow startup, sluggish page navigation, high CPU usage, and frame drops. This article describes systematic performance improvements covering both startup and runtime phases.

Startup Time Optimization

Launch flow refactor : asynchronous network checks, batch log I/O, delayed cleanup of expired directories, and deferred pre‑heat of the streaming page until the home window is shown.

Bundle compression : Webpack + loaders shrink the ASAR from ~18 MB to ~2.5 MB, reducing JS load time.

V8 code cache : pre‑compile scripts; however, Node.js already caches core modules, so gains are limited.

Result: application launch time dropped from ~10 s to ~2.5 s.

Streaming Page Startup Optimization

Initial navigation to the streaming page took >5 s due to data loading, C++ SDK init, and rendering. Optimizations include:

Data pre‑load on the home page.

Make non‑critical SDK init asynchronous.

Pre‑heat the streaming renderer so the hidden window can be shown instantly (≈50 ms).

Result: navigation time reduced from >5 s to ~2 s, and with pre‑heat to ~50 ms (near‑instant).

Runtime Performance Optimization

A custom performance test tool was built to measure CPU, GPU, frame time, FPS, memory, and NAPI latency. The CPU‑locking script used during tests is:

@echo off
set key1=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\intelppm
set key2=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Processor
set value=start
set newvalue=4
reg add "%key1%" /v "%value%" /t REG_DWORD /d %newvalue% /f >nul 2>&1
if %errorlevel% equ 0 (echo Successfully changed %key1%\%value% to %newvalue%) else (echo Failed to change %key1%\%value% to %newvalue%)
reg add "%key2%" /v "%value%" /t REG_DWORD /d %newvalue% /f >nul 2>&1
if %errorlevel% equ 0 (echo Successfully changed %key2%\%value% to %newvalue%) else (echo Failed to change %key2%\%value% to %newvalue%)
pause

Key runtime improvements:

Front‑end page performance : reduced duplicate NAPI calls for scene elements (from 30 s to 1 s for 50 elements) and optimized Baxia security logic by stubbing unused functions.

Client‑side profiling : Visual Studio and Windows Performance Analyzer were used, though they could only resolve system and Electron frames.

Performance Monitoring & Data Collection

Front‑end metrics collected via the Chrome Performance API:

FPS and jank detection using requestAnimationFrame (jank defined as frame gaps >200 ms).

NAPI latency measured with performance.mark / performance.measure and a PerformanceObserver for measure entries.

Long‑task detection (tasks ≥50 ms) via PerformanceObserver on longtask entries, optionally dumping JS stacks with the js‑profiling document policy.

Collected data is reported every 10 seconds to the Medialab platform for real‑time monitoring.

Power‑Management & Degradation Strategies

When streaming quality drops (e.g., encoder FPS < 15 fps for 720p), a multi‑level fallback is triggered:

CPU < 30 % → suggest closing high‑consumption background apps.

Low capture frame rate → prompt user to check camera.

Switch to hardware encoding.

Automatic bitrate/frame‑rate reduction and disable non‑essential features (beauty, AI filters, gifts).

Prompt to disable high‑cost AI/beauty effects.

Resolution downgrade with toast notification.

Results & Outlook

After the optimizations, launch time fell from 10 s to 2.5 s, streaming page start from 5 s to 50 ms, and overall CPU‑heavy stream sessions dropped from 13 % to 6.7 %. Future work includes further NAPI/long‑task reduction and finer‑grained degradation per module.