Skip to main content

ButterCMS CDN infrastructure

ButterCMS has served more than a billion requests. The decoupling of the frontend from the heavy backend makes ButterCMS inherently faster than traditional CMSs. The content API traffic is served through Fastly, a reliable and quick content delivery platform. Your media assets are stored and delivered via Amazon CloudFront, a low-latency CDN.

Dual CDN architecture

ButterCMS employs a strategic dual-CDN approach:
Content TypeCDN ProviderOptimization
API Responses (JSON)FastlyEdge caching, low latency
Media AssetsAmazon CloudFrontImage optimization, global distribution

How CDN caching works

Content delivery operates through a global CDN with 150+ edge locations. Read operations are cached for 20 days at edge locations by default, providing sub-100ms response times for cached content worldwide.

Cache behavior

  • Initial requests fetch content from the API and populate edge caches (~200-500ms)
  • Subsequent requests serve from the nearest location (~50-100ms)
  • Content updates automatically invalidate relevant cache entries globally

Response time comparison

ScenarioResponse TimeNotes
Cache hit (edge)50-100msContent served from nearest CDN location
Cache miss (origin)200-500msContent fetched from origin, then cached
Without CDN500-2000msDirect origin requests from distant locations

Global edge locations

With third-party CDN caching, you can ensure that the same cache is served around the world irrespective of country or region. CDNs improve website performance by cascading data to locations closer to the user.

Edge location benefits

Reduced Latency

Content is served from the geographically nearest location to each user

High Availability

Multiple edge nodes provide redundancy and failover capabilities

Bandwidth Savings

Origin servers handle fewer requests, reducing bandwidth costs

DDoS Protection

CDN absorbs and mitigates distributed attacks

Media delivery optimization

Image CDN features

ButterCMS media assets are delivered through CloudFront with automatic optimizations: Automatic Features:
  • WebP Conversion - Modern browsers receive WebP format automatically
  • Compression - Images are compressed without visible quality loss
  • Lazy Loading Support - URL-based transformations support progressive image loading (requires client-side implementation)
URL Transformations: You can transform images on-the-fly using URL parameters:
https://cdn.buttercms.com/[file-handle]

# Resize to 800px width
https://cdn.buttercms.com/resize=width:800/[file-handle]

# Crop to 400x300
https://cdn.buttercms.com/resize=width:400,height:300,fit:crop/[file-handle]

# Convert to WebP with quality 80
https://cdn.buttercms.com/output=format:webp,quality:80/[file-handle]

Responsive image example

<!-- Responsive images with srcset -->
<img
  src="https://cdn.buttercms.com/resize=width:800/abc123"
  srcset="
    https://cdn.buttercms.com/resize=width:400/abc123 400w,
    https://cdn.buttercms.com/resize=width:800/abc123 800w,
    https://cdn.buttercms.com/resize=width:1200/abc123 1200w
  "
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  alt="Responsive image"
  loading="lazy"
/>

Cache invalidation

Content changes (create, update, delete, and status changes) trigger multi-layer cache invalidation including:
  1. Object cache - Individual cached items
  2. Serialized response cache - Pre-built API responses
  3. Global CDN cache - All edge location caches
Referenced content invalidation cascades automatically - when a referenced object changes, all content that references it also gets invalidated to maintain consistency.

Invalidation flow

Best practices for CDN performance

Smaller payloads cache more efficiently and transfer faster from edge locations. See:
Resize images server-side instead of client-side:
// Good - serve appropriately sized images
<img src="https://cdn.buttercms.com/resize=width:400/abc123" />

// Avoid - downloading full-size then scaling
<img src="https://cdn.buttercms.com/abc123" style={{width: '400px'}} />
When implementing your own caching layer:
// Set cache headers for static content
res.setHeader('Cache-Control', 'public, max-age=3600'); // 1 hour

// For frequently changing content
res.setHeader('Cache-Control', 'public, max-age=60, stale-while-revalidate=300');
Track CDN effectiveness:
  • Cache hit ratio - Should be >90% for static content
  • Edge response times - Should be <100ms for cached content
  • Origin requests - Monitor for unexpected spikes

Security at the CDN level

DDoS protection

Distributed Denial of Service (DDoS) attacks can bring the whole application down if the architecture is not designed to prevent such a situation. ButterCMS protects users at the CDN level and also with load balancers and through AWS Shield. As your application becomes more popular, it can gain more attention from people with bad intentions. Applications based on a traditional monolithic architecture may be easily affected by DDoS attacks. With ButterCMS, your content is protected and will be available without interruptions thanks to modern cloud architectures.

Data security

ButterCMS handles all aspects of security. The data centers used for storing and delivering your content are all ISO-27001 compliant. Your data is encrypted at rest using AES-256, and all API traffic is encrypted in transit using TLS 1.2+.

Regional content delivery

How regional routing works

When a user requests content:
  1. DNS Resolution - Request is routed to nearest edge location
  2. Edge Check - CDN checks if content is cached at that edge
  3. Cache Hit - Cached content served immediately (~50-100ms)
  4. Cache Miss - Request forwarded to origin, response cached at edge

Performance by region

RegionTypical Cache Hit ResponseEdge Locations
North America30-80ms40+
Europe40-90ms30+
Asia Pacific50-100ms25+
South America60-120ms10+
Middle East/Africa70-130ms10+