developer.mozilla.org
Cache
https://developer.mozilla.org/en-US/docs/Web/API/Cache
36 comments
> Cache is super useful for making web apps available offline.
... until you find someone who has very low cache available. Or cache gets evicted.
... until you find someone who has very low cache available. Or cache gets evicted.
Maybe they should have put the line
The browser does its best to manage disk space, but it may delete the Cache storage for an origin.
in a warning box.
The browser does its best to manage disk space, but it may delete the Cache storage for an origin.
in a warning box.
You know, you could just improve this. All you need to go is find the github link for the article at the bottom of the page, find the edit button, and github will guide you through the rest of the process.
(I've done so myself a few times)
If you prefer you can also clone and make a pull request using standard git tools.
(I've done so myself a few times)
If you prefer you can also clone and make a pull request using standard git tools.
Or their computer breaks. Or their electricity cuts off. Or an asteroid hits them.
...things can be super useful without being flawless.
...things can be super useful without being flawless.
...that's OK.
My app works fine online or offline. If you're offline and you ran out of disk space and the cache got evicted, ok, you can't use my web app offline.
(And, if you're out of disk space, all bets are off. You're gonna have other, more significant problems beyond a guitar chord chart site not working offline.)
My app works fine online or offline. If you're offline and you ran out of disk space and the cache got evicted, ok, you can't use my web app offline.
(And, if you're out of disk space, all bets are off. You're gonna have other, more significant problems beyond a guitar chord chart site not working offline.)
Did something change for this API recently or just randomly popped up on frontpage? (:
Or maybe just to show appreciation for this API? At least I do :P
Hah, that's fine. Just checking in case I missed something :P
I haven't been using service workers lately but I had some run-ins recently when writing some CF workers.
I haven't been using service workers lately but I had some run-ins recently when writing some CF workers.
this poster seems to just spam random stuff from mdn and his personal project over and over. you can see that he even added a spam comment to this post asking for stars on his github project.
edit: op deleted his beg comment after it was flagged dead
edit: op deleted his beg comment after it was flagged dead
I kind of like when things randomly show up on the frontpage that I _should_ know about. Today was my turn to be part of the lucky 10,000.
https://xkcd.com/1053
https://xkcd.com/1053
I almost used this recently to gain more control over the HTTP cache behavior in our app at work, but eventually realized what I wanted could be achieved by combining plain old cache headers with some more intelligent cache busting query strings. I would definitely like to see some more real-life examples where this API provides unique benefits over traditional cache handling.
This API is used heavily in service workers to store responses for offline use. I don‘t think you can use HTTP cache headers to robustly achieve the same effect.
I created an SRS based kanji learning app (https://shodoku.app/ https://github.com/runarberg/shodoku) hosted on GitHub Pages (meaning the app is a static HTML page) where all the dictionary data is stored as hundreds of thousands of json (and SVG) files. Storing these assets using the Cache API saves tens of thousands of round trips to the server in addition to offering a somewhat robust offline experience.
I created an SRS based kanji learning app (https://shodoku.app/ https://github.com/runarberg/shodoku) hosted on GitHub Pages (meaning the app is a static HTML page) where all the dictionary data is stored as hundreds of thousands of json (and SVG) files. Storing these assets using the Cache API saves tens of thousands of round trips to the server in addition to offering a somewhat robust offline experience.
This is a lovely app BTW
This API is pretty useful for writing web apps that also work offline/with bad connectivity. It saves you from re-implementing the browser fetching/resource loading logic the browser already does for you.
It's very powerful, which also makes it a footgun: you can end up with fetch() requests going out over the network, with server responses saying one thing, but the frontend receiving something completely differently.
As for examples, I believe Home Assistant uses it to cache pretty much every resource in the frontend pre-emptively so you can use the web UI even if your internet connection is down (but your connection to your home server isn't).
It's very powerful, which also makes it a footgun: you can end up with fetch() requests going out over the network, with server responses saying one thing, but the frontend receiving something completely differently.
As for examples, I believe Home Assistant uses it to cache pretty much every resource in the frontend pre-emptively so you can use the web UI even if your internet connection is down (but your connection to your home server isn't).
We use service workers extensively in the kiosk app world.
Absent a service worker this API won't give you a whole lot but it's a very powerful addition to the web toolkit. With the right caching strategies you can make a really effective offline web app.
HuggingFace’s Transformers.js uses this API to cache model files for when you are running models in the browser.
[deleted]
The Cache API is separate from the traditional HTTP cache. You can access the HTTP cache indirectly by fetching with appropriate HTTP headers, but I suppose there is still no way to access the HTTP cache directly?
[deleted]
Oh nice, I didn't know about that. I wonder if popular libraries like react-query could use it and make a web app fully available offline (readonly) without changing a single line?
Making a web app work fully offline requires a Service Worker, if for no other reason than because something has to handle the initial request for the top-level HTML document (and in practice it's much easier to let the Service Worker handle other things too). TanStack doesn't seem to have anything available out of the box that does this; the most commonly used library for this purpose is Google's Workbox, and it should be possible to integrate the two.
I encourage everybody to work with service workers to encounter the horror that can be service workers gone wrong.
Pro-tip: Use Serwist (https://serwist.pages.dev/), don't learn Workbox. Serwist has beautiful Vite integration for preloading app chunks from a build manifest. Learn all the different caching strategies. Consider dynamic caching strategies, eg. switching between two strategies for a specific cache via messaging throughout the lifetime of the app. Deep breaths. Have a service worker kill-switch in case things go wrong.
Pro-tip: Use Serwist (https://serwist.pages.dev/), don't learn Workbox. Serwist has beautiful Vite integration for preloading app chunks from a build manifest. Learn all the different caching strategies. Consider dynamic caching strategies, eg. switching between two strategies for a specific cache via messaging throughout the lifetime of the app. Deep breaths. Have a service worker kill-switch in case things go wrong.
I encourage everybody to not use service workers so my computer doesn't waste resources.
Used this API in a service worker together with Workbox to allow https://isle.pizza/ to work completely offline if requested. Works great
[deleted]
We use cache to store past conversations offline within our AI chat web app and it's been working fine :) https://jetwriter.ai.
I run a guitar chord chart site[0] that uses cache to enable offline experience; any chord charts you view while online are then available offline thanks to cache. It works pretty great. You service worker intercepts HTTP requests and can first check the cache for cached request/responses.
[0]: https://messianicchords.com