👩🏼‍💼 🛀🏻 🔨 JavaScript Preis 2018 🔴 👩🏾‍⚖️ 🐥

Die Benutzererfahrung mit interaktiven Websites kann den Schritt des Sendens von JavaScript-Code umfassen. Oft - zu viel von diesem Code. Wenn die Site viel JavaScript verwendet, betrifft dies insbesondere mobile Benutzer. Waren Sie beispielsweise schon einmal auf mobilen Webseiten, die anscheinend einsatzbereit sind, aber nicht auf Klicks auf Links oder auf Versuche, durch die Seite zu scrollen, reagiert haben?

JavaScript-Code, der in mobile Browser gelangt, ist nach wie vor die teuerste Ressource, da er in vielerlei Hinsicht den Übergang von Seiten in einen Zustand verzögern kann, in dem Sie mit ihnen interagieren können. Welche Belastung für Systeme ist JavaScript heute? Wie analysiere ich Websites? Wie kann das Laden und Verarbeiten interaktiver Webseiten durch Browser beschleunigt werden? Eddie Osmani, dessen Übersetzung wir heute veröffentlichen, hat beschlossen, Antworten auf diese und viele andere Fragen zu finden, die sich bei denjenigen ergeben, die 2018 JavaScript für die Entwicklung von Websites verwenden.

Allgemeine Bestimmungen

Schauen Sie sich diesen Bericht an, der die Zeit zeigt, die erforderlich ist, um den JavaScript-Code von CNN für verschiedene Geräte zu verarbeiten. Es basiert auf Messungen , die mit Hilfe des WebPageTest.org- Projekts durchgeführt wurden ( hier ist eine Tabelle mit den Quelldaten für diesen Bericht, es gibt auch Daten auf der Walmart-Website).

Die Zeit, die zum Verarbeiten des cnn.com-JS-Codes für verschiedene Geräte benötigt wird

Wie Sie sehen können, erledigt ein High-End-Telefon (iPhone 8) die Aufgabe, den JS-Code in etwa 4 Sekunden zu verarbeiten. Ein Telefon mit mittlerer Reichweite (Moto G4) benötigt ungefähr 13 Sekunden, um das gleiche Problem zu lösen. Ein Budget, wenn auch ein modernes Gerät wie das Alcatel 1X, dauert etwa 36 Sekunden.

Heute werden wir über die Strategien sprechen, die Webentwickler anwenden können, um einerseits bequeme und moderne Websites zu erstellen und andererseits das effektive Laden, Verarbeiten und Funktionieren der JavaScript-Komponente dieser Websites sicherzustellen. Hier, kurz gesagt, sind die Hauptpunkte unseres Gesprächs, das übrigens auf meiner jüngsten Rede basiert:

