Ich habe das Internet einen Tag lang mit einem Budget von 50 MB genutzt

Dieser Artikel ist Teil einer Serie, in der ich versuche, das Internet unter verschiedenen Einschränkungen zu nutzen, die eine bestimmte demografische Gruppe von Benutzern repräsentieren. Ich hoffe, das Profil der Schwierigkeiten zu schärfen, mit denen echte Menschen konfrontiert sind, die vermeidbar sind, wenn wir auf eine Weise entwerfen und entwickeln, die ihren Bedürfnissen gerecht wird.

Letztes Mal habe ich mit Internet Explorer 8 einen Tag lang im Internet navigiert. Dieses Mal habe ich mit einem Budget von 50 MB einen Tag lang im Internet gesurft.

Warum 50 MB?

Viele von uns haben das Glück, mobile Pläne zu haben, die mehrere Gigabyte Datenübertragung pro Monat ermöglichen. Andernfalls können wir normalerweise eine Verbindung zu Heim- oder öffentlichen WLAN-Netzwerken herstellen, die über schnelle Breitbandverbindungen verfügen und über praktisch unbegrenzte Daten verfügen.

Aber es gibt Teile der Welt, in denen mobile Daten unerschwinglich teuer sind und in denen es wenig oder gar keine Breitbandinfrastruktur gibt.

Die Menschen kaufen oft Datenpakete von nur mehreren zehn Megabyte auf einmal, was ein Gigabyte zu einer relativ großen und daher teuren Datenmenge macht.
– Dan Howdle, Analyst für Verbrauchertelekommunikation bei Cable.co.uk

Wie teuer reden wir gerade?

Die Kosten für mobile Daten

Eine Studie von cable.co.uk aus dem Jahr 2018 ergab, dass Simbabwe das teuerste Land der Welt für mobile Daten war, wo 1 GB durchschnittlich 75,20 $ kostete, zwischen 12,50 $ und 138,46 $. Die enorme Preisspanne ist darauf zurückzuführen, dass kleinere Datenmengen sehr teuer sind und proportional günstiger werden, je größer der Datenplan ist, für den Sie sich entscheiden. Weitere Informationen finden Sie in der Studienmethodik.

Simbabwe ist keineswegs ein Einzelfall. Äquatorialguinea, St. Helena und die Falklandinseln sind die nächsten in der Reihe, wobei 1 GB Daten jeweils 65,83 $, 55,47 $ und 47,39 $ kosten. Diese Länder haben im Allgemeinen eine Kombination aus schlechter technischer Infrastruktur und geringer Akzeptanz, was bedeutet, dass die Bereitstellung von Daten kostspielig ist und nicht über die Größenvorteile verfügt, um die Kosten zu senken.

Daten sind auch in Teilen Europas teuer. Ein Gigabyte an Daten kostet in Griechenland 32,71 $; in der Schweiz 20,22 $. Zum Vergleich: Die gleiche Datenmenge kostet in Großbritannien 6,66 $ oder in den USA 12,37 $. Am anderen Ende der Skala ist Indien mit durchschnittlichen Kosten von 0,26 $ der billigste Ort der Welt für Daten. Kirgisistan, Kasachstan und die Ukraine folgen mit jeweils 0,27 $, 0,49 $ und 0,51 $ pro GB.

Auch die Geschwindigkeit der Mobilfunknetze ist von Land zu Land sehr unterschiedlich. Vielleicht überraschend erleben Benutzer in mindestens 30 Ländern weltweit, einschließlich Australien und Frankreich, schnellere Geschwindigkeiten über ein mobiles Netzwerk als WiFi. Südkorea hat mit durchschnittlich 52,4 Mbit/s die schnellste mobile Download-Geschwindigkeit, aber der Irak hat mit durchschnittlich 1,6 Mbit/s Download und 0,7 Mbit/s Upload die langsamste Geschwindigkeit. Die USA rangieren weltweit auf Platz 40 bei mobilen Download-Geschwindigkeiten mit rund 34 Mbit/s und laufen Gefahr, weiter zurückzufallen, wenn sich die Welt in Richtung 5G bewegt.

In Bezug auf die Art der Mobilfunknetzverbindung nutzen 84,7 % der Benutzerverbindungen in Großbritannien 4G, verglichen mit 93 % in den USA und 97,5 % in Südkorea. Dem stehen weniger als 50 % in Usbekistan und weniger als 60 % in Algerien, Ecuador, Nepal und dem Irak gegenüber.

Die Kosten für Breitbanddaten

Unterdessen zeigt eine Studie über die Breitbandkosten im Jahr 2018, dass eine Breitbandverbindung in Niger 263 US-Dollar „pro Megabit pro Monat“ kostet. Diese Metrik ist etwas schwer zu verstehen, daher hier ein Beispiel: Wenn die durchschnittlichen Kosten für Breitbandpakete in einem Land 22 US-Dollar betragen und die durchschnittliche Download-Geschwindigkeit der Pakete 10 Mbit / s beträgt, dann würden die Kosten „pro Megabit pro Monat“ liegen 2,20 $ sein.

Es ist eine interessante Metrik, die anerkennt, dass die Breitbandgeschwindigkeit ein ebenso wichtiger Faktor ist wie die Datenobergrenze. Ein Preis von 263 US-Dollar deutet auf eine Kombination aus extrem langsamem und extrem teurem Breitband hin. Als Referenz beträgt die Metrik 1,19 $ in Großbritannien und 1,26 $ in den USA.

