Erstladeleistung für React-Entwickler: investigativer tiefer Einblick

Ausführliche Diskussion der Ladeleistung des ersten Bildschirms einer Webseite und Optimierungsstrategien

Inhaltsverzeichnis

1. Einführung in Indikatoren für die Erstladeleistung
2. Performance DevTools-Übersicht
   1. Projekteinstellungen
   2. Entdecken Sie wichtige DevTools
3. Untersuchen Sie verschiedene Netzwerkbedingungen
   1. Sehr langsamer Server
   2. Simulation unterschiedlicher Bandbreiten und Latenzen
   3. Bedeutung von CDN
4. Zugriffsleistung wiederholen
   1. Browser-Cache mithilfe des Cache-Control-Headers steuern
   2. Cache-Kontrolle und moderne Bündelungstools
   3. Muss mein einfacher Anwendungsfall das alles wirklich wissen?

Mit dem Boom der KI-gesteuerten Codegenerierung nimmt die Bedeutung des Schreibens von React-Code ab. Jetzt kann jeder und alles Anwendungen in React schreiben. Aber das Schreiben von Code war schon immer nur ein Teil des Puzzles. Wir müssen unsere Anwendungen immer noch irgendwo bereitstellen, sie Benutzern zugänglich machen, sie robust und schnell machen und eine Million anderer Dinge tun. Keine KI kann diese übernehmen. Zumindest noch nicht.

Konzentrieren wir uns also heute darauf, wie Sie Ihre Bewerbung schnell gestalten können. Dazu müssen wir uns für eine Weile von React entfernen. Denn bevor wir etwas schnell machen, müssen wir zunächst wissen, was „schnell“ ist, wie man es misst und was dieses „schnell“ beeinflussen kann.

Spoiler-Alarm: React wird in diesem Artikel außer bei Lernprojekten nicht angezeigt. Heute dreht sich alles um die Grundlagen: die Verwendung von Leistungstools, eine Einführung in Core Web Vitals, das Chrome-Leistungspanel, was Leistung beim anfänglichen Laden ist, welche Metriken sie messen können und wie sich Cache-Steuerungen und unterschiedliche Netzwerkbedingungen darauf auswirken.

Einführung in Indikatoren für die Erstladeleistung

Was passiert, wenn ich meinen Browser öffne und versuche, zu meiner Lieblingswebsite zu navigieren? Ich gebe „https://www.php.cn/link/63ea3fef646010a7255aec506626ea32 in die Adressleiste ein, um eine GET-Anfrage zu stellen und im Gegenzug eine HTML-Seite zu erhalten.

Die dafür benötigte Zeit wird „Time To First Byte“ (TTFB) genannt: die Zeit zwischen dem Senden der Anfrage und dem Eintreffen der Ergebnisse. Nach Erhalt des HTML muss der Browser diesen nun schnellstmöglich in eine nutzbare Website umwandeln.

Es stellt zunächst den sogenannten „kritischen Pfad“ auf dem Bildschirm dar: den kleinsten und wichtigsten Inhalt, der dem Benutzer angezeigt werden kann.

Was in den Schlüsselpfad enthalten sein sollte, ist ein komplexes Problem. Im Idealfall ist alles, dass Benutzer die vollständige Erfahrung sofort sehen können. Aber das gleiche -nichts, weil es so schnell wie möglich sein muss, weil es sich um einen "wichtigen" Weg handelt. Die beiden sind gleichzeitig unmöglich, daher müssen Sie Kompromisse eingehen.

Kompromiss ist so. Der Browser geht davon aus

Die von dem Server empfangene anfängliche HTML -Verwendung, um tatsächliche DOM -Elemente zu erstellen und Erfahrungen zu erstellen.
Die wichtigen CSS -Dateien dieser ersten Elemente -andere Weise, wenn sie anhält, ohne auf sie zu warten, werden Benutzer am Anfang seltsam unaussprechlich "flackern" sehen.
Die Schlüssel -JavaScript -Dateien werden gleichzeitig geändert.

Der Browser erhält die erste (HTML) in der anfänglichen Anforderung des Servers. Es begann es zu analysieren und die Links der CSS- und JS -Dateien zu extrahieren, die den "Schlüsselpfad" in diesem Prozess absolvieren müssen. Anschließend wird eine Anfrage gesendet, um sie vom Server zu erhalten, darauf zu warten, dass sie heruntergeladen werden, mit ihnen umgehen, alle diese zusammen kombinieren und zu einem bestimmten Zeitpunkt die Pixel "Key Path" auf dem Bildschirm zeichnen.

Da der Browser das anfängliche Rendering ohne diese Schlüsselressourcen nicht abschließen kann, werden sie als "Rendering Blocking Resources" bezeichnet. Natürlich werden nicht alle CSS- und JS -Ressourcen blockiert. Normalerweise nur: <:>

Die meisten CSS, ob es sich um eine innere Vereinigung oder durch das

• -Tag handelt. Das Etikett ist nicht asynchron oder verzögerte JavaScript -Ressourcen.
Der gesamte Prozess des Renderns des "Schlüsselweges" ist grob in:

gezeigt

Browser beginnt mit der Analyse des anfänglichen HTML

• dabei extrahiert es die Links von CSS- und JS -Ressourcen aus dem Etikett.
• Dann startet es den Download -Prozess und wartet auf die Blockierungsressourcen, um den Download abzuschließen.
• Wenn möglich, wird es weiterhin mit HTML umgehen.
• Nachdem sie alle wichtigen Ressourcen erhalten haben, werden sie auch damit umgehen.
• Schließlich vervollständigt es die tatsächlichen Pixel der Schnittstelle.
Diesmal nennen wir zum ersten Mal