Damit Webprojekte schnell funktionieren, müssen Sie nur den für die aktuelle Seite erforderlichen JavaScript-Code herunterladen. Mithilfe von Code-Splitting- Technologien können Sie das Laden der vom Benutzer auf jeden Fall benötigten Elemente so schnell wie möglich organisieren und die Technik des verzögerten Ladens auf andere Codefragmente anwenden. Dank dieses Ansatzes kann die Seite schneller als in anderen Fällen geladen werden und schnell einen Zustand erreichen, in dem mit ihr interagiert werden kann. Wenn Sie Systeme verwenden, die standardmäßig eine routenbasierte Codetrennung verwenden, macht dies einen Unterschied.
Halten Sie die für die Projektparameter festgelegten Grenzwerte, das sogenannte „Leistungsbudget“, ein und lernen Sie, diese einzuhalten. Erwarten Sie beispielsweise, dass die Größe des minimierten und komprimierten JS-Codes, der für Seiten erforderlich ist, die für mobile Geräte entwickelt wurden, 170 KB nicht überschreiten sollte. Bei der Umwandlung solcher Materialien in ihre normale Form werden ungefähr 700 KB Code erhalten. Solche Einschränkungen sind für den Erfolg des Projekts von großer Bedeutung, aber nur sie allein können eine langsame Site nicht auf wundersame Weise schnell machen. Hierbei spielen die Teamkultur , Struktur und Mittel zur Überwachung der Umsetzung der Regeln eine Rolle. Projektentwicklung ohne Budget trägt zu einem allmählichen Rückgang der Produktivität bei und kann zu unangenehmen Folgen führen.
Erfahren Sie, wie Sie JavaScript-Bundles (Assemblys) prüfen und ihre Größe reduzieren. Es ist sehr wahrscheinlich, dass Kunden Vollversionen von Bibliotheken herunterladen müssen, während nur Teile davon benötigt werden, damit das Projekt funktioniert. Möglicherweise enthält das Projekt Polyfills für Browser, die sie nicht benötigen, und das Duplizieren von Code wird nicht ausgeschlossen.
Jede Benutzerinteraktion mit der Site ist der Beginn einer neuen Wartezeit, nach der mit der Site gearbeitet werden kann (dies wird als "Zeit bis zur Interaktivität", TTI, Zeit bis zur Interaktivität bezeichnet). In diesem Zusammenhang ist eine Optimierung erwägenswert. Die Größe des übertragenen Codes ist für langsame Mobilfunknetze sehr wichtig, und die zum Parsen des JavaScript-Codes erforderliche Zeit gilt für Geräte mit bescheidenen Rechenkapazitäten.
Wenn die Verwendung von clientseitigem JavaScript Ihre Benutzererfahrung nicht verbessert, sollten Sie überlegen, ob Sie JS in dieser Situation verwenden möchten. In einem solchen Fall wäre es möglicherweise schneller, den HTML-Code auf dem Server zu rendern. Denken Sie daran, die Verwendung von Client-Webframeworks einzuschränken und sie nur zum Erstellen von Seiten zu verwenden, auf die absolut nicht verzichtet werden kann. Sowohl das Rendern auf dem Server als auch das Rendern auf dem Client führen bei falscher Verwendung dieser Technologien zu ernsthaften Problemen.

Moderne Webprojekte und das Problem der übermäßigen Verwendung von JavaScript

Wenn ein Benutzer auf Ihre Site zugreift, senden Sie ihm wahrscheinlich eine ganze Reihe von Dateien, von denen viele Skripte sind. Aus der Sicht eines Webbrowsers sieht es ungefähr so aus.

So fühlt sich ein Browser an, der mit Dateien überflutet ist

Egal wie sehr ich JavaScript liebe, ich kann nur zugeben, dass es immer der teuerste und schwierigste Teil der Website ist, den Browser verarbeiten können. Eigentlich möchte ich darüber sprechen, warum JavaScript das Hauptproblem der Site werden kann.

JavaScript ist der schwierigste Teil der Website

Laut dem JavaScript-Archivbericht vom Juli über die Verwendung von JavaScript verwendet die durchschnittliche Webseite heutzutage ungefähr 350 KB minimierten und komprimierten JavaScript-Code. Dieser Code wird in ein 1-MB-Skript entpackt, das der Browser verarbeiten muss. Damit ein mobiler Benutzer mit einer solchen Seite interagieren kann, muss er mehr als 14 Sekunden warten.

Eine durchschnittliche Seite mit 350 KB komprimiertem JS-Code wird auf einem mobilen Gerät in etwa 15 Sekunden interaktiv

Wenn Sie nicht genau wissen, wie sich Ihre JavaScript-Bundles darauf auswirken, wie lange Benutzer warten müssen, bis sie mit Ihrer Website interagieren können, schauen Sie sich das Lighthouse- Tool an.

Die Downloadzeit von Daten in Mobilfunknetzen und deren Verarbeitung auf einem nicht schnellen Prozessor leisten einen wichtigen Beitrag, während darauf gewartet wird, dass die Seite für die Arbeit auf Mobilgeräten vorbereitet wird.

Lassen Sie uns den Stand der Dinge im Bereich der Mobilfunknetze anhand von OpenSignal-Daten analysieren . Die folgende Abbildung links zeigt die Verfügbarkeit von 4G-Netzen in der Welt (je dunkler die Farbe, mit der das Gebiet des Landes gemalt wird - je höher die Verfügbarkeit), desto rechts werden die Datenübertragungsgeschwindigkeiten angezeigt (wiederum - je dunkler - desto höher die Geschwindigkeit). Länder, deren Territorium ausgegraut ist, werden nicht in die Studie einbezogen. Es ist erwähnenswert , dass in ländlichen Gebieten, sogar in den USA, die Geschwindigkeit der mobilen Datenübertragung 20% langsamer sein kann als in Städten.

