How We Overcame Front‑End Build Chaos: Lessons from 1.0 to 3.0

Front‑End Optimization Journey

As developers, we constantly seek faster product iteration; optimization applies not only to the product but also to the daily development workflow. Building a painless process and continuously improving it requires effort, but any measurable gain validates the work.

1.0 Era

Early modularization using Seajs and Zepto kept code relatively clean, but the module layout mixed public and business code, and most files were bundled into a single

package.js

. This caused merge conflicts, manual version comparisons, frequent overwrites (over 10 times), a single test machine, and chaotic version control that relied on pre‑release servers instead of SVN.

The module diagram showed clear logical layers, yet the HTTP request count surged due to moduleization, forcing us to merge files before deployment.

2.0 Era

We refined modules to separate shared and business code, changed the merge strategy to split the large package, replaced the manual sync tool with ARS (which provides conflict detection), cached common JS in

localStorage

with versioned manifests, and switched to SVN for version control.

Statistics

LocalStorage cache hit rate

First‑paint time

window.onload time

New problems emerged: combo file delays, manual timestamping to bypass cache, and the need to avoid 304 responses for app‑embedded pages.

3.0 Era

We aimed for higher automation.

3.1 Exploration

After trying Grunt, we adopted Baidu's FIS, which generates hash‑named files, merges sprites, compresses/obfuscates code, and bundles JS/CSS. However, FIS configuration grew beyond 200 lines, requiring source modifications for advanced features.

3.2 Pain

Conflict issues persisted, especially in test environments where JS had already been merged.

Build time explosion : file count grew to >4000, causing development debug time of 3987 ms and full release build time of 181 745 ms.

ARS workflow remained cumbersome with multiple manual steps.

Complex build commands and numerous output files made releases error‑prone.

3.3 Deep Optimization

Reduce conflicts by further splitting modules and avoiding merges in test environments.

Shorten build time by implementing dependency‑based builds: only files that depend on changed files are rebuilt.

Build time measurements (ms):

We added a GUI for build commands, reduced output files, and streamlined ARS sync to an 8 ms automatic upload.

Further Improvements

Separate sprite generation for public CSS to avoid frequent changes.

Cache scripts in

localStorage

with long

max-age

values.

Embed small JS directly into HTML to cut HTTP requests, while keeping large libraries external.

Performance tests showed that inlining small scripts reduced download + execution time dramatically compared to external files.

We also compared inline vs external JS for a 8.7 KB file (gzip 3.3 KB); inline load time was near zero, while external load added ~200 ms.

Following Yahoo's 14‑point optimization checklist, we applied domain sharding, aggressive caching, sprite usage, request reduction, and script embedding.

Script domain switching, remove cookies.

File merging.

Long‑term browser caching (

max-age=15552000

).

Sprite generation.

Embed JS into HTML.

Leverage localStorage and app‑provided cache.

Cache HTML fragments.

Testing & Deployment Flow

We use reverse‑proxy + whitelist for external access (403 outside, internal network allowed). Environments: development, testing, pre‑release, production, each with its own domain. All roles can switch environments via the app's debug package.

Conclusion

Reflecting on a year of work, the process evolved from simple to complex and back toward simplicity. Continuous optimization—though never finished—has steadily improved speed, stability, and developer experience.