Wspólną cechą jednostronicowych aplikacji internetowych (SPA) jest minimalny zestaw kodu HTML, CSS i JavaScript potrzebny do obsługi globalnej funkcjonalności aplikacji. W praktyce zwykle są to nagłówki, elementy nawigacyjne i inne typowe elementy interfejsu widoczne na wszystkich stronach. Gdy skrypt service worker wstępnie zapisuje w pamięci podręcznej kod HTML minimalnego interfejsu użytkownika i zasoby zależne, nazywamy to powłoką aplikacji.
Powłoka aplikacji odgrywa istotną rolę dla postrzeganej wydajności aplikacji internetowej. Jest to pierwsza rzecz, która wczytuje się, a dlatego jest też pierwszą rzeczą, którą widzą użytkownicy oczekujący na wypełnienie interfejsu.
Powłoka aplikacji szybko się ładuje (o ile sieć jest dostępna i co najmniej szybka) – skrypt service worker, który wstępnie buforuje powłokę aplikacji i powiązane z nią zasoby, zapewnia modelowi powłoki aplikacji te dodatkowe korzyści:
- Niezawodne i stałe wyniki przy kolejnych wizytach. Przy pierwszej wizycie w aplikacji bez zainstalowanego skryptu service worker trzeba wczytać znaczniki aplikacji i powiązane z nią zasoby z sieci, aby mógł on umieścić je w pamięci podręcznej. Jednak ponowna wizyta spowoduje pobranie powłoki aplikacji z pamięci podręcznej, co oznacza, że wczytywanie i renderowanie będzie odbywać się natychmiast.
- Niezawodny dostęp do funkcji w sytuacjach offline. Czasami połączenie z internetem jest niestabilne lub w ogóle nie ma go w ogóle albo pojawia się obawa „Nie możemy znaleźć tej witryny”. podnosi głowę. Model powłoki aplikacji rozwiązuje ten problem, odpowiadając na każde żądanie nawigacji przy użyciu znaczników powłoki aplikacji z pamięci podręcznej. Nawet jeśli użytkownik odwiedzi w Twojej aplikacji internetowej adres URL, który nigdy wcześniej nie był dostępny, powłoka aplikacji zostanie wyświetlona z pamięci podręcznej i może zawierać przydatne treści.
Kiedy należy używać modelu powłoki aplikacji
Powłoka aplikacji sprawdza się najlepiej, gdy masz typowe elementy interfejsu, które nie zmieniają się w zależności od trasy, ale zawierają treść. Większość aplikacji SPA prawdopodobnie używa już tego, co w praktyce jest już modelem powłoki aplikacji.
Jeśli właśnie tak wygląda Twój projekt i chcesz dodać skrypt service worker, aby zwiększyć jego niezawodność i wydajność, powłoka aplikacji powinna:
- Szybkie ładowanie.
- Używaj zasobów statycznych z instancji
Cache. - Dołącz wspólne elementy interfejsu, takie jak nagłówek i pasek boczny, rozdzielone od treści strony.
- Pobieranie i wyświetlanie treści dotyczących określonej strony.
- W razie potrzeby opcjonalnie buforuj zawartość dynamiczną, by można było przeglądać ją w trybie offline.
Powłoka aplikacji wczytuje zawartość określonej strony dynamicznie przez interfejsy API lub treści zawarte w JavaScript. Powinna być też aktualizowana automatycznie w tym sensie, że jeśli znacznik powłoki aplikacji ulegną zmianie, aktualizacja skryptu service worker powinna automatycznie pobrać nową powłokę aplikacji i zapisać ją w pamięci podręcznej.
Kompiluję powłokę aplikacji
Powłoka aplikacji powinna istnieć niezależnie od treści, a jednocześnie zapewniać podstawę do umieszczania w niej treści. Powinien być jak najwęższy, z taką ilością przydatnych treści, która przy pierwszym pobieraniu będzie dla użytkownika wystarczająca.
Właściwe saldo zależy od aplikacji. Powłoka aplikacji aplikacji Trened To Thrill Jake'a Archibalda zawiera nagłówek z przyciskiem odświeżania umożliwiającym pobranie nowych treści z serwisu Flickr.
Znaczniki powłoki aplikacji mogą być różne w zależności od projektu, ale oto jeden przykład pliku index.html zawierającego schemat aplikacji:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>
Application Shell Example
</title>
<link rel="manifest" href="/manifest.json">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<link rel="stylesheet" type="text/css" href="styles/global.css">
</head>
<body>
<header class="header">
<!-- Application header -->
<h1 class="header__title">Application Shell Example</h1>
</header>
<nav class="nav">
<!-- Navigation items -->
</nav>
<main id="app">
<!-- Where the application content populates -->
</main>
<div class="loader">
<!-- Spinner/content placeholders -->
</div>
<!-- Critical application shell logic -->
<script src="app.js"></script>
<!-- Service worker registration script -->
<script>
if ('serviceWorker' in navigator) {
// Register a service worker after the load event
window.addEventListener('load', () => {
navigator.serviceWorker.register('/sw.js');
});
}
</script>
</body>
</html>
Niezależnie od tego, czy utworzysz powłokę aplikacji dla swojego projektu, musi ona spełniać te wymagania:
- Kod HTML powinien zawierać wyraźnie odizolowane obszary z poszczególnymi elementami interfejsu. W powyższym przykładzie są to nagłówek aplikacji, elementy nawigacyjne, główny obszar treści i miejsce na wskaźnik ładowania. który pojawia się tylko podczas wczytywania treści.
- Początkowy kod JavaScript i CSS wczytane dla powłoki aplikacji powinien być ograniczony i odnosić się wyłącznie do funkcjonalności samej powłoki aplikacji, a nie jej zawartości. Dzięki temu aplikacja będzie jak najszybciej renderować powłokę i minimalizuje pracę wątku głównego do momentu wyświetlenia treści.
- Wbudowany skrypt rejestrujący skrypt service worker.
Po skompilowaniu powłoki aplikacji możesz utworzyć skrypt service worker, który będzie buforował zarówno ją, jak i jej zasoby.
Buforowanie powłoki aplikacji
Powłoka aplikacji i jej wymagane zasoby są tym, w których skrypt service worker powinien natychmiast umieścić dane wstępne w pamięci podręcznej podczas instalacji. Zakładając powłokę aplikacji taką jak w przykładzie powyżej, zobaczmy, jak można to zrobić w podstawowym przykładzie z Workbox przy użyciu workbox-build:
// build-sw.js
import {generateSW} from 'workbox-build';
// Where the generated service worker will be written to:
const swDest = './dist/sw.js';
generateSW({
swDest,
globDirectory: './dist',
globPatterns: [
// The necessary CSS and JS for the app shell
'**/*.js',
'**/*.css',
// The app shell itself
'shell.html'
],
// All navigations for URLs not precached will use this HTML
navigateFallback: 'shell.html'
}).then(({count, size}) => {
console.log(`Generated ${swDest}, which precaches ${count} assets totaling ${size} bytes.`);
});
Ta konfiguracja przechowywana w build-sw.js importuje CSS i JavaScript aplikacji, w tym plik znaczników powłoki aplikacji zawarty w shell.html. Skrypt jest wykonywany w węźle w ten sposób:
node build-sw.js
Wygenerowany skrypt service worker zostanie zapisany w usłudze ./dist/sw.js i po zakończeniu zapisze ten komunikat:
Generated ./dist/sw.js, which precaches 5 assets totaling 44375 bytes.
Po załadowaniu strony skrypt service worker wstępnie zapisuje w pamięci podręcznej znaczniki powłoki aplikacji i jej zależności:
Wstępne buforowanie kodu HTML, CSS i JavaScript powłoki aplikacji jest możliwe w prawie każdym przepływie pracy, także w projektach korzystających z modułów pakowania. W miarę postępów z dokumentacją nauczysz się, jak bezpośrednio używać Workbox do skonfigurowania łańcucha narzędzi w celu utworzenia skryptu service worker, który najlepiej sprawdzi się w Twoim projekcie, niezależnie od tego, czy jest to SPA.
Podsumowanie
Połączenie modelu powłoki aplikacji z skrypcją service worker świetnie nadaje się do buforowania offline, zwłaszcza jeśli połączysz jego funkcję wstępnego buforowania z działaniami bazującymi na sieci i powracaniem do strategii buforowania w przypadku znaczników i odpowiedzi interfejsu API. W rezultacie powłoka aplikacji jest niewiarygodnie szybka, a powłoka natychmiast renderuje się przy kolejnych wizytach, nawet w warunkach offline.