Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚀 Feature Request: Enable caching for assets binding #7650

Open
rdlogout opened this issue Dec 31, 2024 · 3 comments
Open

🚀 Feature Request: Enable caching for assets binding #7650

rdlogout opened this issue Dec 31, 2024 · 3 comments
Labels
enhancement New feature or request Workers + Assets

Comments

@rdlogout
Copy link

Describe the solution

Hi,

I have been using cloudflare pages for my frontend.
Recently i tried to migrate it to worker new asset binding.

But i noticed the site become little slow, when i looked for the cause i found the CF Pages app respect _header and return response with cache
image
but when i tested a skelton app with worker.dev asset binding it return
image

Can u allow _header file in worker asset binding too, it will solve the performance issue.

Thank you

@rdlogout rdlogout added the enhancement New feature or request label Dec 31, 2024
@github-project-automation github-project-automation bot moved this to Untriaged in workers-sdk Dec 31, 2024
@WillTaylorDev
Copy link
Contributor

(As an aside, and I know it's not what you're asking for here-- you could use a experimental_serve_directly=false along with a worker to dynamically fetch your assets. You then could modify the cache-control header yourself before sending the response back. The downside to this is that worker invocations count towards chargeable requests (but might work for smaller sites)).

@rdlogout
Copy link
Author

rdlogout commented Jan 8, 2025

(As an aside, and I know it's not what you're asking for here-- you could use a experimental_serve_directly=false along with a worker to dynamically fetch your assets. You then could modify the cache-control header yourself before sending the response back. The downside to this is that worker invocations count towards chargeable requests (but might work for smaller sites)).

Yes i tried that but as u mentioned it count as invocation and its not ideal for my use case where we have thousands js chunks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Workers + Assets
Projects
None yet
Development

No branches or pull requests

3 participants