Mises à jour de l'API Service Worker Cache

Jake Archibald
Jake Archibald

On m'a demandé d'écrire cet article sur une mise à jour assez mineure de l'API de cache du service worker. Je ne pensais pas que cela méritait un article, mais après un long débat qui s'est finalement terminé par un jeu de pierre-feuille-ciseaux, j'ai perdu, alors le voici.

Êtes-vous prêt à découvrir les mises à jour de l'implémentation de l'API de cache de service worker dans Chrome ?

Je ne vous entends pas. Je vous ai demandé si vous étiez prêt à en savoir plus sur les mises à jour de l'implémentation de l'API de cache du service worker dans Chrome.

(vous ne pouvez continuer à lire que si vous avez sauté sur votre chaise et crié "YEAHHH". Simultanément, faire semblant de manier un lasso est facultatif, mais encouragé).

cache.addAll est disponible depuis Chrome 46

Oui. C'est exact ! Mettre en cache ! Point ajouter tout ! Chrome 46 !

Ok, ok, mis à part le sarcasme, c'est un événement important, car cache.addAll est la dernière partie restante du polyfill "essentiels" du cache, ce qui signifie qu'il n'est plus nécessaire.

Voici comment cache.addAll fonctionne:

// when the browser sees this SW for the first time
self.addEventListener('install', function(event) {
    // wait until the following promise resolves
    event.waitUntil(
    // open/create a cache named 'mysite-static-v1'
    caches.open('mysite-static-v1').then(function(cache) {
        // fetch and add this stuff to it
        return cache.addAll([
        '/',
        '/css/styles.css',
        '/js/script.js',
        '/imgs/cat-falls-over.gif'
        ]);
    })
    );
});

addAll prend un tableau d'URL et de requêtes, les récupère et les ajoute au cache. Il s'agit d'une transaction : si l'une des récupérations ou des écritures échoue, l'ensemble de l'opération échoue et le cache est rétabli à son état précédent. Cela est particulièrement utile pour les opérations d'installation comme ci-dessus, où une seule défaillance doit être considérée comme une défaillance globale.

L'exemple ci-dessus se trouve dans un service worker, mais l'API caches est également entièrement accessible depuis les pages.

Firefox est déjà compatible avec cette API dans sa édition pour développeurs. Elle sera donc disponible avec le reste de l'implémentation du service worker.

Mais ce n'est pas tout ! D'autres améliorations du cache sont en cours de développement.

cache.matchAll arrive dans Chrome 47

Vous pouvez ainsi obtenir plusieurs correspondances:

caches.open('mysite-static-v1').then(function(cache) {
    return cache.matchAll('/');
}).then(function(responses) {
    // …
});

La commande ci-dessus récupère tout ce qui correspond à / dans mysite-static-v1. Le cache vous permet d'avoir plusieurs entrées par URL si elles sont en cache indépendamment, par exemple si elles ont des en-têtes Vary différents.

Firefox est déjà compatible avec cette fonctionnalité dans sa édition développeur. Elle sera donc disponible avec le reste de l'implémentation des service workers.

Options de requête de cache bientôt disponibles dans Chrome

Voici un gestionnaire de récupération assez standard:

self.addEventListener('fetch', function(event) {
    event.respondWith(
    caches.match(event.request).then(function(response) {
        return response || fetch(event.request);
    })
    );
});

Si / est mis en cache et que nous recevons une requête pour /, elle sera diffusée à partir du cache. Toutefois, si nous recevons une requête pour /?utm_source=blahblahwhatever qui ne provient pas du cache, Pour contourner ce problème, ignorez la chaîne de recherche d'URL lors de la mise en correspondance:

self.addEventListener('fetch', function(event) {
    event.respondWith(
    caches.match(event.request, {
        ignoreSearch: true
    }).then(function(response) {
        return response || fetch(event.request);
    })
    );
});

/?utm_source=blahblahwhatever sera désormais associé à l'entrée pour /. Les options complètes sont les suivantes:

  • ignoreSearch : ignorez la partie de recherche de l'URL dans l'argument de requête et les requêtes mises en cache.
  • ignoreMethod : ignorez la méthode de l'argument de requête afin qu'une requête POST puisse correspondre à une entrée GET dans le cache.
  • ignoreVary : ignore l'en-tête "vary" dans les réponses mises en cache

Firefox est déjà compatible avec cette fonctionnalité dans… vous savez déjà comment ça se passe. Dites à Ben Kelly qu'il est génial d'avoir intégré tout cela dans Firefox.

Pour suivre l'implémentation des options de requête de cache dans Chrome, consultez crbug.com/426309.

À bientôt pour un autre chapitre passionnant de la série "Ce que nous avons implémenté dans l'API cache" !