Frontend Service Worker-navigering: Avlyssning av sidladdningar för förbättrad användarupplevelse

Service Workers är en kraftfull teknik som gör att du kan avlyssna nätverksförfrågningar, cachelagra resurser och tillhandahålla offline-funktionalitet för webbapplikationer. En av de mest effektiva funktionerna är att avlyssna sidladdningsförfrågningar, vilket gör att du dramatiskt kan förbättra prestandan och användarupplevelsen. Det här inlägget kommer att utforska hur Service Workers hanterar navigeringsförfrågningar och ger praktiska exempel och handlingsbara insikter för utvecklare.

Förstå navigeringsförfrågningar

Innan vi dyker in i koden, låt oss definiera vad en "navigeringsförfrågan" är i samband med Service Workers. En navigeringsförfrågan är en förfrågan som initieras av användaren som navigerar till en ny sida eller uppdaterar den aktuella sidan. Dessa förfrågningar utlöses vanligtvis av:

• Klicka på en länk (<a>-tagg)
• Skriva en webbadress i adressfältet
• Uppdatera sidan
• Använda webbläsarens bakåt- eller framåtknappar

Service Workers har förmågan att avlyssna dessa navigeringsförfrågningar och avgöra hur de ska hanteras. Detta öppnar upp möjligheter att implementera sofistikerade cachelagringsstrategier, leverera innehåll från cachen när användaren är offline och till och med generera sidor dynamiskt på klientsidan.

Registrera en Service Worker

Det första steget är att registrera en Service Worker. Detta görs vanligtvis i din huvudsakliga JavaScript-fil:

            
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js')
    .then(registration => {
      console.log('Service Worker registrerad med omfång:', registration.scope);
    })
    .catch(error => {
      console.error('Service Worker-registrering misslyckades:', error);
    });
}

            

              
                Copy
              
            
          

Denna kod kontrollerar om webbläsaren stöder Service Workers och, om så är fallet, registrerar filen /service-worker.js. Se till att den här JavaScript-koden körs i ett säkert sammanhang (HTTPS) för produktionsmiljöer.

Avlyssna navigeringsförfrågningar i Service Worker

Inuti din service-worker.js-fil kan du lyssna efter händelsen fetch. Denna händelse utlöses för varje nätverksförfrågan som görs av din applikation, inklusive navigeringsförfrågningar. Vi kan filtrera dessa förfrågningar för att hantera navigeringsförfrågningar specifikt.

            
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    event.respondWith(async () => {
      try {
        // Försök först att använda navigationsförladdningssvaret om det stöds.
        const preloadResponse = await event.preloadResponse;
        if (preloadResponse) {
          return preloadResponse;
        }

        // Försök alltid med nätverket först.
        const networkResponse = await fetch(event.request);
        return networkResponse;
      } catch (error) {
        // catch utlöses bara om ett undantag kastas, vilket troligen är
        // på grund av ett nätverksfel.
        // Om det inte går att hämta HTML-filen, leta efter en reserv.
        console.log('Hämtning misslyckades; returnerar istället offlinesida.', error);

        const cache = await caches.open(CACHE_NAME);
        const cachedResponse = await cache.match(OFFLINE_URL);
        return cachedResponse || createErrorResponse(); // Fallback om offlinesidan inte är tillgänglig
      }
    });
  }
});

            

              
                Copy
              
            
          

Låt oss bryta ner den här koden:

• event.request.mode === 'navigate': Denna villkorliga sats kontrollerar om förfrågan är en navigeringsförfrågan.
• event.respondWith(): Denna metod talar om för webbläsaren hur förfrågan ska hanteras. Den tar ett löfte som löses till ett Response-objekt.
• event.preloadResponse: Detta är en mekanism som kallas Navigationsförladdning. Om den är aktiverad tillåter den webbläsaren att börja hämta navigeringsförfrågan innan Service Workern är helt aktiv. Den ger en hastighetsförbättring genom att överlappa Service Workerns starttid med nätverksförfrågan.
• fetch(event.request): Detta hämtar resursen från nätverket. Om nätverket är tillgängligt kommer sidan att laddas från servern som vanligt.
• caches.open(CACHE_NAME): Detta öppnar en cache med det angivna namnet (CACHE_NAME måste definieras någon annanstans i din Service Worker-fil).
• cache.match(OFFLINE_URL): Detta letar efter ett cachelagrat svar som matchar OFFLINE_URL (t.ex. en offlinesida).
• createErrorResponse(): Detta är en anpassad funktion som returnerar ett fel. Du kan anpassa den här funktionen för att tillhandahålla en användarvänlig offlineupplevelse.

