Leveraging Wasm and WebGL for High‑Performance Frontend Rendering: Simple Engine and Lottie WebGL Rendering

Introduction

As web front‑end technologies evolve, emerging solutions like WebAssembly (Wasm) and WebGL have become powerful tools for developers, offering higher performance and new possibilities. This article, based on projects from the 2024 Douyin "Happy China Year" campaign, demonstrates how Wasm and WebGL can innovate and improve popular front‑end interaction techniques such as Lottie, rendering engines, and animated images.

Simple Rendering Engine

Wasm provides a byte‑code format that runs in browsers with higher performance than JavaScript and supports multiple languages. Leveraging this advantage, the team created a high‑performance, lightweight Simple rendering engine built on Wasm + WebGL.

The engine aims to keep the front‑end interaction lightweight while addressing limitations of mainstream solutions like Lottie, APNG, WebP, and JavaScript rendering engines, which suffer from large resource sizes and lower performance.

Engine Architecture

To reduce learning and usage costs, the Simple engine exposes a TypeScript upper‑layer API that wraps simple objects with type hints for front‑end developers, while the performance‑critical core is implemented in C/C++ for matrix, graphics, animation, and dynamic batching calculations.

The rendering pipeline is primarily 2D and split into two parts: the JavaScript side handles small data with frequent GL calls, whereas the Wasm side processes large data with fewer GL calls, aiming for optimal performance.

The overall architecture is shown below:

Performance Gains

Benefiting from Wasm's computational performance, the Simple engine outperforms mainstream JavaScript engines such as PixiJS 6.3 and Cocos 2.4 in benchmark scenarios like Spine animation, sprite rotation, sprite jumping, and horizontal movement.

The test data, collected on an Android OPPO Find X1 running Douyin's cross‑platform framework in a V8 environment, shows that the Wasm‑based Simple engine delivers clear performance improvements, especially as computational tasks become more complex.

Computation task complexity: skeletal animation > graphics computation > rotation transformation > translation transformation

Test Code

The following images show the test code for 100 Spine animations comparing Simple and Cocos 2.4.

Cocos 2.4

Simple

Compatibility

Since its launch in 2015, the Wasm specification has matured and is now fully supported by major browsers. The Simple engine, started in July 2022, has been deployed in live‑stream, finance, news, music, and novel scenarios, and was used in a 2024 Spring Festival project.

Within Douyin's cross‑platform framework, Wasm usage reaches 96.97%. For environments that do not support Wasm, the engine can fall back to an asm.js version.

After more than a year of practice and verification, the Simple engine demonstrates stable and reliable compatibility.

Lottie WebGL Rendering

The Lottie WebGL rendering solution uses the Wasm + WebGL Simple engine to render Lottie animations, achieving near‑perfect visual fidelity while adding interactive controls, richer features, and performance improvements.

Performance Gains

Lottie, an open‑source animation framework from Airbnb, exports After Effects animations as JSON. The official web renderers (SVG, Canvas 2D, HTML) lack WebGL support, leading to three main issues:

Official Rendering Performance Low

SVG and HTML are unsuitable for handling many elements, and Canvas 2D cannot fully exploit caching, resulting in performance bottlenecks for complex animations.

In a Chrome simulation at 6× slower speed for mobile devices, Lottie SVG consumes 5.77 ms per frame, while Simple Lottie consumes only 1.10 ms, a nearly 6× speedup.

Off‑screen Canvas Rendering Performance Low

Most JS WebGL engines render Lottie via an off‑screen Canvas, which requires copying the animation state to a texture each frame, incurring extra overhead.

Testing 12 × 18 Lottie animations on an i7 Mac with Chrome shows that direct WebGL rendering with Simple Lottie yields 35 fps higher than the off‑screen Canvas approach, roughly a 3× improvement.

JS Graphics Computation Performance Low

When rendering vector‑heavy Lottie animations, JS‑based WebGL engines can be slower than native SVG or Canvas because vector calculations remain in JS.

Benchmarks show SVG frames at 6.26 ms versus PixiJS at 11.68 ms per frame. Only a Wasm + WebGL solution like Simple can fully optimize both rendering and computation.

In the same scenario, Simple Lottie achieves 5.35 ms per frame, with further potential gains by moving remaining JS calculations to Wasm.

Interactive Controls

Beyond performance, Simple enables rich interactive features such as asset replacement, event listening, animation blending, text changes, and physics collisions. In the 2024 Spring Festival "Red Packet Rain" project, all assets were Lottie animations, and Simple allowed dynamic interactions like clickable red packets, dynamic textures, animated numbers, and more.

Feature Support

Simple also enhances Lottie by allowing sprite‑sheet generation to reduce resource requests, compressing textures to save memory, and adding custom effects like particles, shaders (blur, color convolution), and even transparent video support.

WebGL Frame‑Difference Sequence

Frame‑difference sequence is a WebGL 1.0‑based animation image format consisting of a key frame, difference frames (opaque or semi‑transparent), and configuration data, typically packaged in four files.

Background

Traditional formats like video, APNG, and WebP have compatibility, interactivity, or compression drawbacks. APNG frames, for example, are almost as large as the key frame, offering little advantage over raw sequence frames.

Resource Size Optimization

Implementing a custom frame‑difference compression algorithm on top of WebGL 1.0 can replace larger sequence frames, APNG, or WebP with roughly 50 % smaller assets while maintaining visual quality.

Interactive Capability

Frame‑difference sequences also allow high‑performance arbitrary frame seeking, enabling interactive scenarios such as small fire‑person, New Year Beast, and badge projects where users can trigger state changes, 360° rotations, or seamless frame switches that video cannot provide.

Future Outlook

While the team has achieved notable breakthroughs with Wasm and WebGL, further work is needed: upcoming Wasm features (SIMD, threads, GC, WASI) will impact engine architecture; frame‑difference compression still lags behind video efficiency; and exposing Lottie enhancements to designers and developers requires improved workflows.

Team Introduction

We are the Douyin Front‑End Architecture – Interactive Experience Technology Team, providing interactive technology solutions for ByteDance products. Our portfolio includes SAR Creator, the high‑performance Simple Engine, and the AnnieX interactive container, collaborating with various front‑end and cross‑platform teams.

Next Issue Preview

The next article will focus on performance optimization in front‑end interactive scenes, discussing challenges and solutions when sharing limited process resources with host environments.