Co dzieje się w nawigacji
To druga i czteroczęściowa część naszej serii poświęconej pracy nad Chrome. W poprzednim poście pokazaliśmy, jak różne które obsługują różne części przeglądarki. W tym poście dokładniej omawiamy, każdy proces i wątek komunikują się, by wyświetlić stronę internetową.
Przeanalizujmy prosty przypadek użycia internetu: wpisujesz adres URL w przeglądarce, a następnie pobiera dane z internetu i wyświetla stronę. W tym poście skupimy się na części, w której użytkownik wysyła żądanie witryny, a przeglądarka przygotowuje się do renderowania strony, zwanej też nawigacją.
Rozpoczyna się od procesu przeglądarki
Jak już wspominaliśmy część 1. Procesor, GPU, pamięć i architektura wieloprocesowa, wszystko poza kartą jest obsługiwane przez proces przeglądarki. Proces przeglądarki składa się z wątków takich jak wątek UI, który rysuje przyciski i pola do wprowadzania danych przeglądarki, czyli wątku sieciowego, który zajmuje się stosem sieciowym do odbierania danych z internetu. wątek pamięci masowej, który kontroluje dostęp m.in. do plików. Po wpisaniu adresu URL w adresie dane wejściowe są obsługiwane przez wątek interfejsu użytkownika procesu przeglądarki.
Prosta nawigacja
Krok 1. Obsługa danych wejściowych
Gdy użytkownik zaczyna wpisywać tekst na pasku adresu, w pierwszej kolejności pyta: „Czy to wyszukiwane hasło lub adres URL?”. W Chrome pasek adresu jest też polem wyszukiwania, więc wątek UI musi przeanalizować i zdecydować, czy przekierować Cię do wyszukiwarki, czy do żądanej witryny.
Krok 2. Rozpocznij nawigację
Gdy użytkownik naciśnie klawisz Enter, wątek UI inicjuje wywołanie sieciowe w celu pobrania treści witryny. Wskaźnik postępu ładowania jest wyświetlany w rogu karty, a wątek sieciowy przechodzi przez odpowiednie protokoły, takie jak wyszukiwanie DNS i nawiązywanie połączenia TLS dla żądania;
W tym momencie wątek sieciowy może otrzymać nagłówek przekierowania serwera, taki jak HTTP 301. W takim przypadku wątek sieci komunikuje się z wątkiem interfejsu, że serwer żąda przekierowania. Następnie: zostanie zainicjowane kolejne żądanie adresu URL.
Krok 3. Przeczytaj odpowiedź
Gdy treść odpowiedzi (ładunek) zacznie przychodzić, wątek sieciowy przeszuka pierwsze kilka bajtów ze strumienia, jeśli to konieczne. Nagłówek Content-Type odpowiedzi powinien zawierać typ danych ale ponieważ może jej brakować lub być błędny, Wykrywanie typu MIME można zrobić tutaj. To jest „trafny biznes” zgodnie z komentarzem w kodzie źródłowym. Możesz przeczytać komentarz, aby zobaczyć, jak różne przeglądarki traktują pary typ treści i ładunek.
Jeśli odpowiedzią jest plik HTML, następnym krokiem jest przekazanie danych do mechanizmu renderowania ale jeśli jest to plik ZIP lub inny, oznacza to, że jest to żądanie pobrania. muszą przekazać te dane menedżerowi pobierania.
W tym miejscu odbywa się też sprawdzanie SafeBrowsing. Jeśli domena i dane odpowiedzi pasują do znanej złośliwej witryny, wątek sieciowy alerty, aby wyświetlić stronę z ostrzeżeniem. Dodatkowo: Więcej zacisku Pi blokady (CORB) w celu zagwarantowania, że poufne dane które nie są przekazywane do mechanizmu renderowania.
Krok 4. Znajdź proces renderowania
Po zakończeniu wszystkich testów i ustaleniu, że wątek sieciowy będzie pewny, że przeglądarka powinna przejść do z żądanej witryny, wątek sieci informuje wątek UI, że dane są gotowe. i znajduje mechanizm renderowania, który umożliwia renderowanie strony internetowej.
Ponieważ odpowiedź na żądanie sieciowe może zająć kilkaset milisekund, stosuje się optymalizację w celu przyspieszenia tego procesu. Gdy wątek UI wysyła żądanie adresu URL do wątku sieci w kroku 2, wie już, do której witryny prowadzi użytkownik. Wątek UI próbuje proaktywnie znaleźć lub uruchomić proces mechanizmu renderowania równoległego do żądania sieciowego. W ten sposób Jeśli wszystko idzie zgodnie z oczekiwaniami, proces renderowania jest już w stanie gotowości, gdy wątek sieciowy otrzymane dane. Ten proces gotowości może nie zostać użyty, jeśli nawigacja przekierowuje użytkownika między witrynami, w W takim przypadku konieczny może być inny proces.
Krok 5. Zatwierdź nawigację
Dane i proces renderowania są gotowe, więc kod IPC jest wysyłany z procesu przeglądarki do mechanizmu renderowania, aby zatwierdzić nawigację. Przekazuje też strumień danych, więc mechanizm renderowania może nadal otrzymywać dane HTML. Gdy proces przeglądarki usłyszy potwierdzenie, że zatwierdzenie w procesie renderowania, nawigacja została ukończona, a faza wczytywania dokumentu.
Na tym etapie pasek adresu zostanie zaktualizowany, a wskaźnik bezpieczeństwa i interfejs ustawień witryny będą odzwierciedlać o nowej stronie. Historia sesji na tej karcie zostanie zaktualizowana, tak żeby można było przejść wstecz/do przodu będą przechodzić przez witrynę, która właśnie została odwiedzona. Ułatwianie przywracania kart/sesji po zamknięciu karty lub okna historia sesji jest zapisywana na dysku.
Dodatkowy krok: wczytywanie początkowe ukończone
Po zatwierdzeniu nawigacji proces renderowania kontynuuje wczytywanie zasobów i renderuje
stronę. W następnym poście omówimy szczegółowo, co będzie się działo na tym etapie. Gdy mechanizm renderowania
proces „kończy się” wysyła kod IPC z powrotem do procesu przeglądarki (to jest koniec
Zdarzenia (onload) uruchomiły się we wszystkich klatkach na stronie i zakończyły wykonanie). W tym momencie
wątek UI zatrzymuje wskaźnik ładowania na karcie.
Mówię „zakończy się”, ponieważ JavaScript po stronie klienta wciąż może się ładować i wyrenderuj nowe widoki.
Przechodzenie do innej witryny
Prosta nawigacja jest gotowa! Ale co się stanie, jeśli użytkownik wpisze na pasku adresu inny URL?
? Proces przejścia do innej witryny przebiega w ten sam sposób.
Zanim będzie to możliwe, musi jednak sprawdzić, czy w aktualnie renderowanej witrynie jest to ważne.
beforeunload.
beforeunload może tworzyć opcję „Opuścić tę stronę?”. ostrzeżenie przy próbie przejścia na inną stronę lub zamknięcia karty.
Mechanizm renderowania obsługuje wszystko, co znajduje się na karcie, w tym kod JavaScript,
gdy pojawi się nowe żądanie nawigacji, proces przeglądarki musi sprawdzić bieżący proces mechanizmu renderowania.
Jeśli nawigacja została zainicjowana przez proces renderowania (np. użytkownik kliknął link lub
JavaScript po stronie klienta uruchomił window.location = "https://newsite.com") proces renderowania
najpierw sprawdza beforeunload modułów obsługi. Następnie przechodzi przez ten sam proces co przeglądarka.
zainicjowano nawigację. Jedyną różnicą jest to, że żądanie nawigacji jest wysyłane z
mechanizm renderowania w procesie przeglądarki.
Gdy nowa nawigacja trafia do innej witryny niż obecnie renderowana, w interfejsie renderowanym jest
jest wywoływany do obsługi nowej nawigacji, podczas gdy bieżący proces renderowania jest wywoływany
obsługuje zdarzenia takie jak unload. Więcej informacji znajdziesz w omówieniu stanów cyklu życia strony.
i ciesz się zdarzeniami,
Page Lifecycle API.
W przypadku skryptu service worker
Jedną z niedawnych zmian w tym procesie nawigacji jest wprowadzenie skryptor service worker. Skrypt service worker jest sposobem zapisu sieciowy serwer proxy w kodzie aplikacji; dzięki której twórcy stron internetowych mają większą kontrolę nad tym, co mogą buforować lokalnie i kiedy pobrać nowe dane z sieci. Jeśli skrypt service worker jest skonfigurowany do wczytywania strony z pamięci podręcznej, nie ma potrzeby pobierania danych z sieci.
Ważne jest, aby pamiętać, że skrypt service worker jest kodem JavaScript, który jest uruchamiany w mechanizmie renderowania. proces tworzenia konta. Jak jednak po otrzymaniu żądania nawigacji przeglądarka wie, że witryna skrypt service worker?
Gdy skrypt service worker jest zarejestrowany, jego zakres jest zachowywany jako odwołanie (więcej informacji o zakresie znajdziesz w tym artykule Cykl życia mechanizmów Service Worker). Gdy następuje nawigacja, wątek sieciowy sprawdza domenę pod kątem zarejestrowanego skryptu service worker zakresów, to jeśli dla tego adresu URL jest zarejestrowany skrypt service worker, wątek UI znajduje proces renderowania na wykonanie kodu skryptu service worker. Skrypt service worker może być ładowany z pamięci podręcznej, co eliminuje żądania danych z sieci lub nowych zasobów.
Wstępne wczytywanie nawigacji
Jak widać, błąd ten może powodować opóźnienia. jeśli skrypt service worker w końcu zdecyduje się zażądać danych z sieci. Wstępne wczytywanie nawigacji to mechanizm przyspieszający przez wczytywanie zasobów równolegle ze uruchamianiem skryptu service worker. Oznacza te żądania nagłówkiem, pozwalając serwerom na wysyłanie różnych treści tych żądań; na przykład tylko zaktualizowane dane zamiast całego dokumentu.
Podsumowanie
W tym poście pokazaliśmy, co dzieje się podczas nawigacji i jak kod aplikacji internetowej , a kod JavaScript po stronie klienta współdziała z przeglądarką. Przeglądarka kroków pobiera dane z sieci, ułatwiając zrozumienie, dlaczego interfejsy API takie jak nawigacja przedwczesnego wczytywania. W następnym poście dowiemy się, jak przeglądarka ocenia HTML/CSS/JavaScript do renderowania stron.
Podobał Ci się post? Jeśli masz pytania lub sugestie dotyczące przyszłych postów, chętnie na nie odpowiem skontaktuj się z Tobą w sekcji komentarzy poniżej lub @kosamari na Twitterze.