Zeichnen (FP)

. Dies ist das erste Mal, dass Benutzer die Möglichkeit haben, etwas auf dem Bildschirm zu sehen. Ob dies geschieht, hängt von der vom Server gesendeten HTML ab. Wenn es einige sinnvolle Dinge wie Text oder Bilder gibt, ist dies auch die Zeit der ersten Inhaltszeichnung (FCP). Wenn HTML nur eine leere DIV ist, wird FCP später stattfinden.

Die erste Inhaltszeichnung (FCP) ist einer der wichtigsten Leistungsindikatoren, da sie die anfängliche Belastung von

wahrgenommenes

misst. Grundsätzlich ist dies ein vorläufiger Eindruck von der Website der Benutzer der Benutzer.

Bis zu diesem Moment starrte der Benutzer nur auf den leeren Bildschirm, um Nägel zu beißen. Laut Google beträgt die gute FCP -Nummer unter 1,8 Sekunden . Danach verliert der Benutzer das Interesse an den Inhalten, die Ihre Website bereitstellen kann, und kann abreisen.

FCP ist jedoch nicht perfekt. Wenn die Website mit einem Rotor oder einem Ladebildschirm geladen wird, stellt der FCP -Indikator den Inhalt dar. Es ist jedoch unwahrscheinlich, dass Benutzer nur zur Website navigieren, um den schicken Ladebildschirm anzuzeigen. Meistens möchten sie auf den Inhalt zugreifen.

Aus diesem Grund muss der Browser seinen Start abschließen. Es wartet auf den Rest des nicht blockierenden JavaScripts, führt es aus und wendet seine Änderungen auf dem DOM auf dem Bildschirm an, lädt Bilder herunter und verbessert die Benutzererfahrung auf andere Weise.

Zu einem bestimmten Zeitpunkt des Prozesses erfolgt die maximale Zeichnungszeit inhaltlich. Es ist nicht das erste Element wie FCP, sondern der größte Text, Bild oder Video im Hauptinhaltsbereich auf der Seite -der sichtbare Port. Laut Google sollte diese Zahl unter 2,5 Sekunden liegen. Mehr als diese Nummer werden die Benutzer denken, dass die Website langsam ist.

Alle diese Indikatoren sind Teil der Web -Vitals von Google -A -Indizes für die Benutzererfahrung auf der Seite. LCP ist einer der drei Kern -Web -Vitals

-Trei -Indikatoren repräsentieren die verschiedenen Teile der Benutzererfahrung. lcp verantwortungsbewusst Ladeleistung . Diese Indikatoren können über den Leuchtturm gemessen werden. Lighthouse ist ein Google Performance -Tool. Sie können es als Knotenmodul verwenden, damit sie es während der Bauarbeiten ausführen und erkennen können, bevor sie in der Produktionsumgebung zurückkehren. Verwenden Sie die integrierte Devtools -Version für lokales Debuggen und Tests. Und die Webversion, um die Leistung von Wettbewerbern zu überprüfen.

Überblick

übervtools

Das obige ist eine sehr kurze und vereinfachte Erklärung des Prozesses. Aber es gibt viele Abkürzungen und Theorien, die die Menschen verwirrt. Für mich persönlich ist das Lesen solcher Inhalte nutzlos. Es sei denn, ich kann es in Aktion sehen und es selbst bedienen, werde ich sofort alles vergessen.

Für dieses spezielle Thema finde ich, dass der einfachste Weg, diese Konzepte vollständig zu verstehen, darin besteht, verschiedene Szenen auf der Semi -Real -Seite zu simulieren und zu sehen, wie sie die Ergebnisse ändern. Also bevor weitere Theorien (es gibt viele!), Machen wir das.

Projekteinstellungen

Wenn Sie bereit sind, können Sie die folgende Simulation in Ihrem eigenen Projekt ausführen -die Ergebnisse sollten mehr oder weniger betragen. Um jedoch kontrollierbar und vereinfacht zu werden, schlage ich vor, dass Sie das Lernprojekt verwenden, das ich für diesen Artikel vorbereitet habe. Sie können es hier besuchen:

https://www.php.cn/link/def14e8541708294d7558fdf2126ef27

Installieren Sie zuerst alle Abhängigkeiten:

<code>npm install</code>

Konstruktionsprojekt:

<code>npm run build</code>

Starten Sie den Server:

<code>npm run start</code>

Sie sollten in " https://www.php.cn/link/66e8d052ec2230c66bd11e6b5a0e3c8 . sein.

Erforschen Sie die notwendigen Devtools

Öffnen Sie die Website, die in Chrom- und Open Chrome Devtools analysiert werden soll. Finden Sie dort die "Performance" und "Lighthouse" -Paneele und setzen Sie sie zusammen. Wir brauchen beides.

Stellen Sie außerdem sicher, dass das Kontrollkästchen "Deaktiviert Cache" in diesem Artikel in diesem Artikel aktiviert ist. Es sollte sich im oberen "Netzwerk" -Panel befinden.

Auf diese Weise können wir die ersten Besucher simulieren, die unsere Website noch nie besucht haben, und der Browser hat keine Ressourcen zwischengespeichert.

Lighthouse Panel

entdecken

Öffnen Sie jetzt das Leuchtturmpanel. Dort sollten Sie einige Einstellungen und "Analyse -Seite laden" sehen.