Cachelagringsstrategier för navigeringsförfrågningar

Föregående exempel visar en grundläggande nätverk-först-strategi. Du kan dock implementera mer sofistikerade cachelagringsstrategier beroende på din applikations krav.

Nätverk först, återgår till cache

Detta är strategin som visas i föregående exempel. Den försöker först hämta resursen från nätverket. Om nätverksförfrågan misslyckas (t.ex. användaren är offline) återgår den till cachen. Detta är en bra strategi för innehåll som uppdateras ofta.

Cache först, uppdatering i bakgrunden

Denna strategi kontrollerar cachen först. Om resursen finns i cachen returneras den omedelbart. I bakgrunden uppdaterar Service Workern cachen med den senaste versionen av resursen från nätverket. Detta ger en snabb första laddning och säkerställer att användaren alltid får det senaste innehållet så småningom.

            
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      caches.match(event.request)
        .then(cachedResponse => {
          if (cachedResponse) {
            // Uppdatera cachen i bakgrunden.
            event.waitUntil(
              fetch(event.request).then(response => {
                return caches.open(CACHE_NAME).then(cache => {
                  return cache.put(event.request, response.clone());
                });
              })
            );
            return cachedResponse;
          }

          // Om den inte hittades i cachen, hämta från nätverket.
          return fetch(event.request);
        })
    );
  }
});

            

              
                Copy
              
            
          

Endast cache

Denna strategi levererar bara innehåll från cachen. Om resursen inte hittas i cachen misslyckas förfrågan. Detta är lämpligt för tillgångar som är kända för att vara statiska och tillgängliga offline.

Stale-While-Revalidate

Liknar Cache First, men istället för att uppdatera i bakgrunden med event.waitUntil, returnerar du omedelbart det cachelagrade svaret (om det finns) och *försöker alltid* hämta den senaste versionen från nätverket och uppdatera cachen. Denna metod ger en mycket snabb initial laddning, eftersom användaren får den cachelagrade versionen direkt, men den garanterar att cachen så småningom uppdateras med den senaste datan, redo för nästa begäran. Detta är utmärkt för icke-kritiska resurser eller situationer där det är acceptabelt att visa något inaktuell information en kort stund i utbyte mot hastighet.

            
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      caches.open(CACHE_NAME).then(cache => {
        return cache.match(event.request).then(cachedResponse => {
          const fetchedResponse = fetch(event.request).then(networkResponse => {
            cache.put(event.request, networkResponse.clone());

            return networkResponse;
          });

          // Returnera det cachelagrade svaret om vi har det, annars vänta
          // på nätverket.
          return cachedResponse || fetchedResponse;
        });
      })
    );
  }
});

            

              
                Copy
              
            
          

Navigeringsförladdning

Navigeringsförladdning är en funktion som gör att webbläsaren kan börja hämta resursen innan Service Workern är helt aktiv. Detta kan avsevärt förbättra prestandan för navigeringsförfrågningar, särskilt vid det första besöket på din webbplats.

För att aktivera Navigeringsförladdning måste du:

1. Aktivera den i händelsen activate för din Service Worker.
2. Kontrollera preloadResponse i händelsen fetch.

            
// I activate-händelsen:
self.addEventListener('activate', event => {
  event.waitUntil(self.registration.navigationPreload.enable());
});

// I fetch-händelsen (som visas i det första exemplet):
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    event.respondWith(async () => {
      const preloadResponse = await event.preloadResponse;
      if (preloadResponse) {
        return preloadResponse;
      }

      // ... resten av din hämtningslogik ...
    });
  }
});

            

              
                Copy
              
            
          

Hantering av offlinescenarier

En av de främsta fördelarna med att använda Service Workers är möjligheten att tillhandahålla offline-funktionalitet. När användaren är offline kan du visa en cachelagrad version av din applikation eller visa en anpassad offlinesida.

För att hantera offlinescenarier måste du:

