Frontend Development 27 min read

Browser Cache Optimization Strategies for Micro‑Frontend Architecture

This article analyzes the challenges of browser caching in micro‑frontend projects, presents a systematic optimization plan—including resource versioning, server‑side URL proxying, nginx cache‑control configuration, and CDN integration—and demonstrates a 48.5% reduction in page‑load time with detailed implementation steps and performance data.

Rare Earth Juejin Tech Community
Rare Earth Juejin Tech Community
Rare Earth Juejin Tech Community
Browser Cache Optimization Strategies for Micro‑Frontend Architecture

Introduction

In the era of web applications, page load speed is critical for user experience, especially in micro‑frontend architectures where many independent sub‑applications are assembled together. The author discovered a 48.5% improvement in load speed after applying a series of browser storage optimizations.

Background

Micro‑frontend projects split the overall application into multiple small apps that can be developed, built, deployed, and run independently. While this improves maintainability and scalability, it also introduces common problems such as stale browser caches that require users to clear caches or use incognito mode to see the latest content.

Analysis Process

1. Server‑side Issues

The author observed that static resources (JS, CSS, images) share the same domain, allowing a single configuration to control caching. However, internal company upload pipelines added extra headers that prevented proper cache updates.

2. Browser Cache Mechanisms

Two main caching strategies were examined:

Strong cache : Controlled by Expires and Cache‑Control headers (e.g., max‑age ).

Negotiated cache : Uses ETag and Last‑Modified to validate resources.

The author found that their demo files contained both ETag and Last‑Modified , while team resources only had Last‑Modified , leading to inconsistent caching behavior.

3. Micro‑Frontend Server‑Side Optimization

Four techniques were proposed:

Resource versioning or hash : Append a version or hash to static file URLs (e.g., <link rel="stylesheet" href="style.css?v=1.0"> ) so browsers treat changed files as new resources.

Server‑side URL proxy : Use a reverse proxy (nginx) to unify resource requests, add or modify cache‑control headers, and avoid cross‑origin issues.

Leverage browser cache mechanisms : Properly configure Cache‑Control , Expires , ETag , and Last‑Modified to balance freshness and performance.

CDN integration : Deploy a CDN (e.g., Cloudflare, Tencent Cloud CDN) to serve static assets from edge nodes, reducing latency and server load.

Implementation Details

1. Resource Build Configuration

During build, static files are emitted with a hash in their filenames. This ensures that any content change results in a new filename, forcing browsers to fetch the updated file.

2. Nginx Cache‑Control Settings

To prevent HTML from being cached while allowing other assets to be cached, the following nginx snippet was used:

location / {
    if ($request_filename ~* .*(?:htm|html)$) {
        add_header Cache-Control "private, no-store, no-cache, must-revalidate, proxy-revalidate";
    }
}

For selective paths, a regex‑based location block was added:

location ~ ^/static/(admin1|admin2|admin3)/ {
    if ($request_filename ~* .*(?:htm|html)$) {
        add_header Cache-Control "private, no-store, no-cache, must-revalidate, proxy-revalidate";
    }
}

3. HTML Meta Tags (Front‑End Fallback)

When server configuration is not possible, the following meta tags can be placed in the HTML head to disable caching:

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Cache-Control" content="no-cache" />

4. CDN Configuration

After enabling a CDN, the x-cache header shows MISS (no cache) or HIT (cached). Proper TTL settings ensure that static assets are cached while HTML remains fresh.

Results

Performance testing showed:

Before optimization: average page load time ≈ 1.37 s, 16 resource requests.

After optimization: average page load time ≈ 0.706 s, 7 resource requests (56% reduction).

Even when users refresh without clearing caches, the optimized setup still delivers faster loads for changed resources while keeping unchanged assets cached.

Future Directions

Further improvements include gzip compression (nginx gzip on; ), chunked delivery of large JS/CSS files, lazy loading of modules, pre‑loading critical resources, leveraging Service Workers for offline caching, and fine‑tuning cache policies per resource type.

Conclusion

The presented browser cache optimization strategy—combining resource hashing, nginx proxy configuration, selective cache‑control, and CDN deployment—significantly reduces load time and server load in micro‑frontend projects, while maintaining up‑to‑date content for users.

Performancemicro-frontendcdnnginxcache controlBrowser CacheETagresource hashing
Rare Earth Juejin Tech Community
Written by

Rare Earth Juejin Tech Community

Juejin, a tech community that helps developers grow.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.