Tags: serviceworker

64

sparkline

Friday, February 17th, 2017

PWABuilder

A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web appsite.

Sunday, January 29th, 2017

We built a PWA from scratch - This is what we learned

A nice straightforward account of building and testing a progressive web a… I mean, website.

I think every website from now on should use some of the Progressive Web App features. It’s even confusing to call it “Apps” as it applies to all websites and apps.

Friday, January 27th, 2017

A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same

Sally gives a really good introduction to using service workers as a progressive enhancement.

✨Implementing “Save For Offline” with Service Workers | Una Kravets Online✨

A great little script from Una that’s perfect for blogs and news sites—allowing users to explicitly save a page for offline reading.

Sunday, January 15th, 2017

Modernizing our Progressive Enhancement Delivery | Filament Group, Inc., Boston, MA

Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).

Wednesday, January 11th, 2017

Making Resilient Web Design work offline

I’ve written before about taking an online book offline, documenting the process behind the web version of HTML5 For Web Designers. A book is quite a static thing so it’s safe to take a fairly aggressive offline-first approach. In fact, a static unchanging book is one of the few situations that AppCache works for. Of course a service worker is better, but until AppCache is removed from browsers (and until service worker is supported across the board), I’m using both. I wouldn’t recommend that for most sites though—for most sites, use a service worker to enhance it, and avoid AppCache like the plague.

For Resilient Web Design, I took a similar approach to HTML5 For Web Designers but I knew that there was a good chance that some of the content would be getting tweaked at least for a while. So while the approach is still cache-first, I decided to keep the cache fairly fresh.

Here’s my service worker. It starts with the usual stuff: when the service worker is installed, there’s a list of static assets to cache. In this case, that list is literally everything; all the HTML, CSS, JavaScript, and images for the whole site. Again, this is a pattern that works well for a book, but wouldn’t be right for other kinds of websites.

The real heavy lifting happens with the fetch event. This is where the logic sits for what the service worker should do everytime there’s a request for a resource. I’ve documented the logic with comments:

// Look in the cache first, fall back to the network
  // CACHE
  // Did we find the file in the cache?
      // If so, fetch a fresh copy from the network in the background
      // NETWORK
          // Stash the fresh copy in the cache
  // NETWORK
  // If the file wasn't in the cache, make a network request
      // Stash a fresh copy in the cache in the background
  // OFFLINE
  // If the request is for an image, show an offline placeholder
  // If the request is for a page, show an offline message

So my order of preference is:

  1. Try the cache first,
  2. Try the network second,
  3. Fallback to a placeholder as a last resort.

Leaving aside that third part, regardless of whether the response is served straight from the cache or from the network, the cache gets a top-up. If the response is being served from the cache, there’s an additional network request made to get a fresh copy of the resource that was just served. This means that the user might be seeing a slightly stale version of a file, but they’ll get the fresher version next time round.

Again, I think this acceptable for a book where the tweaks and changes should be fairly minor, but I definitely wouldn’t want to do it on a more dynamic site where the freshness matters more.

Here’s what it usually likes like when a file is served up from the cache:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      return responseFromCache;
  }

