How Bigpipe Transforms Frontend Rendering: From Sync to Async Loading

Introduction

The new Seller Center has been online for over three months, and the Midway journey is not only about front‑back separation but also about engineering at scale. Frontend is no longer just on the horizon; we can now dive into the View and Controller layers to do more interesting work.

View Layer

In the View layer, the UI is no longer purely server‑side or client‑side. Midway fully delegates the View layer to the frontend, leaving us to choose between server‑side rendering, client‑side rendering, or a hybrid approach.

Page Loading Methods

Controlling the View layer not only improves efficiency but also allows us to select the most suitable loading method for each scenario.

What Loading Methods Exist?

1. Direct Synchronous Loading

Server‑side rendering, loaded to the client in one go.

Typical scenario: the first‑screen content essentially comprises the entire page.

2. Scroll‑Synchronous Loading (lazyload)

Server‑side renders the first screen; subsequent content is placed in a textarea or comment and rendered when the user scrolls.

Typical scenario: page length far exceeds the first‑screen content.

3. Asynchronous Loading

Server renders the main layout, sends it to the client, then fetches other page content via AJAX and renders it client‑side.

Typical scenario: similar to Taobao Wireless H5, where data is fetched via API and rendered on the client.

4. Scroll Asynchronous Loading (lazyload)

Server renders the first screen, loads it to the client, and fetches subsequent content via AJAX when scrolling.

Typical scenario: page length far exceeds the first‑screen content.

5. Chunked Loading (Bigpipe)

Server supports chunked output, transmitting content in pieces that the client renders as they arrive.

Typical scenario: suitable for first‑screen output.

Choosing the Right Approach

Beyond business logic, page elements, interaction patterns, and third‑party content, the most important factor is user perception – "the page feels fast only if users say so."

Seller Center Home Page

Features of the Home Page

All main content is fully modular.

The first screen has fixed modules.

Each module has its own data.

Non‑official modules can be added and dragged by sellers.

Some modules are third‑party iframes.

Overall, the first screen is relatively fixed but contains many modules, making the page long.

Considerations

Choosing Direct Synchronous Loading will definitely get you called in for a talk tomorrow.

Choosing Scroll Synchronous Loading is better, but requires fetching all module data, assembling it into a textarea, which makes server processing too slow.

Choosing Asynchronous Loading already dominates the View layer; doing this might feel petty.

Choosing Scroll Asynchronous Loading is what most people would pick: render the first screen server‑side, then load modules asynchronously on scroll.

Choosing Chunked Loading raises the question of whether the first screen can be handled this way.

Step 1: Synchronous First‑Screen, Scroll Asynchronous Loading

We first adopt the scroll‑asynchronous loading scheme, assuming modules A/B are first‑screen and module C loads asynchronously on scroll.

Client requests the page.

Server fetches main layout data.

Server fetches data for module A.

Server assembles template for module A.

Server fetches data for module B.

Server assembles template for module B.

Combine into first‑screen HTML.

First‑screen content loads to client.

Client scrolls to module C.

Client sends request for module C.

Server fetches data for module C.

Server assembles template for module C.

Timing

First‑screen display time depends on module B processing time.

White‑screen time equals the time after module B finishes.

Problem 1

The first screen must wait until the last first‑screen module finishes rendering before output.

This leads to a long white‑screen period, making users feel the page is slow.

Step 2: Lighten the First‑Screen

To reduce the white‑screen duration, we make the first screen lighter so users perceive content faster.

Modules A/B are also loaded asynchronously.

The first screen contains only the main layout.

Since A/B belong to the first screen, they load immediately after the layout.

Business Scenario Effect

With this approach, the main framework loads quickly, and first‑screen modules appear soon after a brief loading indicator, giving users a fast‑perceived experience.

Timing

Sync loading approach.

Async loading of first‑screen modules.

First‑screen display time shortens, depending on layout processing time.

White‑screen time equals layout processing time.

Total loading time becomes longer.

Problem 2

After the layout appears, the loading of first‑screen modules is noticeable, creating a "module‑load‑slow" feeling.

More modules mean more requests.

Chunked Loading (Bigpipe)

Chunked Transfer Encoding

Before diving into chunked loading, understand chunked transfer encoding, which allows HTTP responses to be sent in multiple chunks.

In Node.js, streams make it easy to pipe response bodies chunk by chunk, achieving progressive rendering with just a single request.

A Concept Forms

Sync loading of the first screen.

Chunked loading of the first screen.

Total content loading time matches the sync method.

White‑screen time equals layout processing time.

A Demo

Content is transmitted chunk by chunk in order, displaying progressively.

Because module order matters, the server still pushes modules sequentially.

This simple demo won’t save the world, but illustrates the idea.

Breaking Order

Chunk 1 is "respect" – respects module order.

Chunks 2‑4 are "ignore" – ignore module order.

Chunk 5 completes the page structure.

Chunk 1 requires a predefined doProgress method.

doProgress places module content into its proper location.

Parallel Execution

Now we can output content out of order: prioritize the layout, while chunks 2‑4 can be arranged in three possible ways, meaning modules can be pushed to the client as soon as they are ready.

In practice, backend modules need to fetch data and render templates.

Modules can execute in parallel; whichever finishes first is sent to the client without waiting for others.

Flow Diagram

Assuming modules A/B are first‑screen and C loads asynchronously on scroll:

Client requests the page.

Server fetches main layout data.

After assembling the layout, it flushes to the client.

The layout must contain the doProgress method.

Server concurrently fetches data and assembles template for module A.

Server concurrently fetches data and assembles template for module B.

When module A finishes, it calls doProgress('A', 'A template') and flushes the script to the client.

The client executes doProgress to render module A.

When module B finishes, it calls doProgress('B', 'B template') and flushes the script.

The client executes doProgress to render module B.

After all parallel execution, the server flushes the closing tags of the page.

Client scrolls to module C and requests it.

Server fetches data for module C.

Server assembles template for module C.

Business Scenario Effect

The loading finishes so quickly that users barely notice it, confirming the "fast" feeling.

Compared with the effect of Scroll Asynchronous Loading :

Analysis

Both chunked loading and scroll‑asynchronous loading have similar layout output times.

The key difference is that chunked loading completes first‑screen module rendering within a single request, whereas scroll‑asynchronous loading requires additional round‑trips, making chunked loading perceptibly faster.

Bigpipe

The principle of chunked loading is essentially the Bigpipe concept; you can read more about it in related articles.

The new Seller Center provides an excellent scenario, and @乔福's decision to optimize with Bigpipe is a brilliant start.

Implementation

Having understood the theory, implementing Bigpipe with Node.js is straightforward—both Koa and Express have existing solutions. Integrating it into the Midway ecosystem for rapid business adoption still requires practical refinement.

Final Thoughts

Greater power brings greater responsibility; owning the View layer means frontend must act like backend as well.

Perspective shift: applying browser and mobile optimization experience to the server side (e.g., compression, module loading).

Big ideas, small details; while Bigpipe is a concept, the real progress comes from breaking down detailed challenges.

(Unless otherwise stated, this article is licensed under CC BY‑NC‑ND 4.0.)