Imperativer Leitfaden zum Caching

Andrew Guan

Demián Renzulli

Manche Websites müssen möglicherweise mit dem Service Worker kommunizieren, über das Ergebnis informiert sind. Beispiele:

• Eine Seite sendet dem Service Worker eine Liste mit URLs an Prefetch-Option werden aktiviert, sodass Nutzer, die auf eine Anzeige klicken, dass die Unterressourcen des Dokuments oder der Seite bereits im Cache verfügbar sind, sodass nachfolgende die Navigation schneller machen.
• Die Seite fordert den Service Worker auf, eine Reihe von Top-Artikeln abzurufen und im Cache zu speichern, damit diese für Offline-Zwecke verfügbar.

Durch das Delegieren dieser Art von unkritischen Aufgaben an den Service Worker für wichtigere Aufgaben wie das Reagieren auf Nutzerinteraktionen.

In diesem Leitfaden erfahren Sie, wie Sie eine einseitige Kommunikationstechnik von der Seite bis zum dem Service Worker mithilfe der Standardbrowser-APIs und der Workbox-Bibliothek Wir nennen diese Arten von Anwendungsfälle imperatives Caching

Produktionsfall

1-800-Flowers.com implementierte imperatives Caching (Vorabruf) mit Service Workern über postMessage(), um den Top-Artikeln auf Kategorieseiten zu, um die nachfolgende Navigation zu den Produktdetailseiten zu beschleunigen.

Sie verwenden einen gemischten Ansatz, um zu entscheiden, welche Elemente vorab abgerufen werden sollen:

• Bei der Seitenladezeit bitten sie den Servicer-Worker, die JSON-Daten für die neun wichtigsten Elemente abzurufen, und Dem Cache die resultierenden Antwortobjekte hinzufügen
• Für die restlichen Elemente hört sie sich mouseover an. . Wenn ein Nutzer dann Wenn ein Nutzer den Cursor über ein Element bewegt, kann bei Bedarf ein Abruf der Ressource ausgelöst werden.

Zum Speichern von JSON wird die Cache API verwendet. Antworten:

</ph>

Wenn der Nutzer auf ein Element klickt, können die damit verknüpften JSON-Daten aus dem Cache abgerufen werden. ohne das Netzwerk zu verwenden, was die Navigation beschleunigt.

Workbox verwenden

Workbox bietet eine einfache Möglichkeit, Nachrichten an einem Service Worker, über das workbox-window-Paket, eine Reihe von Modulen die im Fensterkontext ausgeführt werden sollen. Sie sind eine Ergänzung zu den anderen Workbox-Paketen. die im Service Worker ausgeführt werden.

Um die Seite mit dem Service Worker zu kommunizieren, rufen Sie zunächst einen Workbox-Objektverweis auf den registrierter Service Worker:

const wb = new Workbox('/sw.js');
wb.register();

Dann können Sie die Nachricht direkt deklarativ senden, ohne die Registrierung, Aktivierungsprüfung oder Überlegungen zur zugrunde liegenden Kommunikations-API:

wb.messageSW({"type": "PREFETCH", "payload": {"urls": ["/data1.json", "data2.json"]}}); });

Der Service Worker implementiert einen message-Handler, um sich diese Nachrichten anzuhören. Optional kann eine Antwort zurückgegeben werden, aber in solchen Fällen ist es Nicht erforderlich:

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PREFETCH') {
    // do something
  }
});

Browser-APIs verwenden

Wenn die Workbox-Bibliothek für Ihre Anforderungen nicht ausreicht, können Sie Window-to-Service wie folgt implementieren: mit Browser-APIs kommunizieren können.

Die postMessage API kann verwendet werden, um einen einseitigen Kommunikationsmechanismus von der Seite zum Service Worker einzurichten.

Die Seite ruft auf, postMessage() im Service Worker-Schnittstelle:

navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
  payload: 'some data to perform the task',
});

Der Service Worker implementiert einen message-Handler, um sich diese Nachrichten anzuhören.

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === MSG_ID) {
    // do something
  }
});

