A Deep Dive into Browser Cache Keys Triggered by HTTP Strong Cache Failure

Author: Xu Sang

1. Introduction

In front-end development, performance optimization has always been a key focus. HTTP caching, as an important means to improve page loading speed, can significantly reduce network requests. However, while developing an image processing feature recently, I encountered a puzzling issue: even though the images were preloaded, they did not hit the strong cache during Canvas drawing, resulting in repeated requests. This seemingly simple problem led to a deeper reflection on the browser cache key mechanism.

2. Discovery of the Problem

Initial Scenario

While developing a product image processing feature, I adopted a common optimization strategy: preloading images in advance and then drawing them onto the Canvas for processing when needed. The code is roughly as follows:

// Preload image
function preloadImage(url) {
    const img = new Image();
    img.src = url;
    return new Promise((resolve) => {
        img.onload = () => resolve(img);
    });
}

// Use image in Canvas
function drawImageToCanvas(imageUrl) {
    const canvas = document.createElement('canvas');
    const ctx = canvas.getContext('2d');
    
    const img = new Image();
    img.crossOrigin = "anonymous"; // To avoid Canvas tainting
    img.src = imageUrl;
    
    img.onload = function() {
        ctx.drawImage(img, 0, 0);
        // Process image...
        const processedDataURL = canvas.toDataURL();
        return processedDataURL;
    };
}

Abnormal Phenomenon

Through the Network panel in Chrome DevTools, I discovered a strange phenomenon:

When the image was preloaded for the first time, the browser made a normal request and cached the image.
Subsequently, when drawing on the Canvas, the browser actually initiated another request for the same URL.
The second request returned200 OK instead of the expected200 (from cache)

This contradicts my understanding of HTTP strong caching. Logically, resources with the same URL should be fetched directly from the cache.

3. Problem Investigation Process

Initial Analysis

I first checked the cache headers returned by the server:

Cache-Control: public, max-age=31536000
Expires: Wed, 18 Sep 2026 07:28:00 GMT

The cache configuration was fine; the image should indeed be strongly cached for a year. So where was the problem?

Comparative Experiment

I conducted a simple comparative experiment:

// Experiment 1: No crossOrigin set
const img1 = new Image();
img1.src = "https://example.com/test-image.jpg";

// Experiment 2: crossOrigin set
const img2 = new Image();
img2.crossOrigin = "anonymous";
img2.src = "https://example.com/test-image.jpg";

By observing the Network panel, I found that:

img1 used the previous cache.
img2 initiated a new network request.

This indicates that thecrossOrigin attribute affects cache hits!

4. crossOrigin and Canvas Tainting

Why is crossOrigin needed?

Before delving into the cache key issue, let’s first understand why we need to setcrossOrigin = "anonymous". This involves an important concept in web security:Canvas Tainting.

What is Canvas Tainting?

Canvas tainting is a security mechanism in browsers. When a cross-origin resource (such as an image from another domain) is drawn onto a Canvas, the browser marks that Canvas as “tainted,” thereby restricting read operations on the Canvas data.

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

// Draw cross-origin image
const img = new Image();
img.src = 'https://other-domain.com/image.jpg';
img.onload = function() {
    ctx.drawImage(img, 0, 0); // Canvas is tainted
    
    try {
        const dataURL = canvas.toDataURL(); // Throws SecurityError
    } catch (e) {
        console.error('Canvas is tainted:', e);
    }
};

The Security Significance of Canvas Tainting

This mechanism prevents malicious websites from reading image data from other domains via Canvas:

// Potential security risk scenario
const img = new Image();
img.src = 'https://bank-website.com/user-avatar.jpg';
img.onload = function() {
    ctx.drawImage(img, 0, 0);
    
    // If there were no tainting mechanism, a malicious site could:
    const imageData = ctx.getImageData(0, 0, 100, 100);
    // Analyze pixel data, potentially obtaining sensitive information
};

Resolving Canvas Tainting

SettingcrossOrigin = "anonymous" can resolve this issue, provided the server supports CORS:

const img = new Image();
img.crossOrigin = "anonymous";
img.src = 'https://other-domain.com/image.jpg';
img.onload = function() {
    ctx.drawImage(img, 0, 0);
    const dataURL = canvas.toDataURL(); // Success!
};

The server needs to return appropriate CORS headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS

5. Browser Cache Key Mechanism

Concept of Cache Key

Returning to our core issue: why does settingcrossOrigin prevent cache hits?

This involves the browser’sCache Key mechanism. A cache key is a unique identifier generated by the browser for each cache entry, used to determine whether a matching cache exists.

