Apple's latest release notes indicate their support for Service Workers.
Highlights of Safari 11.1
- Service Workers. Implement background scripts for offline web applications and faster web pages.
- Payment Request. Provide a consistent user payment experience in Safari using a standards-based API.
- Security Improvements. Improved protection against memory corruption and code execution attacks.
- Web Inspector Updates. New designs for the Network Tab and the Styles sidebar in the Elements Tab.
The Service Worker API that acts as a network proxy for the browser that gives web developers more control over requests. This means better experiences in bad network conditions and developers get access to certain app architecture concepts which can improve user experience in all conditions.
Safari's support will put a huge dent in the Can I Use numbers for the better. What this means for me and my team is that we can start confidently leaning in to Service Workers with more of our time and effort. We still have to build applications that progressively enhance from browsers which do not support them, but that extra layer of complication can now be justified. For some teams, they could have reached that justification earlier, but in my mind Service Workers had to be considered more experimental before this major browser got onboard.
App Shell Architecture
One application design enabled by Service Workers is called App Shell Architecture, where the layout and re-used assets of a web page are cached for re-use and the network requests center more around the data being passed over in order to render content of the page as a secondary request. Similar page-construction choices are already somewhat popular in web dev land but they are not necessarily a great choice without this caching layer in my opinion. If you cannot cache the shell, I really wouldn't advise making so many calls home just to render the first content. You want less latency, not more.
We do not make use of this architexture right now, and that's why this Safari update is important. I think it just puts us over the hump where we can put these ideas front of mind. It gives us enough browser support to build paths where the page layout can be stored on the user's machine—desktop or mobile.
We are certainly web-first shop and there is no native dev.to option yet, and I would not want to put the cart before the horse, but this might give us an excuse to stay fully web even on mobile for a while. But I don't want to commit too far in that direction. The development benefits of only having a single application are great if the user experience helped by powerful browser APIs.
Edge Logic
Our application already makes use of networking logic at the edge via our CDN Fastly and leaning in to Service Workers gives us one more edge layer. A request that has never been handled by Service Workers is still likely to be handled at an edge node.
If you live in New Zealand we don't expect you to come all the way to Utah for your content. Service Workers mean that much of the HTML (and other assets, of course) can stay with you on your browser so your next visit is much faster to show you some layout and sends fewer bytes over the wire. We still want to provide the same crisp load without service workers, but we have the tools to cater a really good overall web experience for consistent users.
Thanks Apple
This move might ease some heartburn over Safari. I'm glad we have dipped our toes in Service Workers so we are not just catching up now, but I am also glad we did not try jumping in head first a year ago only to maintain a more complicated cross-browser compatibility for only 2/3rds support.
Happy coding ❤️
Top comments (8)
App shell architecture whilst discussed at length by Google in the past really couldn't take off like it should have whilst Apple lagged behind as you say. Hopefully we see more applications following this architecture, it makes complete sense.
I currently am reading this from the dev.to PWA. Are you able to share some insights and/or numbers about the PWA usage?
We haven't gotten around to tracking our PWA traffic with much granularity but about 25% of our traffic is Android and we have about 2,000 PWA installs.
The PWA thing is great in the long run if it works out, but in the short term we've been strategically more focused on the technology than the technicalities of PWA install action, which is a bit out of our control.
Awesome to hear that you are using the PWA though!
Can you provide some quick insight as to why App Shell Architecture, ( First time I heard about this ) and Services worker provides "mean that much of the HTML (and other assets, of course) can stay with you on your browser so your next visit is much faster to show you some layout and sends fewer bytes over the wire. "
How is that different from good old Browser Caching?
Service workers can act as a pretty smart programmed reverse proxy. A subset of what you can do with this is caching, but you have a lot more explicit control over this functionality. This post has a lot of great responses to help.
It is important to note that the service worker is not available when the page is loaded inside a WKWebview within a non-browser iOS app. Above restriction can be relaxed if you can add the urls in the plots before building but that is too restrictive.
I like how safari is coming in line, even though it's late. PWAs on iOS would be a huge win for the PWA paradigm.
I'm using macOS Catalina version10.15.4. I'm not able to visit dev.to from my safari browser. But still, I can able to do that from Chrome. @ben Do you have any idea about this issue?