Was vielleicht einfacher zu verstehen ist, sind die durchschnittlichen Kosten eines Breitbandpakets. Beachten Sie, dass diese Studie nach den billigsten angebotenen Breitbandpaketen gesucht hat, wobei ignoriert wurde, ob diese Pakete eine Datenobergrenze hatten oder nicht, und daher eher eine nützliche ungefähre Zahl als die Datenkosten an sich liefert.

Allein bei den Paketkosten hat Mauretanien mit durchschnittlich 768,16 $ (zwischen 307,26 $ und 1.368,72 $) das teuerste Breitband der Welt. Diese enormen Kosten beinhalten den Bau physischer Leitungen zum Grundstück, da es in Mauretanien bereits nur wenige davon gibt. Mit 0,7 Mbit/s verfügt Mauretanien zudem über eines der langsamsten Breitbandnetze der Welt.

Taiwan hat mit einer Durchschnittsgeschwindigkeit von 85 Mbit/s das schnellste Breitband der Welt. Der Jemen ist mit 0,38 Mbit/s am langsamsten. Aber auch Länder mit gut ausgebauter Breitbandinfrastruktur haben sogenannte „Not-Spots“. Das Vereinigte Königreich liegt bei der Breitbandgeschwindigkeit auf Platz 34 von 207 Ländern, aber im Juli 2019 gab es in Großbritannien noch eine Schule ohne Breitband.

Die durchschnittlichen Kosten für ein Breitbandpaket in Großbritannien betragen 39,58 $ und in den USA 67,69 $. Der billigste Durchschnitt der Welt ist die Ukraine mit nur 5 $, obwohl das billigste Breitbandangebot von allen in Kirgisistan gefunden wurde (1,27 $ – gegenüber dem Landesdurchschnitt von 108,22 $).

Simbabwe war das teuerste Land für mobile Daten, und die Statistiken für sein Breitband sind mit durchschnittlichen Kosten von 128,71 USD und Kosten pro Megabit pro Monat von 6,89 USD nicht viel besser.

Absolute Kosten vs. reale Kosten

Alle bisher aufgeführten Kosten sind die absoluten Kosten in USD, basierend auf den Wechselkursen zum Zeitpunkt der Studie. Diese Kosten wurden nicht als Lebenshaltungskosten berücksichtigt, was bedeutet, dass die Kosten für viele Länder real viel höher sind.

Ich werde mein Surfen heute auf 50 MB beschränken, was in Simbabwe bei einem mobilen Datentarif etwa 3,67 $ kosten würde. Das mag nicht nach viel klingen, aber die Lehrer in Simbabwe streikten dieses Jahr, weil ihre Gehälter auf nur 2,50 Dollar pro Tag gefallen waren.

Zum Vergleich: 3,67 Dollar sind etwa die Hälfte des Mindestlohns von 7,25 Dollar in den USA. Als Simbabwer müsste ich ungefähr anderthalb Tage arbeiten, um das Geld für den Kauf dieser 50 MB Daten zu verdienen, verglichen mit nur einer halben Stunde in den USA. Es ist nicht einfach, die Lebenshaltungskosten zwischen den Ländern zu vergleichen, aber allein bei den Löhnen würden sich die Kosten von 3,67 $ für 50 MB Daten in Simbabwe für einen Amerikaner mit Mindestlohn wie 52 $ anfühlen.

Aufbau des Experiments

Ich habe Chrome gestartet und die Entwicklungstools geöffnet, wo ich das Netzwerk auf eine langsame 3G-Verbindung gedrosselt habe. Ich wollte eine langsame Verbindung simulieren, wie sie Benutzer in Usbekistan erleben, um zu sehen, welche Art von Erfahrung Websites mir geben würden. Ich habe auch meine CPU gedrosselt, um zu simulieren, dass ich mich auf einem Gerät mit niedrigerem Ende befinde.

Ich habe ModHeader installiert und den Header „Save-Data“ eingestellt, um Websites mitzuteilen, dass ich meine Datennutzung minimieren möchte. Dies ist auch der von Chrome gesetzte Header für den „Lite-Modus“ von Android, auf den ich später noch näher eingehen werde.

Ich habe TripMode heruntergeladen; eine Anwendung für Mac, mit der Sie steuern können, welche Apps auf Ihrem Mac auf das Internet zugreifen können. Der Internetzugang jeder anderen Anwendung wird automatisch blockiert.

Wie weit werde ich voraussichtlich mit meinem 50-MB-Budget kommen? Da das durchschnittliche Gewicht einer Webseite fast 1,7 MB beträgt, bedeutet dies, dass ich ungefähr 29 Seiten in meinem Budget habe, obwohl wahrscheinlich ein paar mehr als das, wenn ich in der Lage bin, auf denselben Websites zu bleiben und Browser-Caching zu nutzen.

Während des gesamten Experiments werde ich Leistungstipps vorschlagen, um das erste Malen mit Inhalten und die wahrgenommene Ladezeit der Seite zu beschleunigen. Einige dieser Tipps wirken sich möglicherweise nicht direkt auf die übertragene Datenmenge aus , beinhalten jedoch im Allgemeinen das Verzögern des Downloads weniger wichtiger Ressourcen, was bei langsamen Verbindungen bedeuten kann, dass die Ressourcen nie heruntergeladen und Daten gespeichert werden.

