TL;DR: interfejs Extensions API obsługuje pamięć podręczną stanu strony internetowej z wyprzedzeniem wczytywania nawigacji. Więcej informacji znajdziesz poniżej.
W Chrome ciężko pracujemy nad przyspieszeniem nawigacji. Szybka nawigacja technologie takie jak pamięć podręczna stanu strony internetowej (wysłano na komputerze w Chrome 96) i reguły spekulacyjne (wysłany w Chrome 103) usprawnia i przyspiesza działanie i uzyskiwanie dodatkowych informacji. W tym poście omówimy zmiany, jakie wprowadziliśmy w przeglądarce. interfejsów API rozszerzeń do obsługi nowych przepływów pracy.
Omówienie typów stron
Przed wprowadzeniem pamięci podręcznej stanu strony internetowej i renderowania wstępnego karta miała tylko jedną aktywną stronę. To był zawsze ten, który był widoczny. Jeśli użytkownik wróci na poprzednią stronę, aktywna strona zostanie zniszczona (strona B) a poprzednia strona w historii zostałaby całkowicie zrekonstruowana (strona A). Rozszerzenia nie musiały martwić się o to, jaką część stron cyklu życia ponieważ istnieje tylko jedna karta – aktywny/widoczny.
Dzięki pamięci podręcznej stanu strony internetowej i renderowaniu wstępnym nie ma już możliwości kontaktu z klientami. relacji między kartami i stronami. Każda karta zawiera teraz strony i strony przechodzące między stanami zamiast niszczenia odbudowa.
Na przykład strona może zacząć działać jako wstępnie wyrenderowana (niewidoczna) strona, przejście do aktywnej (widocznej) strony, gdy użytkownik kliknie link, zostaną zapisane w pamięci podręcznej stanu strony internetowej (niewidoczne), gdy użytkownik przechodzi do strony kolejną stronę bez jej zniszczenia. W dalszej części tego artykułu Przyjrzymy się nowym właściwościom, które pomogą rozszerzeniom zrozumieć, co w różnych stanach.
Pamiętaj, że karta może zawierać serię wstępnie renderowanych stron (a nie tylko jedną), aktywnej (widocznej) oraz serię stron w pamięci podręcznej stanu strony internetowej.
Co się zmienia dla deweloperów rozszerzeń?
FrameId == 0
W Chromium najwyższą/główną ramką nazywamy ramką najbardziej zewnętrzną.
Autorzy rozszerzeń, którzy zakładają identyfikator frameId
0 (wcześniejszej sprawdzonej metody) mogą powodować problemy.
Karta może teraz mieć wiele zewnętrznych klatek (wstępnie renderowanych i zapisanych w pamięci podręcznej).
stron), założenie, że istnieje jeden najbardziej zewnętrzny
ramka karty jest nieprawidłowa. frameId == 0 nadal będzie reprezentować
to najbardziej zewnętrzna klatka aktywnej strony, ale zewnętrzne ramki
inne strony na tej samej karcie będą miały wartość różną od zera. Nowe pole frameType zawiera
. Przeczytaj sekcję „Jak sprawdzić, czy klatka jest najbardziej zewnętrzną?”.
tego posta.
Cykl życia ramek a dokumentów
Innym problemem związanym z rozszerzeniami jest cykl życia ramki. Ramka zawiera dokument (powiązany z zatwierdzonym adresem URL). Dokument może się zmienić (np. w nawigacji), ale parametr frameId nie. trudno powiązać, że coś się wydarzyło w konkretnym dokumencie tylko frameIds. Wprowadzamy pojęcie documentId. czyli unikalny identyfikator każdego dokumentu. Jeśli poruszana jest klatka, otwiera nowy dokument, którego identyfikator się zmieni. To pole jest przydatne w przypadku określania, kiedy strony zmieniają swój stan cyklu życia (od prerenderowanie/aktywne/pamięci podręcznej), bo pozostaje bez zmian.
Zdarzenia nawigacji internetowej
Zdarzenia w przestrzeni nazw chrome.webNavigation
może uruchomić się wiele razy na
na tej samej stronie w zależności od cyklu życia, w którym się znajdują. Zobacz
„Jak mogę sprawdzić cykl życia strony?”
i „Jak mogę określić, kiedy strona przechodzi?”.
Jak mogę sprawdzić cykl życia strony?
DocumentLifecycle
do wielu interfejsów API rozszerzeń, w których parametr frameId był
wcześniej dostępnych. Jeśli w zdarzeniu występuje typ DocumentLifecycle
(np. onCommitted),
jego wartością jest stan, w którym zdarzenie zostało wygenerowane. Zawsze możesz zapytać
informacje z WebNavigation getFrame()
i getAllFrames()
ale zawsze preferowane jest użycie wartości ze zdarzenia. Jeśli używasz
każda z tych metod ma świadomość, że stan ramki może się zmienić w momencie wystąpienia zdarzenia
został wygenerowany i gdy zwrot obietnic pochodzący z obu metod zostanie rozwiązany.
DocumentLifecycle
ma następujące wartości:
"prerender′′ : obecnie nie przedstawiane użytkownikowi, ale przygotowuje się do ewentualnego wyświetlenia."active": aktualnie wyświetlane użytkownikowi."cached": element zapisany w pamięci podręcznej stanu strony internetowej."pending_deletion": dokument jest niszczony.
Jak ustalić, czy ramka jest najbardziej zewnętrzna?
Wcześniej rozszerzenia mogły sprawdzać, czy frameId == 0
czy zdarzenie dotyczy najbardziej zewnętrznej klatki. Zawiera wiele stron
na karcie mamy teraz wiele zewnętrznych ramek, więc definicja identyfikatora frameId
stanowi problem. Nigdy nie będziesz otrzymywać zdarzeń dotyczących kopii zapasowej w pamięci podręcznej
ramki. Jednak w przypadku wstępnie renderowanych klatek parametr frameId będzie
ma wartość inną niż zero dla najbardziej zewnętrznej klatki. Używaj frameId == 0 jako sygnału dla:
co pozwala określić, czy jest to najbardziej zewnętrzna klatka.
Aby Ci w tym pomóc, wprowadziliśmy nowy typ:
FrameType
więc ustalenie, czy klatka jest rzeczywiście najbardziej zewnętrzna, jest teraz łatwe.
FrameType ma następujące wartości:
"outermost_frame": zwykle zwana klatką najwyższego poziomu. Pamiętaj, że że są ich wielokrotności. Na przykład, jeśli masz wstępnie renderowany i zapisywany w pamięci podręcznej strony, z których każda ma najbardziej zewnętrzną ramkę, którą można nazwać najwyższą ramką."fenced_frame": zarezerwowane do użycia w przyszłości."sub_frame": zwykle element iframe.
Możemy połączyć elementy DocumentLifecycle z parametrem FrameType i określić, czy ramka jest
czyli aktywnej, najbardziej zewnętrznej ramki. Na przykład: tab.documentLifecycle === “active” && frameType === “outermost_frame”
Jak rozwiązywać problemy z czasem użytkowania w przypadku ramek?
Jak wspomnieliśmy powyżej, ramka zawiera dokument, a klatka może przejść do nowego elementu.
dokument, ale frameId się nie zmieni. Powoduje to problemy, gdy
otrzymają wydarzenie z tylko urządzeniem frameId. Jeśli wyszukasz adres URL
może być inna niż moment wystąpienia zdarzenia. Jest to tzw.
problemu w czasie użytkowania.
Aby rozwiązać ten problem, wprowadziliśmy documentId.
(i parentDocumentId).
Metoda webNavigation.getFrame()
teraz atrybut frameId jest opcjonalny, jeśli podano documentId.
Wartość documentId będzie się zmieniać przy każdym przejściu do klatki.
Jak określić, kiedy strona się wyświetla?
Istnieją wyraźne sygnały wskazujące na to, kiedy strona przechodzi między stanami.
Przyjrzyjmy się zdarzeniom WebNavigation.
Przy pierwszej nawigacji na stronie są wyświetlane cztery zdarzenia w kolejności
wymienionych poniżej. Pamiętaj, że te cztery zdarzenia mogą wystąpić w
DocumentLifecycle może mieć stan "prerender" lub "active".
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
Widać to na schemacie poniżej, który pokazuje zmianę documentId.
na "xyz", gdy wstępnie renderowana strona stanie się stroną aktywną.
documentId zmienia się, gdy wstępnie renderowana strona staje się
aktywną stronę.Gdy strona przechodzi z pamięci podręcznej stanu strony internetowej lub jest wstępnie renderowana
w stanie aktywności będą widoczne jeszcze 3 zdarzenia (ale DocumentLifecyle
będąc "active").
onBeforeNavigate
onCommitted
onCompleted
Element documentId pozostanie taki sam jak w oryginalnych wydarzeniach. To jest
pokazane powyżej, gdy aktywuje się documentId == xyz. Pamiętaj, że parametr
uruchamiają się te same zdarzenia nawigacji, z wyjątkiem zdarzeń onDOMContentLoaded
ponieważ strona została już wczytana.
Jeśli masz jakieś pytania lub komentarze, skontaktuj się z rozszerzenia-chromos grupy reklam.