Das Attribut {type : 'MSG_ID'} ist nicht unbedingt erforderlich, aber es ist eine Möglichkeit, der Seite zu ermöglichen, Senden unterschiedlicher Arten von Anweisungen an den Service Worker (z. B. "Prefetch" statt Speicher"). Der Service Worker kann sich basierend auf diesem Flag in verschiedene Ausführungspfade verzweigen.

Wenn der Vorgang erfolgreich war, kann die nutzende Person die Vorteile davon nutzen, aber wenn nicht, ändert sie den grundlegenden User Flow nicht. Wenn beispielsweise 1-800-Flowers.com versucht, einen Pre-Cache zu starten, muss die Seite nicht wissen, ob der Service Worker erfolgreich war. Ist dies der Fall, profitieren die Nutzenden von einer schnelleren Navigation. Ist dies nicht der Fall, muss die neue Seite aufgerufen werden. Es dauert nur noch ein wenig.

Ein einfaches Beispiel für den Vorabruf

Eine der häufigsten Anwendungen des imperativen Caching ist der Vorabruf, d. h. das Abrufen von Ressourcen für eine URL bereitgestellt werden, bevor der Nutzer zu ihr gelangt, um die Navigation zu beschleunigen.

Es gibt verschiedene Möglichkeiten, den Vorabruf auf Websites zu implementieren:

• Verwendung von Link-Prefetch-Tags auf Seiten: Ressourcen werden im Browser-Cache fünf Minuten lang. Danach werden die normalen Cache-Control-Regeln für die Ressource angewendet werden.
• Ergänzung der vorherigen Technik durch eine Laufzeit-Caching-Strategie im Dienst Worker, um die Lebensdauer des Prefetches zu verlängern. -Ressource über dieses Limit hinaus.

Bei relativ einfachen Vorabruf-Szenarien wie dem Vorabrufen von Dokumenten oder bestimmten Assets (JS, CSS usw.), sind diese Techniken der beste Ansatz.

Wenn zusätzliche Logik erforderlich ist, z. B. das Parsen der Prefetch-Ressource (eine JSON-Datei oder -Seite) in um die internen URLs abzurufen, ist es sinnvoller, diese Aufgabe vollständig Service Worker.

Das Delegieren dieser Arten von Vorgängen an den Service Worker bietet folgende Vorteile:

• Die schwierigen Aufgaben des Abrufs und der Post-Fetching-Verarbeitung (die in diesem Programm eingeführt wird in einen sekundären Thread. Dadurch wird der Hauptthread freigegeben, um wichtigere wie das Reagieren auf Interaktionen von Nutzenden.
• Mehrere Clients (z.B. Tabs) die Wiederverwendung einer gemeinsamen Funktion zu erlauben und sogar die ohne den Hauptthread zu blockieren.

Produktdetailseiten vorabrufen

postMessage() zum ersten Mal verwenden auf der Service Worker-Schnittstelle und übergeben Sie ein URL-Array an den Cache:

navigator.serviceWorker.controller.postMessage({
  type: 'PREFETCH',
  payload: {
    urls: [
      'www.exmaple.com/apis/data_1.json',
      'www.exmaple.com/apis/data_2.json',
    ],
  },
});

Implementieren Sie im Service Worker einen message-Handler, um Nachrichten abfangen und verarbeiten, die von einem aktiven Tab gesendet werden:

addEventListener('message', (event) => {
  let data = event.data;
  if (data && data.type === 'PREFETCH') {
    let urls = data.payload.urls;
    for (let i in urls) {
      fetchAsync(urls[i]);
    }
  }
});

Im vorherigen Code wurde eine kleine Hilfsfunktion namens fetchAsync() eingeführt, um die Array von URLs und geben für jede URL eine Abrufanfrage aus:

async function fetchAsync(url) {
  // await response of fetch call
  let prefetched = await fetch(url);
  // (optionally) cache resources in the service worker storage
}

Wenn die Antwort eingeht, können Sie sich auf die Caching-Header der Ressource verlassen. In vielen Fällen Ressourcen werden jedoch, wie auf Produktdetailseiten, nicht im Cache gespeichert. Cache-control-Header von no-cache). In solchen Fällen können Sie dieses Verhalten außer Kraft setzen, indem Sie Speichern der abgerufenen Ressource im Service Worker-Cache Das hat den zusätzlichen Vorteil, dass die in Offlineszenarien bereitgestellt werden kann.

Jenseits von JSON-Daten

Sobald die JSON-Daten von einem Serverendpunkt abgerufen werden, enthalten sie oft weitere URLs, die ebenfalls zum Beispiel ein Bild oder andere Endpunktdaten, die dieser ersten Ebene zugeordnet sind, Daten.

Nehmen wir an, in unserem Beispiel sind die zurückgegebenen JSON-Daten die Informationen einer Website zum Einkaufen von Lebensmitteln:

{
  "productName": "banana",
  "productPic": "https://cdn.example.com/product_images/banana.jpeg",
  "unitPrice": "1.99"
 }

Ändern Sie den fetchAsync()-Code, um die Liste der Produkte durchzugehen und das Hero-Image für diese im Cache zu speichern. alle:

async function fetchAsync(url, postProcess) {
  // await response of fetch call
  let prefetched = await fetch(url);

  //(optionally) cache resource in the service worker cache

  // carry out the post fetch process if supplied
  if (postProcess) {
    await postProcess(prefetched);
  }
}

async function postProcess(prefetched) {
  let productJson = await prefetched.json();
  if (productJson && productJson.product_pic) {
    fetchAsync(productJson.product_pic);
  }
}

Sie können eine Ausnahmebehandlung um diesen Code für Situationen wie 404-Fehler hinzufügen. Das Schöne an der Verwendung eines Service Workers für den Prefetch ist jedoch, dass er ohne viel Aufwand Konsequenz für die Seite und den Hauptthread. Vielleicht haben Sie auch eine komplexere Logik in der Nachbearbeitung des vorabgerufenen Inhalts, wodurch dieser flexibler und von den vorhandenen Daten entkoppelt wird Umgang mit Ihren Daten. Alles ist möglich.

Fazit

In diesem Artikel wurde ein häufiger Anwendungsfall der einseitigen Kommunikation zwischen Seite und Dienst behandelt. Worker: imperatives Caching. Die vorgestellten Beispiele dienen nur dazu, und der Ansatz kann auch auf andere Anwendungsfälle angewendet werden. Caching von Top-Artikeln bei Bedarf, z. B. zur Offline-Nutzung oder zum Speichern von Lesezeichen.

Weitere Kommunikationsmuster für Seiten und Service Worker finden Sie hier:

• Broadcast-Updates: Die Seite wird vom Service Worker zur Information aufgerufen. über wichtige Updates (z. B. ist eine neue Version der Web-App verfügbar)
• Zwei-Wege-Kommunikation: Aufgaben an einen Service Worker delegieren (z.B. ein umfangreicher Download) und die Seite über den Fortschritt auf dem Laufenden zu halten.