Das Experiment

Kurzerhand lud ich google.com, verbrauchte 402 KB meines Budgets und gab 0,03 $ aus (etwa 1 % meines Simbabwe-Budgets).

Alles in allem keine schlechte Seitengröße, aber ich fragte mich, woher diese 24 Netzwerkanfragen kamen und ob die Seite leichter gemacht werden könnte oder nicht.

Google-Startseite – DOM

Wenn man sich das Seiten-Markup ansieht, gibt es keine externen Stylesheets – das gesamte CSS ist inline.

Performance-Tipp Nr. 1: Kritisches Inline-CSS

Dies ist gut für die Performance, da es dem Browser erspart, eine zusätzliche Netzwerkanfrage zu stellen, um ein externes Stylesheet zu holen, sodass die Stile geparst und sofort für das erste inhaltsreiche Malen angewendet werden können. Hier muss ein Kompromiss eingegangen werden, da externe Stylesheets zwischengespeichert werden können, Inline-Stylesheets jedoch nicht (es sei denn, Sie werden mit JavaScript schlau).

Der allgemeine Rat lautet, dass Ihre kritischen Stile (alles, was über der Falte liegt) inline sind und dass der Rest Ihres Stils extern ist und asynchron geladen wird. Das asynchrone Laden von CSS kann in einer bemerkenswert cleveren HTML-Zeile erreicht werden:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Die Devtools zeigen eine verschönerte Version des DOM. Wenn Sie sehen möchten, was tatsächlich in den Browser heruntergeladen wurde, wechseln Sie zur Registerkarte Quellen und suchen Sie das Dokument.

Sie können sehen, dass es hier eine Menge Inline-JavaScript gibt. Es ist erwähnenswert, dass es eher hässlich als nur verkleinert wurde.

Performance-Tipp Nr. 2: Verkleinern und verfremden Sie Ihre Assets

Die Verkleinerung entfernt unnötige Leerzeichen und Zeichen, aber die Verkleinerung „verstümmelt“ den Code tatsächlich, um ihn kürzer zu machen. Das verräterische Zeichen ist, dass der Code kurze, maschinell generierte Variablennamen enthält und keinen unberührten Quellcode. Das ist gut, da es bedeutet, dass das Skript kleiner und schneller herunterzuladen ist.

Trotzdem scheinen Inline-Skripte ungefähr 120 KB der 210-KB-Seitenressource zu sein (etwa die Hälfte der 60-KB-Gzip-Größe). Darüber hinaus gibt es fünf externe JavaScript-Dateien mit einer Größe von 291 KB der heruntergeladenen 402 KB:

Das bedeutet, dass JavaScript etwa 80 Prozent des gesamten Seitengewichts ausmacht.

Dies ist kein nutzloses JavaScript; Google muss einige haben, um Vorschläge anzuzeigen, während Sie tippen. Aber ich vermute, dass vieles davon Tracking-Code und Werbeeinrichtung sind.

Zum Vergleich habe ich JavaScript deaktiviert und die Seite neu geladen:

Die JS-deaktivierte Version der Google-Suche ist nur 102 KB groß, im Gegensatz zu 402 KB. Obwohl Google unter diesen Bedingungen keine automatischen Vorschläge bereitstellen kann, funktioniert die Website immer noch, und ich habe meine Datennutzung gerade auf ein Viertel des ursprünglichen Werts reduziert. Wenn ich meinen Datenverbrauch wirklich dauerhaft einschränken müsste, würde ich als erstes JavaScript deaktivieren. Es ist nicht so schlimm, wie es klingt.

Performance-Tipp Nr. 3: Weniger ist mehr

Das Inlining, Hässliche und Minimieren von Assets ist schön und gut, aber die beste Leistung ergibt sich, wenn die Assets gar nicht erst nach unten gesendet werden.

• Haben Sie ein Leistungsbudget, bevor Sie neue Funktionen hinzufügen?
• Kann Ihre Funktion vor dem Hinzufügen von JavaScript zu Ihrer Website mit einfachem HTML ausgeführt werden? (Zum Beispiel HTML5-Formularvalidierung).
• Bevor Sie eine große JavaScript- oder CSS-Bibliothek in Ihre Anwendung ziehen, verwenden Sie etwas wie bundlephobia.com, um zu messen, wie groß sie ist. Ist der Komfort das Gewicht wert? Können Sie dasselbe mit Vanilla-Code bei einer viel kleineren Datengröße erreichen?

Analysieren der Ressourceninformationen

Hier gibt es viel auszupacken, also legen wir los. Ich habe nur 50 MB zum Spielen, also werde ich jeden Teil dieser Seitenladung melken. Nehmen Sie an einem kurzen Chrome Devtools-Tutorial teil.

402 KB übertragen, aber 1,1 MB Ressourcen: Was bedeutet das eigentlich?

Dies bedeutet, dass tatsächlich 402 KB Inhalt heruntergeladen wurden, jedoch in komprimierter Form (unter Verwendung eines Komprimierungsalgorithmus wie gzip oder brotli). Der Browser musste dann etwas Arbeit leisten, um es in etwas Sinnvolles zu entpacken. Die Gesamtgröße der entpackten Daten beträgt 1,1 MB.

Dieses Entpacken ist nicht kostenlos – es gibt einige Millisekunden Overhead beim Dekomprimieren der Ressourcen. Aber das ist ein vernachlässigbarer Overhead im Vergleich zum Senden von 1,1 MB über die Leitung.

