🚀 Triple-Layered Web Caching Strategy: How Memory, IndexedDB and HTTP Cache Improved Speed by 96%
Discover how to accelerate your website through our powerful triple-layered caching strategy combining Memory Cache, IndexedDB, and HTTP Cache. Detailed guidance from theory to practice helps reduce page load time by up to 96%, improve user experience, and optimize performance across all devices.
In today’s digital age, page load speed is one of the most critical factors affecting user experience and SEO rankings. According to Google research, 53% of users will leave a website if it takes more than 3 seconds to load. With modern web applications, especially SPAs (Single Page Applications), continuous API calls to fetch data can cause slow loading, significantly reducing user satisfaction.
We encountered this issue with our AVA Manifest system – a system that provides configuration data and game information for our website:
High response time: 1.82 seconds for an API request
Large data volume: 28.5MB of transferred data
High request count: 674 requests for a single page load
High TTFB (Time To First Byte): 1.72 seconds
These numbers seriously impact UX and reduce the likelihood of users continuing to use our website.
2. Performance Optimization Concept
After analyzing the problem, we realized that the data from the API doesn’t change frequently, only updating after each new release. This opened up a significant opportunity to apply a multi-layered caching strategy:
Memory Cache: Store data in JavaScript memory for fastest access
IndexedDB: Store data in the user’s browser with large capacity and long lifetime
HTTP Cache: Leverage the browser’s default caching mechanism combined with stale-while-revalidate
We also designed version control mechanisms and automatic stale data removal to ensure users always have the latest data without affecting the experience.
3. Selected Optimization Strategies
3.1. Multi-layered Cache with Different Lifetimes
Memory Cache (5 minutes): Store data in JavaScript memory, fastest access speed
IndexedDB (15 minutes): Store data in the browser, large capacity, persists between sessions
HTTP Cache (15 minutes + 1 hour stale-while-revalidate): Leverage browser’s default cache, combined with stale-while-revalidate for background updates
3.2. Version Control and Automatic Cleanup
Version Control: Create a hash from data to check for changes
Auto Cleanup: Automatically delete stale data after expiration
Background Revalidation: Update data in the background while users use cached data
4. Why Choose These Strategies?
4.1. Aligned with User Behavior
Game sessions typically last 15-30 minutes, so the cache configuration is designed to match this timeframe:
Memory cache (5 minutes): Sufficient to handle repeated requests on the same screen
IndexedDB (15 minutes): Matches the average duration of a game session
HTTP Cache (15 minutes + 1 hour SVR): Ensures smooth UX even when there are server-side changes
4.2. Balance Between Performance and Freshness
The “stale-while-revalidate” strategy allows us to serve cached data immediately (increasing speed) while silently updating new data from the server (ensuring freshness).
4.3. Reducing Server Load
With a high cache hit rate (95%), we significantly reduce the number of requests to the server, helping:
Reduce bandwidth costs
Decrease backend system load
Increase system load capacity
5. Solution Implementation
5.1. Data Structure for Memory Cache
Memory Cache Configuration
// Define cache durations for different strategies
const CACHE_DURATION = {
MEMORY: 5 * 60 * 1000, // 5 minutes for memory cache
HTTP: 15 * 60 * 1000, // 15 minutes for HTTP cache
STALE: 60 * 60 * 1000 // 1 hour for stale-while-revalidate
};
// In-memory cache objects
const appDataCache = {
data: null, // The cached data
version: null, // Version hash for comparison
timestamp: null // When the data was cached
};
5.2. IndexedDB Initialization
IndexedDB Setup
// Initialize IndexedDB
function initializeDatabase() {
return new Promise((resolve, reject) => {
const request = indexedDB.open('app-cache', 1);
// Handle database opening errors
request.onerror = () => reject(request.error);
// Handle successful database open
request.onsuccess = () => resolve(request.result);
// Handle database upgrades/creation
request.onupgradeneeded = (event) => {
const db = event.target.result;
// Create object store if it doesn't exist
if (!db.objectStoreNames.contains('data-store')) {
const store = db.createObjectStore('data-store', { keyPath: 'id' });
// Create indexes for efficient queries
store.createIndex('version', 'version');
store.createIndex('timestamp', 'timestamp');
}
};
});
}
5.3. Automatic Cleanup Mechanism for Stale Data
Cleanup Process
// Remove expired data from IndexedDB
async function cleanupExpiredData() {
try {
const db = await initializeDatabase();
const transaction = db.transaction('data-store', 'readwrite');
const store = transaction.objectStore('data-store');
// Get all stored items
const request = store.getAll();
request.onsuccess = () => {
const items = request.result;
const now = Date.now();
let removedCount = 0;
// Check each item for expiration
items.forEach(item => {
const age = now - item.timestamp;
// Remove if older than cache duration
if (age > CACHE_DURATION.MEMORY) {
console.log(`Removing expired item: ${item.id}`);
store.delete(item.id);
removedCount++;
}
});
if (removedCount > 0) {
console.log(`Cleanup completed: removed ${removedCount} items`);
}
};
// Return a promise that resolves when transaction is complete
return new Promise((resolve, reject) => {
transaction.oncomplete = resolve;
transaction.onerror = () => reject(transaction.error);
});
} catch (error) {
console.error('Cleanup failed:', error);
}
}
5.4. Version Control with Hash Function
Version Hashing
// Generate a hash from data for version control
function generateDataHash(data) {
// Convert data to string
const str = JSON.stringify(data);
// Simple hash function
let hash = 0;
for (let i = 0; i < str.length; i++) {
const char = str.charCodeAt(i);
hash = ((hash << 5) - hash) + char;
hash = hash & hash; // Convert to 32-bit integer
}
// Return positive hex string
return Math.abs(hash).toString(16);
}
// Check if versions are different
function hasVersionChanged(oldVersion, newData) {
const newVersion = generateDataHash(newData);
return oldVersion !== newVersion;
}
5.5. Cache Handling Logic in React/Redux Application
Cache Flow Logic
// Example with Redux Saga
function* fetchDataWithCaching(action) {
// Step 1: Try memory cache first (fastest)
if (appDataCache.data && Date.now() - appDataCache.timestamp < CACHE_DURATION.MEMORY) {
console.log('Using memory cache');
// Return cached data immediately
yield put({ type: 'FETCH_DATA_SUCCESS', payload: appDataCache.data });
// Background revalidation (fetch in background)
const freshData = yield call(api.fetchData);
if (freshData && hasVersionChanged(appDataCache.version, freshData)) {
console.log('Updating cache with new version');
// Update the cache with new data
appDataCache.data = freshData;
appDataCache.version = generateDataHash(freshData);
appDataCache.timestamp = Date.now();
// Save to IndexedDB
yield call(saveToIndexedDB, 'app-data', freshData);
// Update UI with new data
yield put({ type: 'FETCH_DATA_SUCCESS', payload: freshData });
}
return; // Exit early
}
// Step 2: Try IndexedDB if memory cache missing/expired
try {
const cachedData = yield call(loadFromIndexedDB, 'app-data');
if (cachedData) {
console.log('Using IndexedDB cache');
// Update memory cache
appDataCache.data = cachedData.data;
appDataCache.version = cachedData.version;
appDataCache.timestamp = Date.now();
// Return cached data immediately
yield put({ type: 'FETCH_DATA_SUCCESS', payload: cachedData.data });
// Background revalidation
const freshData = yield call(api.fetchData);
if (freshData && hasVersionChanged(cachedData.version, freshData)) {
// Update caches with new data
appDataCache.data = freshData;
appDataCache.version = generateDataHash(freshData);
appDataCache.timestamp = Date.now();
// Save to IndexedDB
yield call(saveToIndexedDB, 'app-data', freshData);
// Update UI with new data
yield put({ type: 'FETCH_DATA_SUCCESS', payload: freshData });
}
return; // Exit early
}
} catch (error) {
console.error('Error loading from IndexedDB:', error);
}
// Step 3: No cache available, fetch from API
try {
console.log('Fetching from API');
yield put({ type: 'FETCH_DATA_LOADING' });
const freshData = yield call(api.fetchData);
if (freshData) {
// Update memory cache
appDataCache.data = freshData;
appDataCache.version = generateDataHash(freshData);
appDataCache.timestamp = Date.now();
// Save to IndexedDB
yield call(saveToIndexedDB, 'app-data', freshData);
// Update UI
yield put({ type: 'FETCH_DATA_SUCCESS', payload: freshData });
}
} catch (error) {
yield put({ type: 'FETCH_DATA_ERROR', error });
}
}
6. Mechanism of Operation
6.1. Data Request Processing Flow
Check Memory Cache:
If data exists and hasn’t expired (< 5 minutes) → Use immediately
Silently call API to check for new version
Check IndexedDB:
If memory cache doesn’t exist or has expired → Look in IndexedDB
If data exists and hasn’t expired (< 15 minutes) → Use and update memory cache
Silently call API to check for new version
Call API (if no cache or all have expired):
Use fetch with HTTP Cache-Control headers
Save results to both memory cache and IndexedDB
6.2. Background Revalidation
When data is served from cache, we still send a background request to the server to check if there’s a new version:
Calculate hash from current data
Compare with hash of new data
If different → Update cache and UI
Users aren’t interrupted during this process
6.3. Automatic Cleanup of Stale Data
Whenever data is accessed from IndexedDB, we run a cleanup process to remove expired data:
Scan all items in IndexedDB
Check timestamp of each item
Remove items that have exceeded cache time
7. Optimization Results
7.1. Performance Metrics Before and After Optimization
Metric
Before
After
Improvement
Load Time
1.82s
70.79ms
96.1% ⬇️
Data Volume
28.5 MB
3.0 MB
89.5% ⬇️
Request Count
674
533
20.9% ⬇️
TTFB
1.72s
61.23ms
96.4% ⬇️
Cache Hit Rate
0%
95%
95% ⬆️
7.2. Benefits
Significantly improved page load speed: 96.1% reduction in response time
Bandwidth savings: 89.5% reduction in data transfer
Smooth user experience: Data served immediately from cache
Reduced server load: 95% of requests served from cache
Offline functionality: Application can still function when connection is lost
7.3. Limitations
Data update delay: It can take up to 15 minutes for users to see the latest data
Complexity in version management: Requires a good version control mechanism
Debugging challenges: Cache can make debugging more complex
8. Future Improvements
8.1. Cache Partitioning
Divide cache into different parts based on the frequency of data changes:
Static data (changes by version): Long-term cache
Dynamic data (changes frequently): Short-term cache
8.2. Service Worker
Integrate Service Worker to:
Better control cache
Support complete offline functionality
Automatically update when there’s a new version
// Simple Service Worker registration
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/service-worker.js')
.then(registration => {
console.log('Service Worker registered with scope:', registration.scope);
})
.catch(error => {
console.error('Service Worker registration failed:', error);
});
});
}
// Basic service-worker.js example
const CACHE_NAME = 'app-cache-v1';
const URLS_TO_CACHE = [
'/',
'/index.html',
'/styles/main.css',
'/scripts/main.js',
'/api/static-data'
];
// Install event - cache critical assets
self.addEventListener('install', event => {
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => {
console.log('Opened cache');
return cache.addAll(URLS_TO_CACHE);
})
);
});
// Fetch event - serve from cache if available
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(response => {
// Cache hit - return response
if (response) {
return response;
}
// Clone the request
const fetchRequest = event.request.clone();
// Make network request and cache the response
return fetch(fetchRequest).then(response => {
// Check if valid response
if (!response || response.status !== 200 || response.type !== 'basic') {
return response;
}
// Clone the response
const responseToCache = response.clone();
// Open cache and store response
caches.open(CACHE_NAME)
.then(cache => {
cache.put(event.request, responseToCache);
});
return response;
});
})
);
});
Analyze data: Identify data types and change frequency
Design cache strategy: Define layers and lifetimes
Implement IndexedDB: Initialize DB, create object stores and indexes
Build cache logic: Implement storage, retrieval, and cleanup
Version control: Create hash mechanism to compare versions
Integrate with data flow: Apply in Redux saga or React hooks
9.3. Final Recommendations
Measure before and after: Always collect metrics before and after optimization to evaluate effectiveness
Consider tradeoffs: Balance between speed and data freshness
Prioritize UX: Always prioritize user experience, display data from cache first then update later
Start simple: Implement step by step, beginning with memory cache then gradually adding more complex layers
Handle errors well: Always have fallback mechanisms when cache fails
Performance optimization is a continuous journey, not a destination. By applying multi-layered caching strategies, you can significantly improve user experience and reduce load on your backend systems.
This article explores the core differences between Redux Thunk and Redux Saga, highlighting their strengths, weaknesses, and best use cases. Whether you’re building a small application or managing complex asynchronous workflows, understanding these middleware options will help you make the right choice for your Redux architecture.
An in-depth analysis of React 19’s new hooks from a 20-year veteran engineer’s perspective. Learn practical implementation strategies, best practices, and real-world use cases for use(), useFormState(), useFormStatus(), and useOptimistic() hooks.