Components of Cache Key

The browser’s cache key typically consists of the following elements:

1. URL (most important)

// These will be considered different cache entries
https://example.com/image.jpg
https://example.com/image.jpg?v=1.0
https://example.com/image.jpg?v=2.0

2. HTTP Method

GET https://api.example.com/data
POST https://api.example.com/data  // Different cache entries

3. Request Headers (specified by Vary response header)

// Server response
Vary: Accept-Encoding, User-Agent

// Different Accept-Encoding will produce different cache keys
Accept-Encoding: gzip
Accept-Encoding: br

4. CORS-related Attributes

// This is the key to our problem!
const img1 = new Image();
img1.src = "https://example.com/image.jpg";  // Cache Key A

const img2 = new Image();
img2.crossOrigin = "anonymous";
img2.src = "https://example.com/image.jpg";  // Cache Key B (different!)

Why does crossOrigin affect the cache key?

When thecrossOrigin attribute is set, the browser sends different request headers, which may lead to:

Change in request nature: from a simple request to a CORS request.
Different request headers: may include theOrigin header.
Differences in caching strategy: the browser may adopt different caching strategies.

6. In-Depth Exploration: Factors Affecting Cache Key

Through this problem investigation, I further researched which factors could affect the browser’s cache key:

1. Subtle Differences in URL

// Every subtle difference in URL will produce different cache keys
const urls = [
    'https://example.com/api/data',
    'https://example.com/api/data/',        // Trailing slash
    'https://example.com/api/data?',        // Empty query parameter
    'https://example.com/api/data#section', // Fragment is usually ignored
    'https://example.com/api/data?a=1&amp;b=2',
    'https://example.com/api/data?b=2&amp;a=1', // Different parameter order
];

2. Protocol and Port

// Different protocols or ports will produce different cache keys
http://example.com/image.jpg
https://example.com/image.jpg      // Different cache keys
https://example.com:8080/image.jpg // Different cache keys

3. Impact of Vary Response Header

// Server settings
app.get('/api/data', (req, res) => {
    res.set('Vary', 'Accept-Language, Accept-Encoding');
    res.set('Cache-Control', 'max-age=3600');
    // ...
});

// Client - Different header values will produce different cache keys
fetch('/api/data', {
    headers: { 
        'Accept-Language': 'zh-CN',
        'Accept-Encoding': 'gzip'
    }
});

fetch('/api/data', {
    headers: { 
        'Accept-Language': 'en-US',  // Different language
        'Accept-Encoding': 'gzip'
    }
});

4. Request Mode and Credentials

// Different fetch configurations may produce different cache keys
fetch('/api/data', { mode: 'cors' });
fetch('/api/data', { mode: 'no-cors' });
fetch('/api/data', { credentials: 'include' });
fetch('/api/data', { credentials: 'omit' });

7. Solutions and Best Practices

1. Unified crossOrigin Settings

To avoid inconsistencies in cache keys, we should maintain consistentcrossOrigin settings throughout the application:

// Encapsulate image loading function
function loadImage(src, needsCORS = false) {
    const img = new Image();
    if (needsCORS) {
        img.crossOrigin = 'anonymous';
    }
    img.src = src;
    return img;
}

// Set crossOrigin during preloading
function preloadImagesForCanvas(urls) {
    return Promise.all(
        urls.map(url => new Promise((resolve) => {
            const img = loadImage(url, true); // Unified crossOrigin setting
            img.onload = () => resolve(img);
        }))
    );
}

2. Standardizing Cache Keys

For API requests, we can standardize parameters to ensure cache key consistency:

// Standardize query parameters
function normalizeParams(params) {
    return Object.keys(params)
        .sort()
        .reduce((result, key) => {
            if (params[key] !== undefined &amp;&amp; params[key] !== '') {
                result[key] = params[key];
            }
            return result;
        }, {});
}

// Use standardized parameters
const fetchData = (params) => {
    const normalized = normalizeParams(params);
    const queryString = new URLSearchParams(normalized).toString();
    return fetch(`/api/data?${queryString}`);
};

3. Server-Side Optimization

Set the Vary header reasonably to avoid excessive cache segmentation:

app.get('/api/images/*', (req, res) => {
    // Only set Vary for headers that truly affect response content
    res.set('Vary', 'Accept'); // ✅ Reasonable
    // res.set('Vary', 'User-Agent'); // ❌ Overly segmented
    
    res.set('Cache-Control', 'public, max-age=31536000');
    res.set('Access-Control-Allow-Origin', '*'); // Support CORS
    
    // Return image...
});

