CDN Support

[highhi]

It would be useful to have an option to change the reference to the assets to a CDN host.
For ex.

# before
<link rel="stylesheet" href="/_astro/foo.css">

#after
<link rel="stylesheet" href="https://cdn.example.com/assets/foo.css">

Nuxt and Next allow that.

Nuxt
https://nuxtjs.org/docs/configuration-glossary/configuration-build/#publicpath

Next
https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

[matthewp]

Would you want this to be the same for all URLs? Also, is this because you are hosting your site on a different subdomain as your assets?

[highhi]

Also, is this because you are hosting your site on a different subdomain as your assets?

Yes.

Several applications I am currently developing have separate hosts for sites and assets.

This is a very effective way to safely the CDN cache.

Usually, assets have hash values in their filenames due to cache busters, which allows for long term caching. However, caching html and other files must be carefully determined.

Therefore, only assets may be delivered from a CDN.

[highhi]

The same seems to be possible with the svelte kit
https://kit.svelte.jp/docs/configuration#paths

[ZebraFlesh]

Would you want this to be the same for all URLs?

It should be the same for all asset URLs, but not link URLs (so <base> tag is not a viable solution).

Also, is this because you are hosting your site on a different subdomain as your assets?

We use an entirely different domain for our assets: our existing site is "mature", so it's unclear what might break if throw a bunch of optimization switches. The solution was to create a new CDN domain with all of the optimizations built in and serve assets from there.

Additionally, we deliver each of our Astro applications separately to our CDN. For sanity, each app goes into its own folder. Given how Astro currently builds the /_astro folder, it is not possible to achieve this separation (short of writing an integration or some post-processings scripts). Sometimes applications are in different domains, so they're owned by different teams -- that implies a much stronger need for separation because Team A should not be touching Team B's application.

[morriq]

+1 for this or astro could set some cache-policy/expires/max-age on assets in public directory. currently cloudflare cache always shows EXPIRED because files in public directory have max-age=0:

curl -I localhost:3000/favicon.svg

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=0 <------- 💩
Last-Modified: Thu, 09 Feb 2023 20:49:00 GMT
ETag: W/"588-18637f04a60"
Content-Type: image/svg+xml
Content-Length: 1416
Date: Thu, 09 Feb 2023 20:57:00 GMT
Connection: keep-alive
Keep-Alive: timeout=5

[edv-ns]

I have been using astrojs/node as a middleware, and wrapped with a custom server configuration. We have just migrated to fastify (I have also added minimal example to docs https://docs.astro.build/en/guides/integrations-guide/node/#middleware)

Additionally static files serving in the server configuration, I have added the caching headers too:

await app.register(fastifyStatic, {
  root: fileURLToPath(new URL('./dist/client', import.meta.url)),
  setHeaders(res) {
    res.setHeader('Cache-Control', 'max-age=31536000,immutable');
  },
});

Since static pablic/ contents ends up in dist this should do the trick.

[wangxiao95]

I also encountered the same problem. The purpose of this is to reduce the pressure of the main service and transfer the requests of static resources to the CDN server. This is a very common solution in a large traffic website. VITEThe base option originally supported a complete HTTPS link, but the settings in ASTRO are invalid, and there is no entrance to solve this problem

[wangxiao95]

I also encountered the same problem. The purpose of this is to reduce the pressure of the main service and transfer the requests of static resources to the CDN server. This is a very common solution in a large traffic website. VITEThe base option originally supported a complete HTTPS link, but the settings in ASTRO are invalid, and there is no entrance to solve this problem

Even if I set up a complete https link, such as: "https: mycdn.com", Astro will turn it into "/https:mycdn.com"

[dmitriy-savranskiy-igotanoffer]

The same problem for me. In our case, we're slowly migrating from the existing app to Astro. We have configured NGINX so some URLs point to our old app (Django) and other URLs are just static serving of the Astro. We can't host the Astro app on a CDN entirely because we want the same domain for both types of URLs.

[yanni4night]

Require this feature to deploy more applications.

[bluwy]

We have discussed and accepted the proposal! Thanks everyone for chiming in to give feedback and presented the usecase.

This has been moved to stage 2 at #534

[highhi]

thunks!

[yoyo837]

Require this feature to deploy css, js, img... to cdn server.

When visiting https://mysite.com/index.html, index.html request with other resources hopefully from cdn server, not fromhttps://mycdn.com

[yoyo837]

I found this https://docs.astro.build/en/reference/configuration-reference/#buildassetsprefix. It is works.