How Qwik.js Resumability Supercharged Meituan‑Dianping’s M‑Site Performance

1. Background and Challenge: Traffic Conversion and User Experience Dilemma

The M‑site (mobile entry point) aggregates public‑domain traffic for Meituan‑Dianping and funnels it to the app; its three core pages (merchant detail, content detail, homepage) must load instantly even on the worst devices and networks, because any delay directly harms conversion and brand perception.

2. The Bottleneck: Traditional Architecture Performance Ceiling

The legacy stack compiled a custom DSL into Vue, resulting in large first‑load bundles, slow hydration, and high maintenance cost. The merchant detail page also faced four hard constraints: no pre‑optimization, real‑time POI data, massive POI count, and strong SEO requirements, making server‑side rendering the only viable solution.

3. Breaking the Deadlock: Why Choose Qwik and Resumability?

3.1 Traditional SSR/CSR Performance Bottleneck: Hydration

Both CSR and classic SSR require full‑page JavaScript download, parsing, execution, and event binding before the page becomes interactive, causing long white‑screen times especially for first‑time visitors (over 50% of traffic).

3.2 Qwik’s Resumability Design

Qwik serialises component state and event bindings into the HTML so the client can resume interaction without re‑executing component logic. HTML therefore contains not only the DOM skeleton but also the complete application state.

Resumability core: HTML is no longer a static skeleton.

Example component boundary generated by Qwik:

<!--qv q:id=a q:key=tL5t:jQ_0-->
<div style="color:blue" q:key="jQ_3"/> <!-- component markup -->
<!--/qv-->

QRL (Qwik Resource Locator) strings embed lazy‑load URLs directly in HTML attributes, e.g.:

<button on:click="./q-CyCA2y-K.js#s_pElXkJ1YLxE" q:key="jQ_2">App内打开</button>

During client execution the Qwikloader (≈1 KB) registers a global click listener, captures the QRL, and lazily fetches the tiny JS chunk only when the user interacts.

3.3 Ultra‑fine Code Splitting: Optimizer

Qwik’s compiler breaks every event handler, hook, and style into independent chunks (often a few hundred bytes). The optimizer runs as a Vite/Rollup plugin and inserts <!--qv--> markers to rebuild the component tree without a virtual DOM.

3.4 Qwik’s Compile‑time Optimizations

Pre‑compilation: Reactive dependencies are analysed at build time, generating direct DOM update instructions.

Virtual‑DOM avoidance: Most updates modify the real DOM directly; a lightweight virtual DOM is only used for rare bulk updates.

Extreme tree‑shaking: Unused interaction code never enters the initial bundle.

3.5 Syntax is Easy, Mastery Requires Deep Understanding

Qwik’s API mirrors React, with the only difference being the $ suffix on lazy‑loadable functions (e.g., onClick$). However, developers must understand serialisable state, component boundaries, and the impact of misuse of hooks like useVisibleTask$ on TTI.

4. Implementation: First‑Screen‑Optimized Architecture

4.1 Balancing TTFB and Content Completeness with Hybrid Loading

Critical POI data (L0) is rendered server‑side and inlined; secondary data (L1) is fetched client‑side using useVisibleTask$ and lazy‑loaded components, with CSS skeletons displayed meanwhile.

4.2 Deployment Architecture and Network Layer Optimizations

Custom Adapter Layer: Implemented adapters for Express, Fastify, and a minimal Node server to bridge Qwik City with the company’s Serverless BFF platform.

Build and Release Refactor: Static assets are uploaded to CDN; CI pipeline automates test‑pre‑release‑release flow.

Router Pruning & I/O Optimization: Each Serverless function handles a single page’s SSR, reducing routing overhead.

Connection‑Pool Reuse: Enabled keep‑alive and undici HTTP client, cutting cross‑service latency by >20%.

Streaming + Gzip: Initially used Qwik streaming with Gzip, later switched to inlining critical CSS for better performance on cache‑less users.

4.3 Fault‑Tolerance and Degradation Mechanisms

SSR timeout fallback to client‑side rendering.

Serverless failure fallback to pre‑generated SSG static assets.

Legacy‑browser fallback routing to the old M‑site.

All fallbacks share a common interceptors library that normalises A/B experiments, auth, and error handling.

5. Fine‑Tuning: Millisecond‑Level Polish

5.1 CSS Inlining and On‑Demand Loading

Global styles and skeleton CSS are inlined via <style> tags; module‑level styles are loaded on demand with useStylesScoped$ and Vite’s ?inline query, reducing First Contentful Paint (FCP) TP90 by >100 ms.

5.2 Resource Orchestration: Prioritizing Critical Rendering Path

Preload LCP images with fetchPriority="high".

Serve AVIF/WebP for modern browsers, falling back to JPG.

DNS pre‑connect and pre‑fetch for CDN domains.

Lazy‑load non‑critical images.

5.3 Interface Aggregation and Optimization

Server‑side BFF aggregates all POI‑detail sub‑requests, performs token renewal and experiment decisions upstream, and trims response payloads, cutting main‑API latency by 31.6% (TP95).

6. Outcomes and Outlook

After migration, first‑screen JS size dropped from ~2 MB to <10 KB, first‑screen load time fell dramatically, and conversion metrics rose consistently across both merchant‑detail and UGC pages, especially on weak networks and low‑end devices. The team plans to explore edge‑rendering, RPC refactoring, Partytown for third‑party off‑loading, and further data‑caching strategies.

7. Acknowledgements

Thanks to the growth, product, and measurement teams for their close collaboration.