How ice.js 3 Redefines Loading & Rendering for Faster Web Experiences

Loading Strategy

Both MPA and SPA

ice.js 3 does not separate MPA and SPA; it merges their optimizations. Traditional MPA builds separate HTML and JS bundles for each page, causing duplicate resource loading, while SPA loads all pages from a single bundle serially.

Each page builds its own HTML and includes only the resources it needs, avoiding serial loading (MPA‑like output).

During navigation, only the next page's specific bundle is loaded, preventing duplicate resource loads (SPA‑like behavior).

The framework aims to make the default resource loading logic optimal.

Parallel Block Loading

In ice.js 3, a page consists of multiple layout components and a page entry component, forming a nested route. Optimizations include:

Resources and data requests of layout components and page entry are loaded in parallel for fastest loading.

When navigating between routes (e.g., /sales/recommends to /sales/favorites), only the differing component ( favorites.tsx) is loaded, while shared layout components are reused.

This allows developers to organize logically separated parts using nested routes for better loading experience.

Example: a mobile marketing page can split common Slider into a layout component and waterfall flows into route components, enabling parallel loading and on‑demand rendering when tabs switch.

Parallel Data Loading

Typical React/Rax apps fetch data in useEffect, which waits for the business bundle to load, causing delayed requests. ice.js 3 introduces a dataLoader convention: the framework (or container) initiates data requests in parallel with bundle loading, and in PHA containers like Taobao, it can become a pre‑request.

This pattern yields inherently better performance.

Cloud‑Combined Pre‑Request

Pre‑requesting data and resources together is a mainstream optimization. By combining cloud and client, resource loading and data loading can be fully parallelized. When a container receives a page URL, it can determine the required assets and data endpoints and request them immediately. ice.js is experimenting with this cloud‑edge link to improve performance.

Rendering Strategy

Default HTML Is No Longer Blank

Conventional CSR builds HTML with only a container node, leaving the initial page blank until JS renders. ice.js 3 enables SSG by default, rendering static parts at build time, reducing white‑screen time and delivering a static skeleton before dynamic data fills in.

Out‑of‑the‑Box SSR

SSR is a proven performance booster used in many Alibaba services. ice.js 3 adopts the Rax + Midway FaaS model, allowing developers to maintain page logic and rendering services in a single project and deploy as Serverless. Built‑in environment simulation and error fallback lower SSR development costs.

Streaming Page Rendering

Traditional SSR waits for all data requests before sending the full HTML, causing long white‑screen times if any request is slow. Streaming renders page sections incrementally: fast sections are sent first, while slower blocks render later, improving perceived performance.

Zero‑Bundle‑Size Exploration

React’s Server Components concept proposes that components rendered on the server need not send a JS bundle to the client, similar to the Islands Architecture. This splits the page into Server Components (static) and Client Components (interactive). Only the client‑side bundles for interactive parts are loaded, dramatically reducing bundle size (e.g., from 498 KB to 178 KB in the official demo) and speeding up interactivity.

Conclusion

ice.js 3 introduces two major experience‑enhancing directions:

Loading strategy: optimized default resource loading, parallel block and data loading, and ongoing cloud‑edge pre‑request research.

Rendering strategy: SSG for static HTML, continued SSR improvements with streaming and Server Components to further boost performance.

ice.js 3 is officially released and invites more projects to adopt and validate its capabilities.