4G-Netzwerkverfügbarkeit und Datenrate

Wir haben oben gesagt, dass das Herunterladen und Analysieren von 350 KB minimiertem und komprimiertem JS-Code eine gewisse Zeit in Anspruch nimmt. Wenn Sie sich jedoch beliebte Websites ansehen, stellt sich heraus, dass sie den Benutzern viel mehr Code senden. Die in der folgenden Abbildung gezeigten Daten stammen von hier . Dies sind die Größen der entpackten JavaScript-Bundles verschiedener bekannter Webressourcen wie Google Sheets, deren entpackter JS-Code auf Desktop-Plattformen 5,8 MB benötigt.

Entpackte JavaScript-Baugruppengrößen für verschiedene Ressourcen

Wie Sie sehen, müssen Browser sowohl auf Desktop- als auch auf mobilen Plattformen manchmal mehrere Megabyte JS-Code verarbeiten, um mit verschiedenen Websites arbeiten zu können. Die Hauptfrage hier ist: Können Sie es sich leisten, so große Mengen an JavaScript zu verwenden?

JavaScript ist nicht kostenlos

Laut Alex Russell sind Websites, für deren Funktion sehr viel JavaScript erforderlich ist, für viele Benutzer einfach nicht zugänglich. Laut Statistik warten Benutzer nicht (und werden nicht warten) auf das Laden solcher Ressourcen.

Kannst du es dir leisten?

Wenn Sie zu große Mengen an JS-Code an Benutzer senden müssen, sollten Sie die Code- Splitting-Technologie verwenden, um Bündel in kleine Teile zu zerlegen, oder die Code-Menge mithilfe des Tree-Shaking-Algorithmus reduzieren.

JS-Bundles moderner Websites enthalten häufig Folgendes:

Client-Webframework oder Benutzeroberflächenbibliothek.
Ein Tool zum Verwalten des Status einer Anwendung (z. B. Redux).
Polyfills (oft für moderne Browser, die sie nicht benötigen).
Vollversionen von Bibliotheken und nicht nur die Teile, die tatsächlich verwendet werden (z. B. die gesamte Lodash-Bibliothek, Moment.js-Bibliothek in der Version mit Unterstützung für alle regionalen Standards).
Eine Reihe von Komponenten der Benutzeroberfläche (Schaltflächen, Überschriften, Seitenleisten usw.).

All dies trägt zur Gesamtgröße des Codes bei, der vom Browser des Benutzers akzeptiert und verarbeitet werden muss. Je mehr Code, desto länger dauert es natürlich, bis der Browser die Seite in einen funktionsfähigen Zustand versetzt.

Das Laden einer Webseite ähnelt dem Verschieben von Filmen im Projektor, bei dem drei wichtige Schritte erfasst werden, mit denen die folgenden Fragen beantwortet werden:

Passiert das? (Passiert es?).
Was nützt das? (Ist es nützlich?).
Kann das verwendet werden? (Ist es verwendbar?).

So stellen Sie sich diese Schritte vor, die wiederum in kleinere „Frames“ unterteilt werden können, wenn wir die Analogie zum Film fortsetzen.

Das Laden von Seiten ist ein Prozess. In letzter Zeit hat sich der Fokus der Webbranche auf Indikatoren verlagert, die die Benutzererfahrung beim Arbeiten mit Webseiten widerspiegeln. Anstatt unsere ganze Aufmerksamkeit auf die domContentLoaded onload oder domContentLoaded richten, fragen wir uns jetzt, ob der Benutzer wirklich mit der Seite arbeiten kann. Wenn er auf etwas auf der Seite klickt, wird es sofort eine Reaktion geben?

Ladevorgang der Webseite

Im Schritt "Passiert das?" Die Site beginnt möglicherweise, einige Daten an den Browser zu übertragen. Hier können Sie Fragen dazu stellen, ob der Browserzugriff des Benutzers auf den Server behoben wurde (z. B. durch Klicken auf einen bestimmten Link) und ob der Server eine Antwort generiert hat.
Auf dem Schritt "Was nützt das?" Auf der Website wird Text oder anderer Inhalt angezeigt, der es dem Benutzer zum einen ermöglicht, etwas Nützliches zu lernen, und zum anderen, ihn zu interessieren.
Beim Schritt "Kann dies verwendet werden?" Der Benutzer kann eine vollständige Interaktion mit der Site beginnen, was zu bestimmten Ereignissen führen kann.