Für diesen Abschnitt interessieren wir uns für den "Navigations" -Modus -analysiert die anfängliche Last der Seite im Detail. Der Bericht bietet Ihnen die folgenden Punkte:

Die lokale Leistung ist perfekt, was nicht überraschend ist -alles ist "auf meiner Maschine zu laufen".

Es wird auch die folgenden Indikatoren geben:

Die FCP- und LCP -Werte, die wir hier benötigen, befinden sich oben.

unten sehen Sie eine Liste von Vorschlägen, mit denen Sie Ihre Punktzahl verbessern können.

Jeder Vorschlag kann erweitert werden, Sie finden dort detailliertere Informationen und manchmal finden Sie einen Link, um das spezifische Thema zu erklären. Nicht all dies kann Maßnahmen ergreifen, aber es ist ein hervorragendes Tool, das die Leistung der Leistung beginnt und verschiedene Dinge versteht, die es verbessern können. Das Lesen dieser Berichte und verwandten Links dauert mehrere Stunden.

Leuchtthouse liefert jedoch nur Oberflächeninformationen und ermöglicht es Ihnen nicht, verschiedene Szenarien wie langsame Netzwerke oder niedrige CPUs zu simulieren. Es ist nur ein guter Einstiegspunkt und ein großartiges Werkzeug für die Verfolgung der Leistung im Laufe der Zeit. Um zu verstehen, was tiefer passiert, brauchen wir

"Performance"

Panels.

Das Explorationsleistungspanel Beim zum ersten Mal geladenen "Performance" -Panel sollte unten angezeigt werden:

Es zeigt drei zentrale Web Vitals-Metriken an, darunter unser LCP, mit dem Sie langsame Netzwerke und CPUs simulieren und Leistungsdetails im Zeitverlauf protokollieren können.

Suchen und aktivieren Sie das Kontrollkästchen „Screenshot“ oben im Bedienfeld, klicken Sie dann auf die Schaltfläche „Aufzeichnen und neu laden“ und wenn die Website neu geladen wird, stoppen Sie die Aufzeichnung. Dies ist Ihr detaillierter Bericht darüber, was mit Ihrer Seite beim ersten Laden passiert ist.

Dieser Bericht wird mehrere Abschnitte enthalten.

Ganz oben befindet sich der reguläre Abschnitt „Zeitleistenübersicht“ .

Hier sehen Sie, dass auf der Website etwas passiert, aber nichts weiter. Wenn Sie mit der Maus darüber fahren, wird ein Screenshot des Geschehens angezeigt und Sie können einen bestimmten Bereich auswählen und vergrößern, um ihn genauer zu betrachten.

Darunter befindet sich der Netzwerkbereich. Nach der Erweiterung sehen Sie alle heruntergeladenen externen Ressourcen und deren genaue Zeit auf der Zeitleiste. Wenn Sie mit der Maus über eine bestimmte Ressource fahren, werden Details dazu angezeigt, wie viel Zeit in welcher Phase des Downloads aufgewendet wurde. Ressourcen mit einer roten Ecke weisen auf blockierende Ressourcen hin.

Wenn Sie das Lernprojekt verwenden, sehen Sie genau das gleiche Bild, und dieses stimmt wörtlich mit dem überein, was wir im vorherigen Abschnitt durchgegangen sind:

• Am Anfang steht ein blauer Block – eine Anfrage zum Abrufen des Website-HTML
• Nachdem der Ladevorgang abgeschlossen ist, gibt es eine kurze Pause (Analyse des HTML-Codes) und es werden zwei Anfragen nach weiteren Ressourcen gestellt.
• Eine davon (gelb) ist für JavaScript – nicht blockierend.
• Das andere (lila) ist für CSS, das blockiert.

Wenn Sie jetzt Ihren Lernprojektcode öffnen und den dist-Ordner anzeigen, entspricht der Quellcode diesem Verhalten:

• Im Assets-Ordner befinden sich eine index.html-Datei sowie .css- und .js-Dateien
Im Abschnitt
• der Datei index.html befindet sich ein Tag , der auf die CSS-Datei verweist. Wie wir wissen, blockieren CSS-Ressourcen in -Tags das Rendern, daher kann dies überprüft werden.
• Darüber hinaus gibt es ein <script>-Tag, das auf die JavaScript-Datei im Asset-Ordner verweist. Es ist weder verzögert noch asynchron, hat aber den Typ „Module“. Diese werden automatisch zurückgestellt, sodass auch dies überprüft wird – JavaScript-Dateien in Panels sind nicht blockierend. </script>

Zusätzliche Übungen

Wenn Sie an einem Projekt arbeiten, achten Sie auf dessen anfängliche Ladeleistung und sehen Sie sich das Netzwerkfenster an. Möglicherweise werden weitere Ressourcen heruntergeladen.

• Wie viele Rendering -Hindernisse haben Sie? Ist all dies notwendig?
• Wo wissen Sie, wo der "Eintragspunkt" des Projekts und die Blockierungsressourcen im Teil <script> erscheinen? Versuchen Sie, Ihre NPM -Build -Variante zu verwenden, um ein Projekt zu erstellen und zu suchen. Tipp:-Wenn Sie ein reines Webpack-Projekt haben, finden Sie Webpack.config.js-Dateien. Der Weg des HTML -Eingangspunkts sollte im Inneren sein. </script>
• Wenn Sie vite verwenden, überprüfen Sie den DIST -Ordner -das Gleiche wie das Lernprojekt
• Wenn Sie die nächste.

