Obwohl wir es bereits erwähnt haben, dachte ich, dass dieser herausragende Beitrag von Addy Osmani über die Performance-Bedenken von JavaScript es immer noch wert ist, etwas genauer untersucht zu werden.
In diesem Beitrag geht Addy auf alle Aspekte der Performance-Arbeit ein und wie wir einige der gravierendsten Probleme beheben können, von der Einrichtung eines Budgets bis hin zu "Time-to-Interactive"-Messungen und der Überprüfung Ihrer JavaScript-Bundles.
Nutzen Sie Performance-Budgets und lernen Sie, sich daran zu halten. Für Mobilgeräte streben Sie ein JS-Budget von < 170 KB minimiert/komprimiert an. Unkomprimiert sind das immer noch ~0,7 MB Code. Budgets sind entscheidend für den Erfolg, aber sie können die Performance nicht isoliert magisch verbessern. Teamkultur, Struktur und Durchsetzung sind wichtig. Der Bau ohne Budget lädt zu Performance-Regressionen und zum Scheitern ein.
Super spezifisch und super praktisch!
Überraschenderweise erwähnt Addy, dass "die durchschnittliche Webseite heute etwa 350 KB minimiertes und komprimiertes JavaScript versendet", was ehrlich gesagt viel weniger ist, als ich erwartet hätte. Die Statistik, die mir am meisten Angst macht, ist, dass die durchschnittliche Webseite etwa fünfzehn ganze Sekunden braucht, bis sie interaktiv ist. Und das Ziehen all dieses JS in einen Web Worker oder das Caching mit Service Workern wird diese Interaktionszeit nicht einmal wettmachen. Yikes.
Ein weiterer wichtiger Punkt: Nicht alle Bytes sind gleich. Zum Beispiel sind 200 KB JavaScript nicht gleich einer 200 KB JPG-Bilddatei
Eine JPEG-Datei muss dekodiert, gerastert und auf dem Bildschirm dargestellt werden. Ein JavaScript-Bundle muss heruntergeladen und dann geparst, kompiliert und ausgeführt werden – und es gibt eine Reihe weiterer Schritte, die eine Engine abschließen muss. Seien Sie sich einfach bewusst, dass diese Kosten nicht ganz gleichwertig sind.