Verringern der App-Ladezeit

Verringern der App-Ladezeit (HTML)

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Wenn ein Benutzer zum Starten einer App auf die entsprechende Kachel tippt, ist das die erste Erfahrung, die er mit der App macht. Der erste Eindruck zählt. Deshalb ist es wichtig, dass der Benutzer nicht lange warten muss, bis die App gestartet ist. Wie Sie die App verpacken und die Codedateien referenzieren kann sich positiv auf die Startdauer der App auswirken.

Begrenzen des Inhalts auf das App-Paket

Sie können die Ladezeit der App erheblich verbessern, wenn Sie ihren Inhalt (z. B. JavaScript, CSS, Bilder und andere wichtige App-Dateien) lokal verpacken. Datenträgervorgänge sind schneller als Netzwerkvorgänge (wie das Abrufen der Datei von einem Remoteserver). Das lokale Verpacken von Dateien bietet zudem weitere Leistungsvorteile, wie die Bytecode-Zwischenspeicherung.

Nutzen der Bytecode-Zwischenspeicherung

Windows 8 verfügt über ein Feature namens Bytecode-Zwischenspeicherung, mit dem die Ladezeiten von JavaScript-Dateien einer App verringert werden können. Die Bytecode-Zwischenspeicherung ist eine Technik, mit der das System für jede JavaScript-Datei einmalig einen Bytecode erstellt, anstatt den Bytecode bei jedem Start der App neu zu erstellen.

Damit Sie die Funktionsweise von Bytecode-Zwischenspeicherung besser verstehen, müssen Sie wissen, wie das System Apps installiert. Eine App beginnt als Paket. Dieses Paket enthält alle Dateien, aus denen die App besteht. Dazu gehören HTML-, JavaScript-, CSS- und Mediendateien. Wenn die App im System bereitgestellt wird, extrahiert das System das Paket in separate Dateien.

Inhalt eines Pakets

Wenn ein normaler Browser die JavaScript-Dateien lädt, wird als einer der ersten Schritten das JavaScript in Bytecode umgewandelt. Dabei handelt es sich um ein JavaScript-Format, das der Browser ausführen kann. Der Browser führt diesen Schritt für jede JavaScript-Datei aus. Folglich erhöht dieses Verfahren die Ladezeiten für die Dateien.

Wenn Sie hingegen eine Windows Store-App mit JavaScript auf dem System installieren, sucht das System die JavaScript-Dateien im Paket und konvertiert sie in Bytecode. Anschließend verwendet die App die Bytecodeversion des JavaScripts. Die Bytecode-Zwischenspeicherung beschleunigt das Starten der Anwendung, da die JavaScript-Dateien bereits in Bytecode konvertiert wurden und nicht erneut verarbeitet werden müssen. Die Bytecode-Zwischenspeicherung verbessert die Ladezeit von größeren Anwendungen um ungefähr 30 %.

Die Plattform kann die Bytecode-Zwischenspeicherung nur für JavaScript ausführen, das im App-Paket enthalten ist. Das ist ein weiterer Grund, warum der App-Inhalt auf das lokale Paket beschränkt bleiben sollte.

So stellen Sie sicher, dass die App von der Bytecode-Zwischenspeicherung profitiert:

  • Stellen Sie sicher, dass alle JavaScript-Dateien in UTF8 mit einer Bytereihenfolge-Marke (Byte-Order Mark, BOM) codiert sind.
  • Stellen Sie sicher, dass im Stamm der HTML-Startseite auf alle JavaScript-Dateien verwiesen wird.

Schnelleres Laden der JavaScript-Dateien

