• Erledigen Sie die Anwendungssicherheit auf die richtige Weise! Erkennen, schützen, überwachen, beschleunigen und mehr…
  • 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.

    Fügen Sie die richtigen Maße hinzu

    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:

    Messungen | Diagramm erstellt am Terrastruktur

    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 inhaltliche Farbe bezieht sich darauf, wann das erste Element im DOM gerendert wird. Das kann so einfach sein wie Text, 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 inhaltliche Farbe bezieht sich darauf, wann das größte Element im Browser-Ansichtsfenster des Benutzers gerendert wird. Dies signalisiert normalerweise das Ende des Rendering-Teils des Seitenladens, und der Benutzer sieht einen ausgefüllten Bildschirm. Dies wird auch durch Ausführen von Lighthouse gemessen.

    Größte inhaltliche Farbe bis Zeit für interaktive:

    Schließlich bezieht sich die Zeit bis zur Interaktion 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 erwarten, dass sie dazu in der Lage sind! Dies ist eine weitere Metrik, die Lighthouse uns beim Messen hilft.

    Code reduzieren

    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 klein; Da Anforderungen über das Kabel komprimiert werden, können Sie beim Schneiden von 1 MB Quellcode nur 10 KB Bandbreite einsparen. Die Beschleunigung durch weniger 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 Features ausschneiden oder Code löschen. Glücklicherweise gibt es einige Standardverfahren, um Code zu reduzieren, ohne dies tun zu müssen.

    • Führen Sie Ihren Code durch Minifizierer. Minifahrer führen Optimierungen durch, z. B. lange Namen in kurze verkürzen (signUpDarkModeButton wird zu ss), Leerzeichen entfernen und andere, um Ihren Code so kompakt wie möglich zu gestalten, 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.

    Teilen Sie den Code in Blöcke auf

    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.

    Angenommen, 20% Ihres Codes unterstützen eine Funktion Ihrer App, auf die Benutzer nur mit wenigen Klicks zugreifen können. Es wäre Zeitverschwendung für den Browser, diesen Code zu analysieren, bevor ein Ladebildschirm angezeigt wird. Das Aufteilen Ihres Codes in Blöcke kann die Zeit bis zur Interaktion erheblich verkürzen.

    Anstatt ein ineinander verschlungenes Abhängigkeitsdiagramm der Importe für alle Ihre Javascript-Dateien zu haben, identifizieren Sie Bereiche, die leicht geschnitten werden können. Beispielsweise lädt eine Komponente möglicherweise einige schwere Bibliotheken. Sie können diese Komponente in eine eigene Datei isolieren und dann nur 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.

    Serverseitiges Rendern

    Angesichts der Tatsache, dass Browser all das intensive Parsen und Kompilieren durchführen müssen und Benutzer auf Chromebooks und Mobilgeräten haben, besteht eine übliche Technik zur Verkürzung der Ladezeiten darin, dass Ihre Server einen Teil dieser Last übernehmen. Dies bedeutet, dass Sie, anstatt eine leere Seite anzugeben und dann den gesamten Inhalt mit Javascript auszufüllen, wie dies heutzutage bei den meisten Apps mit nur einer Seite der Fall ist, 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 sind viel schneller und vorhersehbarer als die Browser der Benutzer. Unweigerlich müssen sie noch Javascript-Code analysieren, damit die App interaktiv ist. Das serverseitige Rendern kann jedoch einen Großteil des ursprünglichen Inhalts ausfüllen, sodass beim Aufrufen der Seite mindestens ein Ladebildschirm oder ein Fortschrittsbalken angezeigt wird.

    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.

    Assets komprimieren

    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 ihre kleinstmöglichen Abmessungen, bei denen sie gezeigt werden. Wenn Sie ein Benutzerprofil in einem winzigen Element von 50 x 50 Pixel ohne Größenänderung anzeigen lassen, nimmt sich Ihre App die Zeit, um das vollständige Bild, das als Desktop-Hintergrund scharf aussieht, herunterzuladen und es dann auf die winzige Größe zu verkleinern.

    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 und video Elemente, die das Zurückgreifen von Formaten 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.