Was passiert bei der Navigation?
Dieser Artikel ist der zweite Teil einer vierteiligen Blogreihe, in der es um die Funktionsweise von Chrome geht. Im vorherigen Post haben wir uns damit beschäftigt, Prozesse und Threads verarbeiten verschiedene Teile eines Browsers. In diesem Beitrag gehen wir näher darauf ein, alle Prozesse und Threads kommunizieren, um eine Website anzuzeigen.
Sehen wir uns einen einfachen Anwendungsfall für das Surfen im Web an: Sie geben eine URL in einen Browser ein, dann den ruft Daten aus dem Internet ab und zeigt eine Seite an. In diesem Beitrag konzentrieren wir uns auf den Teil, in dem ein Ein Nutzer eine Website anfordert und der Browser bereitet sich auf das Rendern der Seite vor. Dies wird auch als Navigation bezeichnet.
Es beginnt mit einem Browser-Prozess
<ph type="x-smartling-placeholder">![Browserprozesse](https://developer.chrome.com/static/blog/inside-browser-part2/image/browser-processes-1abcf214c73ef.png?authuser=6&hl=de)
Wie wir bereits in Teil 1: CPU-, GPU-, Arbeitsspeicher- und Multi-Prozess-Architektur, wird alles außerhalb eines Tabs vom Browserprozess verarbeitet. Der Browserprozess umfasst Threads wie den UI-Thread, der Schaltflächen und Eingabefelder der der Netzwerk-Thread, der Daten aus dem Internet empfängt, den Speicherthread, der den Zugriff auf die Dateien und mehr steuert. Wenn Sie eine URL in die Adresse eingeben, wird Ihre Eingabe vom UI-Thread des Browserprozesses verarbeitet.
Eine einfache Navigation
Schritt 1: Eingabe verarbeiten
Wenn ein Nutzer mit der Eingabe in die Adressleiste beginnt, wird als Erstes gefragt: „Ist das Suchanfrage oder URL?“. In Chrome ist die Adressleiste auch ein Eingabefeld für die Suche. Der UI-Thread muss parsen und entscheiden, ob Sie an eine Suchmaschine oder die angeforderte Website weitergeleitet werden sollen.
<ph type="x-smartling-placeholder">![Nutzereingabe verarbeiten](https://developer.chrome.com/static/blog/inside-browser-part2/image/handling-user-input-24fea2c817a6a.png?authuser=6&hl=de)
Schritt 2: Navigation starten
Wenn ein Nutzer die Eingabetaste drückt, initiiert der UI-Thread einen Netzwerkaufruf, um Websiteinhalte abzurufen. Rotierendes Ladesymbol wird in der Ecke eines Tabs angezeigt und der Netzwerk-Thread durchläuft entsprechende Protokolle, DNS-Lookup und Herstellen einer TLS-Verbindung für die Anfrage.
<ph type="x-smartling-placeholder">![Navigationsbeginn](https://developer.chrome.com/static/blog/inside-browser-part2/image/navigation-start-4aeb163d61a8c.png?authuser=6&hl=de)
An dieser Stelle erhält der Netzwerk-Thread möglicherweise einen Server-Weiterleitungs-Header wie HTTP 301. In diesem Fall Der Netzwerk-Thread kommuniziert mit dem UI-Thread, dass der Server eine Weiterleitung anfordert. Gehen Sie dann so vor: wird eine weitere URL-Anfrage initiiert.
Schritt 3: Antwort lesen
<ph type="x-smartling-placeholder">![HTTP-Antwort](https://developer.chrome.com/static/blog/inside-browser-part2/image/http-response-0ae2751b24973.png?authuser=6&hl=de)
Sobald der Antworttext (Nutzlast) eingeht, prüft der Netzwerkthread die ersten Byte des Streams hinzufügen. Im Content-Type-Header der Antwort sollte angegeben sein, um welchen Datentyp es sich handelt. aber da diese möglicherweise fehlen oder falsch sind, MIME-Typ-Sniffing wird hier erledigt. Das ist ein „kniffliges Geschäft“ wie im Quellcode kommentiert. Sie können den Kommentar lesen, um zu sehen, wie verschiedene Browser Content-Typ/Nutzlast-Paare verarbeiten.
Wenn die Antwort eine HTML-Datei ist, werden die Daten im nächsten Schritt an den Renderer übergeben. Wenn es sich jedoch um eine ZIP-Datei oder eine andere Datei handelt, handelt es sich um eine Download-Anfrage. müssen die Daten an den Download-Manager übergeben werden.
<ph type="x-smartling-placeholder">![MIME-Typ-Sniffing](https://developer.chrome.com/static/blog/inside-browser-part2/image/mime-type-sniffing-444e1a2f5b037.png?authuser=6&hl=de)
Hier findet auch die SafeBrowsing-Prüfung statt. Wenn die Domain- und Antwortdaten offenbar mit einer bekannten schädlichen Website übereinstimmen, ist der Netzwerkthread um eine Warnseite anzuzeigen. Außerdem Fross-Orire-Read-Blocking (CORB) um sicherzustellen, dass sensible Website-übergreifende gelangen die Daten nicht in den Renderer-Prozess.
Schritt 4: Renderer-Prozess finden
Sobald alle Prüfungen abgeschlossen sind und der Netzwerk-Thread sicher ist, dass der Browser zur angefragte Website an, teilt der Netzwerk-Thread dem UI-Thread mit, dass die Daten bereit sind. findet dann eine Renderer-Prozess für das Rendern der Webseite.
<ph type="x-smartling-placeholder">![Renderer-Prozess suchen](https://developer.chrome.com/static/blog/inside-browser-part2/image/find-renderer-process-4d4055665d4a7.png?authuser=6&hl=de)
Da es mehrere hundert Millisekunden dauern kann, bis die Netzwerkanfrage eine Antwort zurückgibt, um diesen Prozess zu beschleunigen. Wenn der UI-Thread eine URL-Anfrage an mit dem Netzwerk-Thread in Schritt 2 verbunden ist, weiß schon, zu welcher Website er navigiert. Der UI-Thread versucht, parallel zur Netzwerkanfrage proaktiv einen Rendererprozess zu finden oder zu starten. Auf diese Weise Läuft alles erwartungsgemäß, befindet sich ein Renderer-Prozess bereits in der Standby-Position, wenn der Netzwerk-Thread empfangenen Daten. Dieser Standby-Prozess wird möglicherweise nicht verwendet, wenn die Navigation websiteübergreifend, in In diesem Fall ist möglicherweise ein anderer Prozess erforderlich.
Schritt 5: Commit-Navigation
Da die Daten und der Renderer-Prozess nun bereit sind, wird ein IPC vom Browserprozess an den Renderer-Prozess, um die Navigation zu übergeben. Sie leitet auch den Datenstream weiter, damit der Renderer kann weiterhin HTML-Daten empfangen. Sobald der Browser-Prozess die Bestätigung erhält, dass der Commit durchgeführt wurde, im Renderer-Prozess stattgefunden hat, ist die Navigation abgeschlossen und die Phase des Dokumentladevorgangs ist abgeschlossen. beginnt.
Jetzt wird die Adressleiste aktualisiert und die Benutzeroberfläche für die Sicherheitsanzeige und die Website-Einstellungen Website-Informationen der neuen Seite. Der Sitzungsverlauf für den Tab wird aktualisiert, sodass navigieren Sie durch die Website, zu der Sie gerade navigiert sind. Um die Wiederherstellung von Tabs/Sitzungen zu erleichtern Wenn Sie einen Tab oder ein Fenster schließen, wird der Sitzungsverlauf auf dem Laufwerk gespeichert.
<ph type="x-smartling-placeholder">![Commit für Navigation durchführen](https://developer.chrome.com/static/blog/inside-browser-part2/image/commit-navigation-bc2943921c6f6.png?authuser=6&hl=de)
Zusätzlicher Schritt: Anfänglicher Ladevorgang abgeschlossen
Nachdem die Navigation per Commit übertragen wurde, lädt der Renderer-Prozess weiter Ressourcen und rendert
Seite. Im nächsten Beitrag erfahren Sie, was in dieser Phase geschieht. Sobald der Renderer
Prozess „beendet“ wird ein IPC zurück an den Browserprozess gesendet.
onload
-Ereignisse wurden für alle Frames auf der Seite ausgelöst und ihre Ausführung ist abgeschlossen. An dieser Stelle
stoppt der UI-Thread das Laden des rotierenden Ladesymbols auf dem Tab.
Ich sage „beendet“, weil clientseitiges JavaScript noch geladen werden kann zusätzliche Ressourcen zu erstellen und neue Ansichten zu rendern.
<ph type="x-smartling-placeholder">![Fertigstellen der Seite](https://developer.chrome.com/static/blog/inside-browser-part2/image/page-finish-loading-1bee6888e9e56.png?authuser=6&hl=de)
Zu einer anderen Website navigieren
Die einfache Navigation war fertig! Aber was passiert, wenn ein Nutzer eine andere URL in die Adressleiste eingibt?
noch einmal? Nun, der Browser-Prozess durchläuft dieselben Schritte, um zu den unterschiedlichen Websites zu navigieren.
Zuvor muss jedoch mit der aktuell gerenderten Website geprüft werden, ob sie Interesse daran hat,
Ereignis beforeunload
.
beforeunload
kann „Website verlassen?“ erstellen angezeigt, wenn Sie versuchen, eine Seite zu verlassen oder den Tab zu schließen.
Alles auf einem Tab, einschließlich Ihres JavaScript-Codes,
wird vom Renderer-Prozess verarbeitet.
Der Browserprozess muss mit dem aktuellen Rendererprozess übereinstimmen, wenn eine neue Navigationsanfrage eingeht.
![„beforeunload“-Event-Handler](https://developer.chrome.com/static/blog/inside-browser-part2/image/beforeunload-event-handle-53b6fa7dd9be3.png?authuser=6&hl=de)
Wurde die Navigation über den Renderer-Prozess initiiert, z. B. wenn der Nutzer auf einen Link oder
clientseitiges JavaScript ausgeführt hat window.location = "https://newsite.com"
) den Renderer-Prozess
prüft zuerst beforeunload
-Handler. Dann durchläuft sie denselben Prozess wie der Browserprozess.
die Navigation gestartet haben. Der einzige Unterschied besteht darin, dass die Navigationsanfrage
mit dem Browserprozess zu verknüpfen.
Wenn die neue Navigation zu einer anderen Website als der derzeit gerenderten Website führt, wird ein separates
-Prozess wird aufgerufen, um die neue Navigation zu bearbeiten, während der aktuelle Render-Prozess
verarbeiten Ereignisse wie unload
. Weitere Informationen
und wie Sie sich mithilfe von
Page Lifecycle API.
![neue Navigation und Entladen](https://developer.chrome.com/static/blog/inside-browser-part2/image/new-navigation-unload-29ee714c3fcf4.png?authuser=6&hl=de)
Im Fall eines Service Workers
Eine kürzlich erfolgte Änderung an diesem Navigationsprozess ist die Einführung von Service Worker generiert. Mit einem Service Worker können Sie Netzwerk-Proxy in Ihrem Anwendungscode verwenden; So haben Webentwickler mehr Kontrolle darüber, und wann neue Daten aus dem Netzwerk abgerufen werden. Wenn der Service Worker so eingestellt ist, dass er die Seite lädt aus dem Cache, müssen die Daten nicht vom Netzwerk angefordert werden.
Denken Sie daran, dass es sich bei Service Worker um JavaScript-Code handelt, der in einem Renderer ausgeführt wird. . Woher weiß jedoch ein Browserprozess, dass auf der Website eine Navigationsanfrage eingeht, Service Worker?
<ph type="x-smartling-placeholder">![Service Worker-Bereichssuche](https://developer.chrome.com/static/blog/inside-browser-part2/image/service-worker-scope-look-f48a8d509535a.png?authuser=6&hl=de)
Wenn ein Service Worker registriert wird, wird dessen Bereich als Referenz beibehalten (Weitere Informationen zum Umfang finden Sie in diesem Service Worker-Lebenszyklus). Bei einer Navigation prüft der Netzwerkthread die Domain mit dem registrierten Service Worker Wenn ein Service Worker für diese URL registriert ist, findet der UI-Thread einen Renderer-Prozess in um den Service Worker-Code auszuführen. Der Service Worker kann Daten aus dem Cache laden, Daten müssen aus dem Netzwerk angefordert werden. Eventuell werden auch neue Ressourcen vom Netzwerk angefordert.
<ph type="x-smartling-placeholder">![Serviceworker Navigation](https://developer.chrome.com/static/blog/inside-browser-part2/image/serviceworker-navigation-8576df1bffcf9.png?authuser=6&hl=de)
Navigationsvorabladen
Dieser Umlauf zwischen Browserprozess und Rendererprozess kann zu Verzögerungen führen. wenn sich der Service Worker entscheidet, Daten aus dem Netzwerk anzufordern. Mit der Funktion Navigationsvorabladen lässt sich dieser Vorgang beschleunigen. durch das parallele Laden von Ressourcen zum Start des Service Workers. Diese Anfragen werden mit einem Header gekennzeichnet, sodass die Server entscheiden können, ob sie andere Inhalte diese Anträge stellen; beispielsweise nur aktualisierte Daten anstelle eines vollständigen Dokuments.
<ph type="x-smartling-placeholder">![Navigationsvorabladen](https://developer.chrome.com/static/blog/inside-browser-part2/image/navigation-preload-a859b1ad065e3.png?authuser=6&hl=de)
Zusammenfassung
In diesem Post haben wir uns damit befasst, was bei einer Navigation passiert und wie Ihr Webanwendungscode da Antwort-Header und clientseitiges JavaScript mit dem Browser interagieren. Browser mit den Schritten Daten aus dem Netzwerk abzurufen, erleichtert es zu verstehen, warum APIs wie die Navigation Vorabladen entwickelt wurden. Im nächsten Beitrag erfahren Sie, wie der Browser die HTML/CSS/JavaScript zum Rendern von Seiten.
Hat Ihnen der Beitrag gefallen? Wenn Sie Fragen oder Vorschläge für den nächsten Beitrag haben, findest du unten in den Kommentaren oder @kosamari auf Twitter.
<ph type="x-smartling-placeholder"></ph> Nächster Schritt: Innere Funktionsweise eines Renderer-Prozesses