Wenn das Laden einer App beginnt, wird von Windows zuerst die HTML-Start Page geladen, die im Paketmanifest angegeben ist. Die Start Page ist der Ausgangspunkt der App und bestimmt, welcher Inhalt und Code zuerst geladen und ausgeführt wird. Wie sie den Code einschließen, kann großen Einfluss auf die Leistung haben. Code kann im HTML der Startseite über statisches Markup eingeschlossen, dynamisch geladen oder inline deklariert werden. Sie haben folgende Möglichkeiten, um Code einzuschließen:

  • Verwenden von statischem Markup auf der Startseite

    Sie können das JavaScript der App am schnellsten laden, indem Sie ein script-Element verwenden und dessen src-Attribut auf die lokale JavaScript-Datei festlegen. In diesem Fall beginnt Windows mit dem Laden der Datei sofort beim Analysieren der Start Page. Hier sehen Sie ein Beispiel für dieses Skriptelement:

    
    <script type="text/javascript" src='code.js'></script>
    
    

    Schnellere Ladezeiten erzielen Sie, wenn Sie mit statischem Markup das gesamte JavaScript laden, das zum Initialisieren der App benötigt wird.

  • Dynamisches Laden von JavaScript über die Codeausführung

    Die JavaScript-Codeausführung stellt eine weitere Möglichkeit dar, eine JavaScript-Datei zu laden. In diesem Beispiel wird mit JavaScript ein script-Element dynamisch erstellt und weiteres JavaScript geladen:

    
    var s = document.createElement(‘script');
    s.src = ‘code.js';
    document.head.appendChild(s);
    
    
    

    Das Problem beim dynamischen Laden von JavaScript-Dateien liegt darin, dass das System den dynamischen Code erst laden kann, nachdem es vorher anderen Code geladen und ausgeführt hat — d. h. den Code, der das dynamische Laden ausführt.

    Das dynamische Laden empfiehlt sich nur in folgenden Fällen:

    • Die App benötigt die JavaScript-Datei beim Laden nicht. Die Datei kann später geladen werden.
    • Die URI der JavaScript-Datei ist der App erst nach dem Starten bekannt. Die Datei kann deshalb nicht statisch eingeschlossen werden.
  • Deklarieren von JavaScript inline (nicht empfehlenswert)

    Als dritte Möglichkeit zum Einschließen von JavaScript kann JavaScript-Code inline in der HTML-Datei deklariert werden. In diesem Beispiel wird eine einfache JavaScript-Anweisung inline deklariert:

    
    <script type="text/javascript">
      // JavaScript code here
      var a = 2 + 2; 
    </script>
    
    
    

    Wir raten davon ab, JavaScript inline zu deklarieren. Denn damit ist es nicht möglich, die gleichen Leistungsoptimierungen (z. B. Bytecode-Zwischenspeicherung) zu erzielen wie mit JavaScript, das in der eigenen Datei deklariert wird. Speichern Sie den JavaScript-Code immer in einer externen Datei, und verwenden Sie das src-Attribut eines script-Elements, um ihn zu laden.

Wenn die App eine JavaScript-Datei beim Starten benötigt, laden Sie die Datei nicht dynamisch. Fügen Sie stattdessen der Start Page, die auf die JavaScript-Datei verweist, ein script-Element hinzu. Diese Optimierung kann die Ladezeit der App erheblich verkürzen. Wir haben schon erlebt, dass eine App für das dynamische Laden von JavaScript 700 ms benötigt hat.

Tipp  Definieren Sie alle Dateien, die zum Initialisieren einer App benötigt werden, im HTML ihrer Start Page. Verwenden Sie kein Skriptladeprogramm, um die JavaScript-Dateien dynamisch zu laden, die die App für die Initialisierung benötigt.
 

Nur das Nötigste laden

Eine weitere, häufig vergessene Möglichkeit zum Verbessern der App-Ladezeit besteht darin, nur das zu laden, was für die erste Seite benötigt wird. Der Rest kann später geladen werden. Diese Empfehlung bezieht sich auf Bilder, JavaScript, CSS-Dateien und andere entsprechende Dateien.

In den folgenden Abschnitten finden Sie einige Möglichkeiten, um das Ladens von Dateien zu vermeiden, die die App nicht unmittelbar benötigt:

  • Verzögern des Ladens von JavaScript

    Es gibt zwei Möglichkeiten, wie Sie JavaScript mithilfe des script-Elements für die App laden können. Die erste Möglichkeit besteht darin, das script-Element zu verwenden und nur den Typ- und den src-Wert anzugeben. Wenn der Host das script-Element verarbeitet, wird das Laden nicht verzögert. Der Hostprozess muss diese Datei laden und ausführen, bevor die App als geladen betrachtet werden kann. Dadurch erhöht sich die Initialisierungsdauer für die App.

    Das folgende Beispiel verwendet keine Ladeverzögerung:

    
    <script type="text/javascript" src='file1.js'></script>
    
    
    

    Die zweite Verwendungsmöglichkeit für das script-Element besteht in der Verwendung des defer-Attributs. Das script-Attribut teilt dem Hostprozess mit, dass der Code im Skript zum Initialisieren der App nicht benötigt wird und später geladen und ausgeführt werden kann. Das nächste Beispiel verwendet das verzögerte Laden:

    
    <script type="text/javascript" src='file1.js' defer='defer'></script>
    
    
    
  • Referenzieren von JavaScript innerhalb des zugeordneten Fragments

    Fragmente sind ein Feature der Windows-Bibliothek für JavaScript und ermöglichen es einer App, verschiedene Seiten und Ansichten in Komponenten aufzugliedern. Zu den größten Vorteilen von Fragmenten zählt, dass die App auf JavaScript im Fragment verweisen kann und das System die JavaScript-Fragmentdatei erst lädt, wenn die entsprechende Seite benötigt wird. Einige Apps enthalten unter Umständen viele Zeilen mit JavaScript-Code, die erst später relevant sind, für den ersten Ladebildschirm aber nicht gebraucht werden. Wenn dieser Code in eine andere JavaScript-Datei ausgegliedert wird, kann das die Ladezeit der App verkürzen, indem die JavaScript-Fragmentdatei erst bei Bedarf geladen wird.

    Die meisten Spiele werden auf diese Weise geladen. Wenn ein Spiel zum ersten Mal geladen wird, erscheint das Hauptmenü in der Regel sehr schnell, da nur die Elemente geladen werden, die für diesen Bildschirm nötig sind. Wenn ein Benutzer dann mit der Verwendung des Spiels beginnt (also ein Spiel erstellt oder lädt), werden die restlichen Daten des Spiels geladen.

  • Zwischenspeichern der App-Fragmente

    Ein Fragment können Sie mit der WinJS.UI.Fragments.cache-Funktion zwischenspeichern. Sobald es sich im Cache befindet, kann die App das Fragment mit der renderCopy-Funktion schnell anzeigen. Falls der Benutzer schon beim Laden der App oder kurz danach mit dem Fragment interagiert, müssen Sie es während der Aktivierung oder direkt im Anschluss zwischenspeichern. Wenn Sie ein Fragment nicht explizit zwischenspeichern, übernimmt die App diese Zwischenspeicherung, wenn sie das Fragment zum ersten Mal verwendet.

    Sie müssen die zwischengespeicherten Fragmente und das Löschen des Fragmentcaches nicht nachverfolgen. Der Cache wird von WinJS gepflegt.

    Beim Zwischenspeichern eines Fragments geht es darum, eine Aufgabe vorab auszuführen, und der zwischengespeicherte Inhalt verbraucht Arbeitsspeicher. Zudem werden CPU-Zeit und E/A-Kapazitäten beansprucht. Wir empfehlen daher Folgendes:

    • Speichern Sie bei einer kleinen App mit schneller Aktivierung alle Fragmente zwischen, bevor Sie die Aktivierung abschließen.
    • Sind hingegen viel Fragmentinhalte vorhanden, und die Aktivierung der App dauert bereits lange, sollten Sie die Fragmente nach der Aktivierung zwischenspeichern. Speichern Sie die Fragmente nicht alle gleichzeitig zwischen, sondern einzeln. Dadurch vermeiden Sie, dass bei einer Interaktion des Benutzers mit der App zu viele Ressourcen blockiert werden.
    • Falls Sie sich nicht sicher sind, ob Sie die Fragmente während oder nach der Aktivierung zwischenspeichern sollten, können Sie beides ausprobieren und dabei die jeweils benötigte Zeit für den App-Start ermitteln.
  • Duplizieren Sie keine Verweise auf CSS- (Cascading Style Sheets) und JavaScript-Dateien in Seitenfragmenten — verweisen Sie auf allgemeine Dateien auf der Startseite.

    Jeder Verweis auf eine CSS- oder JavaScript-Datei kostet das System Zeit zum Laden und Analysieren der Datei. Ein häufig begangener Fehler ist die Verwendung von Verweisen auf eine CSS- oder JavaScript-Datei in einem Fragment, das die Startseite oder ein anderes Fragment bereits geladen hat. Unser Test zeigt, dass sich die Ladezeiten um durchschnittlich 40 ms verbessern lassen, wenn doppelte Verweise vermieden werden.

Tipp  Verzögern Sie nach Möglichkeit das Laden von JavaScript-Dateien, und verwenden Sie Fragmente, um Ihr JavaScript in separate Dateien aufzugliedern, die nicht alle sofort beim App-Start geladen werden müssen.
 

 

 

Anzeigen:
© 2017 Microsoft