Leistungstipp Nr. 4: Komprimieren Sie textbasierte Assets

Komprimieren Sie Ihre Assets grundsätzlich immer mit etwas wie gzip. Verwenden Sie jedoch keine Komprimierung für Ihre Bilder und andere Binärdateien – Sie sollten diese im Voraus an der Quelle optimieren. Die Kompression könnte tatsächlich dazu führen, dass sie größer werden.

Und wenn möglich, vermeiden Sie das Komprimieren von Dateien, die 1500 Byte oder kleiner sind. Die kleinste TCP-Paketgröße beträgt 1500 Byte. Wenn Sie also beispielsweise auf 800 Byte komprimieren, sparen Sie nichts, da es immer noch im selben Byte-Paket übertragen wird. Auch hier sind die Kosten vernachlässigbar, verschwenden jedoch etwas CPU-Zeit für die Komprimierung auf dem Server und CPU-Zeit für die Dekomprimierung auf dem Client.

Nun zurück zur Registerkarte Netzwerk in Chrome: Lassen Sie uns diese Prioritäten untersuchen. Beachten Sie, dass Ressourcen die Priorität „Höchste“ bis „Niedrigste“ haben – dies ist die beste Einschätzung des Browsers, welche Ressourcen am wichtigsten zum Herunterladen sind. Je höher die Priorität, desto früher versucht der Browser, das Asset herunterzuladen.

Performance-Tipp Nr. 5: Geben Sie dem Browser Ressourcenhinweise

Der Browser errät, welche Assets die höchste Priorität haben, aber Sie können mit dem <link rel="preload"> -Tag einen Ressourcenhinweis bereitstellen, der den Browser anweist, das Asset so schnell wie möglich herunterzuladen. Es empfiehlt sich, Schriftarten, Logos und alles andere, was über dem Falz angezeigt wird, vorab zu laden.

Lassen Sie uns über das Caching sprechen. Ich halte ALT gedrückt und klicke mit der rechten Maustaste, um meine Spaltenüberschriften zu ändern und weitere wichtige Informationen freizuschalten. Wir werden uns Cache-Control ansehen.

Cache-Control gibt an, ob eine Ressource zwischengespeichert werden kann oder nicht, wie lange sie zwischengespeichert werden kann und welche Regeln sie bei der erneuten Validierung befolgen sollte. Das Festlegen der richtigen Cache-Werte ist entscheidend, um die Datenkosten für wiederholte Besuche niedrig zu halten.

Leistungstipp Nr. 6: Legen Sie Cache-Control-Header für alle cachefähigen Assets fest

Beachten Sie, dass der Cache-Kontrollwert mit einer Direktive von public oder private beginnt, gefolgt von einem Ablaufwert (z. B. max-age=31536000 ). Was bedeutet die Richtlinie und warum der seltsam spezifische Wert für das max-age ?

Der Wert 31536000 ist die Anzahl der Sekunden, die ein Jahr hat, und ist der theoretische Höchstwert, der von der Cache-Steuerungsspezifikation zugelassen wird. Es ist üblich, dass dieser Wert auf alle statischen Assets angewendet wird und bedeutet effektiv „diese Ressource wird sich nicht ändern“. In der Praxis wird kein Browser ein ganzes Jahr zwischenspeichern, aber er wird das Asset so lange zwischenspeichern, wie es sinnvoll ist.

Um die public/private Direktive zu erklären, müssen wir die zwei Haupt-Caches erläutern, die außerhalb des Servers existieren. Erstens gibt es den herkömmlichen Browser-Cache, in dem die Ressource auf dem Computer des Benutzers (dem „Client“) gespeichert wird. Und dann gibt es noch den CDN-Cache, der sich zwischen dem Client und dem Server befindet; Ressourcen werden auf CDN-Ebene zwischengespeichert, um zu verhindern, dass das CDN die Ressource immer wieder vom Ursprungsserver anfordert.

Eine public Cache-Control Anweisung ermöglicht, dass die Ressource sowohl im Client als auch im CDN zwischengespeichert wird. Ein private Wert bedeutet, dass nur der Client ihn zwischenspeichern kann; das CDN soll das nicht. Dieser letztere Wert wird normalerweise für Seiten oder Assets verwendet, die hinter der Authentifizierung existieren, wo es in Ordnung ist, auf dem Client zwischengespeichert zu werden, aber wir möchten keine privaten Informationen durchsickern lassen, indem wir sie im CDN zwischenspeichern und an andere Benutzer weitergeben.

Eine Sache, die meine Aufmerksamkeit erregte, war, dass das Google-Logo eine Cache-Steuerung von „privat“ hat. Andere Bilder auf der Seite haben einen öffentlichen Cache, und ich weiß nicht, warum das Logo anders behandelt werden sollte. Wenn Sie Ideen haben, lassen Sie es mich in den Kommentaren wissen!

Ich habe die Seite aktualisiert und die meisten Ressourcen wurden aus dem Cache bereitgestellt, abgesehen von der Seite selbst, die, wie Sie bereits gesehen haben, private, max-age=0 , was bedeutet, dass sie nicht zwischengespeichert werden kann. Dies ist normal für dynamische Webseiten, bei denen es wichtig ist, dass der Benutzer beim Aktualisieren immer die allerneueste Seite erhält.

