[e12e]

I think it's actually much worse than that - it's a little tricky to tell on mobile, but going from "stats" to "bagle" and back again - looks like this mucks up the client side cache? While one whole second is "90s slow" for a first render for a static site - it's truly ludicrous for navigating back to an already cached page?

How are the cache control headers with this set-up - is there a varnish or similar cdn/cache doing useful work (I'm assuming not, more importantly I'm worried pointing something like fastly at this will fail in caching static pages?).

[zamadatix]

The request headers have no-cache set. I assume this is because it's in a live developer playground page instead of a production deployment.

[e12e]

> I assume this is because it's in a live developer playground page instead of a production deployment.

Not how I read it - the first link is to a site deployed via "deno deploy", the last one is a link to the same content in a playground.

>> Hosted on Deno Deploy, this little website is able to acheive a perfect pagespeed score. Serviced from an anycast IP address over encrypted HTTP from 29 data centers around the world, the site is fully managed and will be available indefinitely at zero cost.

>> Everything mentioned here can be viewed on a playground.

For what it's worth, the deployed site seems a little snappier to me now on mobile - maybe I'm just less grumpy after dinner...

[zamadatix]

You know what's funny I'm a fool that still had "disable cache" checked in the dev tools from a previous session when I was checking the request headers. At the current moment now that I have unchecked that in dev tools it is actually respecting the cache for those images. I can't definitively say if that is different than before but either way at least it seems cache is verifiably working with it normally now that I have that unchecked.

[e12e]

Still, that's quite different from live editing static files on disk - then you'd normally get cache and invalidation (if-modified-since/304 etc).