4. Cache Strategy Design

Design different caching strategies based on resource types:

// Static resources: long-term cache + filename hash
const staticAssets = {
    'app.js': 'app.abc123.js',
    'style.css': 'style.def456.css'
};

// API data: short-term cache or negotiated cache
fetch('/api/user-info', {
    headers: {
       'Cache-Control': 'max-age=300'// 5 minutes cache
    }
});

// Image resources: consider Canvas usage scenarios
const loadImageForCanvas = (url) => {
    const img = new Image();
    img.crossOrigin = 'anonymous'; // Pre-set CORS
    img.src = url;
    return img;
};

8. Debugging and Monitoring

1. Developer Tools Usage Tips

// Detect cache behavior in the console
const testCache = async (url1, url2) => {
    console.time('Request 1');
    await fetch(url1);
    console.timeEnd('Request 1');
    
    console.time('Request 2');
    await fetch(url2);
    console.timeEnd('Request 2');
};

// Check if cache hit
testCache('/api/data?v=1', '/api/data?v=1');

2. Cache Key Visualization

// Simplified cache key generation logic (for understanding)
function generateCacheKey(url, options = {}) {
    const { method = 'GET', headers = {}, cors = false } = options;
    
    let key = `${method}:${url}`;
    
    if (cors) {
        key += ':CORS';
    }
    
    // Add headers that affect caching
    const varyHeaders = ['Accept-Language', 'Accept-Encoding'];
    const headerParts = varyHeaders
        .filter(header =&gt; headers[header])
        .map(header =&gt;`${header}:${headers[header]}`);
    
    if (headerParts.length > 0) {
        key += `|${headerParts.join('|')}`;
    }
    
    return key;
}

// Usage example
console.log(generateCacheKey('https://example.com/image.jpg'));
// Output: GET:https://example.com/image.jpg

console.log(generateCacheKey('https://example.com/image.jpg', { cors: true }));
// Output: GET:https://example.com/image.jpg:CORS

9. Performance Impact Analysis

Cost of Cache Failure

Through this issue, I realized the performance impact of inconsistent cache keys:

// Measure the impact of cache failure
const measureCacheImpact = async () => {
    const imageUrl = 'https://example.com/large-image.jpg';
    
    // First load (preload)
    console.time('Preload');
    const img1 = new Image();
    img1.src = imageUrl;
    await new Promise(resolve => img1.onload = resolve);
    console.timeEnd('Preload'); // Possible output: Preload: 500ms
    
    // Second load (Canvas usage, with crossOrigin set)
    console.time('Canvas Load');
    const img2 = new Image();
    img2.crossOrigin = 'anonymous';
    img2.src = imageUrl;
    await new Promise(resolve => img2.onload = resolve);
    console.timeEnd('Canvas Load'); // Possible output: Canvas Load: 480ms (cache not hit!)
};

For large images or slower networks, the impact of this repeated request will be even more pronounced.

10. Conclusion and Reflection

This cache issue triggered by thecrossOrigin attribute has given me a deeper understanding of the browser caching mechanism:

Key Takeaways

Complexity of Cache Keys: Browser cache keys are not just URLs; they also include request methods, specific headers, CORS attributes, and more.
Necessity of Canvas Tainting: AlthoughcrossOrigin affects caching, it is an important safeguard for web security and should not be simply removed.
Importance of Consistency: Maintaining consistent request configurations throughout the application can maximize caching effectiveness.
Balancing Performance and Security: It is necessary to find a balance between caching performance and security.

Summary of Best Practices

Plan Ahead: Consider which resources need Canvas processing during the design phase and set crossOrigin uniformly.
Parameter Standardization: Sort and filter URL parameters to ensure cache key consistency.
Server Configuration: Set CORS and Vary headers reasonably to support front-end caching strategies.
Monitoring and Debugging: Use developer tools to monitor cache hits and identify issues promptly.

Future Considerations

As web technologies evolve, browser caching mechanisms are also continuously evolving. New technologies like Service Workers and HTTP/3 provide more possibilities for cache control. As front-end developers, we need to keep learning and adapting to these changes, continuously optimizing application performance while ensuring functionality correctness.

This problem investigation process reminds me that seemingly simple caching issues often hide complex mechanisms. Only by deeply understanding these mechanisms can we write more efficient and reliable code.

This article documents a real problem investigation process and hopes to help developers encountering similar issues. If you have any questions or additions, feel free to discuss in the comments.