Interaktive Seiten und ihre Probleme

Oben haben wir einen solchen Indikator als Zeit bis zur Interaktivität (Zeit bis zur Interaktivität, TTI) erwähnt. Lassen Sie uns genauer darüber sprechen. Unten in der von Kevin Schaaf erstellten animierten Zeichnung können Sie sehen, wie die Seite, auf der nicht alle Materialien heruntergeladen und verarbeitet wurden, den Benutzer glauben lässt, dass er eine Aktion ausführen kann, aber tatsächlich aufgrund der Tatsache, dass der entsprechende JS Der Code wurde noch nicht vollständig verarbeitet. Diese Aktion kann nicht ausgeführt werden.

Benutzer sind verärgert über Seiten, deren Vorbereitung zu lange dauert

Damit eine Seite interaktiv ist, muss sie schnell auf Benutzerinteraktionen reagieren können. Die geringen Mengen an JS-Code, die die Seiten mit Strom versorgen, tragen dazu bei, die Zeit für die Vorbereitung der Seiten auf die Arbeit zu verkürzen.

Wenn der Benutzer auf den Link klickt oder die Seite scrollt, muss er sehen, dass als Reaktion auf seine Aktionen etwas passiert. Wenn die Seite nicht auf die Auswirkungen der Benutzer reagiert, gefällt sie ihnen nicht.

Hier ist ein Bericht, der in einer Testumgebung mit Lighthouse-Tools erstellt wurde und eine Reihe von Indikatoren enthält (es gibt auch Zeit für interaktive Aktionen), die sich darauf konzentrieren, wie Benutzer die Seite wahrnehmen.

Leuchtturmbericht, der Indikatoren enthält, die die Wahrnehmung der Seite durch den Benutzer widerspiegeln

Ähnliches wie in der vorherigen Abbildung tritt auf, wenn in einem bestimmten Projekt ein Server-Rendering verwendet wird und die Ergebnisse dessen, was auf dem Server generiert wird, und der JS-Code, der zum „Revitalisieren“ der Benutzeroberfläche verwendet wird, an den Client übertragen werden (z. B. dieses) , können Ereignishandler und einige zusätzliche Mechanismen verbinden, die für das Verhalten der Seite verantwortlich sind).

Wenn der Browser solchen Code verarbeitet, der Ereignisse verbindet, die der Benutzer wahrscheinlich benötigt, wird dies höchstwahrscheinlich in demselben Thread ausgeführt, der Benutzereingaben verarbeitet. Dies ist der sogenannte Hauptstrom.

Das Laden von zu viel JavaScript-Code mithilfe des Hauptthreads (dies geschieht beispielsweise bei Verwendung des <script> ) wirkt sich negativ auf die Zeit bis zur Interaktivität aus. Das Herunterladen von JS-Code, den Sie in Web Workern ausführen oder mit Service Workern zwischenspeichern möchten, wirkt sich nicht so stark negativ auf TTI aus.

Hier ist ein Video , das ein Beispiel eines Benutzers zeigt, der mit einer ausgefallenen Site arbeitet. Normalerweise kann der Benutzer die Kontrollkästchen sicher aktivieren oder auf die Links klicken. Wenn Sie jedoch das Blockieren des Hauptthreads imitieren, kann der Benutzer nichts tun - weder das Kontrollkästchen aktivieren noch auf den Link klicken.

Versuchen Sie, Situationen zu minimieren, in denen der Haupt-Thread blockiert sein kann. Hier finden Sie das Material, in dem Sie Details dazu finden.

Wir sehen, wie die Teams, mit denen wir zusammenarbeiten, unter JavaScript leiden, das auf TTI auf vielen Arten von Websites wirkt.

JavaScript kann die Ausgabe sichtbarer Elemente im interaktiven Modus verzögern