An diesem Punkt klickte ich versehentlich auf eine „Erklärungs“-URL in den Devtools, die mich zur Netzwerkanalyse-Referenz führte, was mich etwa 5 MB meines Budgets kostete. Hoppla.

Google-Dev-Docs

4,2 MB dieser neuen 5-MB-Seite waren Bilder; speziell SVGs. Das schwerste davon war 186 KB, was nicht besonders groß ist – es waren einfach so viele davon und sie wurden alle auf einmal heruntergeladen.

Diese Seitenlast von 5 MB machte 10 % meines heutigen Budgets aus. Bisher habe ich 5,5 MB verwendet, einschließlich des Neuladens der Google-Startseite ohne JavaScript, und 0,40 $ ausgegeben. Ich wollte diese Seite gar nicht öffnen.

Was wäre hier eine bessere Benutzererfahrung gewesen?

Performance-Tipp Nr. 7: Laden Sie Ihre Bilder faul

Normalerweise würde ich, wenn ich versehentlich auf einen Link geklickt habe, die Zurück-Schaltfläche in meinem Browser drücken. Ich hätte überhaupt keinen Nutzen daraus gezogen, diese Bilder herunterzuladen – was für eine Verschwendung von 4,2 MB!

Abgesehen von Videos, bei denen Sie im Allgemeinen wissen, worauf Sie sich einlassen, sind Bilder bei weitem der größte Übeltäter für die Datennutzung im Internet. Eine Studie der 500 besten Websites der Welt ergab, dass Bilder bis zu 53 % der durchschnittlichen Seitengröße ausmachen. „Das bedeutet, dass sie einen großen Einfluss auf die Seitenladezeiten und damit auf die Gesamtleistung haben.“

Anstatt alle Bilder beim Laden der Seite herunterzuladen, empfiehlt es sich, die Bilder verzögert zu laden, sodass nur Benutzer, die sich mit der Seite beschäftigen, die Kosten für das Herunterladen zahlen. Benutzer, die sich dafür entscheiden, nicht unter die Falte zu scrollen, verschwenden daher keine unnötige Bandbreite, um Bilder herunterzuladen, die sie nie sehen werden.

Es gibt einen großartigen css-tricks.com-Leitfaden zum Rollout von Lazy-Loading für Bilder, der eine gute Balance zwischen denen mit guten Verbindungen, denen mit schlechten Verbindungen und denen mit deaktiviertem JavaScript bietet.

Wenn diese Seite Lazy Loading gemäß der obigen Anleitung implementiert hätte, wäre jedes der 38 SVGs standardmäßig durch ein 1-KB-Platzhalterbild dargestellt und nur beim Scrollen in die Ansicht geladen worden.

Performance-Tipp Nr. 8: Verwenden Sie das richtige Format für Ihre Bilder

Ich dachte, dass Google einen Trick verpasst hat, indem es WebP nicht verwendet hat, ein Bildformat, das im Vergleich zu PNGs (ohne Qualitätsverlust) 26 % kleiner und im Vergleich zu JPEGs 25-34 % kleiner ist (und von a vergleichbare Qualität). Ich dachte, ich würde versuchen, SVG in WebP zu konvertieren.

Die Konvertierung in WebP hat eines der SVGs von 186 KB auf nur 65 KB reduziert, aber wenn man sich die Bilder nebeneinander ansieht, ist das WebP tatsächlich körnig geworden:

Ich habe dann versucht, eines der PNGs in WebP zu konvertieren, das verlustfrei sein und kleiner ausfallen sollte. Allerdings war die WebP-Ausgabe *schwerer* (127 KB, von 109 KB)!

Das hat mich überrascht. WebP ist nicht unbedingt die Wunderwaffe, für die wir es halten, und sogar Google hat es versäumt, es auf dieser Seite zu verwenden.

Mein Rat wäre also: Experimentieren Sie nach Möglichkeit mit verschiedenen Bildformaten pro Bild. Das Format, das die beste Qualität für die kleinste Größe bietet, ist möglicherweise nicht das, was Sie erwarten.

Nun zurück zum DOM. Ich bin darauf gestoßen:

Beachten Sie das async Schlüsselwort im Google Analytics-Skript?

Obwohl dies eines der ersten Dinge im Kopf des Dokuments war, wurde ihm eine niedrige Priorität eingeräumt, da wir uns ausdrücklich dagegen entschieden haben, eine Blockierungsanforderung zu sein, indem wir das async Schlüsselwort verwenden.

Eine Blockierungsanforderung stoppt das Rendern der Seite. Ein <script> -Aufruf blockiert standardmäßig und stoppt das Parsen des HTML, bis das Skript heruntergeladen, kompiliert und ausgeführt wurde. Aus diesem Grund setzen wir traditionell <script> -Aufrufe am Ende des Dokuments.

Leistungstipp Nr. 9: Vermeiden Sie es, blockierende Skriptaufrufe zu schreiben

Indem wir das async -Attribut zu unserem <script> -Tag hinzufügen, weisen wir den Browser an, die Darstellung der Seite nicht zu stoppen, sondern das Skript im Hintergrund herunterzuladen. Wenn der HTML-Code zum Zeitpunkt des Herunterladens des Skripts noch analysiert wird, wird die Analyse angehalten, während das Skript ausgeführt wird, und dann fortgesetzt. Dies ist deutlich besser, als das Rendern zu blockieren, sobald <script> angetroffen wird.

