CDN for websites
Every website still has an origin. Visitors should not.
Corporate, content and marketing websites repeat the same HTML, CSS, JS and images. Serving them from one hosting account makes every foreign visitor wait on that account.
Put Cloud CDN in front of the site hostname. Cache assets aggressively and HTML with purge. Keep forms, previews and admin on the origin.
Why teams use Aptranet
What CDN for websites 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.
Pages from 210+ PoPs
30 ms average worldwide latency for cached HTML and assets.
TLS 1.3 and DDoS on the public name
Visitors terminate at the edge. The origin is no longer the public path.
Publish, then purge
CMS updates can invalidate HTML without waiting on a long TTL.
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.
- 1Connect the existing website origin
Pull the current host over HTTPS.
- 2Cache static files first
CSS, JS, fonts and images, then HTML.
- 3Bypass admin and forms
POSTs and CMS editors must reach origin.
- 4Cut over DNS
Attach a certificate and point the site domain at Cloud CDN.
Outcomes
What changes once the hostname is on Aptranet.
- Public websites are served from the edge
- Admin and forms remain dynamic
- TLS and DDoS sit on the hostname
- CMS publish can purge HTML
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
If the host can be pulled over HTTPS, yes. Cloud CDN does not require you to move the CMS.
Yes. Map the existing hostname and use a managed or custom certificate.
Form POSTs bypass cache and reach the origin or form handler.
No. Dynamic websites can still cache assets and anonymous HTML. See WordPress, PHP and web applications.