Diese Situation kann für viele Unternehmen ein ernstes Problem sein. Oben sind einige Beispiele aus der Google-Suchmaschine aufgeführt. Elemente werden auf dem Bildschirm angezeigt. Sie sehen so aus, als ob es bereits möglich ist, mit ihnen zu arbeiten. Wenn jedoch zu große Mengen an JS-Code für ihre Funktion verantwortlich sind, wechseln sie mit einiger Verzögerung in den Betriebsmodus. Dies spricht Benutzer möglicherweise nicht an. Im Idealfall sollte alles, mit dem der Benutzer interagieren kann, so schnell wie möglich betriebsbereit sein.

TTI und mobile Geräte

Hier sind die TTIs für news.google.com bei Verwendung einer langsamen 3G-Internetverbindung. Hier sehen Sie die Daten, auf deren Grundlage dieses Diagramm erstellt wird. Die Messungen werden mit WebPageTest und Lighthouse durchgeführt.

TTI für news.google.com

Nach der Analyse dieser Daten können Sie feststellen, dass zwischen den Geräten der niedrigsten und höchsten Kategorie eine gravierende Lücke besteht. Das leistungsstärkste Gerät im TTI-Test ist also ungefähr 7 Sekunden. Im einfachsten Fall sind es bereits 55 Sekunden.

Hier haben wir eine Frage, was der TTI sein soll. Wir sind der Meinung, dass Sie sich bemühen sollten, Seiten auf Geräten mit mittlerer Reichweite, die mit langsamen 3G-Netzwerken verbunden sind, in weniger als 5 Sekunden interaktiver zu gestalten.

Es lohnt sich, in 5 Sekunden nach TTI zu streben

Vielleicht werden Sie hier sagen, dass alle Ihre Benutzer Top-End-Telefone haben und mit schnellen Netzwerken verbunden sind. Ist das wirklich so? Vielleicht ist jemand in einem Café mit einem „schnellen“ Wi-Fi-Netzwerk verbunden, aber tatsächlich steht ihm nur die Geschwindigkeitscharakteristik von 2G- oder 3G-Verbindungen zur Verfügung. Wenn man die Fähigkeiten der Benutzer beurteilt, kann man die Vielfalt der Geräte und Methoden für den Zugriff auf das von ihnen verwendete Netzwerk nicht außer Acht lassen.

Auswirkungen der Verkleinerung von JS-Code auf TTI

Hier einige Beispiele, wie sich die Reduzierung der Größe des JS-Seitencodes auf die TTI auswirkt.

Das Pinterest-Projekt reduzierte JS-Bundles von 2,5 MB auf weniger als 200 KB. Die Zeit bis zur Interaktivität verringerte sich von 23 Sekunden auf 5,6 Sekunden. Der Umsatz des Unternehmens stieg um 44%, die Anzahl der Abonnements um 753% und die Anzahl der aktiven wöchentlichen Benutzer der mobilen Version der Website um 103%.
AutoTrader reduzierte das JS-Bundle um 56%, was zu einer TTI-Reduzierung von ca. 50% führte.
Die Nikkei.com- Ressource reduzierte die Größe des JS-Bundles um 43%, wodurch sich der TTI um 14 Sekunden verbessern konnte.

Diese Ergebnisse legen nahe, dass Websites für eine flexible mobile Umgebung konzipiert werden sollten und gleichzeitig sicherstellen sollten, dass sie nicht an große Mengen an JavaScript-Code gebunden sind.

Das Entwerfen von Websites basiert auf einer flexiblen mobilen Umgebung

TTI hat viel zu tun. Beispielsweise kann die Verwendung eines mobilen Geräts zum Anzeigen einer Website, deren Netzwerkfähigkeiten durch einen bestimmten Tarifplan eingeschränkt sind, diesen Indikator beeinflussen. TTI kann durch die Tatsache beeinflusst werden, dass der Benutzer über einen öffentlichen, nicht besonders schnellen Wi-Fi-Zugangspunkt arbeitet, oder durch die Tatsache, dass der mobile Benutzer ist in ständiger Bewegung und verliert regelmäßig das Netzwerk.

