Chrome 85 domyślnie wyłącza obsługę pamięci podręcznej aplikacji. Większość deweloperów powinna już teraz przejść z pamięci podręcznej aplikacji i nie czekać.
W związku z wcześniejszymi ogłoszeniami wycofamy obsługę AppCache w Chrome i innych przeglądarkach opartych na Chromium. Zachęcamy deweloperów do przejścia z pamięci podręcznej aplikacji już teraz, bez oczekiwania.
Skrypty service worker, które są powszechnie obsługiwane w aktualnych przeglądarkach, stanowią alternatywę dla środowiska offline oferowanego przez AppCache. Zobacz Strategie migracji.
Oś czasu
Najnowsze zmiany w harmonogramie publikacji Chrome oznaczają, że harmonogramy niektórych z tych działań mogą się różnić. Postaramy się zaktualizować ten harmonogram, ale na tym etapie jak najszybciej przeprowadź migrację z AppCache, zamiast czekać na konkretne etapy.
„Wycofana” funkcja nadal istnieje, ale loguje komunikaty ostrzegawcze, które zniechęcają do jej użycia. „Usunięta” funkcja nie jest już dostępna w przeglądarce.
| Wycofanie w niezabezpieczonych kontekstach | Chrome 50 (kwiecień 2016 r.) |
| Usuwanie z niezabezpieczonych kontekstów | Chrome 70 (październik 2018 r.) |
| Wycofanie w bezpiecznych kontekstach | Chrome 79 (grudzień 2019 r.) |
| Ograniczenie zakresu AppCache | Chrome 80 (luty 2020 r.) |
| Rozpoczęcie testowania origin „Reverse” | Chrome 84 (lipiec 2020 r.) |
| Usuwanie z bezpiecznych kontekstów z wyjątkiem użytkowników, którzy wyrazili zgodę na testowanie origin | Chrome 85 (sierpień 2020 r.) |
| Całkowite usunięcie z bezpiecznych kontekstów dla wszystkich z zakończeniem testowania origin | 5 października 2021 r. (mniej więcej Chrome 95) |
Testowanie origin
Na osi czasu widać 2 kolejne etapy usuwania. Począwszy od Chrome 85, pamięć podręczna aplikacji nie będzie już domyślnie dostępna w Chrome. Deweloperzy, którzy potrzebują więcej czasu na migrację poza pamięć podręczną aplikacji, mogą zarejestrować się w ramach „odwrotnego” okresu próbnego, aby zwiększyć dostępność pamięci podręcznej aplikacji dla swoich aplikacji internetowych. Testowanie origin rozpocznie się w Chrome 84 (przed domyślnym usunięciem w Chrome 85) i będzie trwać do 5 października 2021 roku (mniej więcej w Chrome 95). Po tym czasie pamięć AppCache zostanie całkowicie usunięta u wszystkich użytkowników, nawet u osób, które zarejestrowały się na testowanie origin.
Aby wziąć udział w testowaniu odwrotnego pochodzenia:
- Poproś o token dla Twojego punktu początkowego.
- Dodaj token do stron HTML. Możesz to zrobić na 2 sposoby:
- Dodaj tag
origin-trial<meta>w nagłówku każdej strony. Przykład:<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - Możesz też skonfigurować serwer tak, aby zwracał odpowiedzi zawierające nagłówek HTTP
Origin-Trial. Nagłówek odpowiedzi powinien wyglądać mniej więcej tak:Origin-Trial: TOKEN_GOES_HERE
- Dodaj tag
- Dodaj ten sam token do plików manifestu AppCache. Zrób to za pomocą nowego pola w pliku manifestu w formacie:
ORIGIN-TRIAL:
TOKEN_GOES_HERE
(Między ORIGIN-TRIAL a Twoim tokenem musi być nowy wiersz).
Poniżej znajduje się przykładowy projekt pokazujący dodawanie prawidłowych tokenów próbnych origin do plików index.html i manifest.appcache.
Dlaczego tokeny są potrzebne w wielu miejscach?
Ten sam token próbny origin musi być powiązany z:
- Wszystkie strony HTML, które używają pamięci podręcznej aplikacji.
- Wszystkie pliki manifestu AppCache w polu manifestu
ORIGIN-TRIAL.
Jeśli w przeszłości zdarzyło Ci się korzystać z testów origin, token mógł zostać dodany tylko do stron HTML. Testowanie odwrotnego źródła AppCache jest wyjątkowe, ponieważ wymaga powiązania tokena z każdym plikiem manifestu AppCache.
Dodanie tokena próbnego origin do stron HTML włącza interfejs window.applicationCache z poziomu Twoich aplikacji internetowych. Strony, które nie są powiązane z tokenem, nie będą mogły korzystać z metod ani zdarzeń window.applicationCache. Strony bez tokena również nie będą mogły wczytywać zasobów z pamięci podręcznej aplikacji. Począwszy od Chrome 85, będą się one zachowywać tak, jakby pamięć podręczna aplikacji nie istniała.
Dodanie tokena próbnego origin do plików manifestu AppCache wskazuje, że każdy plik manifestu jest nadal prawidłowy. Począwszy od Chrome 85 wszystkie pliki manifestu bez pola ORIGIN-TRIAL będą traktowane jako uszkodzone, a reguły w pliku manifestu będą ignorowane.
Czas wdrożenia wersji próbnej origin i logistyka
Chociaż testowanie origin „reverse” oficjalnie rozpoczyna się w Chrome 84, już dziś zarejestruj się i dodaj tokeny do plików manifestu HTML i AppCache. W miarę jak użytkownicy Twojej aplikacji internetowej będą stopniowo uaktualniać Chrome do wersji 84, wszystkie dodane przez Ciebie tokeny zaczną obowiązywać.
Po dodaniu tokena do pliku manifestu AppCache otwórz about://appcache-internals, aby sprawdzić, czy lokalne wystąpienie Chrome (w wersji 84 lub nowszej) prawidłowo powiązało token próbny origin z wpisami w pamięci podręcznej pliku manifestu. Jeśli wersja próbna origin witryny została rozpoznana, na tej stronie powinno pojawić się pole z tekstem Token Expires: Tue Apr 06 2021... powiązane z Twoim plikiem manifestu:
Testowanie przed usunięciem
Zdecydowanie zalecamy jak najszybsze przeprowadzenie migracji danych z AppCache. Jeśli chcesz przetestować usuwanie pamięci podręcznej aplikacji w swoich aplikacjach internetowych, użyj flagi about://flags/#app-cache, aby symulować jego usunięcie. Ta flaga jest dostępna od Chrome 84.
Strategie migracji
Skrypty service worker, które są powszechnie obsługiwane w obecnych przeglądarkach, stanowią alternatywę dla środowiska offline udostępnianego przez AppCache.
Udostępniliśmy kod polyfill, który wykorzystuje skrypt service worker do replikacji niektórych funkcji AppCache, ale nie replikuje całego interfejsu AppCache. Nie zastępuje ona interfejsu window.applicationCache ani powiązanych zdarzeń AppCache.
W bardziej złożonych przypadkach biblioteki takie jak Workbox umożliwiają łatwe utworzenie nowoczesnego skryptu service worker do aplikacji internetowej.
Skrypty service worker i AppCache wzajemnie się wykluczają
Podczas opracowywania strategii migracji pamiętaj, że Chrome będzie wyłączać funkcję AppCache na każdej stronie, która jest ładowana pod kontrolą przez mechanizm Service Worker. Innymi słowy, gdy tylko wdrożysz mechanizm Service Worker kontrolujący daną stronę, nie będzie już można używać AppCache na tej stronie.
Z tego powodu odradzamy próby migracji do mechanizmów Service Worker pojedynczo. Wdrożenie skryptu service worker, który zawiera tylko część logiki buforowania, byłoby błędem. Nie można użyć pamięci podręcznej aplikacji, aby „wypełnić luki”.
Podobnie, jeśli wdrożysz skrypt service worker przed usunięciem pamięci podręcznej aplikacji, a następnie stwierdzisz, że musisz przywrócić poprzednią implementację AppCache, musisz go wyrejestrować. Dopóki istnieje zarejestrowany skrypt service worker w zakresie danej strony, pamięć podręczna aplikacji nie będzie używana.
Historia na wielu platformach
Zachęcamy do skontaktowania się z konkretnym dostawcą przeglądarek, aby uzyskać więcej informacji na temat jego planów usunięcia z pamięci podręcznej aplikacji.
Firefox na wszystkich platformach
Przeglądarka Firefox wycofała pamięć podręczną aplikacji w wersji 44 (wrzesień 2015 r.) i wycofała jej obsługę w wersjach beta i Nightly od września 2019 r.
Safari na urządzeniach z iOS i macOS.
Na początku 2018 r. Safari wycofała pamięć podręczną AppCache.
Chrome na system iOS
Szczególnym przypadkiem jest Chrome na iOS, ponieważ korzysta z innego silnika przeglądarki niż Chrome na innych platformach: WKWebView. Skrypty service worker nie są obecnie obsługiwane w aplikacjach na iOS korzystających z WKWebView, a ogłoszenie o usunięciu pamięci podręcznej aplikacji Chrome nie informuje o dostępności pamięci podręcznej aplikacji w Chrome na iOS. Pamiętaj o tym, jeśli wiesz, że Twoja aplikacja internetowa ma wielu użytkowników Chrome na iOS.
Komponenty WebView Androida
Niektórzy deweloperzy aplikacji na Androida używają WebView w Chrome do wyświetlania treści z internetu, ale mogą też używać pamięci podręcznej AppCache. Nie można jednak włączyć wersji próbnej origin komponentu WebView. W związku z tym komponent WebView Chrome będzie obsługiwać pamięć podręczną aplikacji bez testowania origin do momentu ostatecznego usunięcia (zgodnie z oczekiwaniami w Chrome 90).
Więcej informacji
Oto materiały dla programistów, którzy przechodzą z AppCache na mechanizmy Service Worker.
Artykuły
- Skrypty Service Workers: wprowadzenie
- Cykl życia mechanizmów Service Worker
- Szkolenie z progresywnych aplikacji internetowych
- Niezawodność sieci
Narzędzia,
Uzyskiwanie pomocy
Jeśli podczas korzystania z określonego narzędzia napotkasz problem, otwórz jego repozytorium na GitHubie.
Możesz zadać ogólne pytanie na temat migracji z pamięci podręcznej aplikacji na stronie Stack Overflow, używając tagu html5-appcache.
Jeśli natrafisz na błąd związany z usunięciem pamięci podręcznej aplikacji Chrome, zgłoś go, korzystając z narzędzia do śledzenia błędów Chromium.
Baner powitalny stworzony na podstawie organizacji Smithsonian Institution Archives, Acc. 11-007, Box 020, nr zdjęcia: MNH-4477.