Es gibt auch ein defer Attribut, das etwas anders ist. <script defer> weist den Browser an, die Seite zu rendern, während das Skript im Hintergrund geladen wird, und selbst wenn das HTML zum Zeitpunkt des Herunterladens des Skripts noch geparst wird, muss das Skript warten, bis die Seite gerendert ist, bevor es ausgeführt werden kann . Dadurch wird das Skript vollständig nicht-blockierend. Lesen Sie „Effizientes Laden von JavaScript mit Defer und Async“ für weitere Informationen.

Wie auch immer, genug Google seziert. Es ist Zeit, eine andere Seite auszuprobieren. Ich habe noch fast 45 MB meines Budgets übrig!

Amazonas

Die Amazon-Homepage wird mit einem Gesamtgewicht von ca. 6 MB geladen. Eines davon war ein 587 KB großes Bild, das ich nicht einmal auf der Seite finden konnte. Dies war ein PNG, vermutlich um gestochen scharfen Text zu haben, aber auf einem fotografischen Hintergrund – eine klassische Kombination, die für die Leistung schrecklich ist.

Tatsächlich gab es in meinem Netzwerk-Tab ein paar mehrere hundert Kilobyte große Bilder, die ich auf der Seite nicht wirklich sehen konnte. Ich vermute irgendwo bei Amazon eine Fehlkonfiguration, aber diese unsichtbaren Bilder haben zusammen mindestens 1 MB meiner Daten durchgekaut.

Wie sieht es mit dem Heldenbild aus? Es ist das Hauptbild auf der Seite und hat nur eine übertragene Größe von 94 KB – aber es könnte um etwa 15 % verkleinert werden, wenn es direkt um den Text und die Fußballer herum zugeschnitten würde. Wir könnten dann in CSS dieselbe Hintergrundfarbe anwenden wie im Bild. Dies hat den zusätzlichen Vorteil, dass die Größe auf kleinere Bildschirme angepasst werden kann, während die Lesbarkeit des Textes erhalten bleibt.

Ich habe es einmal gesagt, und ich sage es noch einmal: Das Optimieren und Lazy-Loading Ihrer Bilder ist der größte Vorteil, den Sie für das Seitengewicht Ihrer Website erzielen können .

Die Optimierung von Bildern lieferte bei weitem die bedeutendste Datenreduktion. Sie können den Fall argumentieren, dass JavaScript für die Gesamtleistung eine größere Sache ist, aber nicht für die Datenreduzierung. Das Optimieren oder Entfernen von Bildern ist der sicherste Weg, um ein viel leichteres Erlebnis zu gewährleisten, und das ist die primäre Optimierung, auf die sich Data Saver verlässt.
– Tim Kadlec, Chrome Lite-Seiten verstehen

Um fair zu Amazon zu sein: Wenn ich die Größe des Browsers auf eine mobile Größe ändere und die Seite aktualisiere, ist die Website für Mobilgeräte optimiert und das Gesamtgewicht der Seite beträgt nur 2,1 MB.

Aber das bringt mich zu meinem nächsten Punkt…

Leistungstipp Nr. 10: Machen Sie keine Annahmen über Datenverbindungen

Es ist schwierig zu erkennen, ob jemand auf einem Desktop über eine Breitbandverbindung verfügt oder über einen datenbegrenzten Dongle oder ein Mobiltelefon anbindet. Viele Menschen arbeiten auf diese Weise im Zug oder leben in einer Gegend, in der die Breitbandinfrastruktur schlecht ist, aber das Mobilfunksignal stark ist. Im Fall von Amazon gibt es Raum für große Dateneinsparungen auf der Desktop-Site, und wir sollten nicht selbstgefällig werden, nur weil die Bildschirmgröße vermuten lässt, dass ich kein mobiles Gerät verwende.

Ja, wir sollten mit einer größeren Seitenlast rechnen, wenn unser Darstellungsbereich „Desktop-Größe“ hat, da die Bilder größer und besser für den Bildschirm optimiert sind als ein körnigeres mobiles. Aber die Seite sollte nicht um Größenordnungen größer sein.

Außerdem habe ich den Save-Data Header mit meiner Anfrage gesendet. Dieser Header weist ausdrücklich auf eine Präferenz für eine reduzierte Datennutzung hin, und ich hoffe, dass in Zukunft mehr Websites darauf aufmerksam werden.

Die anfängliche „Desktop“-Last mag 6 MB betragen haben, aber nach einer Minute des Sitzens und Beobachtens war sie auf 8,6 MB gestiegen, als die Ressourcen mit niedrigerer Priorität und die Ereignisverfolgung in Aktion traten. Dieses Seitengewicht enthält fast 1,7 MB minimiertes JavaScript. Ich will gar nicht erst anfangen , darauf zu schauen.

Leistungstipp Nr. 11: Verwenden Sie Web Worker für Ihr JavaScript

Was wäre schlimmer – 1,7 MB JavaScript oder 1,7 MB Bilder? Die Antwort lautet JavaScript: Die beiden Assets sind in Bezug auf die Leistung nicht gleichwertig.

Ein JPEG-Bild muss dekodiert, gerastert und auf den Bildschirm gemalt werden. Ein JavaScript-Bundle muss heruntergeladen und dann geparst, kompiliert und ausgeführt werden – und es gibt eine Reihe weiterer Schritte, die eine Engine ausführen muss. Beachten Sie, dass diese Kosten nicht ganz gleichwertig sind.
– Addy Osmani, Die Kosten von JavaScript im Jahr 2018

