Wie schnell Ihre Website oder App anfänglich geladen wird, ist der erste Eindruck, den Ihre Benutzer erhalten. In diesem Handbuch werden bewährte Techniken aufgeführt, mit denen Sie wertvolle Sekunden nach dem ersten Laden der Seite sparen können.
Anfangsladezeit
Die Zeit, die von der Eingabe Ihres Domainnamens durch Ihren Benutzer oder Kunden bis zur Anzeige von Inhalten benötigt wird, ist die wichtigste Zeit, die Sie benötigen, um einen guten ersten Eindruck zu hinterlassen.
Amazon stellte fest, dass alle 100 Millisekunden Latenz 1% Umsatz kosteten.
Und dennoch behandeln viele Webentwickler dies als einen nachträglichen Gedanken. Immer mehr Bibliotheken werden für immer mehr Funktionen hinzugefügt, und im Laufe der Zeit werden allmählich weniger Conversions angezeigt. Schlimmer noch, diese Umwandlungsverluste sind schwer zu erkennen, weil sie a aufgeben langsam ladende Seite bevor es Zeit hat, Metriken zu senden.
Einige davon sind Techniken, die im Front-End und andere im Back-End implementiert werden können. Unabhängig davon müssen Web-Apps schnell geladen werden.
Add the right measurements
Als erstes müssen Sie Messungen hinzufügen. Es gibt viele Phasen des Ladevorgangs, und Sie werden nicht wissen, wo der Engpass liegt, ohne die richtigen Segmente zu messen.
Das Folgende sind die wichtigsten Meilensteine des Ladevorgangs:
Dies bedeutet, dass Sie Metriken für verfolgen sollten jedes Segment dieses Diagramms.
Lassen Sie uns durchgehen, wie Sie das tun könnten.
Browser-Anfrage zur Antwort zugestellt:
Messen Sie dies auf Ihrem Server. Sie möchten den Moment erhalten, in dem Ihre API die Anfrage erhält, wenn sie eine Antwort liefert. Je nachdem, ob beispielsweise externe Aufrufe von Datenbanken getätigt werden, kann dies entweder sehr kurz oder ein erheblicher Engpass sein.
Antwort auf die erhaltene Antwort:
Dies ist schwieriger zu messen, aber eine Möglichkeit, dies zu tun, besteht darin, einen Zeitstempel hinzuzufügen, wenn Ihre Antwort Ihren Server verlässt, und diesen mit der aktuellen Zeit auf der Benutzerseite zum erstmöglichen Zeitpunkt zu messen (ein Skript-Tag im Kopf des HTML-Codes) Seite).
Antwort auf erste inhaltliche Farbe erhalten:
Die erste Inhaltsfarbe ist, wenn das erste Element auf dem DOM gerendert wird. Das kann etwas so Einfaches sein wie ein Text, ein Hintergrund oder ein Ladespinner. Dies kann durch Laufen gemessen werden Lighthouse in den Chrome Dev Tools.
Erste inhaltliche Farbe zur größten inhaltlichen Farbe:
Die größte inhaltsreiche Farbe ist, wenn das größte Element im Browser-Ansichtsfenster des Benutzers gerendert wird. Dies signalisiert normalerweise das Ende des „Rendering“-Teils des Ladens der Seite und der Benutzer sieht einen gefüllten Bildschirm. Dies wird auch gemessen, indem Lighthouse ausgeführt wird.
Größte inhaltliche Farbe bis Zeit für interaktive:
Schließlich bezieht sich die Interaktionszeit darauf, wann der Benutzer Aktionen wie Scrollen, Klicken und Tippen ausführen kann. Es kann besonders frustrierend sein, wenn diese Dauer lang ist, weil sie einen gerenderten Bildschirm vor sich sehen, aber nichts tun können, wenn sie es erwarten! Dies ist eine weitere Metrik, die Lighthouse uns bei der Messung hilft.
Reduce code
Nachdem Sie die Messungen durchgeführt haben, können Sie Optimierungen vornehmen. Optimierungen haben Kompromisse, und die Messungen zeigen Ihnen, welche es wert sind.
Die am schnellsten zu ladende Seite ist eine leere Seite, aber einer App kann viel Code hinzugefügt werden, bevor jemand den Unterschied in der Ladegeschwindigkeit zwischen dieser und einer leeren Seite bemerken kann. Was oft passiert, ist, dass die Inkremente so klein sind, dass Sie den Unterschied von Build zu Build erst eines Tages wahrnehmen. Es fühlt sich nur langsam an. Sie erkennen, dass Ihre App aufgebläht ist, und an diesem Punkt macht das Reduzieren von Code einen Unterschied.
Wenn Sie den Code reduzieren, erhalten Sie zwei Geschwindigkeitsverbesserungen:
- Ihre App wird schneller über das Netzwerk übertragen.
- Der Browser des Benutzers beendet das Parsen des Codes schneller.
Die erste Beschleunigung ist gering; Da Anfragen über die Leitung komprimiert werden, kann es sein, dass Sie nur 1 KB Bandbreite einsparen, wenn Sie 10 MB Quellcode kürzen. Die Beschleunigung durch das Parsen ist jedoch signifikant. Ihre Benutzer führen Ihre App wahrscheinlich auf einem ganzen Spektrum von Browsern und Computern aus, von denen viele nicht über die Rechenleistung verfügen, die den Code möglicherweise so schnell wie auf eigene Faust analysiert.
Oder sie könnten weiterlaufen mobile Gerätemit noch weniger Rechenleistung. Der Unterschied kann in der Größe von Sekunden liegen.
Je weniger Code Sie haben, desto schneller kann der Browser das Parsen beenden und Ihre App ausführen. Selbst wenn Sie einen Ladebildschirm anzeigen möchten, den Javascript steuert, wurde dieser Code analysiert.
Sie möchten jedoch keine Funktionen kürzen oder Code löschen. Glücklicherweise gibt es ein paar Standardpraktiken, um Code zu reduzieren, ohne dies tun zu müssen.
- Führen Sie Ihren Code durch Minifizierer. Minifier führen Optimierungen wie kurze lange Namen in kurze durch (signUpDarkModeButton wird zu ss), entfernen Leerzeichen und andere, um Ihren Code so kompakt wie möglich zu machen, ohne etwas zu verlieren.
- Partials importieren. Bibliotheken sind oft mit Dingen aufgebläht, die Sie nicht benötigen, die aber unter einem Dach zusammengefasst sind. Möglicherweise möchten Sie nur eine bestimmte Funktion einer Dienstprogrammbibliothek. Anstatt die gesamte Bibliothek zu importieren, können Sie nur den Code importieren, den Sie benötigen.
- Baum-Shake-toter Code. Manchmal verlassen Sie Code für Debugging-Zwecke oder haben eine veraltete Funktion nicht gründlich bereinigt, und obwohl sie in Ihrem Quellcode enthalten ist, wird sie nie ausgeführt. Es gibt Werkzeuge in der JavaScript-Toolchainwie Webpack, das toten Code oder nicht verwendete Abhängigkeiten erkennen und diese automatisch für Sie aus dem Produktionsbuild entfernen kann.
Split code into chunks
Nachdem Sie so viel Code wie möglich aus Ihrer gesamten App reduziert haben, können Sie darüber nachdenken, diese Idee weiter zu verdrängen und den für das anfängliche Laden erforderlichen Code zu reduzieren.
Nehmen wir an, 20 % Ihres Codes unterstützen eine App-Funktion, auf die Benutzer nur nach wenigen Klicks zugreifen können. Es wäre Zeitverschwendung für den Browser, diesen Code zu parsen, bevor ein Ladebildschirm angezeigt wird. Das Aufteilen Ihres Codes in Chunks kann die Interaktionszeit erheblich verkürzen.
Anstatt ein verflochtenes Abhängigkeitsdiagramm von Importen für alle Ihre Javascript-Dateien zu haben, identifizieren Sie einfach geschnittene Bereiche. Beispielsweise lädt eine Komponente möglicherweise einige umfangreiche Bibliotheken. Sie können diese Komponente in eine eigene Datei isolieren und sie dann nur dann importieren, wenn der Benutzer bereit ist, mit dieser Komponente zu interagieren.
Es gibt mehrere Bibliotheken, die das Laden verzögern können, je nachdem, welches Framework Sie verwenden. Es ist nicht erforderlich, über Bord zu gehen und jede Komponente aufzuteilen, da der Benutzer dann eine schnelle Anfangslast hat und auf jede nachfolgende Interaktion warten muss. Finden Sie die größten Teile, die Sie segmentieren können, und teilen Sie dort Ihren Quellcode auf.
Server-side render
Da Browser all diese intensive Analyse und Kompilierung durchführen müssen und Benutzer auf Chromebooks und Mobilgeräten haben müssen, besteht eine gängige Technik zur Reduzierung der Ladezeiten darin, dass Ihre Server einen Teil dieser Last übernehmen. Das bedeutet, dass Sie, anstatt eine leere Seite zu geben und dann Javascript zu verwenden, um den gesamten Inhalt auszufüllen, wie es die meisten Single-Page-Apps heutzutage tun, eine Javascript-Engine auf Ihrem Server (normalerweise Node.js) ausführen und ausfüllen können so viele Daten und Inhalte wie möglich.
Ihre Server werden viel schneller und vorhersehbarer sein als die Browser der Benutzer. Unweigerlich müssen sie noch etwas Javascript-Code parsen, damit die App interaktiv ist. Dennoch kann das serverseitige Rendern einen Großteil des anfänglichen Inhalts ausfüllen, sodass der Benutzer, wenn er die Seite erhält, bereits mindestens einen Ladebildschirm oder einen Fortschrittsbalken anzeigt.
Und wenn Daten für die erste Ansicht benötigt werden, muss der Client keine separate Anfrage stellen, um diese zu erhalten. Es wird bereits in der App hydratisiert, damit der Kunde es verwenden kann.
Compress assets
Mit Assets wird eine Seite zum Leben erweckt, und eine Seite fühlt sich erst dann vollständig geladen an, wenn das Rendern dieser Assets abgeschlossen ist. Dies können Ihr Hintergrund, Benutzeroberflächensymbole, ein Benutzerprofilbild oder sogar der Ladespinner sein. Häufig können Assets auch das Layout ändern. Wenn ein Benutzer versucht, mit etwas zu interagieren, springt die Seite möglicherweise weiter, während Assets geladen werden. Manchmal sind diese Assets die größte inhaltliche Farbe.
Assets sind aber auch einer der schwersten Teile einer App. Ein Bild kann mit mehreren Megabyte eingehen, und das Laden vieler Symbole kann leicht das maximale Limit für gleichzeitige Netzwerkanforderungen des Browsers überschreiten, was zu einer erstaunlichen Warteschlange beim Laden führt.
Sie möchten fast nie ein Bild aus dem Internet herunterladen und dann in Ihrer App darauf verweisen. Die Größe der Bilder sollte geändert werden auf die kleinstmöglichen Abmessungen, in denen sie gezeigt werden. Wenn Sie ein Benutzerprofil in einem winzigen 50-Pixel-mal-50-Pixel-Element anzeigen lassen, ohne die Größe zu ändern, nimmt sich Ihre App die Zeit, das vollständige Bild herunterzuladen, das als Desktop-Hintergrund scharf aussieht, und ändert es dann auf die winzige Größe.
Zweitens Bilder können komprimiert werden abhängig von ihrem Format. Heutzutage, webm ist das bevorzugte Format, aber das Feld der Komprimierung im Web wird ständig verbessert, und viele neue Formate sind in Sicht. Aufgrund der sich ändernden Formate unterstützen einige Browser die neueren möglicherweise nicht! Glücklicherweise kann die Browsertechnologie den Browser des Benutzers das von ihm unterstützte Format laden lassen.
Komprimieren Sie also auf das neueste und beste Format, behalten Sie aber auch eine weniger moderne Version bei und verwenden Sie sie picture funktioniert video Elemente, die Fallback-Formate unterstützen.
Fazit
Dies sind fünf der effektivsten Techniken, um Ihren Benutzern eine zu geben blitzschnelle erste Ladung auf Ihrer App. Diese verbessern Ihre Conversion-Raten, die Benutzerzufriedenheit und sogar Rankings suchen, da SEO schnelle Ladezeiten belohnt. Beim TerrastrukturWir verwenden diese und weitere Techniken, damit Benutzer so schnell wie möglich Diagramme erstellen und anzeigen können, die Sie in diesem Artikel sehen.
