CDN for static sites
Static files still need a global edge.
A static site in one bucket or VM is still one origin. HTML, images and JS should be copied out to 210+ locations, not fetched from a single region on every view.
Use the static host as a Cloud CDN origin. Long-cache fingerprinted assets, purge HTML on deploy, and terminate TLS at the edge.
Why teams use Aptranet
What CDN for static sites looks like on this network.
Cloud CDN caches and accelerates eligible content on 210+ points of presence, with Origin Shield when the origin must stay out of the way.
Every object next to the reader
210+ PoPs, 30 ms average latency and HTTP/3 for HTML and assets.
Deploy, then purge
CI invalidates HTML so new builds are live without waiting on TTL.
The bucket is not public
Visitors hit Cloud CDN. Origin pull, TLS and DDoS mitigation sit in front.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud CDN configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Put the static files on an HTTPS origin
A files host or static origin that Cloud CDN can pull.
- 2Cache by file type
Long TTL for hashed JS/CSS. Purgeable TTL for HTML.
- 3Add purge to CI
After each publish, purge HTML and any unhashed paths.
- 4Map the site domain
Attach a managed or custom certificate and cut over DNS.
Outcomes
What changes once the hostname is on Aptranet.
- Static sites are served from 210+ PoPs
- HTML can be purged on every build
- The origin only answers misses
- TLS and DDoS sit at the edge
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
Hugo, Astro, Eleventy, Jekyll, Vite static builds and any other HTML output. The CDN caches files, not the generator.
Yes when you want independent purge, logs, image optimization or a multi-CDN design.
Configure the origin to return a 404 page. Cloud CDN will cache that according to policy.
Yes. Cloud CDN supports Brotli and Gzip for eligible text assets.