1. Cachelagra nödvändiga tillgångar, inklusive din HTML, CSS, JavaScript och bilder.
2. I händelsen fetch ska du fånga eventuella nätverksfel och visa en cachelagrad offlinesida.

            
// Definiera webbadressen till offlinesidan och cache-namnet
const OFFLINE_URL = '/offline.html';
const CACHE_NAME = 'my-app-cache-v1';

// Installera händelse: cache statiska tillgångar
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/style.css',
        '/app.js',
        OFFLINE_URL // Cachelagra offlinesidan
      ]);
    })
  );
  self.skipWaiting(); // Aktivera Service Workern omedelbart
});

// Fetch-händelse: hantera navigeringsförfrågningar och offline-fallback
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    event.respondWith(async () => {
      try {
        // Försök först att använda navigationsförladdningssvaret om det stöds.
        const preloadResponse = await event.preloadResponse;
        if (preloadResponse) {
          return preloadResponse;
        }

        // Försök alltid med nätverket först.
        const networkResponse = await fetch(event.request);
        return networkResponse;
      } catch (error) {
        // catch utlöses bara om ett undantag kastas, vilket troligen är
        // på grund av ett nätverksfel.
        // Om det inte går att hämta HTML-filen, leta efter en reserv.
        console.log('Hämtning misslyckades; returnerar istället offlinesida.', error);

        const cache = await caches.open(CACHE_NAME);
        const cachedResponse = await cache.match(OFFLINE_URL);
        return cachedResponse || createErrorResponse(); // Fallback om offlinesidan inte är tillgänglig
      }
    });
  }
});

function createErrorResponse() {
    return new Response(
        `
Offline
Du är för närvarande offline. Kontrollera din internetanslutning.
`, {
            headers: { 'Content-Type': 'text/html' }
        }
    );
}

            

              
                Copy
              
            
          

Den här koden cachelagrar en offline.html-sida under händelsen install. I händelsen fetch, om nätverksbegäran misslyckas (catch-blocket körs), kontrollerar den cachen för offline.html-sidan och returnerar den till webbläsaren.

Avancerade tekniker och överväganden

Använda Cache Storage API direkt

Objektet caches tillhandahåller ett kraftfullt API för att hantera cachelagrade svar. Du kan använda metoder som cache.put(), cache.match() och cache.delete() för att manipulera cachen direkt. Detta ger dig finkornig kontroll över hur resurser cachelagras och hämtas.

Dynamisk cachelagring

Förutom att cachelagra statiska tillgångar kan du också cachelagra dynamiskt innehåll, till exempel API-svar. Detta kan avsevärt förbättra prestandan för din applikation, särskilt för användare med långsamma eller opålitliga internetanslutningar.

Cacheversionering

Det är viktigt att versionera din cache så att du kan uppdatera de cachelagrade resurserna när din applikation ändras. En vanlig metod är att inkludera ett versionsnummer i CACHE_NAME. När du uppdaterar din applikation kan du öka versionsnumret, vilket tvingar webbläsaren att ladda ner de nya resurserna.

            
const CACHE_NAME = 'my-app-cache-v2'; // Öka versionsnumret

            

              
                Copy
              
            
          