Im Abschnitt "Netzwerk" finden Sie den Abschnitt "Frame" und "Timing".

Diese sind sehr cool. Im Abschnitt "Timing" können Sie alle Indikatoren (FP, FCP, LCP) sehen, die wir früher besprochen haben, und einige Indikatoren, die wir nicht besprochen haben. Wenn Sie den Indikator schweben, können Sie die genaue Zeit erkennen, die es kostet. Klicken Sie auf sie, um die Unterseite auf der Registerkarte "Abstract" zu aktualisieren. Informationen zu diesem Indikator finden Sie weiter und verlinken Sie weitere Informationen. Bei DeVtools geht es jetzt darum, Menschen zu erziehen.

schließlich Lord

Teil. Dies ist im Hauptfaden während der Zeitachse der aufgezeichneten Zeitleiste passiert.

Wir können sehen, was wie "Parsen html" oder "Layout" und wie lange es kostet. Der gelbe Teil bezieht sich auf JavaScript und ist etwas nutzlos, da wir eine Produktionsversion mit Komprimierung von JavaScript verwenden. Aber auch in diesem Zustand können wir im Allgemeinen verstehen, wie lange die JavaScript -Ausführung mit der HTML -Analyse und dem Zeichnungslayout verglichen wird.

Wenn Netzwerk

und

der Herr

sowohl offen als auch amplifiziert, um den gesamten Bildschirm zu besetzen, ist es besonders nützlich für die Leistungsanalyse.

Von hier aus kann ich sehen, dass mein Server sehr schnell ist und die Bundle -Tasche sehr klein ist. Keine Netzwerkaufgabe ist ein Engpass. Wenn ich hier die anfängliche Ladegeschwindigkeit beschleunigen möchte, muss ich untersuchen, warum "Auflösung HTML" so langsam ist -es ist die längste Aufgabe in der Tabelle.

oder, wenn wir uns die absolute Zahl ansehen -ich sollte hier in Bezug auf die Leistung nichts tun. Die gesamte anfängliche Ladezeit beträgt weniger als 200 Millisekunden, weitaus niedriger als der von Google empfohlene Schwellenwert? und verwenden Sie auch einen sehr einfachen Server.

Es ist Zeit, das wirkliche Leben zu simulieren.

Erforschen Sie verschiedene Netzwerkbedingungen

sehr langsamer Server

Lassen Sie uns zunächst den Server realistischer machen. Jetzt ist der erste "blaue" Schritt etwa 50 Millisekunden, von denen 40 Millisekunden nur warten.

Im wirklichen Leben führt der Server bestimmte Vorgänge aus, überprüft die Berechtigungen, generiert bestimmte Inhalte und überprüfe die Berechtigungen erneut (da er viele übrig gebliebene Codes hat und die Schecks dreimal verloren gehen), sonst wird es sein) Sehr beschäftigt.

