Web Performance Optimization: Core Web Vitals and Beyond

Here's something most performance guides won't tell you: aggressive optimization can introduce serious security vulnerabilities. I've audited sites where performance "improvements" created XSS vulnerabilities, exposed sensitive data through caching, and opened timing attack vectors. The rush to optimize often bypasses security reviews, and that's dangerous.

Content Delivery Networks (CDNs) are a perfect example. Everyone knows CDNs improve performance by caching content closer to users. But here's what happens in practice: developers cache everything including authenticated API responses, session data, and user-specific content. I've personally seen a major e-commerce site accidentally cache user account pages on their CDN, exposing customer data to anyone who visited the same URL. One user's order history, payment methods, and personal information was served to random visitors for hours before someone noticed.

The problem compounds with shared caching. When you use a public CDN like Cloudflare or CloudFront, your content sits on servers shared with thousands of other sites. Misconfigure your cache headers, and sensitive data becomes accessible not just to your users but potentially to anyone probing the CDN. Cache poisoning attacks exploit this - attackers inject malicious content into the CDN cache, and suddenly you're serving malware from your "trusted" domain.

Lazy loading and code splitting introduce their own risks. When you dynamically import JavaScript, you're loading code from a URL at runtime. If an attacker compromises your CDN or performs a man-in-the-middle attack, they can inject malicious code into those dynamic imports. Your users trust your domain, so their browsers execute the malicious code without question. Subresource Integrity (SRI) tags don't work with dynamic imports, leaving you vulnerable.

CDN Security: What You Must Do

First, understand that CDN caching is not content-aware. The CDN doesn't know if a response contains sensitive data - it just follows your Cache-Control headers blindly. You must explicitly tell the CDN what's safe to cache and what's not:

// NEVER cache authenticated responses
app.use((req, res, next) => {
  if (req.headers.authorization || req.cookies.session) {
    // Explicitly prevent caching
    res.set('Cache-Control', 'private, no-cache, no-store, must-revalidate');
    res.set('Pragma', 'no-cache');
    res.set('Expires', '0');
  }
  next();
});

// Safe caching for public assets only
app.use('/public', (req, res, next) => {
  res.set('Cache-Control', 'public, max-age=31536000, immutable');
  next();
});

// Vary header for user-specific content
app.get('/api/user/preferences', (req, res) => {
  // Tell CDN this varies by Cookie
  res.set('Vary', 'Cookie, Authorization');
  res.set('Cache-Control', 'private, max-age=300');
  // Now CDN caches separately per user
  res.json(getUserPreferences(req.user.id));
});

Timing Attacks: The Hidden Danger

Performance optimizations make timing attacks easier. When you cache database queries, the response time difference between cached and uncached requests reveals whether data exists. Attackers use this to enumerate users, guess email addresses, or map your database structure. I've seen systems where checking if a username exists took 500ms (database lookup) versus 5ms (cache hit). Attackers scripted this to enumerate millions of valid usernames in hours.

// VULNERABLE: Timing reveals if user exists
app.post('/api/check-username', async (req, res) => {
  const user = await db.users.findOne({
    username: req.body.username
  });

  if (user) {
    return res.json({ available: false }); // Fast response
  }

  return res.json({ available: true }); // Slow response reveals it doesn't exist
});

// SECURE: Constant-time responses
app.post('/api/check-username', async (req, res) => {
  const startTime = Date.now();

  const user = await db.users.findOne({
    username: req.body.username
  });

  // Always take minimum 200ms
  const elapsed = Date.now() - startTime;
  if (elapsed < 200) {
    await sleep(200 - elapsed);
  }

  return res.json({ available: !user });
});

Content Security Policy for Performance Assets

When you load scripts from CDNs for performance, you must restrict where scripts can come from. Without CSP, an attacker who compromises any script on your page can inject additional malicious scripts:

// Strict CSP that allows performance optimizations safely
app.use((req, res, next) => {
  res.set('Content-Security-Policy', [
    "default-src 'self'",
    "script-src 'self' https://cdn.trusted.com", // Only trusted CDN
    "style-src 'self' https://cdn.trusted.com 'unsafe-inline'",
    "img-src 'self' data: https:", // Allow optimized images
    "connect-src 'self' https://api.yoursite.com",
    "frame-ancestors 'none'",
    "base-uri 'self'",
    "form-action 'self'"
  ].join('; '));
  next();
});

// Use Subresource Integrity for external scripts
<script
  src="https://cdn.trusted.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
  crossorigin="anonymous"
></script>

Performance and security aren't opposites - they're complementary when done right. But you can't bolt on security after optimizing. Every caching decision, every CDN configuration, every dynamic import needs security review. The fastest site is useless if it's leaking user data or serving malware. Test your cache headers, implement CSP, use SRI tags, and always assume your CDN could be compromised. Defense in depth matters for performance infrastructure just as much as application code.