How to Transform Existing Websites into Native‑Like Experiences with Low‑Cost Same‑Screen Rendering

Why Web Apps Lag Behind Native Apps

Even with Progressive Web Apps (PWA) that support adding to the desktop and offline access, the user experience of web applications remains noticeably inferior to native applications. The main cause is the fundamental difference between Browser/Server (B/S) and Client/Server (C/S) architectures, leading to page fragmentation, loading delays, and loss of in‑memory state during navigation.

Rendering Performance Issues

A typical client‑side rendering (CSR) flow loads HTML and JavaScript only after a user click, repeats framework code on every page, and loads APIs late, which hurts perceived performance.

The ideal rendering process should preload HTML, CSS, and JavaScript so that the next page can be displayed instantly.

Low‑Cost Native‑Like Experience: Same‑Screen Rendering

To achieve a native‑like experience without a full SPA rewrite, the team built a solution called LightHub that renders new pages within the same screen context, keeping the current page alive while loading the next one.

Key Components

Sandbox that can be attached to any existing page to restore it to an initial state while preserving shared objects.

Transition animation (simple slide‑in) that runs on the GPU to avoid blocking JavaScript.

Parallel API loading with a shared context.

HTML rendering that mimics browser behavior.

Event triggering that follows the normal browser lifecycle.

Sandbox Implementation

The sandbox records global variables on window, event listeners on window/document, timers ( setInterval, setTimeout, requestAnimationFrame, requestIdleCallback), and MutationObserver. When navigating, the DOM is cleared and the recorded state is restored, optionally keeping shared resources such as the framework or JSONP tags.

Parallel API Loading

runInSharedContext(() => {<br>  // This setTimeout must not be cleared by the sandbox<br>  setTimeout(() => window.sharedfetchDataPromise = fetch(res));<br>});

Subsequent pages can reuse the promise via window.sharedfetchDataPromise || fetch(url). The redfox library automates this reuse.

Browser‑Like HTML Rendering

Instead of directly assigning document.innerHTML = nextHTML, a custom renderHTML function parses the fetched HTML, appends CSS asynchronously, hides the body until CSS loads, and then appends scripts respecting inline, defer, and async semantics.

Event Lifecycle

During navigation the following events are triggered in order: beforeunload → pagehide → unload on the old page, then the new page resets readyState and fires domInteractive, defer scripts, and finally DOMContentLoaded. Unit tests are required to verify this behavior.

Analysis and Results

Timeline measurements show that API requests start immediately after click and the framework code is not re‑executed, confirming the expected performance gains.

Memory pressure is mitigated by the sandbox, which clears DOM, globals, timers, and observers on each navigation, preventing leaks in most cases. However, retaining shared services and using a non‑secure sandbox can still pose risks.

Custom phase timing shows API latency of 124 ms and total data fetch time of 350 ms, providing insight for further optimization.

The final performance comparison shows page load time improving from ~2.8 s to ~1.8 s, and a stable 3 % increase in exposure for the “Just For U” module.

Limitations and Future Directions

The approach requires same‑origin pages due to History API constraints and relies on developers to avoid memory leaks. Upcoming browser features like the Portal API promise a safer, cross‑origin sandbox that could replace the current JavaScript‑based implementation.