Du måste också ta bort gamla cacheminnen för att förhindra att de ackumuleras och slösar bort lagringsutrymme. Du kan göra det i händelsen activate.

            
self.addEventListener('activate', event => {
  const cacheWhitelist = [CACHE_NAME];

  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

            

              
                Copy
              
            
          

Bakgrundssynkronisering

Service Workers tillhandahåller också Background Sync API, som gör att du kan skjuta upp uppgifter tills användaren har en stabil internetanslutning. Detta är användbart för scenarier som att skicka formulär eller ladda upp filer när användaren är offline.

Push-aviseringar

Service Workers kan också användas för att implementera push-aviseringar, som gör att du kan skicka meddelanden till dina användare även när de inte aktivt använder din applikation. Detta kan användas för att meddela användare om nytt innehåll, uppdateringar eller viktiga händelser.

Internationell (i18n) och lokalisering (L10n) Överväganden

När du implementerar Service Workers i en global applikation är det viktigt att ta hänsyn till internationalisering (i18n) och lokalisering (L10n). Här är några viktiga aspekter:

• Språkdetektering: Implementera en mekanism för att upptäcka användarens föredragna språk. Detta kan innebära att du använder HTTP-headern Accept-Language, en användarinställning eller webbläsare-API:er.
• Lokaliserat innehåll: Lagra lokaliserade versioner av dina offlinesidor och annat cachelagrat innehåll. Använd det upptäckta språket för att visa lämplig version. Du kan till exempel ha separata offlinesidor för engelska (/offline.en.html), spanska (/offline.es.html) och franska (/offline.fr.html). Din Service Worker skulle då dynamiskt välja rätt fil som ska cachelagras och visas baserat på användarens språk.
• Datum- och tidsformatering: Se till att alla datum och tider som visas på dina offlinesidor är formaterade enligt användarens språk. Använd JavaScripts Intl API för detta ändamål.
• Valutaformatering: Om din applikation visar valutavärden ska du formatera dem enligt användarens språk och valuta. Använd återigen Intl API för valutaformatering.
• Textriktning: Tänk på språk som läses från höger till vänster (RTL), till exempel arabiska och hebreiska. Dina offlinesidor och cachelagrat innehåll bör stödja RTL-textriktning med hjälp av CSS.
• Resursladdning: Ladda dynamiskt lokaliserade resurser (t.ex. bilder, teckensnitt) baserat på användarens språk.

Exempel: Val av lokaliserad offlinesida

            
// Funktion för att hämta användarens önskade språk
function getPreferredLanguage() {
  // Det här är ett förenklat exempel. I en riktig applikation,
  // skulle du använda en mer robust språkdetekteringsmekanism.
  return navigator.language || navigator.userLanguage || 'en';
}

// Definiera en mappning av språk till webbadresser för offlinesidor
const offlinePageUrls = {
  'en': '/offline.en.html',
  'es': '/offline.es.html',
  'fr': '/offline.fr.html'
};

// Hämta användarens önskade språk
const preferredLanguage = getPreferredLanguage();

// Bestäm webbadressen till offlinesidan baserat på önskat språk
let offlineUrl = offlinePageUrls[preferredLanguage] || offlinePageUrls['en']; // Standard till engelska om ingen matchning

// ... resten av din service worker-kod, med hjälp av offlineUrl för att cachelagra och visa lämplig offlinesida ...

            

              
                Copy
              
            
          

Testning och felsökning

Att testa och felsöka Service Workers kan vara utmanande. Här är några tips:

• Använd Chrome DevTools: Chrome DevTools tillhandahåller en dedikerad panel för att inspektera Service Workers. Du kan använda den här panelen för att visa statusen för din Service Worker, inspektera cachelagrade resurser och felsöka nätverksförfrågningar.
• Använd Service Worker Update on Reload: I Chrome DevTools -> Application -> Service Workers kan du markera "Uppdatera vid omladdning" för att tvinga Service Workern att uppdatera vid varje sidoladdning. Detta är extremt användbart under utveckling.
• Rensa lagring: Ibland kan Service Workern hamna i ett dåligt tillstånd. Att rensa webbläsarens lagring (inklusive cachen) kan hjälpa till att lösa dessa problem.
• Använd ett bibliotek för testning av Service Worker: Det finns flera bibliotek tillgängliga som kan hjälpa dig att testa dina Service Workers, till exempel Workbox.
• Testa på riktiga enheter: Även om du kan testa Service Workers i en stationär webbläsare är det viktigt att testa på riktiga mobila enheter för att säkerställa att de fungerar korrekt under olika nätverksförhållanden.

Slutsats

Att avlyssna sidladdningsförfrågningar med Service Workers är en kraftfull teknik för att förbättra användarupplevelsen av webbapplikationer. Genom att implementera cachelagringsstrategier, tillhandahålla offline-funktionalitet och optimera nätverksförfrågningar kan du avsevärt förbättra prestandan och engagemanget. Kom ihåg att beakta internationalisering när du utvecklar för en global publik för att säkerställa en konsekvent och användarvänlig upplevelse för alla.

Den här guiden ger en solid grund för att förstå och implementera Service Worker-navigeringsavlyssning. När du fortsätter att utforska den här tekniken kommer du att upptäcka ännu fler sätt att utnyttja dess möjligheter för att skapa exceptionella webbupplevelser.