Static Assets HTML 304 local but 200 only when deployed
I'm trying to experiment with the advantages of building out a static site through static assets and pre-compiled HTML. Locally, when I serve up a page, I see an initial 200 response with a 304 + ETAGS, as expected, on reload. However, when I deploy this bare-bones worker and load it up, I only see 200 responses and it never sets ETAGS to take advantage of 304 responses.
Also, when developing locally, if you enable assets in wrangler, it seems that no
console
logs get executed... at all. There seems to be some kind of aggressive caching happening locally. In fact, if I delete the entire fetch
handler and restart the worker, it loads from cache even on a hard reload. Is this normal?3 Replies
See -> https://developers.cloudflare.com/cache/concepts/default-cache-behavior/
The Cloudflare CDN does not cache HTML or JSON by default.
Cloudflare Docs
Default cache behavior | Cloudflare Cache (CDN) docs
Cloudflare respects the origin web server’s cache headers in the following order unless an Edge Cache TTL cache rule overrides the headers. Refer to the Edge TTL section for details on default TTL behavior.
Static assets from Workers bypass the cache by default? News to me.
I was under the impression that static assets get treated as sourced by origin? E.g. when I do a trace I see the worker is of type "origin" and the cache rule matches.
Counter indicative is that I do not see a high enough number of cached responses currently. This is a bit confusing.
I do see the necessary
etag
and other headers in the response, though, with the cache rule for static assets. So I think the reason that I do not see many cache hits is just because there not many returning requests currently (fresh domain without real traffic). I am pretty certain that static assets are the origin and the default cache behavior and cache rules apply?
But thank you help me understanding this, although your remarks were initially not helpful.
This again not very helpful and confusing remark does not reflect by what I read from the docs.
Okay, this starts to make sense. Thank you.Ok, I think I'm getting confused.
So, if we have a worker leveraging static assets to deliver pre-compiled HTML (generated during the build process and pushed to the
/public
directory) to the browser, what's the best practice to ensure that it's taking advantage of proper best-practices for browser / server caching?
What's confusing me is that when using npx wrangler dev
to view the site locally, I'm seeing what I would expect... which is that on the initial load, a 200
response with an ETAG
header and then upon second load, a 304
response with both ETAG
and If-None-Match
headers.
However, when I deploy this simple script (which is deployed to a testing subdomain of my primary domain, i.e., sandbox.domain.com
), I only see 200
responses for the HTML page."
At first, I thought that this might have something to do with setting a Cache rule to enforce strong ETAGs. So, I created a cache rule for all incoming requests to respect strong ETAGs. Now the ETAGs show up and I see 304 responses but without bronti (or any) compression.
So, I'm starting to get a bit lost about best practices here and any explanations would be appreciated.
---
BONUS QUESTION
As a follow up question, I'm seeing really strange behavior with local Workers using static assets. Take, for example, this very simple fetch
handler...
So, ASSETS
maps to the /public
directory which has two HTML files.
These will render properly. If I uncomment that console.log
, it will not show up when I serve up the site locally. Furthermore, if I literally delete the entire contents of the fetch
handler... reload the worker... I can still hit the site. What kind of caching is going on here that allows that?