Ich habe eine Handvoll guter Links zu Artikeln über Performance, die ein Loch in meinen Lesezeichenordner brennen und die ich hier teilen möchte.

- Von Fonts zu SVG: Eine Strategie zur Icon-Migration— Erwin Hofman merkt an, dass er aus reiner Bequemlichkeit Icon-Fonts verwendet hat, aber es gibt viele Gründe, sie nicht zu verwenden. Er gibt Details zu seiner neuen Strategie für die Verwendung von Icons, die auf der
<use>-Technik basiert. Fünf Jahre später bin ich immer noch ein großer Fan davon, einfach das<svg>in den HTML-Code einzufügen, wo man es braucht. Es ist einfach ein HTML-Partial wie jedes andere. - Next.js Performance: Einen schnellen Framework noch schneller machen— Ben Schwarz sagt, dass Next.js bereits ein ziemlich schneller Framework ist, da es clevere Dinge tut, die selbst React-basierte Seiten flüssig halten. Aber Performance ist nichts, was man ganz einem Framework überlassen kann. *Du* musst Arbeit leisten. Glücklicherweise bietet Next.js einige ziemlich nützliche Hilfsmittel für Dinge wie dynamisches (Lazy) Laden von Komponenten, verzögertes Ausführen von Skripten, Optimierung von Bildern und mehr.
- Redirect Liquidation— Tim Vereecke behandelt eine faszinierende Technik, bei der anstatt einer alten URL auf eine neue URL zu *weiterleiten*, die alte URL geladen wird, der neue Inhalt dynamisch geladen wird und dann mit
history.replaceStatedie alte URL durch die neue ersetzt wird. Das ist schneller, aber tu es einfach nicht für Bots. - Performantes A/B-Testing mit Cloudflare Workers— Philip Walton behandelt, wie A/B-Testing auf statischen Websites kniffliger ist als auf serverseitig gesteuerten Websites, aber man kann es (performant) dank Cloudflare Workers schaffen, die HTML manipulieren können, bevor es den Browser erreicht, ähnlich wie ein Service Worker, nur eben am Edge statt auf dem Client. Wenn man einen Cookie speichert, kann man Benutzer in ihren richtigen Gruppen halten.
- Eine vereinheitlichte Theorie der Web-Performance— Alex Russell versucht, Tanner Hodges' Aufruf zu beantworten, Web-Performance tatsächlich zu definieren. Es ist eines dieser Dinge, die offensichtlich erscheinen (wie es klar ist, wann bestimmte Dinge der Web-Performance helfen und schaden), aber es tatsächlich zu definieren ist knifflig. Und nicht nur die Definition in Bezug auf spezifische Metriken (selbst das ist knifflig), sondern die Beantwortung von Fragen wie: *Was sind die Leitprinzipien dieser Disziplin?* *Wie sieht es aus, Web-Performance zu praktizieren? Wie machen wir das?*
- Enthüllung der neuen WebPageTest UI— Ich liebe es absolut zu sehen, wie sich das Design von WebPageTest weiterentwickelt und verbessert. Es ist eines dieser Produkte, die eindeutig ein erstklassiges Werkzeug für Performance-Praktiker sind, und hatten dennoch jahrelang ein *ziemlich* hässliches Design. Das hier ist viel besser. Es ist wie damals, als Google Fonts endlich ein Redesign bekam und die breite Community einen kollektiven Seufzer der Wertschätzung ausstieß.
- Best Practices für Cache-Header— Simons Hearnes Dissertation über Cache-Header. Als ich mich zum ersten Mal für Web-Performance interessierte, war das, wie, das *wichtigste* Ding. Wenn man Cache-Header falsch sendet, laden Benutzer möglicherweise immer wieder unnötigerweise eine Datei herunter, wenn sie sie nicht brauchen, was ungefähr das Schlimmste ist, was passieren kann. Ich bin froh zu sehen, dass Header weiterhin Aufmerksamkeit bekommen und neu gedacht werden, während sich das Web weiterentwickelt.