Wenn jemand mit Ihrer Site in einer ähnlichen Situation wie der oben beschriebenen arbeitet und gleichzeitig sicherstellt, dass die Ressource funktioniert, muss eine große Menge JS-Code heruntergeladen und verarbeitet werden. Für den Benutzer kann die Interaktionssitzung mit der Site leer sein Bildschirm. Wenn auf der Site immer noch mindestens etwas auf dem Bildschirm angezeigt wird, kann es sehr lange dauern, bis Sie damit arbeiten können. Solche Probleme können im Idealfall gemindert werden, indem einfach die Größe des JS-Codes verringert wird, der für die Arbeit der Sites erforderlich ist.

Warum ist JavaScript so teuer?

Um zu verstehen, warum das Vorbereiten von JavaScript-Code für Seiten eine enorme Belastung für das System darstellen kann, sprechen wir darüber, was passiert, wenn der Server Daten an den Browser sendet.

Alles beginnt also damit, dass der Benutzer die URL der Site, zu der er gelangen möchte, in die Adressleiste des Browsers eingibt.

Alles beginnt mit der Eingabe einer URL in die Adressleiste des Browsers

Die Anforderung wird dann an den Server gesendet, der das HTML-Markup an den Browser zurückgibt. Der Browser analysiert dieses Markup und findet die Ressourcen, die zum Erstellen der Seite erforderlich sind: CSS, JavaScript, Bilder. Dann muss der Browser all dies vom Server anfordern und verarbeiten.
In diesem Szenario passiert beispielsweise bei der Arbeit mit Google Chrome alles.

Die Schwierigkeit bei diesem gesamten Prozess besteht darin, dass sich JavaScript letztendlich als Engpass des gesamten Systems herausstellt. Im Idealfall möchten wir, dass der Browser schnell eine grafische Darstellung der Seite anzeigt, wonach eine Interaktion möglich ist. Wenn JavaScript jedoch ein Engpass ist, muss der Benutzer nach der Anzeige auf dem Bildschirm hilflos prüfen, mit was er nicht arbeiten kann.

Unser Ziel ist es sicherzustellen, dass JavaScript in modernen Szenarien der Benutzerinteraktion mit Webressourcen kein Engpass mehr ist.

Wie kann ich die Arbeit mit JavaScript beschleunigen?

Die JavaScript-Beschleunigungsaufgabe kann in mehrere Unteraufgaben unterteilt werden. Die Zeit, die für alles, was mit JS zu tun hat, aufgewendet wird, ist die Summe aus Laden, Parsen, Kompilieren und Ausführen von Code.

Die JavaScript-Geschwindigkeit besteht aus der Geschwindigkeit des Ladens, Parsens, Kompilierens und Ausführens von Code

All dies bedeutet, dass wir sowohl bei der Codeübertragung als auch bei der Verarbeitung Geschwindigkeit benötigen.
Wenn zu viel Zeit für das Parsen und Kompilieren des Skripts in der JS-Engine aufgewendet wird, wirkt sich dies darauf aus, wie schnell der Benutzer mit der Seite interagieren kann.

Betrachten Sie einige Daten zu den oben genannten Prozessen. Hier erfahren Sie mehr darüber, wie V8 , die in Chrome verwendete JavaScript-Engine, Zeit mit der Verarbeitung von Seiten mit Skripten verbringt.

Das Parsen und Kompilieren von Schritten dauert in V8 beim Laden einer Seite 10 bis 30% der Zeit

Die Fragmente, die die zum Parsen des Codes beliebter Websites erforderliche Zeit darstellen, sind orange hervorgehoben. Gelb steht für die Kompilierungszeit. Zusammen nehmen diese beiden Phasen etwa 30% der Gesamtzeit in Anspruch, die für die Verarbeitung des Seiten-JS-Codes erforderlich ist. 30% sind eine ernsthafte Zahl.

In Chrome 66 kompiliert V8 Code im Hintergrundthread, wodurch bis zu 20% der Kompilierungszeit eingespart werden können. Das Parsen und Kompilieren ist jedoch immer noch extrem teuer, sodass Sie selten ein großes Skript sehen, das in weniger als 50 ms ausgeführt wird. nach dem Laden, auch wenn es im Hintergrund-Thread kompiliert wird.

Wie unterscheidet sich JavaScript von anderen Ressourcen?

