CDN for SvelteKit
SvelteKit prerender is better with a global cache.
SvelteKit apps mix prerendered pages, hashed client files and optional SSR. A single adapter origin should not be the only copy of that output.
Cache _app assets with long TTLs. Cache prerendered and anonymous SSR pages at Cloud CDN. Bypass form actions and session-specific routes.
Why teams use Aptranet
What CDN for SvelteKit 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.
Client assets at every PoP
Hashed _app files are served with 30 ms average latency.
Prerendered HTML at the edge
Static SvelteKit routes are an ideal CDN cache.
Actions stay on the origin
Form actions and authenticated load functions bypass cache.
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 SvelteKit adapter origin
Pull Node, static or other adapter output over HTTPS.
- 2Cache _app and prerendered routes
Long TTL for hashed files. Purgeable TTL for HTML.
- 3Bypass actions and private loads
Do not cache POST actions or cookie-varying pages.
- 4Purge on deploy
Invalidate HTML after each production adapter deploy.
Outcomes
What changes once the hostname is on Aptranet.
- SvelteKit assets are cached globally
- Prerendered pages live at the edge
- Form actions remain dynamic
- Deploys purge HTML
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
Yes. Static output is a natural Cloud CDN origin.
Only public GET endpoints. Mutations and authenticated JSON must bypass cache.
Pick one canonical URL shape and cache that. Avoid duplicating the same page under two keys.
Yes when many edges miss the same SSR route at once after a deploy or TTL expiry.