Offloading static assets to a CDNfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Offloading static assets to a CDN
Last updated :  
11.x , 10.x , 9.x , 8.x

You already configured CDN delivery for CSS/JS/images back in the Asset Management section — that lesson was about delivery speed for the visitor. This lesson is about the same technique from the opposite angle: every request a CDN serves from its edge cache is a request your origin server never has to handle at all, directly reducing the CPU, memory, and disk I/O load you just spent this whole section tuning.

What you'll learn in this lesson

  • Why "CDN for speed" and "CDN for origin relief" are the same config, different motivations
  • How to estimate how much origin load a CDN actually removes
  • What still has to hit your origin no matter what

The same setting, a different reason to care

If you already set up file_public_base_url or the CDN module (from the Asset Management section), you've already done the technical work this lesson is about — nothing new to configure. What's worth understanding now is the capacity-planning side: every one of the thousands of image, CSS, and JS requests a busy page generates is a request your PHP-FPM workers and database never see, because the CDN's edge server answered it directly.

Estimating the actual origin relief

# Compare total requests vs. requests that actually reach your app.
# Web server access log, filtered to non-static paths:
grep -v -E '\.(css|js|jpg|jpeg|png|webp|svg|woff2?)$' access.log | wc -l
# vs total:
wc -l access.log

On a typical content-heavy site, static assets often outnumber dynamic page requests by 5-10x. Offloading all of that to a CDN can mean your origin server only ever sees a small fraction of total site traffic — which is exactly why this lesson sits in "Server-Side Optimization" even though the underlying config lives in the Asset Management section.

What a CDN can never take off your origin's plate: the actual HTML response for every page view still has to be generated by Drupal (or served from Varnish, per the earlier lesson) — a CDN caching your assets does nothing for that. Don't mistake "static asset offload" for "full-page offload"; they're complementary techniques covered in different lessons, not the same thing.

Quick check: your access logs show 100,000 requests/day, of which 85,000 are for CSS/JS/images. After correctly configuring a CDN for those assets, roughly how many requests should your origin server actually need to handle per day? If you said around 15,000 — the dynamic-page portion, since the static 85,000 now go to CDN edge servers instead — you've understood exactly what this lesson adds on top of the earlier CDN-for-speed lesson.

Key takeaways

  • CDN configuration for static assets serves two purposes at once: faster delivery to visitors, and reduced load on your origin server.
  • Static assets typically outnumber dynamic page requests by a wide margin — offloading them can dramatically shrink your origin's real traffic.
  • A CDN never reduces the cost of generating dynamic HTML itself — that still needs Drupal (or a full-page cache like Varnish) regardless of CDN configuration.
  • Measure your own site's static-vs-dynamic request ratio from real access logs rather than assuming a generic number.

Coming up next

You've now covered the complete server-side optimization toolkit. Next, we shift focus to a different kind of load entirely: making sure your cron jobs and queued background tasks run efficiently without competing with real visitor traffic.