Upcoming change to Cloudflare Pages projects

[jrf0110]

Describe the problem

👋

Hi there. John here from the Cloudflare Pages team.

When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions.

This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency.

Describe the proposed solution

The Cloudflare Pages team has been rolling out support to customize how project Functions are mounted and thus can save money and latency by providing this metadata on build. The @sveltejs/adapter-cloudflare package should expose a set of includes and excludes based on static files generated. For the time being, I suggest we be conservative and include the Functions worker on all routes but exclude on /_app/immutable/.

If the SvelteKit user uses the hooks functionality, they may need to tune these patterns manually on a case-by-case basis.

Alternatives considered

No response

Importance

nice to have

Additional Information

We (the Cloudflare Pages team) will be contributing the relevant changes.

[Rich-Harris]

Thank you for the heads up and the forthcoming contribution!

If the SvelteKit user uses the hooks functionality, they may need to tune these patterns manually on a case-by-case basis.

Just to clarify, hooks only apply to routes, not to static assets, so it's safe to bypass the worker for everything that matches the contents of static, and everything in config.kit.appDir (which defaults to _app) as long as it's still possible to configure the relevant cache headers.

[jrf0110]

hooks only apply to routes, not to static assets

Ah that makes things much easier. Thank you. ❤️

as long as it's still possible to configure the relevant cache headers.

Indeed. We'll do that sort of statically via the _headers file. I say sort of statically because we do need to interpolate config.kit.appDir

it's safe to bypass the worker for everything that matches the contents of static

For now, we're going to be fairly conservative with this, matching only static assets that look like a favicon. The reason being that there may be content in that directory that the user does intend to run through functions (e.g. for gating access to a sensitive document). We may walk back on this in the future, but I think it's better to be conservative and not potentially break a deployment.

I'll have a PR ready soon.