Es ist zu beachten, dass die Zeit, die beispielsweise zum Verarbeiten eines Skripts mit einer Größe von 200 KB und zum Verarbeiten eines Bilds mit derselben Größe erforderlich ist, erheblich variiert. In diesem Beispiel kann die über das Netzwerk übertragene Datenmenge dieselbe sein, auch die Zeit für ihre Übertragung. Dies kann nicht über die Kosten der Ressourcen gesagt werden, die erforderlich sind, um die Daten in etwas zu verwandeln, mit dem Sie arbeiten können.

200 KB JavaScript-Code und eine JPEG-Datei derselben Größe sind zwei verschiedene Dinge.

Das JPEG-Bild muss dekodiert, gerastert und angezeigt werden. Und das JS-Bundle ist notwendig, wenn wir es einfach betrachten, laden, analysieren, kompilieren, ausführen. Tatsächlich muss die Engine andere Probleme bei der Verarbeitung von JS-Code lösen. Im Allgemeinen sollte berücksichtigt werden, dass viel mehr Systemressourcen für die Verarbeitung von JavaScript-Code aufgewendet werden, dessen Größe in Byte mit der Größe anderer Materialien vergleichbar ist.

Einer der Gründe, die in letzter Zeit so viel Aufmerksamkeit auf das Problem der Geschwindigkeit der Verarbeitung von JavaScript-Code durch Browser gelenkt haben, ist die unglaubliche Verbreitung der Mobiltechnologie.

Mobile Web- und Gerätevielfalt

In der mobilen Webwelt gibt es eine Vielzahl von Geräten. Wenn Sie ganz einfach versuchen, sie nach Kosten zu klassifizieren, dann handelt es sich um Einstiegstelefone im Bereich von 30 US-Dollar, Mittelklasse-Geräte, deren Kosten 200 US-Dollar nicht überschreiten, und Top-End-Geräte, deren Preis bei etwa 1000 US-Dollar liegt.

Verschiedene mobile Geräte

Wenn sich die Umstände als gut herausstellen, muss die Site auf Geräten mittlerer und höherer Ebene funktionieren. In der Realität verfügen jedoch nicht alle Benutzer über solche Geräte.

Daher können die meisten Benutzer von Geräten der ersten und mittleren Ebene aus im Internet arbeiten. Selbst wenn wir uns auf diese beiden Ebenen beschränken, kann der Funktionsumfang der darin enthaltenen Geräte sehr groß sein. Beispielsweise laufen die Prozessoren in einigen von ihnen mit voller Geschwindigkeit, und in einigen von ihnen kann ihre Frequenz verringert werden, um Energie zu sparen oder eine Überhitzung der Geräte zu verhindern.

Vergleichbare Prozessoren können unterschiedliche Cache-Größen haben. Letztendlich können Geräte völlig andere Prozessoren verwenden, ganz zu schweigen von anderen Systemkomponenten. Infolgedessen hängt die für die Verarbeitung von Ressourcen wie JavaScript erforderliche Zeit stark von den Eigenschaften der Geräte ab, die zum Anzeigen von Websites verwendet werden. Darüber hinaus werden weltweit Einstiegstelefone verwendet, sogar in den USA .

Hier sind die Ergebnisse einer Studie der derzeit verwendeten Android-Smartphones von newzoo . Wie Sie sehen, ist das Android-Betriebssystem auf 75,9% der verwendeten Telefone installiert, und es wird erwartet, dass 2018 weitere 300 Millionen Geräte hinzugefügt werden. Viele dieser neuen Geräte sind budgetfreundlich.

Android-Smartphones im Jahr 2018

Mal sehen, wie lange es dauert, JavaScript auf verschiedenen modernen Geräten zu analysieren und zu kompilieren. Hier sind die Rohdaten.

Die Zeit, die für die Verarbeitung (Analyse und Kompilierung) von 1 MB unkomprimiertem JS-Code benötigt wird (zum Beispiel können es etwa 200 KB minimierter Code sein, der mit gzip komprimiert wurde). Die Messungen wurden manuell an realen Geräten durchgeführt.

Am oberen Rand des Diagramms befinden sich erstklassige Geräte wie das iPhone 8, die Skripte relativ schnell verarbeiten. Wenn Sie tiefer gehen, gibt es bereits Geräte der Mittelklasse wie das Moto G4 und das sehr einfache Alcatel 1X. Der Unterschied zwischen diesen Geräten ist mit bloßem Auge sichtbar.

