Mises à jour de l'API Service Worker Cache

Jake Archibald
Jake Archibald

On m'a demandé de rédiger ce post sur une mise à jour assez mineure de l'API de cache de service workers. Je ne pensais pas qu'elle justifiait son propre article, mais après un long débat qui s'est finalement porté sur un jeu de pierre-papier-ciseaux, j'ai perdu, alors voilà.

Êtes-vous prêt à recevoir des informations sur les modifications apportées à l'implémentation de l'API Service Workers Cache dans Chrome ?

Je ne vous entends pas. Je vous ai dit : êtes-vous prêt à recevoir des informations sur les modifications apportées à l'implémentation de l'API Service Workers Cache dans Chrome ?

(Vous ne pouvez poursuivre la lecture que si vous êtes monté sur votre chaise et crié "YEAHHH !". En même temps, faire semblant de jouer un lasso est facultatif, mais encouragé.)

cache.addAll est arrivé dans Chrome 46

Oui. C'est exact ! Cache! Ajoutez tout ! Chrome 46!

Très bien, sarcasme mis à part, c'est en fait un gros problème, car cache.addAll est la dernière partie du polyfill "Éléments essentiels" du cache, ce qui signifie qu'il n'est plus nécessaire.

Voici comment fonctionne cache.addAll:

// 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 accepte un tableau d'URL et de requêtes, les récupère et les ajoute au cache. Il s'agit d'une transaction transactionnelle : si l'une des opérations d'extraction ou d'écriture échoue, l'ensemble de l'opération échoue et le cache revient à son état précédent. Cela est particulièrement utile pour les opérations d'installation comme ci-dessus, où un échec unique doit être un échec global.

L'exemple ci-dessus concerne un service worker, mais l'API de cache est également entièrement accessible depuis les pages.

Firefox est déjà compatible avec cette API dans l'édition pour les développeurs. Elle sera donc intégrée au reste de l'implémentation de service worker.

Et ce n'est pas tout ! D'autres améliorations sont prévues pour le cache...

cache.matchAll bientôt disponible dans Chrome 47

Cela vous permet d'obtenir plusieurs correspondances:

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

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

Firefox prend déjà en charge cette fonctionnalité dans l'édition pour les développeurs. Elle sera donc intégrée au reste de l'implémentation du service worker.

Options de requête en 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 nous avons / mis en cache et que nous recevons une requête pour /, elle est diffusée à partir du cache. Toutefois, si nous recevons une requête pour /?utm_source=blahblahwhatever, celle-ci ne proviendra pas du cache. Vous pouvez contourner ce problème en ignorant la chaîne de recherche de l'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 de /. Les options complètes sont les suivantes:

  • ignoreSearch : ignore la partie de recherche de l'URL à la fois dans l'argument de requête et dans les requêtes mises en cache.
  • ignoreMethod : ignore la méthode de l'argument de requête, de sorte qu'une requête POST peut correspondre à une entrée GET du cache.
  • ignoreVary : ignorer l'en-tête "Vary" dans les réponses mises en cache

Firefox prend déjà en charge cette fonctionnalité dans... OK, vous connaissez maintenant le détail. Va dire à Ben Kelly combien il est génial d'utiliser tout cela dans Firefox.

Si vous souhaitez suivre la mise en œuvre des options de requête en cache dans Chrome, consultez la page crbug.com/426309.

À bientôt pour un nouveau chapitre passionnant de "ce que nous avons implémenté dans l'API de cache" !