nicht angemeldet ZFviaMe
Matthias Scharwies
Rolf B
ZFviaMe
klawischnigg
ZFviaMe
klawischnigg
ZFviaMe
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Hi,
bei der Erstellung einer Website mit Unterstützung von KI bin ich auf eine für mich neue SVG-Technik gestoßen: Mehrere Bilder werden in einer einzigen SVG-Datei gespeichert und lassen sich dennoch einzeln über einen normalen <img>-Tag einbinden – beispielsweise mit sprite.svg#logo.
Für mein Projekt fand ich diese Methode einfacher einzubinden und zu pflegen als klassische CSS-Hintergrund-Sprites, weil keine Bildpositionen über background-position verwaltet werden müssen. Daraus entstand die Idee, einen Web-Generator zu entwickeln, der diesen Arbeitsablauf vereinfacht:
SVG Sprite Generator ausprobieren: https://css-img-sprite-generator.ingozoell.de
Der Generator fasst Bilder in einer gemeinsamen SVG-Datei zusammen und liefert den passenden HTML- und CSS-Code für die einzelne Einbindung. Mir geht es darum, eine bestehende Technik leichter nutzbar zu machen.
Wenn ihr Zeit und Interesse habt, würde ich mich freuen, wenn ihr den Generator ausprobiert. Besonders interessieren mich eure Einschätzungen und mögliche Grenzen oder Probleme, die euch dabei auffallen.
Viele Grüße, Ingo
klawischnigg
Servus!
Hi,
bei der Erstellung einer Website mit Unterstützung von KI bin ich auf eine für mich neue SVG-Technik gestoßen: Mehrere Bilder werden in einer einzigen SVG-Datei gespeichert
Ja, das findet sich auch im SELF-Wiki:
und lassen sich dennoch einzeln über einen normalen <img>-Tag einbinden – beispielsweise mit sprite.svg#logo.
Diese Methode hat den Nachteil, dass du ein img nicht mehr färben und anders mit CSS gestalten kannst.
Wenn du wie im Tutorial inline-SVG verwendest, kannst du Farben, Abmessungen und Koordinaten, mit ein bisschen Geschick sogar Shape-Morphing festelgen, was sich bei :hover oder :focus dann automatisch ändert.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Diese Methode hat den Nachteil...
Es kommt eben darauf an, was man erreichen möchte. Wenn ich lediglich Sprites brauche und nicht weiter manipulieren muss, UND diese Sprites in mehreren HTML-Dateien brauche, dann kann man das so machen. Früher hat man dafür Bitmap-Bilder verwendet, als background-image gesetzt und den sichtbaren Ausschnitt entsprechend verschoben.
Wenn ich einen Hamburger-Button brauche und mit CSS von ≡ in × umformen will, dann brauche ich inline-SVG.
Rolf
Hallo Matthias,
vielen Dank für dein Feedback.
Bei dem Generator ging es mir vor allem darum, CSS Sprites nicht auf die herkömmlich Methode – mit Background-Images – einzubinden. Und diesen für den Benutzer besonders einfach und intuitiv zu gestalten.
Ist für diesen Nutzen der PREMIUM Preis gerechtfertigt/realistisch aus eurer @Matthias Scharwies @Rolf B Sicht?
Grüße, Ingo
Hi there,
Ist für diesen Nutzen der PREMIUM Preis gerechtfertigt/realistisch aus eurer @Matthias Scharwies @Rolf B Sicht?
Auch wenn ich weder Matthias noch Rolf bin - ich denke, der Preis ist für jemanden, der das benötigt, sowohl gerechtfertigt als auch realistisch. Daß das viele sein werden, da hab ich meine Zweifel, aber darum gehts ja nicht. Ich finde das ist sehr gut gemacht und auch professionell und optisch ansprechend umgesetzt.
Was ich noch sagen wollte - im Footer weist Du auf die Möglichkeit einer Spende/Unterstützung via paypal hin - ich hoffe, bei der Bezahlung der PREMIUM-Version hat man mehr Auswahl. Denn wenn jemand dafür etwas bezahlt, dann nutzt er es vermutlich nicht privat, im geschäftlichen Umfeld ist paypal aber eher unüblich...
Hallo klawischnigg,
vielen Dank für deine Einschätzung.
Die PREMIUM-Variante lässt sich zusätzlich zu PayPal auch mit Kreditkarte bezahlen. Weshalb denkst du, dass dieses Angebot nicht wirklich viele nutzen würden?
Viele Grüße, Ingo
Hi there,
Weshalb denkst du, dass dieses Angebot nicht wirklich viele nutzen würden?
Zum einen, weil die Leute halt einfach träge sind. Es geht nicht ums Geld; 12 oder 9 Euro sind den meisten Menschen völlig wurscht, aber viele scheuen die Prozedur des Bezahlens und sehen sich daher nach einem Angebot um, das nichts kostet. Und zum anderen denke ich, daß Dein Angebot eine Lösung für ein sehr spezielles Problem ist, das die meisten Anwender wenn überhaupt vielleicht ein, zweimal in ihrem Leben haben werden. Das macht einen "lifetime-Account", auch wenn er wenig kostet, wenig begehrenswert.
Geht mich nichts an, aber an Deiner Stelle würd' ich die Seite mit ein wenig Werbung verbinden (muss ja nichts nerviges sein, kann man auch dezent gestalten) - ich weiß, das klingt total nach bäähhh und no-go, aber wenn Du eine halbwegs realistische Entschädigung für Deinen Aufwand suchst, wirst Du darum nicht herumkommen...
Dachte, dass wäre mehr wie ein reines Nischenprodukt. Sehe den Mehrwert darin, dass man diese Sprites vernünftig updaten kann und einfach einzubauen sind; also kein "background Gefummele" mehr.
Habe dazu recherchiert, nicht wirklich was vergleichbares gefunden, da kam mir die Idee des Generators. Das kann andererseits auch bedeuten, dass dafür kein Bedarf besteht.
Werbung vielleicht erst was später.
@@klawischnigg
Ich finde das ist sehr gut gemacht und auch professionell und optisch ansprechend umgesetzt.
Hast du mal unter die Haube geschaut? Vermutlich nicht, sonst wärst du wohl kaum zu dieser Einschätzung gelangt.
🖖 Live long and prosper
Hi there,
Ich finde das ist sehr gut gemacht und auch professionell und optisch ansprechend umgesetzt.
Hast du mal unter die Haube geschaut? Vermutlich nicht, sonst wärst du wohl kaum zu dieser Einschätzung gelangt.
Nein, aber es funktioniert. Und den Einwand von zu großen Dateien find ich angesichts des Library-Mülls, den die diversen Contentmanagment-Systeme produzieren, eine quantité negligeable. Für einen Perfektionisten mag es in bestimmten Bereichen mangelhaft sein, aber für Perfektionisten wurde es vermutlich nicht gemacht, sondern für Anwender...
@@ZFviaMe
SVG Sprite Generator ausprobieren: https://css-img-sprite-generator.ingozoell.de
Hab ich mal gemacht. Reingegeben: ein JPEG mit 42 kB, eins mit 79 kB und eins mit 80 kB. Die übrigens als Einzelbilder vom Browser parallel geladen werden können.
Herausgekommen ist ein SVG mit 270 kB. Do the math: 270 ≫ 42 + 79 + 80 = 201.
Der Generator fasst Bilder in einer gemeinsamen SVG-Datei zusammen
An der Stelle muss man einen Blick unter die Haube werfen, wie er das tut! Rastergrafiken werden Base64-codiert in data-URIs gepackt. „Gepackt“ hier im Sinne von „getan“, nicht im Sinne von „komprimiert“, denn das Gegenteil ist der Fall: Ihre Größe nimmt um etwa ein Drittel zu.
Und so stehen statt 80 kB dann 270 kB auf der Performance-Uhr, mehr als das Dreifache! Und das bei 3 Bildern; bei 5 Bildern sähe das Verhältnis noch deutlich ungünstiger aus.
Du versuchst, was für developer convenience zu tun, das ist nicht zu verübeln. Aber auf Kosten der user experience?? Nein, das ist der falsche Weg!
Dein Generator ist nichts, was das Web besser macht. Im Gegenteil. Man kann von dessen Verwendung nur abraten.
🖖 Live long and prosper
PS: Du magst jetzt einwerfen, das Ding wäre ja nur für Icons gedacht, die sind keine 80 kB groß. Den Gedanken hast du aber nicht umgesetzt.
Bau doch eine Beschränkung auf maximal 20 kB pro Bilddatei ein! Wenn was Größeres hochgeladen wird, weise darauf hin, dass das für ein Icon zu groß ist.[1] Dann wäre das Ergebnis immer noch größer als die Summe der Einzelbilder (die auch nicht mehr parallel geladen werden können), aber vielleicht kleiner als die Summe der Einzelbilder, bevor der Webseitenbastler gezwungen wurde, sie auf verträgliche Größen runterzubringen. Dann würde dein Generator doch noch was Gutes fürs Web sein.
Nachtrag: Darauf solltest du natürlich gleich hinweisen, bevor ein Nutzer versucht, eine größere Bilddatei hochzuladen. ↩︎
Danke fürs Ausprobieren und für die konkrete Rückmeldung. Beim Base64-Aufschlag hast du recht: Aus 201 kB Bilddaten werden ungefähr 268 kB plus SVG-Struktur. Das Bündeln ist keine Bildkomprimierung, und diesen Unterschied sollte die Seite deutlicher erklären.
Einen Punkt möchte ich einordnen: Wenn alle drei Bilder benötigt werden, müssen auch beim parallelen Laden insgesamt 201 kB übertragen werden. Aus "270 statt 80 kB" lässt sich deshalb keine dreifache Ladezeit ableiten. Wird nur eines der Bilder gebraucht, ist dein Einwand dagegen berechtigt: Der Sprite lädt unnötige Daten mit.
Der Nutzen meines Generators liegt vor allem in der gemeinsamen Datei und der Einbindung über <img>. Das ist kein pauschaler Performance-Vorteil. Gerade für Fotos oder Bilder, die nicht gemeinsam benötigt werden, sind Einzeldateien häufig die bessere Wahl.
Ich nehme aus deinem Feedback mit, diese Grenzen klarer zu benennen und bei Rasterbildern auf die Größenänderung hinzuweisen. Eine feste Grenze von 20 kB überzeugt mich weniger: Die Dateigröße allein entscheidet nicht, ob der Einsatz sinnvoll ist. Eine transparente Größenanzeige mit Warnung halte ich für hilfreicher.
Danke jedenfalls für den Anstoß – die Kritik an der bislang zu wenig erklärten Größenproblematik ist angekommen.
@@ZFviaMe
Einen Punkt möchte ich einordnen: Wenn alle drei Bilder benötigt werden, müssen auch beim parallelen Laden insgesamt 201 kB übertragen werden.
Ja, aber nicht nacheinander, sondern gleichzeitig. Deshalb ist bei der Ladezeit nicht die Summe, sondern die Größe der größten Bilddatei entscheidend.
Aus "270 statt 80 kB" lässt sich deshalb keine dreifache Ladezeit ableiten.
Aber aus einem anderen Grund als du dachtest. Ich hatte nämlich auch einen Denkfehler in der Rechnung. Übertragen wird ja komprimiert (gzip, Brotli, …). Für die Ladezeit ist die Größe der komprimierten Ressource entscheidend.
Hab mal das 270-kB-SVG durch gzip geschickt: 183 kB. Das ist sogar noch etwas weniger als 201 kB, aber mehr als 80 kB.
🖖 Live long and prosper
Hast du einen technischen Verbesserungsvorschlag für mich? Base64 Dateien werden ja immer ca. 1/3 größer als die Originaldatei.
Wie könnte man die "aufgeblähte" Datei kleiner machen ohne die Qualität zu mindern? Gzip steht ja nicht auf jedem Server bereit.
Finde die Grundidee des Generators gut, nur habe ich mir nicht viele Gedanken dazu gemacht, wie später die SVG Datei "zusammengebaut" wird.
Hallo ZFviaMe,
Inhaltlich habe ich mich in einem anderen Posting geäußert, hier nur dies:
Gzip steht ja nicht auf jedem Server bereit.
Echt jetzt? Das hätte ich für eine Standardkomponente jedes Webservers gehalten. Bei Brotli mag es anders aussehen, aber GZip gibt's sogar bei Microsoft im IIS…
Rolf
Habe mich falsch aus. Ich meinte auch, dass der User das Aktiv aktiviert hat.
Hallo Gunnar,
Deshalb ist bei der Ladezeit nicht die Summe, sondern die Größe der größten Bilddatei entscheidend.
Das unterstellt, dass die Leitungskapazität auf die Übertragungszeit keinen Einfluss hat. Das stimmt aber nicht. Die Netto-Übertragungsdauer im Parallelbetrieb ist die Summe der Nettoübertragungsdauern bei sequenzieller Übertragung (was beim Bündeln in einer Datei der Fall ist).
Brutto sieht das anders aus, beim Parallelbetrieb müssen 3 Requests über die Leitung, was mehr Overhead bedeutet und mehr Ressourcen im Server bündelt (er muss 3 Tasks statt nur einen verarbeiten). Wie sich das konkret in der Praxis auswirkt, hängt von vielen Faktoren ab: Serverbelastung, Serverkonfiguration, aber auch Browserverhalten - die Anzahl parallel übertragener Dateien ist limitiert.
Mich wundert allerdings, dass Du, wenn Du 3 JPG-Dateien base64 codiert in ein SVG bündelst und dieses SVG dann GZIPst, weniger Bytes herausbekommst als wenn Du die JPGs direkt überträgst. Hast Du mal geschaut, auf wieviel GZIP die JPG-Dateien einschrumpft? Als statische Ressource dürfte der Server sie ja auch durch Kompressor jagen.
Ansonsten bin ich mittlerweile zu der Meinung gelangt, dass diese Bündelung als SVG keine gute Idee ist. Man wird es zumeist nicht messen können, aber meine Hypothese wäre, dass die SVG-Lösung den Browser mehr Ressourcen kostet.
Die bessere Idee für ein Tool wäre für mich, die Bilddateien automatisiert zu einem Spritecontainerbild zu kombinieren und dazu ein CSS-Snippet zu erzeugen, das die nötigen background-Eigenschaften enthält, um die Sprites darstellen zu können. Wenn das Tool weiß, wie groß die Sprites dargestellt werden sollen, kann es bedarfsweise die Einzelbilder skalieren und sie dann zu einer JPG, PNG oder WEBP Datei zusammenfassen. Die Auswahl des Sprites ließe sich über Klassen implementieren.
Ja, sicher, dann müssen die Bilder neu komprimiert werden. Und man muss es auf dem Server tun und IMagick oder ähnliches verwenden. Die Codierung als SVG lässt sich hingegen komplett im Browser erledigen, was den Privacy-Anforderungen der User entgegenkommt. Möglicherweise ist es auch Geschmackssache…
Rolf
Hallo Rolf,
danke für deine Überlegungen und Idee.
Nur wäre ich dann wieder bei einem "klassischen" Sprite Generator angekommen...
@@ZFviaMe
SVG Sprite Generator ausprobieren: https://css-img-sprite-generator.ingozoell.de
Zweiter Versuch. Hochgeladen: ein SVG:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="376 148 72 120" width="15" height="25">
<path fill="currentColor" d="M424.03 231.79c4.01,4.36 11.34,15.79 21.99,34.29 -1.14,-45.83 -11.56,-84.64 -31.28,-116.43 -20.64,29.62 -33.03,68.12 -37.16,115.5 20.86,-20.05 34.48,-31.27 40.87,-33.67 2.69,-1.13 4.54,-1.03 5.58,0.31z"/>
</svg>
Herausgekommen ist:
<svg xmlns="http://www.w3.org/2000/svg">
<svg class="icon" id="starfleet" viewBox="0 0 15 25" width="100%" height="100%" data-image-decorative="false" data-original-width="15" data-original-height="25">
<image width="15" height="25" href="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjM3NiAxNDggNzIgMTIwIiB3aWR0aD0iMTUiIGhlaWdodD0iMjUiPgoJPHBhdGggZmlsbD0iY3VycmVudENvbG9yIiBkPSJNNDI0LjAzIDIzMS43OWM0LjAxLDQuMzYgMTEuMzQsMTUuNzkgMjEuOTksMzQuMjkgLTEuMTQsLTQ1LjgzIC0xMS41NiwtODQuNjQgLTMxLjI4LC0xMTYuNDMgLTIwLjY0LDI5LjYyIC0zMy4wMyw2OC4xMiAtMzcuMTYsMTE1LjUgMjAuODYsLTIwLjA1IDM0LjQ4LC0zMS4yNyA0MC44NywtMzMuNjcgMi42OSwtMS4xMyA0LjU0LC0xLjAzIDUuNTgsMC4zMXoiLz4KPC9zdmc+"/>
</svg>
<style>svg.icon{display:none!important}svg.icon:target{display:inline!important}</style>
</svg>
SVG-Code Base64 zu codieren, um das in ein SVG einzufügen, macht überhaupt keinen Sinn!
Was herauskommen sollte:
<svg xmlns="http://www.w3.org/2000/svg">
<svg id="starfleet" viewBox="376 148 72 120" width="15" height="25">
<path fill="currentColor" d="M424.03 231.79c4.01,4.36 11.34,15.79 21.99,34.29 -1.14,-45.83 -11.56,-84.64 -31.28,-116.43 -20.64,29.62 -33.03,68.12 -37.16,115.5 20.86,-20.05 34.48,-31.27 40.87,-33.67 2.69,-1.13 4.54,-1.03 5.58,0.31z"/>
</svg>
<style>
:root > svg{display:none!important}
:root > svg:target{display:inline!important}
</style>
</svg>
Der SVG-Code sollte um id (und evtl. class – aber wozu?) angereichert werden und ansonsten unverändert bleiben; nicht aber Base64-codiert in ein image-Element gepfercht werden.
Anstatt svg.icon kannst du :root > svg selektieren, und schon brauchst du class="icon" nicht.
Das symbol-Element kennst du? Das ließe sich hier verwenden, und schon brauchst du <style>svg.icon{display:none!important}svg.icon:target{display:inline!important}</style> nicht.
<svg xmlns="http://www.w3.org/2000/svg">
<symbol id="starfleet" viewBox="376 148 72 120" width="15" height="25">
<path fill="currentColor" d="M424.03 231.79c4.01,4.36 11.34,15.79 21.99,34.29 -1.14,-45.83 -11.56,-84.64 -31.28,-116.43 -20.64,29.62 -33.03,68.12 -37.16,115.5 20.86,-20.05 34.48,-31.27 40.87,-33.67 2.69,-1.13 4.54,-1.03 5.58,0.31z"/>
</symbol>
</svg>
Referenzieren dann über use.
Irgendwann hatte ich das mal in einer Art Tutorial aufgeschrieben: Teil 1 | Teil 2 (statt xlink:href jetzt href verwenden)
@Matthias Scharwies hat da einen Hinweis aufs Wiki drübergepappt, aber den Link falsch gesetzt. Richtig wäre: https://wiki.selfhtml.org/wiki/SVG/Tutorials/Icons#SVG-Sprites. Man will sich nicht durch den ersten Teil durchwühlen müssen, um zum relenten Teil zu kommen. Könntest du den Link bitte berichtigen?
🖖 Live long and prosper
Danke @Gunnar Bittersmann für den Hinweis habe das angepasst.
@@Gunnar Bittersmann
Anstatt
svg.iconkannst du:root > svgselektieren, und schon brauchst duclass="icon"nicht.
Ich hab das in dem Codeblock darüber noch angepasst.
Statt des Zweizeilers
:root > svg { display: none !important}
:root > svg:target { display: inline !important}
sollte es auch der Einzeiler tun:
:root > svg:not(:target) { display: none !important }
Und !important muss es auch nicht sein, oder?
Aber das ist nur Schmuck am Kleid. Das ganze Konzept steht auf sehr wackligen Füßen.
🖖 Live long and prosper
@@ZFviaMe
lassen sich dennoch einzeln über einen normalen <img>-Tag einbinden – beispielsweise mit sprite.svg#logo.
Wenn es sich bei den Icons um SVGs handelt (was es bei Icons tun sollte), dann ist das überhaupt keine gute Idee. Bei Einbindung als img funktioniert die Umschaltung zwischen Lightmode und Darkmode nicht.
Und dass Nutzer zwischen Lightmode und Darkmode wählen können, sollte 2026 Standard sein.
🖖 Live long and prosper
Die Idee beim Generator war, dass unabhängig der Dateiformate diese via SVG eingebunden werden können.
@@ZFviaMe
Die Idee beim Generator war, dass unabhängig der Dateiformate diese via SVG eingebunden werden können.
Das war mir schon klar. Aber wenn da nichts Gutes bei rauskommt, ist die Idee vielleicht doch nicht so gut.
🖖 Live long and prosper
Ja.
Vielleicht könnte man den Generator darauf beschränken, nur echte SVGs in eine SVG zu packen und dann über den img Tag auszugeben. Dann wäre zumindest das Größenproblem gelöst.
Oder?
@@ZFviaMe
Vielleicht könnte man den Generator darauf beschränken, nur echte SVGs in eine SVG zu packen
Um mehrere SVGs in eine zu packen, braucht man keine Generator-Webapp. Das schafft man im Texteditor.
und dann über den img Tag auszugeben.
Ebendas sollte man mit SVGs nicht tun.
🖖 Live long and prosper
Zusammengefasst ist mein Generator überflüssig und somit Schrott.
Hallo Ingo,
Zusammengefasst ist mein Generator überflüssig und somit Schrott.
@klawischnigg und andere haben gesagt, dass sie die Idee gut finden und es nutzen würden.
Ob man 200kb auf einmal lädt oder wie man optimal packt, ist eher eine Debatte um technische Perfektion.
Deine Idee anstelle eines Hintergrundbilds ein img mit Alt-Text zu verwenden ist auch ok. Trotzdem sollte man sich immer fragen, warum eben scheinbar noch keiner auf diese Idee gekommen ist.
Heute verwendet man eben SVG-Icons. Diese haben viele Vorteile gegenüber Rastergrafiken.
SVG bietet gegenüber klassischen Bild-Sprites aber noch einen entscheidenden Vorteil: SVG ist nicht einfach ein fertiges Pixelbild, sondern beschreibt die Grafik als Vektoren.
- CSS: Farben, Linien und andere Eigenschaften eines SVG lassen sich mit CSS verändern.
- Hell- und Dunkelmodus: Ein SVG kann sich beispielsweise mit prefers-color-scheme an das Farbschema der Seite anpassen.
- Animationen: Einzelne Formen eines SVG lassen sich animieren. So kann beispielsweise aus einem Kreis allmählich ein Quadrat werden (Shape-Morphing).
Damit wird aus einem früher hauptsächlich zur Einsparung von HTTP-Anfragen verwendeten Bild-Sprite ein viel flexibleres Werkzeug: SVG kann Grafik, Gestaltung und Animation miteinander verbinden.
Das habe ich im CSS-Sprites-Tutorial gleich an den Anfang gesetzt.
Das Tutorial SVG-Icons_erstellen_und_verwenden werde ich in den nächsten Tagen sichten und aktualisieren. Was da fehlt ist ein Icon, das gemorpht wird, bzw. die Berücksichtigung von Dark- und light mode
Herzliche Grüße
Matthias Scharwies
Bin mir nicht sicher, ob ich doch besser das Tool offline stellen soll.
Ich habe die verlustfreie Komprimierung jetzt als Standard gesetzt. Einsparung ca. 25%.
Salü zusammen
Doch, img darf man inzwischen auch.
Seit April 2026 schaltet endlich auch der Safari SVGs korrekt in den dark mode um, die per img eingebunden werden:
Gruss, Bertie
Salü Ingo
Du hast Dir (oder der KI) viel Arbeit damit gemacht, das sieht man schon. Für mich ist das uninteressant, weil ich für Icons längst auf Vektorgrafik umgestiegen bin.
SVG Sprite Generatoren gibt es online schon länger, ich bevorzuge aber die Handarbeit an den Vektorgrafiken mit einem Editor und im Code.
P.S. Wenn Du schon den Vorteil von Sprites anpreist, dass damit weniger Dateien geladen werden müssen: Mein Safari Inspektor zeigt an, dass Deine Seite 89 Dateien vom Webserver lädt, davon alleine 74 JavaScript, das passt nicht zur Prämisse von möglichst wenig Dateien.
Gruss, Bertie
Salü @Bertie,
danke für dein Feedback.
Die js-Dateien habe ich wohl "etwas" aus den Augen verloren. Habe dies reduziert auf 3 Anfragen. Wenn ich gerade dabei war: CSS von 3 auf 1 Anfrage.
Hättest du eine Anregung für die Modifizierung des Generators dahin gehend, dass dieser einer breiteren Masse zugänglich gemacht werden könnte?
Grüße, Ingo
Salü Ingo
Ist für mich schwierig einzuschätzen – ich bin eben ein alter Sack, der in seinem Kämmerchen einsam vor sich hin werkelt, auf möglichst einfache, robuste und gut wartbare Lösungen steht und in mögliche marginale Optimierungen nicht viel zusätzlichen Aufwand investieren will.
Oft fällt mir auf einer Website gleich das unscharfe Logo ins Auge und ich ahne, das ist Wordpress (was sich im Quelltext meist bestätigt), da müsste man für den Upload von SVGs halt zuerst z.B. ein Plugin installieren.
Wenn viele Leute nicht einmal hier Qualitätsansprüche haben nehme ich nicht an, dass sie sich dann Gedanken über die Optimierung ihrer Pixelgrafik-Icons in 1 Datei machen, was mit HTTP/2 eine kleine Beschleunigung bringen mag. Massiv kürzere Ladezeiten lassen sich meist mit Server-Caching, optimierten Fotos etc. mit weniger Aufwand und Gehirnschmalz erreichen, aber auch darum machen sich nach meinem Eindruck nur wenige Verantwortliche Gedanken.
Und wenn man's gerne scharf und schnell mag, findet man online etliche SVG Sprite Generatoren.
Gruss, Bertie
Danke @Bertie.
Ich werde erstmal alles so belassen und beobachten, ob der Generator genutzt wird.
@@Bertie
Doch,
imgdarf man inzwischen auch. Seit April 2026 schaltet endlich auch der Safari SVGs korrekt in den dark mode um, die perimgeingebunden werden:
Ah, danke, gut zu wissen.
Wollte gerade mal eine Testseite erstellen … Oh, da hab ich ja schon eine. Oder zwei.
Ja, die Umschaltung funktioniert bei Einbindung als img auch im Safari – sowohl mit Mediaquery prefers-color-scheme als auch mit der CSS-Funktion light-dark().
🖖 Live long and prosper