Links on Performance IV

• HTTP Caching ist eine Superkraft — Hugh Haworth erklärt, wie der Cache-Control Header eine außerordentlich wirkungsvolle Zutat für die Web-Performance ist. Ich habe den Titel zuerst falsch gelesen und wartete darauf, etwas über HTML-Caching zu lesen. Hugh behandelt es ein wenig (wie man vorsichtig sein müsste, wenn man es auf etwas wie ein Forum anwendet, wo sich der Inhalt von Seiten schnell ändert), aber ich finde es etwas, das im Allgemeinen zu wenig thematisiert wird. Im Allgemeinen wird HTML überhaupt nicht gecacht, weil es sich am meisten ändert und es riskant ist, der Elternteil der meisten anderen Caches zu sein. Ich mache es jetzt nur noch, weil Cloudflare es handhabt.
• Warum es in Ordnung ist, wenn Web Components Frameworks verwenden — Ich gebe zu, es stößt mich ab, wenn ich daran denke, dass Web Components überhaupt ein Framework benötigen, geschweige denn, dass eine Ansammlung zufälliger Frameworks in Ordnung ist. Aber Nolan Lawson geht hier auf die Nuancen ein. Ein paar Kilobytes, die Lazy Loaded/Code-Split werden können, sind keine große Sache, besonders da die Frameworks für die Laufzeitperformance optimiert sein könnten.
• web-vitals-element — Ein npm-Paket von Stefan Judis, das eine <web-vitals> Web-Komponente startet, die Ihre CLS, FID, LCP und BVD anzeigt (Demo). Irgendwie seltsam, dass es nicht auf Skypack gebaut wird.
• Top 10 Performance-Fallstricke — Ich hätte wahrscheinlich keine der Dinge erraten, die Jake und Surma in dieser Top-10-Liste behandeln. Ich vermute, dass die leicht zu erreichenden Früchte der Performance entweder durch technologische Verbesserungen zu einer Reihe von Nicht-Problemen werden oder von Seitenbesitzern und Hosts generell gehandhabt werden und somit eine neue Reihe von Problemen zu den Top-Übeltätern werden.
• Wie man Render-Blocking-Ressourcen eliminiert: Ein Deep Dive — Sia Karamalegos: Render-Blocking-Ressourcen sind Dateien, die den kritischen Rendering-Pfad „anhalten“. Sie unterbrechen einen oder mehrere Schritte. Sie sollten sich sehr bewusst sein, was render-blocking ist, und nur absichtlich render-blocking (wie Critical CSS) einsetzen, anstatt es versehentlich geschehen zu lassen.
• Wie wir die Seitengröße von Next.js um das 3,5-fache reduziert und eine Lighthouse-Bewertung von 98 erreicht haben — Colin Armstrong erklärt, wie dynamisches Laden von Assets, Reduzierung der Asset-Größe und die Verwendung von responsiven Bildern viel bewirken. Glücklicherweise sind die Werkzeuge zur Diagnose von Performance-Problemen und die Werkzeuge zur Lösung davon weitgehend in Next.js integriert. Der Teil über PurgeCSS und Tailwind scheint hier besonders relevant zu sein. Ich denke, wenn Sie PurgeCSS nicht verwenden, um ungenutzte Tailwind-Selektoren zu entfernen (oder den JIT-Compiler, um nur die benötigten Selektoren zu erstellen), machen Sie Tailwind im Grunde falsch. 350 KB CSS statt der benötigten 10 KB zu liefern, ist nicht in Ordnung.
• Verbesserung der Reaktionsfähigkeit von Texteingaben — Nolan Lawson erklärt, wie man verhindert, dass das input-Ereignis durch „teure“ Hauptthread-Arbeiten blockiert wird, und wie man requestIdleCallback verwendet, um UI-Updates zu stapeln.
• Vektor? Raster? Warum nicht beides! — Zach erzielt die bestmögliche Dateigröße, indem er eine Grafik in zwei Teile aufteilt: Eine SVG (Vektor) für die Dinge, die SVG gut kann, und eine superoptimierte Rastergrafik (idealerweise AVIF) für die Dinge, die sie gut kann, und legt sie dann übereinander.

Weitere Links!