Ich sage schon seit Jahren, dass ein ziemlich gutes Icon-System darin besteht, Icons mit Inline-<svg> dort einzufügen, wo man sie braucht. Das ist einfach zu machen, bietet volle Designkontrolle, hat (im Allgemeinen) eine gute Performance und bedeutet, dass man sich nicht mit Caching und Browserunterstützungs-Kram herumschlagen muss.
In diesem Sinne… die Verwendung von <img> ist für Icons auch keine schlechte Idee. Sie bietet nicht so viel Feineinstellungsmöglichkeiten für das Design (obwohl man sie immer noch mit filter einfärben kann) und ist wohl auch nicht *ganz* so schnell (da die Bilder separat vom Dokument geladen werden müssen), aber sie hat immer noch viele der gleichen Vorteile wie Inline-SVG-Icons.
Shubham Jain hat ein Projekt namens SVGBOX, das Icons als <img> anbietet und eine der Design-Einschränkungen durch einen URL-Parameter zur Farbänderung aufhebt.
Ein Instagram-Icon, aber in Rot? Geben Sie red ein
Wenn Sie viele Icons verwenden möchten, bietet der bereitgestellte Copy-and-Paste-Code eine "SVG-Sprite"-Version, bei der die URL so aussieht
<img src="//s.svgbox.net/social.svg?fill=805ad5#instagram">Das erhöht das Downloadgewicht des Icons (da alle Icons dieses Sets heruntergeladen werden), ist aber möglicherweise effizienter, da es ein einzelner Download statt vieler ist. Es ist heutzutage schwer zu sagen, ob das effizienter ist oder nicht, mit HTTP/2 im Spiel.
Interessant ist der Teil #instagram am Ende der URL. Nur ein Hash-Link, oder? Nein! Raffinierter! Im SVG-Bereich kann das ein Fragment-Identifikator sein, was bedeutet, dass nur der Teil des SVG angezeigt wird, der dem entsprechenden <view>-Element entspricht. Das sieht man nicht jeden Tag.
Autor des Projekts hier. Chris hat Recht, Inline-SVGs bieten die größte Flexibilität. Aber es gibt ein paar Nachteile: Ihr Code wird unübersichtlich, es ist schwierig, sie als Hintergründe und in Pseudoelementen zu verwenden, und persönlich fand ich es einfacher, mit Imgs umzugehen.
Außerdem beschleunigt HTTP/2 das gleichzeitige Laden von Ressourcen, aber es gibt immer noch ein paar Gründe, warum Sie Verkettung bevorzugen könnten. Wenn das Icon dynamisch gerendert werden muss (z. B. wenn ein Dropdown-Menü angezeigt wird, nachdem Sie mit der Maus über etwas fahren), ist ein einzelnes SVG vorzuziehen, da das neue Icon sofort gerendert wird, anstatt eine neue HTTP-Anfrage auszulösen.
Ein weiterer Vorteil ist, dass Sie mit dem LINK-Tag ein Icon-Set "vorladen" können. Schließlich hat HTTP/2, obwohl es das gleichzeitige Laden stark beschleunigt, seine Grenzen. Wenn Sie 50+ Icons auf der Seite rendern (z. B. Flaggen), sind Sprites deutlich leistungsfähiger.
Oder lassen Sie den Browser SVG-Icons clientseitig *erstellen*; siehe https://iconmeister.github.io