Around 2x faster

From KV

Normal Cloudflare Page

Note that for KV I'm also using Cache API

I though it would be a lot slower as it needs to perform extra commands.

Pages also stores assets in KV, and there’s probably more overhead covering edge-cases than in your specific code. It’ll probably be marginal though if you do more conclusive tests with 100 or more tries.

A nuxt3 project deployed through cloudflare pages functions sometimes fails to retrieve static assets only from the main page. -> 404 not found If you look carefully at the capture screen, the path of entry called by HTML and entry called by browser are different. What should I do to solve this problem? I am not using the service worker on the client because of this problem.

Do you by any chance have caching enabled on the zone? It could have cached a 404 on the route before it was deployed - if you use SSR for the page, then retrieve the js&css as static assets in the browser, the worker could have been updated, while the static assets are somehow cached to be all 404 - the two different hashes as the css and the js for entry, if you look at the first and the last row.

Yes, the error service is a subdomain and the root domain is using caching. So, if you try bypassing the cache by adding a page rule and performing a cache purge, the previous HTML results are still often returned.

and this screenshot is response header

As a result of my checking, it is the following phenomenon. Sometimes the previously distributed HTML is answered and requests the address of the script that has already been removed. So the page is also empty, no CSS, no script, or 404. However, it returns multiple versions of HTML instead of one previous version of html. So I tried removing both cache purge and pages deployment version, but the problem was still the same.

But the interesting fact is that there is no problem if you go through the other route. ex) /posts, /posts/1 ... This phenomenon occurs only in the root path, index.html.

Also, I am saying that the same problem still appears even if the development mode is enabled in the cache configuration. This seems like Cloudflare is responding to the wrong version at the edge, not the cache. Or, I think that the function of cache setting or cache deletion may not actually work, or cloudflare pages may not be normal.

I've got a solution. I just tried, and it worked. This stupid cloudflare pages functions cache purge doesn't work, so if you delete the project altogether and recreate it, it works very well I don't want to use it already because I think about deleting and re-creating the project every time I distribute it.

Hi friends, has anyone been able to use service bindings with pages? Running this command

npx -y https://prerelease-registry.developers.workers.dev/runs/3446839001/npm-package-wrangler-2162 pages dev ./public --local --persist --service TEST=a

when I print out my context I get

{ ASSETS: Fetcher {}, ENVIRONMENT: 'development' }

no service binding there. Thank you for your help!

I tried to fix this by adding

_headers

file with

`
/
    Cache-Control: public, max-age=0, s-maxage=0, must-revalidate

But cache status is still HIT (with proxy disabled, otherwise it says DYNAMIC, which is pretty missleading). Is there any way to disable removed asset caching on

/

or globally? It's very annoying.

Are you talking about applying it to Cache in Functions, or Cache on static assets?

I'm talking about the problem that @TL&D described - I had a static site generated from Nuxt 3, then I switched to SSR (yarn build) and now on

/

route (index) I'm randomly getting cache hits from multiple old versions. I would like to disable that behavior. I thought that

_headers

file was way to do that, but it's not working.

I believe that while the headers file can override static asset headers, it doesn’t work as well for Functions, since the framework you use may have its own rules about caching.

This is not the framework issue and I think it might not be connected with functions (I know this channel might not be appropriate, but I'm just reacting to previous messages). Pages add cache to deleted static assets - I had static

index.html

, but now that there is SSR, the static asset is deleted, Pages adds cache header to it, so old clients won't break. But I don't want that, I want to force new version. This is not an issue when you deploy immediately to SSR, but it appers when you switch from static to SSR. https://community.cloudflare.com/t/custom-purge-not-working-with-pages/331906/6 here is the same problem I believe. I thought

_headers

was the mentioned config, but I guess it wasn't implemented at all?

Ok, yeah, I see the issue. AFAIK, there isn’t much you can do about it right now, short of publishing a blank file to wipe out the cache

has anyone able to run a real-world next.js project on CF pages? Seems still some blocking issues on next.js deployment https://github.com/cloudflare/next-on-pages/issues

If it's relatively small and you don't want to use any other CF features, I've seen some people have limited success.

As you noticed though, I'd be wary about using it for anything important. There's lots of issues with it, and I've seen users waste hours of time trying to get it working, or running well with any real-world projects. It’s in a state right now that I couldn't personally recommend it due to lack of maintenance and support, and generally encourage people to consider an alternative solution like Netlify or Vercel for their projects.

Thx for reply, our main product is already on CF pages with enterprise contract using create-react-app, and we were hoping to improve perf and SEO using next.js, seems like a dead end in this case with cloudflare?

I would generally avoid next-on-pages at this time if it were me, yeah. If you can do a static

next export

, you might be good though.

but that only works for static pages, right? Our critical paths are all dynamic routes

It does, yeah (outside of client side rendering which isn't ideal for SEO). If I were you I'd stick with what you have, or if you really want to use next.js, consider another vendor for hosting.

If you want to change your framework but stay with pages, you might find more luck with Remix?

It's also react-based