Offline Prerender (OPR): A Low‑Cost Alternative to SSR for First‑Screen Performance

The author, a former front‑end lead at Zhaozhuan Platform Operations, first outlines the common first‑screen optimization approaches—SSR, Prerender, and CSR—highlighting SPA’s inherent drawbacks that make traditional performance tricks ineffective.

He then enumerates various SPA‑centric optimizations (code‑size reduction, request merging, caching, web‑worker pre‑fetch, WebP images) and notes their limited impact on white‑screen time, which remains around 1.2‑1.5 seconds due to large framework bundles.

Because SSR can dramatically cut white‑screen time by delivering ready‑to‑render HTML, the author examines why many projects avoid it: high migration cost, dependency on API latency, node load limits, and lack of graceful degradation.

To obtain SSR‑like speed without its drawbacks, the author proposes Offline Prerender (OPR) , a hybrid solution that periodically renders pages with Puppeteer, captures the fully rendered HTML, injects a marker variable __offline_prerender_data__ , optionally caches API responses, and uploads the result to a CDN.

The OPR pipeline consists of seven steps:

Schedule a Node service to visit target pages.

Wait for the page to finish rendering (using page.waitForRequest tied to performance beacons).

Capture the rendered HTML with page.$eval('html', e => e.outerHTML) .

Inject the OPR marker and, if enabled, embed fetched API data for client‑side reuse.

Perform device‑specific style adjustments (rem conversion, head injection).

Remove unnecessary DOM fragments and compare the new HTML with the previous version to avoid redundant uploads.

Upload the final HTML to CDN with a distinct filename (e.g., index-Book-Home.html ) to separate it from the SPA entry.

During client navigation, both SSR and OPR pages undergo two rendering phases: an initial static DOM render and a subsequent Vue virtual‑DOM mount. OPR’s second‑render strategy uses delayed mounting—Vue is instantiated without an el target, and the DOM is swapped in only when the static and virtual DOMs are sufficiently similar, minimizing visual flash.

Additional optimizations include CSS tree‑shaking (reducing inline style blocks from thousands of lines to a few hundred), converting scripts to async loading to avoid blocking DOM construction, and defining a fallback that serves the captured static HTML if OPR encounters errors.

Real‑world results show first‑screen times dropping from 1.5‑4 seconds to 0.3‑0.8 seconds across multiple business lines, with OPR already deployed on all non‑login‑required home and list pages. Future work will extend support to pages that depend on user authentication.