Typowa cecha architektoniczna aplikacji internetowych z jedną stroną to minimalny zestaw kodu HTML, CSS i JavaScript potrzebny do obsługi globalnej funkcji aplikacji. W praktyce są to zazwyczaj nagłówek, elementy nawigacyjne i inne elementy interfejsu, które występują na wszystkich stronach. Gdy skrypt service worker wstępnie zapisuje w pamięci podręcznej kod HTML i zasoby zależne interfejsu, jest to tzw. powłoka aplikacji.
Powłoka internetowa odgrywa ważną rolę w postrzeganiu wydajności aplikacji internetowej. Jest to pierwsza rzecz, która się wczytuje, a tym samym pierwszą rzeczą, jaką widzą użytkownicy podczas oczekiwania na pojawienie się treści w interfejsie.
Chociaż powłoka aplikacji szybko się wczytuje – o ile sieć jest dostępna i chociaż trochę szybka, skrypt service worker, który wstępnie zapisuje w pamięci podręcznej powłokę aplikacji i powiązane z nią zasoby, zapewnia modelowi powłoki te dodatkowe korzyści:
- Niezawodna i stała skuteczność w przypadku powtarzających się wizyt. Przy pierwszym otwarciu aplikacji bez zainstalowanego skryptu service worker znaczniki aplikacji i powiązane z nią zasoby muszą zostać wczytane z sieci, zanim mechanizm Service Worker będzie mógł umieścić je w pamięci podręcznej. Powtarzające się wizyty spowodują jednak pobranie powłoki aplikacji z pamięci podręcznej, co oznacza, że wczytywanie i renderowanie będzie natychmiastowe.
- Niezawodny dostęp do funkcji w trybie offline. Czasami dostęp do internetu jest przerywany lub w ogóle w ogóle go nie ma. Pojawia się wtedy przerażający ekran „Nie możemy znaleźć tej strony”. Model powłoki aplikacji rozwiązuje ten problem, odpowiadając na każde żądanie nawigacji z użyciem znaczników powłoki aplikacji z pamięci podręcznej. Nawet jeśli użytkownik otworzy w Twojej aplikacji internetowej adres URL, który nie był wcześniej przez Ciebie odwiedzany, powłoka aplikacji zostanie wyświetlona z pamięci podręcznej i może być wypełniona przydatną treścią.
Kiedy należy używać modelu powłoki aplikacji
Powłoka aplikacji ma największy sens, gdy typowe elementy interfejsu użytkownika nie zmieniają się w zależności od trasy, ale treść już tak. Większość aplikacji jednostronicowych prawdopodobnie korzysta już z modelu powłoki aplikacji.
Jeśli to opisuje 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. - Uwzględnić typowe elementy interfejsu, takie jak nagłówek i pasek boczny, niezależnie od treści strony.
- Pobierz i wyświetl zawartość stron.
- W razie potrzeby opcjonalnie zapisz zawartość dynamiczną w pamięci podręcznej do przeglądania offline.
Powłoka aplikacji dynamicznie wczytuje treści związane ze stronami przez interfejsy API lub treści w kodzie JavaScript. Aktualizuje się również automatycznie w tym sensie, że jeśli znaczniki powłoki aplikacji ulegną zmianie, skrypt service worker powinien pobrać nową powłokę i automatycznie ją buforować.
Kompilowanie powłoki aplikacji
Powłoka aplikacji powinna istnieć niezależnie od treści, a zarazem stanowić podstawę treści do wypełnienia. Najlepiej, gdyby był on jak najmniejszy, ale zawierał wystarczającą ilość treściwej treści na początku pobierania, aby użytkownik wiedział, że aplikacja szybko się wczytuje.
Równowaga zależy od aplikacji. Powłoka aplikacji Trened To Thrill Jake Archilda zawiera nagłówek z przyciskiem odświeżania, które pozwala pobierać nowe treści z serwisu Blogger.
Znaczniki powłoki aplikacji różnią się w zależności od projektu. Oto przykład pliku index.html, który zawiera 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, jak tworzysz powłokę aplikacji na potrzeby swojego projektu, musi ona mieć te cechy:
- Kod HTML powinien zawierać wyraźnie wyodrębnione obszary dla poszczególnych elementów interfejsu użytkownika. W powyższym przykładzie obejmuje to nagłówek aplikacji, nawigację, główny obszar treści i miejsce na wskaźnik wczytywania, który pojawia się tylko podczas wczytywania treści.
- Początkowy kod JavaScript i kod CSS wczytywany do powłoki aplikacji powinny być minimalne i odnosić się wyłącznie do funkcjonalności powłoki aplikacji, a nie do jej treści. Dzięki temu aplikacja będzie renderować powłokę tak szybko, jak to możliwe, a praca z wątkami głównymi minimalizuje się do czasu pojawienia się treści.
- Wbudowany skrypt rejestrujący skrypt service worker.
Po zbudowaniu powłoki aplikacji możesz utworzyć skrypt service worker, który będzie buforował zarówno tę aplikację, jak i jej zasoby.
Buforowanie powłoki aplikacji
Powłoka aplikacji i jej wymagane zasoby to elementy, które skrypt service worker powinien wstępnie buforować podczas instalacji. Przyjmijmy, że powłoka aplikacji jest taka sama jak w przykładzie powyżej. Zrobimy to w podstawowym przykładzie z polem 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 zapisana w pliku build-sw.js importuje pliki CSS i JavaScript aplikacji, w tym plik znaczników powłoki aplikacji zawarty w pliku shell.html. Skrypt jest uruchamiany w węźle w ten sposób:
node build-sw.js
Wygenerowany skrypt service worker jest zapisywany w systemie ./dist/sw.js i po zakończeniu zapisze ten komunikat:
Generated ./dist/sw.js, which precaches 5 assets totaling 44375 bytes.
Po wczytaniu strony skrypt service worker zapisuje w pamięci podręcznej znaczniki powłoki aplikacji i ich zależności:
Przygotowanie do zapisywania kodu HTML, CSS i JavaScript powłoki aplikacji jest możliwe w niemal każdym przepływie pracy, w tym w projektach korzystających z programów tworzenia pakietów. Z dokumentacji dowiesz się, jak bezpośrednio używać Workbox do konfigurowania łańcucha narzędzi do tworzenia skryptu service worker, który najlepiej sprawdza się w przypadku danego projektu – niezależnie od tego, czy jest to SPA.
Podsumowanie
Połączenie modelu powłoki aplikacji z mechanizmem Service Worker świetnie się sprawdza w przypadku buforowania w trybie offline, zwłaszcza gdy połączysz jego funkcje wstępnego buforowania z działalnością głównie na sieci i Powrót do strategii pamięci podręcznej w przypadku znaczników lub odpowiedzi interfejsu API. W efekcie otrzymujemy niezawodnie szybkie i natychmiast wyrenderowane powłokę aplikacji przy kolejnych wizytach, nawet w trybie offline.