LsLoader: A Front-End Module Caching and Performance Optimization Tool

Background

Because of JavaScript’s characteristics, front‑end scope splitting has always been a primary challenge. From simple global variables to RequireJS’s AMD modules, and then to static references via browserify/webpack, front‑end business logic has evolved from a linear list of CSS/JS files into a directed acyclic graph rooted at an entry file. The development source files typically pass through the process illustrated below.

Fine‑grained splitting is a trend that benefits code modularity and maintainability. However, the monolithic bundling performed by existing build tools creates performance conflicts: large bundles cause duplicate module downloads across pages and longer load times; small bundles improve cache hit rates but generate excessive HTTP requests, also hurting load time. The following diagram shows the files loaded in the browser after RequireJS/webpack bundling.

Performance Optimization

To improve Web App performance, we need a tool with the following features:

1) JavaScript modules are cached separately.

2) Each update is combined into a single HTTP request via an online combo service.

3) The caching mechanism is plug‑and‑play, independent of the existing tech stack.

We introduced LsLoader.js, which caches module files in the browser’s localStorage and controls module updates and execution via JavaScript.

Advantages of localStorage caching:

1) Excellent mobile compatibility – supported by mainstream mobile browsers and WebViews, without the iOS UIWebView cache‑loss bug.

2) Fully controlled by JavaScript; front‑end code does not depend on the host environment.

3) Significantly speeds up loading on weak networks; a 100 KB script that blocks page rendering can be reduced to 1–3 seconds on poor 3G.

4) Compared with PWA or WeChat Mini‑Programs, localStorage works across many business lines and environments (WeChat, native WebView, browsers) and supports both single‑page and multi‑page H5 scenarios.

Disadvantages:

1) Appending JavaScript via append is slightly slower than loading via <script> tags, and parsing the appended file adds overhead.

2) In PC environments with good network conditions, module‑level updates bring little time savings, so the benefit may be limited.

Implementation Principles and Layered Structure of LsLoader

To be compatible with various front‑end build stacks (from global scope splitting to RequireJS AMD to modern webpack), LsLoader adopts a three‑layer design:

1) Front‑end Build Layer – your existing gulp/webpack build pipeline.

2) LsLoader Processing/Compilation Layer – uses UglifyJS or Babylon.js to analyze JavaScript dependencies and transform them into a format LsLoader can recognize.

3) Result Layer – a compressed ~2 KB inline script that defines how modules are cached, loaded, and updated in the browser, supporting iOS/Android browsers, WebViews, and handling environments where localStorage is disabled or full.

The design differs from tools like Meituan’s TruckJS or Scrat.js, which require a full build configuration. LsLoader works as a middleware, easily inserted or removed from existing projects.

Processing Layer Workflow

For RequireJS builds, LsLoader first parses source files with Babylon or Uglify into an AST, locates define calls, removes duplicate references, and orders modules by dependency.

For webpack builds, LsLoader similarly parses the source, traverses entry import dependencies, extracts common modules into an array for CommonsChunkPlugin, and passes the dependency graph to the front‑end part so the page can load the generated webpackJSONP bundle in the correct order.

After processing, the module list is delivered to the browser as an array and executed/cached as shown below.

Modules are separated on the server using /combojs/ comments and support various packaging formats such as define or webpackJSONP.

Online Effects of LsLoader

Macro results

Meituan Waimai red‑packet page load time reduced from 3 s to 2 s (‑30 %); interactive time from 2.2 s to 1.2 s (‑45 %).

Meituan Waimai i‑version home page load time reduced from 2.8 s to 1.8 s.

Static resource size: 80 KB × 4.5 M ≈ 343 GB; CDN request size 78 GB; traffic saved 265 GB.

Micro results

Online demo: https://i.waimai.meituan.com/node/demo/vue

The page contains one entry file and three dependency packages, each cached separately in localStorage. Subsequent updates download only the changed module.

Three module files are merged into a single request and split on the client using comment delimiters.

Without splitting, a large bundle would be ~80 KB for a simple Vue list; multi‑page, multi‑component apps would waste far more bandwidth.

Complex example: a two‑page Vue SPA using LsLoader versus not using it.

The app depends on 4 component files, 2 libraries, and 3 functional JS modules – a total of 9 packages (≈120 KB). With a single large bundle, each deployment costs 120 KB; with LsLoader, module‑level updates typically affect only 1–2 files, costing 10–20 KB per iteration.

Six of the nine files are shared across pages (Vue, Zepto, utility modules, a common Vue component), so caching benefits other pages on the same domain as well.

Potential Extensions of LsLoader

Because LsLoader is compatible with various web build systems, it can be extended with custom features, such as on‑demand loading for SPAs or pre‑loading resources in hybrid apps by generating a hidden preload page that caches assets via localStorage, thereby improving first‑screen load performance.

Author Bio

Huan Yu, senior front‑end engineer at Meituan Waimai. Joined in 2016, responsible for i‑version, red‑packet page, and hybrid pages. Focuses on component‑based development, page acceleration, and user experience. Led the migration from gulp + RequireJS to webpack 2 + Vue 2 + LsLoader.