Backend/Index.ts Datei (

https://www.php.cn/link/def14e8541708294d7558fdf2126ef27). Finden Sie die Kommentare > // warten Sie den Schlaf (500) und stornieren Sie die Annotation. Dies verzögert den Server 500 Millisekunden, bevor HTML zurückgegeben wird. Dies scheint für alte komplexe Server vernünftig zu sein. rekonstruieren Sie das Projekt (NPM -Run -Build), starten Sie es neu (NPM Run Start) und richten Sie den Leistungsrekord neu.

Abgesehen von der anfänglichen blauen Linie hat sich die mit dem Rest vergleichende Zeitleiste nicht ändern. Es ist jetzt sehr lang.

Diese Situation unterstreicht die Bedeutung der Überprüfung der globalen und identifizierenden Engpässe, bevor eine Leistungsoptimierung durchgeführt wird. Der LCP -Wert beträgt ungefähr 650 Millisekunden, von denen etwa 560 Millisekunden verwendet werden, um auf die anfängliche HTML zu warten. Der React -Teil beträgt ungefähr 50 Millisekunden. Selbst wenn ich versuche, es zu reduzieren und auf 25 Millisekunden zu reduzieren, beträgt es nur 4%in der Gesamtsituation. Die Reduzierung von IT erfordert eine Menge Anstrengungen. Eine effektivere Strategie kann darin bestehen, sich auf den Server zu konzentrieren und herauszufinden, warum er so langsam ist.

simulieren unterschiedliche Bandbreite und Verzögerung Nicht jeder lebt in einer Welt der 1 Gigabit -Verbindung. In Australien ist beispielsweise 50 Billionen/Sekunde eine der Internetverbindungen mit hoher Geschwindigkeit, und Sie werden etwa 90 US -Dollar pro Monat ausgeben. Natürlich ist es nicht 3G und viele Menschen auf der ganzen Welt sind gefangen. Dennoch werde ich jedes Mal, wenn ich die 1 Gigabit 1/Second oder 10 Euro Internet -Plan der Europäer höre, weinen.

Wie auch immer. Lassen Sie uns dieses unangenehme australische Internet simulieren und sehen, was in Leistungsindikatoren passiert. Löschen Sie zu diesem Zweck die vorhandenen Datensätze auf der Registerkarte Performance (Nachladen und Schaltfläche in der Nähe der Schaltfläche "Daten). Das Netzwerkeinstellungsfeld sollte angezeigt werden:

Wenn es nicht in Ihrer Chrome -Version angezeigt wird, sollten die gleichen Einstellungen auf der Registerkarte "Netzwerk" verfügbar sein.

Fügen Sie dem Drop -Down -Menü "Netzwerk" eine neue Konfigurationsdatei hinzu. Verwenden Sie die folgenden Zahlen:

• Konfigurationsdateiname: "Durchschnittliche Internetbandbreite"
• Download: 50000 (50 Mbit / s)
• hochladen: 15000 (15 Mbit / s)
• Verzögerung: 40 (der Durchschnittswert der allgemeinen Internetverbindung)

Wählen Sie nun die Konfigurationsdatei im Drop -Down -Menü aus und führen Sie den Leistungsdatensatz erneut aus.

Was hast du gesehen? Für mich sieht es so aus.

lcp

Der Wert hat fast keine Veränderung -seltener von 640 Millisekunden auf 700 Millisekunden erhöht. Der anfängliche blaue "Server" -Teil hat keine Änderung, was erklärt werden kann: Es sendet nur die grundlegendste HTML. Daher sollte es nicht lange dauern. Aber die Beziehung zwischen den herunterladbaren Ressourcen und dem Haupt -Thread hat sich dramatisch geändert.

Ich kann deutlich den Einfluss von blockierenden CSS

-Datei erkennen. Die Mission "Analysis html" wurde abgeschlossen, aber der Browser ist untätig und wartet auf CSS -es kann vor dem Herunterladen keinen Inhalt zeichnen. Vergleichen Sie es mit den vorherigen Bildern.

Danach kann der Browser technisch gesehen einige Inhalte gezogen werden -aber kein Inhalt, wir senden nur einen leeren DIV in der HTML -Datei. Daher wird der Browser bis zum Download und Ausführen der JavaScript -Datei fortgesetzt.

Die wartende Lücke von etwa 60 Millisekunden ist die Zunahme von

lcp

Ich habe gesehen.

verringern die Geschwindigkeit, um den Fortschritt zu betrachten. Erstellen Sie eine neue Netzwerkkonfigurationsdatei, nennen Sie es "Low -Internet -Bandbreite", kopieren Sie die Download-/Upload -Nummer in der Konfigurationsdatei "Low Internet Bandwidth" und setzen Sie die Verzögerung auf 40 Millisekunden.

und führen Sie den Test erneut aus.

LCP -Wert ist jetzt auf fast 500 Millisekunden gestiegen. JavaScript lädt ungefähr 300 Millisekunden herunter. Relativ gesehen nimmt die Bedeutung der "analytischen HTML" -Task und die Ausführungsaufgabe von JavaScript ab.

zusätzliche Übung

Wenn Sie ein eigenes Projekt haben, versuchen Sie, diesen Test darauf auszuführen.

• Wie lange dauert es, alle wichtigen Pfadressourcen herunterzuladen?
• Wie lange dauert es, alle JavaScript -Dateien herunterzuladen?
• Wie viel kostet der Download nach der Aufgabe "Parsen html"?
• Wie viel kostet der Ressourcen -Download von "Analyse von HTML" und JavaScript für den Download "Analyse von HTML"?
• Wie wirkt es sich auf den LCP -Index aus?

Was in der Ressourcenleiste passiert ist, ist auch sehr interessant. Hängen Sie die Maus an die gelbe JavaScript -Leiste. Sie sollten diesen Inhalt dort sehen:

Der interessanteste Teil hier ist "Anfragen und Warten", das ungefähr 40 Millisekunden dauert. Hängen Sie die Maus an die verbleibenden Netzwerkressourcen -alle diese haben sie. Das ist unsere Latenz, wir setzen eine Netzwerkverzögerung auf 40. Viele Dinge beeinflussen Verzögerungszahlen. Die Art der Netzwerkverbindung ist eine davon. Beispielsweise beträgt die durchschnittliche 3G -Verbindungsbandbreite 10/1 Mbit/s und verzögert sich zwischen 100 und 300 Millisekunden.

Um dies zu simulieren, erstellen Sie bitte eine neue Netzwerkkonfigurationsdatei, nennen Sie es "Durchschnitt 3G", kopieren Sie die Download-/Upload -Nummer aus der Konfigurationsdatei "Low Internet Bandbreite" und setzen Sie die Verzögerung auf 300 Millisekunden.

wieder laufen. Das "Senden von Anfragen und Warten" aller Netzwerkressourcen sollte auf etwa 300 Millisekunden erhöht werden. Dies fördert weiter LCP

Zahlen: Es ist für mich 1,2 Sekunden . Jetzt ist ein interessanter Teil: Was wird passieren, wenn ich die Bandbreite zur Ultra -Hochgeschwindigkeit wiederhere, aber die geringe Verzögerung beibehält? Versuchen wir diese Einstellung:

Download

: 1000 Mbit / s
• hochladen : 100 mbit / s
• Verzögerung : 300 Millisekunden
• Wenn sich Ihr Server irgendwo in Norwegen befindet und der Kunde reich an Australier ist, ist dies einfach zu passieren. Dies ist das Ergebnis:

lcp

Die Zahl beträgt ungefähr

960 Millisekunden

. Es ist schlimmer als das langsamste im Internet, das wir zuvor versucht haben! In diesem Fall ist die Größe des gebündelten Pakets nicht wichtig, und die Größe des CSS ist überhaupt nicht wichtig. Selbst wenn Sie beides ohne beide sind, bewegt sich der LCP -Indikator kaum. Eine hohe Verzögerung ist besser als alles.

Dies erinnert mich an die erste Leistungsverbesserung, die jeder erreichen sollte, wenn er es noch nicht erreicht hat. Es heißt "Sicherstellen statischer Ressourcen

immer

, um Dienste über CDN anzubieten." Die Bedeutung von CDN CDN (Content Distribution Network) ist im Grunde der 0. Schritt jeder Performance -Arbeiten der Front -End -Leistung und noch bevor er anfing, ausgefallene Dinge zu berücksichtigen (z. B. Code -Segmentierung oder Serverkomponente).

Der Hauptzweck eines CDN (Inhaltsverteilungsnetzwerk) besteht darin, die Verzögerung zu reduzieren und den Inhalt so bald wie möglich an den Endbenutzer zu liefern. Sie haben eine Vielzahl von Strategien dafür implementiert. Die beiden wichtigsten dieses Artikels sind "verteilte Server" und "Cache".

CDN -Anbieter haben mehrere Server an verschiedenen geografischen Orten. Diese Server können Kopien statischer Ressourcen speichern und sie an Benutzer senden, wenn sie sie nach ihrem Browser fragen. CDN ist im Grunde eine weiche Schicht um Ihren ursprünglichen Server, das ihn vor dem externen Einfluss schützen und seine Interaktion mit der externen Welt minimieren kann. Es ist ein bisschen wie der introvertierte KI -Assistent, der einen typischen Dialog bewältigen kann, ohne dass echte Menschen teilnehmen können.

Im obigen Beispiel befindet sich unser Server in Norwegen und der Client in Australien.

Mit dem mittleren CDN ändert sich das Bild. CDN hat einen Server an einem Ort, an dem Benutzer näher kommen, wie beispielsweise irgendwo in Australien. Irgendwann erhält CDN eine Kopie statischer Ressourcen vom ursprünglichen Server. Danach erhalten Benutzer aus Australien oder irgendwo diese Kopien anstelle der Originalkopie vom norwegischen Server.

es implementiert zwei wichtige Dinge. Erstens wird die Last auf dem ursprünglichen Server reduziert, da Benutzer nicht mehr direkt darauf zugreifen müssen. Zweitens können Benutzer diese Ressourcen jetzt schneller erstellen, da sie einige JavaScript -Dateien nicht mehr über den Ozean herunterladen müssen.

Der LCP -Wert in unserer Simulation oberhalb fällt von 960 Millisekunden auf 640 Millisekunden ab?

Zugriffsleistung wiederholen Bisher diskutieren wir nur die erste Besuchsleistung -die Leistung von Personen, die Ihre Website noch nie besucht haben. Aber ich hoffe, dass die Website so hervorragend ist, dass die meisten der ersten Besucher Stammkunden werden. Oder zumindest nach der ersten Ladung gehen sie nicht, stöbern Sie ein paar Seiten und können etwas kaufen. In diesem Fall hoffen wir normalerweise, dass der Browser die statischen Ressourcen (wie CSS und JS) zwischen den Kopien von ihnen in der Region einräumt, nicht immer herunterladen.

Schauen wir uns an, wie sich die Leistungsdiagramme und Zahlen in diesem Fall ändern.

Öffnen Sie das Lernprojekt erneut. Stellen Sie im Entwicklungstool das "Netzwerk" auf die "durchschnittliche 3G" ein, die wir vor der hohen Latenz und einer niedrigen Bandbreite erstellt haben, damit wir den Unterschied sofort erkennen können. Und stellen Sie sicher, dass das Kontrollkästchen "Netzwerkcache deaktivieren" nicht ausgewählt ist.

Aktualisieren Sie den Browser zuerst, um sicherzustellen, dass wir die ersten Besucher eliminieren. Dann aktualisieren und die Leistung messen.

Wenn Sie ein Lernprojekt verwenden, kann das Endergebnis etwas überraschend sein, da es so aussieht:

CSS- und JavaScript-Dateien sind auf der Registerkarte „Netzwerk“ immer noch sehr prominent und ich sehe sie mit etwa 300 ms in „Anfrage senden und warten“ – der Latenzeinstellung, die wir im Profil „Durchschnittliches 3G“ festgelegt haben. Infolgedessen ist LCP nicht so niedrig, wie es sein könnte, und ich habe eine Lücke von 300 ms, wenn der Browser nur darauf wartet, CSS zu blockieren.

Was ist passiert? Sollten Browser dieses Zeug nicht zwischenspeichern?

Browser-Cache mithilfe des Cache-Control-Headers steuern

Wir müssen jetzt das Netzwerk-Panel verwenden, um zu verstehen, was vor sich geht. Öffnen Sie es und suchen Sie dort die CSS-Datei. Es sollte so aussehen:

Das Interessanteste hier sind die Spalte „Status“ und die „Größe“. Bei „Größe“ handelt es sich definitiv nicht um die Größe der gesamten CSS-Datei. Es ist zu klein. Bei „Status“ handelt es sich nicht um unseren üblichen 200-Status „Alles ist in Ordnung“, sondern um etwas anderes – einen 304-Status.

Zwei Fragen hier: Warum 304 statt 200 und warum wurde die Anfrage überhaupt gesendet? Warum funktioniert das Caching nicht?

Erste 304-Antwort. Dies ist die Antwort, die ein gut konfigurierter Server auf eine bedingte Anfrage sendet – wobei sich die Antwort basierend auf verschiedenen Regeln ändert. Solche Anfragen werden häufig zur Steuerung des Browser-Cache verwendet.

Wenn der Server beispielsweise eine Anfrage für eine CSS-Datei erhält, kann er prüfen, wann die Datei zuletzt geändert wurde. Wenn dieses Datum mit dem Datum in der browserseitigen Cache-Datei übereinstimmt, wird eine 304 mit leerem Textkörper zurückgegeben (deshalb ist es nur 223 B). Dies bedeutet, dass der Browser Dateien, die er bereits besitzt, sicher wiederverwenden kann. Sie müssen keine Bandbreite verschwenden und sie erneut herunterladen.

Aus diesem Grund sehen wir in den Leistungsbildern die großen Zahlen „Anfrage senden und warten“ – der Browser bittet den Server um eine Bestätigung, dass die CSS-Datei noch aktuell ist. Aus diesem Grund beträgt der „Inhaltsdownload“ dort 0,33 ms – der Server gibt „304 Unmodified“ zurück und der Browser verwendet einfach die zuvor heruntergeladene Datei wieder.

Zusätzliche Übungen

1. Gehen Sie im Lernprojekt zum Ordner dist/assets und benennen Sie die CSS-Datei um
2. Gehen Sie zur Datei dist/index.html und aktualisieren Sie den Pfad zur umbenannten CSS-Datei
3. Aktualisieren Sie die geöffnete Seite und öffnen Sie die Registerkarte „Netzwerk“. Die CSS-Datei sollte nun mit einem neuen Namen, dem Status 200 und der richtigen Größe angezeigt werden – sie wurde erneut heruntergeladen. Dies wird als „Cache-Busting“ bezeichnet – eine Methode, mit der der Browser gezwungen wird, möglicherweise zwischengespeicherte Ressourcen erneut herunterzuladen.
4. Die Seite wurde erneut aktualisiert – sie ist zum Status 304 zurückgekehrt und die zwischengespeicherte Datei wurde wiederverwendet.

Nun zur zweiten Frage – warum wurde diese Anfrage überhaupt gesendet?

Dieses Verhalten wird durch den Cache-Control-Header gesteuert, den der Server als Antwort festlegt. Klicken Sie im Bereich „Netzwerk“ auf die CSS-Datei, um die Anfrage-/Antwortdetails anzuzeigen. Suchen Sie im Block „Response Headers“ der Registerkarte „Headers“ nach dem Wert „Cache-Control“:

In diesem Header können Sie sich mit einem Komma mit verschiedenen Kombinationen trennen. In unserem Beispiel gibt es zwei:

max -age
• mit einer Zahl -Wie lange wird diese spezifische Antwort (in Sekunden) gespeichert muss
-in in der Revalidate It angeben, dass die Antwort, wenn sie abgelaufen ist, immer eine neue Version der Anforderung an den Server sendet. Wenn die Antwort im Cache mehr als der Wert des maximalen Alters vorliegt, läuft die Antwort ab.
• Daher sagt der Header im Grunde den Browser:

Sie können diese Antwort in Ihrem Cache speichern, müssen jedoch nach einer Weile wieder mit mir verifizieren.

übrigens können Sie die Cache -Zeit genau
• null
zweiten. Viel Glück.
• Infolgedessen verifizieren Sie den Browser
immer

mit dem Server und verwenden Sie den Cache niemals sofort.

Wir können diese -wir müssen diese -Wir müssen jedoch nur die maximale Anzahl auf 0 bis 31536000 ändern (ein Jahr, die maximale Anzahl von Sekunden). In Ihrem Lernprojekt finden Sie in Ihrem Lernprojekt in die Datei Backend/INDEX.TS-Datei, um die Position des Einstellens max-ay = 0 zu finden und sie auf 31536000 (ein Jahr) zu ändern. Aktualisieren Sie die Seite mehrmals, Sie sollten den folgenden Inhalt der CSS -Datei auf der Registerkarte "Netzwerk" sehen:

Bitte beachten Sie, dass die Spalte "Status" jetzt grau geworden ist. Die CSS -Datei bietet jetzt Dienste aus dem Cache des Browsers und wird in einem Jahr immer der Fall sein. Aktualisieren Sie die Seite mehrmals, um sie anzuzeigen, sie wird sie nicht ändern.

Nun, für alle Hauptpunkte der Verarbeitung des Cache -Headers: Messen Sie die Leistung der Seite erneut. Vergessen Sie nicht, die Einstellungen "Durchschnitt 3G" -Konfigurationsdatei einzustellen und die Einstellungen "Cache deaktivieren" beizubehalten.

Das Ergebnis sollte ähnlich sein wie:

Obwohl die Verzögerung hoch ist, ist der Abschnitt "Anforderung und Warten" fast auf Null reduziert.

Zusätzliche Übungen

1. Ändern Sie den Wert für das maximale Alter auf 10 (10 Sekunden)
2. Aktivieren Sie das Kontrollkästchen „Cache deaktivieren“ und aktualisieren Sie die Seite, um den Cache zu löschen.
3. Deaktivieren Sie das Kontrollkästchen und aktualisieren Sie die Seite erneut – dieses Mal sollte sie aus dem Speichercache bereitgestellt werden.
4. Warten Sie 10 Sekunden und aktualisieren Sie die Seite erneut. Da das maximale Alter nur 10 Sekunden beträgt, überprüft der Browser die Ressource erneut und der Server gibt erneut 304 zurück.
5. Aktualisieren Sie die Seite jetzt – sie sollte wieder aus dem Speicher bereitgestellt werden.

Cache-Kontrolle und moderne Bündelungstools

Bedeuten die oben genannten Informationen, dass Caching unser Allheilmittel für die Leistung ist und dass wir alles so aggressiv wie möglich zwischenspeichern sollten? Absolut nicht! Darüber hinaus führt die Möglichkeit, dass eine Kombination aus „nicht technisch versierten Kunden“ und „am Telefon erklärt werden muss, wie man den Browser-Cache löscht“ dazu, dass selbst der erfahrenste Entwickler eine Panikattacke bekommt.

Es gibt Millionen von Möglichkeiten, das Caching zu optimieren, Millionen von Kombinationen von Anweisungen im Cache-Control-Header mit anderen Headern, die die Cache-Dauer beeinflussen können oder auch nicht, was von der Serverimplementierung abhängen kann oder auch nicht. Allein zu diesem Thema könnten wohl mehrere Bücher geschrieben werden. Wenn Sie ein Caching-Guru werden möchten, beginnen Sie mit den Artikeln unter https://web.dev/ und den MDN-Ressourcen und folgen Sie den Breadcrumbs.

Leider kann Ihnen niemand sagen: „Hier sind die fünf besten Caching-Strategien für alles.“ Die Antwort könnte bestenfalls lauten: „Wenn Sie diesen Anwendungsfall in Kombination mit diesem, diesem und diesem haben, dann ist diese Kombination von Cache-Einstellungen eine gute Wahl, aber seien Sie sich dieser Probleme bewusst.“ Es kommt darauf an, Ihre Ressourcen und Ihr Build-System zu verstehen, wie oft sich Ihre Ressourcen ändern, wie sicher Ihr Cache ist und welche Konsequenzen es hat, wenn Sie etwas falsch machen.

Es gibt jedoch eine Ausnahme. Eine Ausnahme, für die es klare „Best Practices“ gibt: JavaScript- und CSS-Dateien für Websites, die mit modernen Tools erstellt wurden. Moderne Paketierungstools wie Vite, Rollup, Webpack usw. können „unveränderliche“ JS- und CSS-Dateien erstellen. Sie sind natürlich nicht wirklich „unveränderlich“. Diese Tools generieren jedoch Dateinamen mithilfe von Hash-Strings, die vom Dateiinhalt abhängen. Wenn sich der Dateiinhalt ändert, ändert sich auch der Hash und damit auch der Dateiname. Wenn die Website bereitgestellt wird, ruft der Browser daher unabhängig von den Cache-Einstellungen erneut eine neue Kopie der Datei ab. Der Cache wird „geleert“, genau wie beim vorherigen manuellen Umbenennen der CSS-Datei.

Sehen Sie sich zum Beispiel den Ordner dist/assets im Lernprojekt an. JS- und CSS-Dateien haben Index-[Hash]-Dateinamen. Merken Sie sich diese Namen und führen Sie npm run build ein paar Mal aus. Die Namen bleiben gleich, da sich der Inhalt dieser Dateien nicht geändert hat.

Gehen Sie nun zur Datei src/App.tsx und fügen Sie irgendwo etwas wie console.log('bla') hinzu. Führen Sie npm run build erneut aus und überprüfen Sie die generierten Dateien. Sie sollten sehen, dass der CSS-Dateiname derselbe bleibt, der JS-Dateiname sich jedoch geändert hat. Wenn diese Website bereitgestellt wird und ein wiederkehrender Benutzer sie das nächste Mal besucht, fordert der Browser eine völlig andere JS-Datei an, die nie in seinem Cache erscheint. Der Cache wurde geleert.

Zusätzliche Übungen

Suchen Sie das Äquivalent des dist-Ordners Ihres Projekts und führen Sie Ihren Build-Befehl aus.

• Wie sieht der Dateiname aus? So etwas wie ein Hash oder einfach index.js, index.css usw.?
• Ändert sich der Dateiname, wenn Sie den Build-Befehl erneut ausführen?
• Wenn Sie irgendwo in Ihrem Code eine einfache Änderung vornehmen, wie viele Dateinamen ändern sich?

Wenn Ihr Build-System auf diese Weise konfiguriert ist, haben Sie Glück. Sie können Ihren Server sicher so konfigurieren, dass er den maximalen Max-Age-Header für generierte Assets festlegt. Wenn Sie alle Bilder gleich versionieren – noch besser: Sie können Bilder auch in eine Liste aufnehmen.

Abhängig von der Website und ihren Benutzern sowie deren Verhalten kann dies zu einer ziemlich schönen Leistungssteigerung beim ersten kostenlosen Laden führen.

Muss mein einfacher Anwendungsfall das alles wirklich wissen?

An diesem Punkt denken Sie wahrscheinlich so etwas wie: „Sie sind verrückt. Ich habe am Wochenende eine einfache Website mit Next.js erstellt und sie in 2 Minuten auf Vercel/Netlify/HottestNewProvider bereitgestellt. Natürlich diese.“ Moderne Werkzeuge erledigen das alles für mich.“ Das ist völlig in Ordnung. Das denke ich auch. Aber dann habe ich es tatsächlich ausprobiert und wow, ich war überrascht?

Beide meiner Projekte haben max-age=0 und müssen für CSS- und JS-Dateien erneut validiert werden. Es stellt sich heraus, dass dies die Standardeinstellung meines CDN-Anbieters ist??‍♀️. Natürlich haben sie Gründe

Das obige ist der detaillierte Inhalt vonErstladeleistung für React-Entwickler: investigativer tiefer Einblick. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!