Steve Souders, „JavaScript dominiert die Browser-CPU“
Vor zehn Jahren war das Netzwerk der Hauptflaschenhals. Heute ist JavaScript der Hauptflaschenhals. Die Menge an JavaScript auf Seiten wächst rasant (fast 5x in den letzten 7 Jahren). Um das Rendering von Seiten schnell zu halten und sie schnell erscheinen zu lassen, müssen wir uns auf die JavaScript-CPU-Zeit konzentrieren, um die Blockierung des Hauptthreads des Browsers zu reduzieren.
Alex Russell, beschreibt einen Prototyp von „Never-Slow Mode“ in Chrome
… blockiert große Skripte, setzt Budgets für bestimmte Ressourcentypen (Skript, Schriftart, CSS, Bilder), schaltet document.write() aus, unterdrückt synchrone XHRs, aktiviert client-hints flächendeckend und puffert Ressourcen ohne gesetzten Content-Length.
Craig Hockenberry, postet eine Idee im WebKit-Bugtracker
Ohne Grenzen gibt es keinen Anreiz für einen JavaScript-Entwickler, seine Codebasis klein und Abhängigkeiten minimal zu halten. Es ist einfach, ein weiteres Framework hinzuzufügen, und dieses Framework fügt ein weiteres Framework hinzu, und ehe man sich versieht, lädt man zig Megabyte an Daten, nur um ein paar hundert Kilobyte Inhalt anzuzeigen. …
Die Situation, die ich mir vorstelle, ist, dass eine Website mir jede gewünschte Werbung anzeigen kann, solange sie die Gesamtgröße unter einem festen Betrag hält, sagen wir einem Megabyte pro Seite. Wenn sie sich anstrengen, ihre Website effizient zu gestalten, bin ich gerne bereit, meine Augen zu geben.
Es ist leicht, mit dem Finger auf Frameworks und Skripte von Drittanbietern für große Mengen an JavaScript zu zeigen. Wenn Sie daran interessiert sind, mehr über die Größe von Frameworks zu erfahren, könnten Sie es genießen, mich und Dave mit Jason Miller darüber diskutieren zu hören.
Und wo wir gerade von Drittanbietern sprechen, Patrick Hulce hat Third Party Web erstellt: „Dieses Dokument ist eine Zusammenfassung, welche Skripte von Drittanbietern heute für übermäßige JavaScript-Ausführung im Web am meisten verantwortlich sind.“
Manchmal ist das Anprangern eine wirksame Taktik, um Veränderungen anzustoßen.
Addy Osmani schreibt über eine ESLint-Regel, die bestimmte Pakete verbietet, mit denen Sie die Verwendung bekanntermaßen riesiger Pakete verhindern können. Wenn also jemand versucht, das gesamte lodash oder moment.js zu laden, kann dies auf Linting-Ebene gestoppt werden.
Tim Kadlec fasst die Fäden sehr gut in „Limiting JavaScript?“ zusammen. Wenn Ihre sofortige Reaktion darauf ist, dass JavaScript unfair als Bösewicht ins Visier genommen wird, räumt Tim ein, dass
Eine häufig geäußerte Sorge war: „Wenn JavaScript, warum dann nicht auch andere Ressourcen?“ Es stimmt; JavaScript wird oft kritisiert, wenn auch nicht ohne Grund. Byte für Byte ist JavaScript die bedeutendste Beeinträchtigung der Leistung im Web, daher ist es sinnvoll, sich auf die Reduzierung der Menge, die wir verwenden, zu konzentrieren.
Der Punkt ist jedoch gültig. JavaScript mag häufiger der Hauptschuldige sein, aber es ist nicht der Einzige.
Die universell ignorierte Wahrheit ist, dass Latenz die Leistung auf lange Sicht weit mehr beeinträchtigt als Bandbreite.
Wollen Sie Beweise? Wenn Bandbreite wichtig wäre, gäbe es YouTube und Netflix nicht einmal.
Es gibt ABSOLUT NICHTS, das mehr als 1 HTTP-Anfrage PRO SEITE verlangt.
Was? Aber wenn das Netzwerk 20-mal schneller wäre, wäre dieser Beitrag dann noch relevant? Ich denke, das Netzwerk ist immer noch der Schuldige. Ich sollte 1 GB pro Sekunde herunterladen können. Warum nicht?
Hä? Es ist nicht das Netzwerk. Wenn Sie 1 GB mit Lichtgeschwindigkeit herunterladen, aber Ihr Browser muss das dann entpacken und Elemente an den DOM anhängen und möglicherweise asynchrone Ressourcen nach dem Rendern bestimmter Elemente herunterladen, ist die Downloadzeit das geringste Ihrer Probleme. Es sind diese „modernen“ Frameworks und Muster, die zu viel vom Browser verlangen. Sie bitten Ihren Browser im Wesentlichen, Ihr Betriebssystem zu sein, während Ihr Webcode Ihre Anwendung ist. Die beliebte Methode, ein großes JavaScript-„Bundle“ zu erstellen, das eine kompilierte JS-App ist, verlangt dem Browser einfach zu viel ab. Tut mir leid, Leute. Kehren Sie zu sauberem HTML zurück und verbessern Sie es progressiv von dort aus.
Geben Sie JS nicht die Schuld für ein Entwicklungsproblem. JS ist das Beste, was der Webentwicklung passiert ist. Wie sieht es mit den Hunderten von Online-Kursen aus, die sagen, dass man in weniger als 2 Monaten Webentwickler werden kann? Heute haben wir schöne Browser, leistungsstarke Prozessoren und günstigen RAM, wir brauchen auch schöne Web-Apps. Web-Apps sind das billigste und effektivste Mittel für ein Unternehmen, ein plattformübergreifendes Informationssystem zu entwickeln. AJAX, Diagramme oder DOM-Manipulationen sind notwendig, um eine funktionale und schöne Benutzererfahrung zu bieten. Und dafür brauchen wir JS.
Ich bin ehrlich, ich mag JavaScript nicht mehr. Persönlich versuche ich, es minimal zu verwenden.