I’ve introduced an extra step where the fresher version is fetched from the network. This is where the code can look a bit confusing: the network request is happening in the background after the cached file has already been returned, but the code appears before the return statement:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      // If so, fetch a fresh copy from the network in the background
      event.waitUntil(
          // NETWORK
          fetch(request)
          .then( responseFromFetch => {
              // Stash the fresh copy in the cache
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      return responseFromCache;
  }

It’s asynchronous, see? So even though all that network code appears before the return statement, it’s pretty much guaranteed to complete after the cache response has been returned. You can verify this by putting in some console.log statements:

caches.match(request)
.then( responseFromCache => {
  if (responseFromCache) {
      event.waitUntil(
          fetch(request)
          .then( responseFromFetch => {
              console.log('Got a response from the network.');
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      console.log('Got a response from the cache.');
      return responseFromCache;
  }

Those log statements will appear in this order:

Got a response from the cache.
Got a response from the network.

That’s the opposite order in which they appear in the code. Everything inside the event.waitUntil part is asynchronous.

Here’s the catch: this kind of asynchronous waitUntil hasn’t landed in all the browsers yet. The code I’ve written will fail.

But never fear! Jake has written a polyfill. All I need to do is include that at the start of my serviceworker.js file and I’m good to go:

// Import Jake's polyfill for async waitUntil
importScripts('/js/async-waituntil.js');

I’m also using it when a file isn’t found in the cache, and is returned from the network instead. Here’s what the usual network code looks like:

fetch(request)
  .then( responseFromFetch => {
    return responseFromFetch;
  })

I want to also store that response in the cache, but I want to do it asynchronously—I don’t care how long it takes to put the file in the cache as long as the user gets the response straight away.

Technically, I’m not putting the response in the cache; I’m putting a copy of the response in the cache (it’s a stream, so I need to clone it if I want to do more than one thing with it).

fetch(request)
  .then( responseFromFetch => {
    // Stash a fresh copy in the cache in the background
    let responseCopy = responseFromFetch.clone();
    event.waitUntil(
      caches.open(staticCacheName)
      .then( cache => {
          cache.put(request, responseCopy);
      })
    );
    return responseFromFetch;
  })

That all seems to be working well in browsers that support service workers. For legacy browsers, like Mobile Safari, there’s the much blunter caveman logic of an AppCache manifest.

Here’s the JavaScript that decides whether a browser gets the service worker or the AppCache:

if ('serviceWorker' in navigator) {
  // If service workers are supported
  navigator.serviceWorker.register('/serviceworker.js');
} else if ('applicationCache' in window) {
  // Otherwise inject an iframe to use appcache
  var iframe = document.createElement('iframe');
  iframe.setAttribute('src', '/appcache.html');
  iframe.setAttribute('style', 'width: 0; height: 0; border: 0');
  document.querySelector('footer').appendChild(iframe);
}

Either way, people are making full use of the offline nature of the book and that makes me very happy indeed.

A Tale of Four Caches · Yoav Weiss

A cute explanation of different browser caches:

  • memory cache,
  • service worker cache,
  • disk cache, and
  • push cache.

Monday, January 9th, 2017

The Futures of Typography

A wonderfully thoughtful piece from Robin, ranging from the printing technologies of the 15th century right up to the latest web technologies. It’s got all my favourite things in there: typography, digital preservation, and service workers. Marvellous!

Saturday, December 24th, 2016

10 things I learned making the fastest site in the world

Behind the amusing banter there’s some really solid performance advice in here. Good stuff.

Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.

Thursday, December 8th, 2016

Hey, Hey, Cloud Four is a PWA! - Cloud Four

Jason talks through the service worker strategy for his company website.

Sunday, December 4th, 2016

Service Worker, what are you? - Mariko Kosaka

This is a fun—and accurate—explanation of service workers.

There’s definitely something “alien” about a service worker—it’s kind of like a virus that gets installed on the user’s device. I’ve taken to describing it as “a man-in-the-middle attack on your own website” which makes sound a bit scarier than is necessary.

Thursday, November 17th, 2016

Less JavaScript

Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.

The day was unsurprisingly excellent. All the speakers brought their A-game on a wide range of topics. Of course JavaScript was covered, but there was also plenty of mindfood on CSS, accessibility, progressive enhancement, dev tools, creative coding, and even emoji.

Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.

I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.

In his talk on service workers (what else?), Jake makes the point that not everything needs to be a single page app, echoing Ada’s talk at FFConf.

He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.

They’ve written a lot of JavaScript to make this quite slow.

Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.

Alex followed up his barnstorming talk from the Polymer Summit with some more uncomfortable truths about how mobile phones work.

Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.

And JavaScript frameworks aren’t helping. Quite the opposite.

But make no mistake: if you’re using one of today’s more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this.

Today’s frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance.

Sunday, October 16th, 2016

The Service Worker Lifecycle  |  Web  |  Google Developers

Jake goes into the details of what exactly is happening when a service worker is installed or replaced.

This is easily the most complex part of working with service workers, and I think I’m beginning to wrap my head around it, but the good news is that, for the most part, you don’t really need to know the ins and outs of this to get started (and dev tools are now making it easier to nuke from orbit if this begins to bite).

Wednesday, October 12th, 2016

Enhancing a comment form: From basic to custom error message to BackgroundSync | justmarkup

This is a truly fantastic example of progressive enhancement applied to a form.

What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.

Superb!

Tuesday, September 27th, 2016

Offline content with service workers · MadebyMike

This is a really great step-by-step walkthrough of adding a service worker to a website. Mike mentions the gotchas he encountered along the way, and describes how he incrementally levelled up the functionality.

If you’ve been going through a similar process, please write it down and share it like this!

Monday, September 19th, 2016

An intro to progressive web apps | 8th Light

A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:

No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.

Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.

Cross-origin Service Workers: Experimenting with Foreign Fetch | Web Updates - Google Developers

This one is definitely for service worker nerds only. I’ve been trying to get my head around this idea of “foreign fetch” which allows third parties to install service workers—could be handy for sites with APIs like Huffduffer and The Session. This article does a good job of explaining the somewhat tangled process.

What, Exactly, Makes Something A Progressive Web App? | Infrequently Noted

Alex runs through the features that a progressive web app must have, should have, and would be nice to have.

In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.

Right now, this is in the nice-to-have category:

Mobile-friendly, not mobile-only.

Personally, I’d put that in the must-have category, and not just for progressive web apps.

Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.

lyzadanger/pragmatist-service-worker: Pragmatist’s Guide to Service Worker

Lyza put together some example code for her Smashing Conference talk on service workers. If you haven’t written a service worker before, these are really nice examples of how to grok it bit by bit.

Monday, September 5th, 2016

The Building Blocks Of Progressive Web Apps – Smashing Magazine

This is a really good overview of progressive web apps:

An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.

At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.