Wenn Sie so viel JavaScript versenden müssen, versuchen Sie, es in einen Webworker zu integrieren. Dadurch wird der Hauptteil des JavaScripts vom Hauptthread ferngehalten, der jetzt für das Neuzeichnen der Benutzeroberfläche frei ist, wodurch Ihre Webseite auf Geräten mit geringer Leistung reaktionsfähig bleibt.

Ich habe jetzt ungefähr 15,5 MB in meinem Budget und habe 1,14 $ meines Datenbudgets in Simbabwe ausgegeben. Ich hätte einen halben Tag als Lehrer arbeiten müssen, um das Geld zu verdienen, um so weit zu kommen.

Pinterest

Ich habe viel Gutes über die Leistung von Pinterest gehört, also habe ich beschlossen, es auf die Probe zu stellen.

Vielleicht ist dies nicht der fairste Test; Ich wurde zur Anmeldeseite weitergeleitet, auf der ein asynchroner Prozess feststellte, dass ich bei Facebook angemeldet war, und mich automatisch anmeldete. Die Seite wurde relativ schnell geladen, aber die Anfragen schlichen sich, da immer mehr Inhalte vorgeladen wurden.

Ich habe jedoch gesehen, dass der Servicemitarbeiter bei nachfolgenden Seitenladevorgängen einen Großteil des Inhalts auftauchte und etwa die Hälfte des Seitengewichts einsparte:

Die Pinterest-Site ist eine progressive Web-App; Es installierte einen Service-Worker, um das Caching von CSS und JS manuell zu handhaben. Ich könnte jetzt mein WLAN ausschalten und die Seite weiter nutzen (wenn auch nicht sehr sinnvoll):

Leistungstipp Nr. 12: Verwenden Sie Servicemitarbeiter, um Offline-Support bereitzustellen

Wäre es nicht toll, wenn ich eine Website nur einmal über das Netzwerk laden müsste und jetzt alle Informationen bekomme, die ich brauche, auch wenn ich offline bin?

Ein gutes Beispiel wäre eine Website, die die Wettervorhersage für die Woche anzeigt. Ich sollte diese Seite nur einmal herunterladen müssen. Wenn ich meine mobilen Daten ausschalte und anschließend irgendwann wieder auf die Seite gehe, sollte sie mir die letzten bekannten Inhalte liefern können. Wenn ich mich wieder mit dem Internet verbinde und die Seite lade, würde ich eine aktuellere Prognose erhalten, aber statische Assets wie CSS und Bilder sollten weiterhin lokal vom Servicemitarbeiter bereitgestellt werden.

Dies ist möglich, indem ein Servicemitarbeiter mit einer guten Caching-Strategie eingerichtet wird, sodass auf zwischengespeicherte Seiten offline erneut zugegriffen werden kann. Die Lodash-Dokumentationswebsite ist ein schönes Beispiel für einen Servicemitarbeiter in freier Wildbahn:

Inhalte, die selten aktualisiert werden und wahrscheinlich ziemlich regelmäßig verwendet werden, sind ein perfekter Kandidat für die Behandlung durch Servicemitarbeiter. Dynamische Websites mit ständig wechselnden Newsfeeds eignen sich nicht ganz so gut für Offline-Erlebnisse, können aber dennoch davon profitieren.

Servicemitarbeiter können wirklich den Tag retten, wenn Sie ein knappes Datenbudget haben. Ich bin nicht davon überzeugt, dass die Pinterest-Erfahrung in Bezug auf die Datennutzung optimal war – nachfolgende Seiten lagen um die 0,5-MB-Marke herum, selbst auf Seiten mit wenigen Bildern –, aber ich überlasse es Ihrem JavaScript, Seitenanfragen für Sie zu verarbeiten, und behält dieselben Navigationselemente bei kann sehr performant sein. Die BBC bewältigt eine Übertragungsgröße von nur 3,1 KB für Wiederaufrufe von Artikeln, die über die Single-Page-Anwendung darstellbar sind.

Bisher hat Pinterest allein 14 MB durchgekaut, was bedeutet, dass ich ungefähr 30 MB meines Budgets oder 2,20 $ (fast ein Tageslohn) meines Simbabwe-Budgets gesprengt habe.

Mit meinen letzten 20 MB sollte ich besser vorsichtig sein … aber wo bleibt da der Spaß?

Spielespot

Ich habe mich für dieses entschieden, weil es sich in der Vergangenheit auf meinem Handy merklich träge anfühlte und ich wollte den Gründen dafür auf den Grund gehen. Sicher genug, das Laden der Homepage verbraucht 8,5 MB Daten.

6,5 MB davon entfielen auf ein automatisch abspielendes Video in der Mitte der Seite, das – um fair zu sein – nicht heruntergeladen zu werden schien, bis ich anfing zu scrollen. Nichtsdestotrotz…

Ich konnte nur die Hälfte des Videos in meinem Ansichtsfenster sehen – die rechte Seite war abgeschnitten. Es war auch 30 Sekunden lang, und ich würde wetten, dass die meisten Leute nicht dasitzen und sich das Ganze ansehen werden. Dieses einzelne Asset hat die Größe der Seite mehr als verdreifacht.

Leistungstipp Nr. 13: Laden Sie kein Video vorab

Laden Sie Video in der Regel nicht vorab, es sei denn, das primäre Kommunikationsmittel Ihrer Website ist Video.

Wenn Sie YouTube oder Netflix sind, ist es vernünftig anzunehmen, dass jemand, der auf Ihre Seite kommt, möchte, dass das Video automatisch geladen und abgespielt wird. Es besteht die Erwartung, dass das Video einige Daten durchkauen wird, aber dass es ein fairer Austausch für den Inhalt ist. Aber wenn Sie eine Website sind, deren primäres Medium Text und Bild sind – und Sie zufällig zusätzliche Videoinhalte anbieten – dann laden Sie das Video nicht vorab.

Denken Sie an Nachrichtenartikel mit eingebetteten Videos. Viele Benutzer möchten nur die Überschrift des Artikels überfliegen, bevor sie mit ihrer nächsten Sache fortfahren. Andere werden den Artikel lesen, aber Einbettungen ignorieren. Und andere werden jedes eingebettete Video fleißig anklicken und ansehen. Wir sollten nicht die Bandbreite jedes Benutzers in Anspruch nehmen, wenn wir davon ausgehen , dass er diese Videos ansehen möchte.

Um es noch einmal zu wiederholen: Benutzer mögen keine automatisch abgespielten Videos. Als Entwickler tun wir es nur, weil unsere Manager es uns sagen, und sie sagen uns nur, dass wir es tun sollen, weil all die coolsten Apps es tun, und die coolsten Apps tun es nur, weil Videoanzeigen 20- bis 50-mal mehr Einnahmen generieren als herkömmliche Anzeigen. Google Chrome hat damit begonnen, Videos mit automatischer Wiedergabe für einige Websites basierend auf persönlichen Vorlieben zu blockieren. Selbst wenn Sie also Ihre Website für die automatische Wiedergabe von Videos entwickeln, gibt es keine Garantie dafür, dass Ihre Benutzer diese Erfahrung machen.

Wenn wir zustimmen, dass es eine gute Idee ist, Videos zu einem Opt-in-Erlebnis zu machen (Click-to-Play), können wir noch einen Schritt weiter gehen und es auch Click-to-Load machen. Das bedeutet, ein Video-Platzhalterbild mit einer Play-Schaltfläche darüber zu verspotten und das Video nur herunterzuladen, wenn Sie auf die Play-Schaltfläche klicken. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

Das ist es. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

Der Lite-Modus teilt die HTTPS-URL mit Google, daher ist es sinnvoll, dass dieser Modus im Inkognito-Modus nicht verfügbar ist. Andere Informationen wie Cookies, Anmeldeinformationen und personalisierte Seiteninhalte werden jedoch laut ghacks.net nicht mit Google geteilt und „unterbrechen niemals sichere Verbindungen zwischen Chrome und einer Website“. Man fragt sich, warum anscheinend keiner dieser Datenspardienste auf iOS erlaubt ist (und es gibt keine Neuigkeiten darüber, ob der Lite-Modus jemals auf iOS verfügbar sein wird).

Datenschoner-Proxies erfordern viel Vertrauen; Ihre Browsing-Aktivitäten, Cookies und andere sensible Informationen werden einem Server anvertraut, oft in einem anderen Land. Viele Proxys funktionieren einfach nicht mehr, weil viele Seiten auf HTTPS umgestellt haben, was bedeutet, dass Initiativen wie der Turbo-Modus zu einem weitgehend „nutzlosen Feature“ geworden sind. HTTPS verhindert diese Art von Man-in-the-Middle-Verhalten, was gut ist, obwohl es den Niedergang einiger dieser Proxy-Dienste bedeutet und Websites für diejenigen mit schlechten Verbindungen weniger zugänglich gemacht hat.

Ich konnte kein OSX- oder iOS-kompatibles Datenspeichertool finden, außer Bandwidth Hero für Firefox (für das die Einrichtung eines eigenen Datenkomprimierungsdienstes erforderlich ist – weit über die technischen Möglichkeiten der meisten Benutzer hinaus!) und skyZIP Proxy (das zuletzt aktualisiert wurde in 2017 und voller Tippfehler, ich konnte mich einfach nicht dazu bringen, zu vertrauen).

Fazit

Die Reduzierung des Datenverbrauchs Ihrer Website geht Hand in Hand mit der Verbesserung der Frontend-Performance. Es ist das zuverlässigste, was Sie tun können, um Ihre Website zu beschleunigen.

Neben den Datenkosten gibt es viele gute Gründe, sich auf die Leistung zu konzentrieren, wie in einem GOV.UK-Blogbeitrag zu diesem Thema beschrieben:

• 53 % der Nutzer verlassen eine mobile Website, wenn das Laden länger als 3 Sekunden dauert.
• Menschen müssen sich 50 % mehr konzentrieren, wenn sie versuchen, eine einfache Aufgabe auf einer Website mit einer langsamen Verbindung zu erledigen.
• Leistungsfähigere Webseiten sind besser für die Akkulaufzeit des Geräts des Benutzers und erfordern normalerweise weniger Energie auf dem Server, um sie bereitzustellen. Eine performante Website ist gut für die Umwelt.

Wir haben nicht die Macht, die globalen Kosten der Datenungleichheit zu ändern. Aber wir haben die Möglichkeit, seine Auswirkungen zu verringern und die Erfahrung für alle Beteiligten zu verbessern.