Mit der Zeit werden Telefone mit Android billiger, aber nicht schneller . In der Regel verwenden billige Telefone schwache Prozessoren mit einem kleinen L2 / L3-Cache. Wenn Sie sich auf Geräte der obersten Ebene konzentrieren, können Sie daher die Anforderungen eines durchschnittlichen Benutzers, der kein solches Gerät besitzt, vollständig ignorieren.

Kehren wir zum Beispiel mit einer realen Site zurück, die wir bereits berührt haben. Die Messungen wurden mit WebPageTest durchgeführt, hier sind die Quelldaten.

Die Zeit, die zum Verarbeiten des cnn.com-JS-Codes für verschiedene Geräte benötigt wird

Auf dem iPhone 8 (mit dem A11- Chip) dauert die Verarbeitung 9 Sekunden schneller als auf einem Telefon mit mittlerer Reichweite. Wir sprechen über die Tatsache, dass die Site auf dem iPhone 8 9 Sekunden früher interaktiv sein wird.

Wenn WebPageTest nun Alcatel 1X unterstützt (dieses Telefon wurde in den USA für etwa 100 US-Dollar verkauft , es wurde zu Beginn des Verkaufs verkauft), können wir das „ Storyboard “ der cnn.com-Website auf Einstiegs- und Mittelklasse-Telefonen laden. Alcatel 1X hat die Site mithilfe des 3G-Netzwerks in 65 Sekunden vollständig geladen. Es ist nicht einmal "langsam". Das ist einfach inakzeptabel.

Laden Sie cnn.com mit Alcatel 1X, Moto G gen 1, Moto G4 herunter

Diese Studie legt nahe, dass wir wahrscheinlich aufhören sollten zu denken, dass alle unsere Benutzer in schnellen Netzwerken auf leistungsstarken Geräten arbeiten. Daher sollten Anwendungen in realen Netzwerken und auf realen Geräten getestet werden. Die Vielzahl mobiler Geräte, auf denen Websites ausgeführt werden müssen, ist ein echtes Problem.

Gehen Sie nicht davon aus, dass alle Benutzer schnelle Netzwerke und leistungsstarke Geräte verwenden.

Laut Ilya Grigorik ist Volatilität das, was die Benutzererfahrung beeinträchtigt. Selbst schnelle Geräte können manchmal langsam laufen. Und schnelle Netzwerke können langsam sein. Variabilität kann absolut alles verlangsamen.

Während die Variabilität die Benutzererfahrung beeinträchtigen kann, können Sie durch die Entwicklung von Webprojekten, die auf nicht den produktivsten Geräten basieren, sowohl "schnelle" als auch "langsame" Benutzer sich wohl fühlen. Wenn Ihr Team die Statistiken analysieren und verstehen kann, welche Geräte für die Arbeit mit Ihrer Site verwendet werden, erhalten Sie einen Hinweis darauf, welches Gerät es wahrscheinlich wert ist, im Büro aufbewahrt zu werden, und können es zum Testen der Site verwenden.

Das Testen von Standorten erfolgt auf realen Geräten, die mit realen Netzwerken verbunden sind

Wenn die Option mit Ihrem eigenen Mittelklasse-Telefon nicht zu Ihnen passt , bietet das WebPageTest- Projekt bei der Auswahl mobiler Testkonfigurationen Zugriff auf angepasste Moto G4-Telefone. Es gibt dort andere Konfigurationen.

Darüber hinaus müssen Tests in Netzwerken durchgeführt werden, in denen typische Benutzer arbeiten. Zuvor habe ich über die Bedeutung des Testens von Websites auf Einstiegs- und Mittelklasse-Telefonen gesprochen, und Brian Holt hat zu diesem Thema die folgende hervorragende Bemerkung gemacht : Es ist sehr wichtig, Ihr Publikum zu kennen. Er sagt, dass es entscheidend ist, das Publikum zu kennen und die Anwendungsleistung für die Bedürfnisse des Publikums zu optimieren.

Kennen Sie Ihr Publikum

Es ist zu beachten, dass nicht jeder Standort auf einem Einstiegsgerät, das mit einem 2G-Netzwerk verbunden ist, gut funktionieren sollte. , — .

, , Google Analytics → Audience → Mobile → Devices. .

Google Analytics

, . — , , , , .

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );