A couple of days ago, we finally released an exciting new Progressier feature which our customers have been relentlessly requesting since we launched our beta.
By default, browsers tend to cache resources somewhat unpredictably through the HTTP cache mechanism. You have little control over how resources are cached and updated.
Instead with the Cache interface available in service workers, you can define very precisely how each type of resource is fetched, cached and refreshed.
With the right strategies, you can:
- make your app functional offline
- improve load times
- keep key resources fresh without having to use a versioning trick
- decrease your server costs
Pretty cool, in theory. In practice? Not so easy. Earlier this year, Google nearly gave every web app developer an ultimatum: make your app work offline or lose the install functionality. As I postulated when they abandoned that plan, making a website work offline consistently is harder than most people think.
CORS, preflight requests, opaque responses, cache-control headers… these are some of the concepts that make caching hard to grasp. They're abstract and opiniated -- and truthfully most developers don't really know about them.
So the challenge was double. First, how does one build a universal service worker that works with any domains and resources? And second, how does one build a user interface that doesn't have a learning curve for this inherently complicated process?
The key is that everyone deals with caching the same way: by copy-pasting code snippets from the Workbox site or the Google Dev Site and swapping sample values with their own variables. Progressier lets you define these variables with toggles and dropdowns instead of hard-coding them in your service worker.
And then there are variable-looking things that in our day and age just aren't needed anymore. One of the ways Progressier simplifies the process is by shielding you from them automatically. A good example of this is caching expiration dates.
You shouldn't have to worry about expiration dates anymore. Because caching expiration dates are no longer needed. They're an antiquated way of invalidating cached resources -- reminiscent from the time the only way to deal with caching was the unpredictable HTTP Cache interface.
With the Cache interface available in service workers, there's absolutely no need to set expiration dates anywhere. You have much better control on things now:
- You can keep resources systematically fresh by not using caching at all (Network Only)
- You can keep resources fresh but fall back to a cached version when the network isn't available (Network First)
- You can fetch resources from the cache first to reduce load times but systematically revalidate them every time (Stale-while-Revalidate)
- You can get resources from the cache and never revalidate them to reduce server costs (Cache First)
With Progressier, you simply choose one of the strategies above and select which resources to apply it to. Examples of rules:
- "Apply Network First to all resources from cdn.whatever.com"
- "Apply Cache First to all Font files"
- "Apply Network Only to api.mydomain.com/very-important-data.json"
- "Apply Stale-While-Revalidate to all images hosted on my domain"
And because Progressier is a no-code tool, you specify these rules in plain English -- just the way I did it above. That may seem frivolous. But if you have to modify them two years from now, you'll be glad not to have to decipher a bunch of regular expressions.
You can also visualize how each of the strategies intercept your resources (as rules may have overlap).
Caching strategies is the key to making a web app functional offline. For a complete offline experience, there are a few other mechanisms that one must know about as well.
Here are some of the things you can configure your web app to do automatically with a few clicks in Progressier:
- Precache resources required for your app to launch while offline
- Retry failed requests later when network connectivity is lost
- Build redundancy by providing fallback URLs for important resources
- Override headers that prevent caching (especially useful for no-code builders like Bubble).
- Show an offline alert to warn users that they've lost network connectivity
Steve Jobs said "Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains."
Building the user interface of a caching strategy builder might be the hardest simple thing I've ever had to do. And while Progressier definitely won't move mountains, it does put caching within reach of any developers -- whether they write code or use no-code builders. If this sounds interesting, you can try it for free here.