Bricks Icon Falle

Icon-Falle vermeiden

tl;dr: Icons im SVG-Format sind toll. Klein, laden schnell, lassen sich animieren, bleiben in jeder Bildschirmauflösung scharf. Und ausserdem sind sie oft schon eingebaut: in Elementor, Bricks oder anderen Themes. Aber aufgepasst: immer wenn etwas zu bequem ist kann ein Haken dran sein – in diesem Fall das ganze Iconset, das gleich mit geladen wird.

Beispiel und Analyse

Wenn wir uns einen Einleitungstext vorstellen den wir ein wenig behübschen wollen denkt der Webdesigner gerne an Icons: sie laden schnell, sind gut zu handhaben (wenn man die entsprechenden Optionen im Backend eingestellt hat) und haben ein paar Vorteile, wie ich sie schon vor Jahren hier beschrieben habe. Aber Vorsicht: ein Kontrollblick zeigt eine Falle, die zur unnötigen Ladezeit und damit Ressoucenverschendung führt.
Während das WordPress-Log mit 2 kB doch recht komolex ist kommen die beiden anderen Icons mit 611 und 420 Byte aus, also alle drei Icons zusammen etwa 3 kB Ladevolumen. Die Speicher-Größe ist also nicht das Problem, die ist gut so. Geladen und verwaltet werden diese Icons aber im .woff2-Format als Font-Datei.
Bindet man nur ein einziges dieser Icons ein muss der ganze Font geladen werden, um es anzuzeigen. 

Wer jetzt einwendet, dass .woff2-Fonts ohnehin die besten und kleinsten Dateien sind hat in diesem Fall leider unrecht: Die in unserem Beispiel im Bricks vorinstallierten Daten sind größer als gedacht: 
Beispiel für die Anwendung von drei Icons in einer Section
In der Hero-Sektion wurden 3 Icons verwendet: ein WordPress-Logo als Deko und 2 Icons um die Buttons zu illustrieren.
Tabelle Ladevolumen
Die Page-Insights verraten: die 3 Icons liegen in 3 verschiedenen Sets, es werden als 3 Schriften statt 3 Icons geladen.
Zugegeben: ich habe mich für das Beispiel absichtlich in allen 3 zur Verfügung stehenden Icon-Sets bedient. Aber: 296 kB statt 3 kB sind doch ein eindrucksvolles Argument, oder?

Neben der reinen Datenmenge ist ausserdem zu Bedenken, dass zusätzlich 3 Serververbindungen aufgebaut werden müssen. Die kann man sparen, wenn die Icons gleich mit dem HTML mit ausgeliefert werden.

Eigene Icon-Sets anlegen

Bricks hat aber von Haus aus eine sehr feine Lösung eingebaut, um der oben beschriebenen Speed- und Ressourcenfalle zu entgehen: eigene Icon-Sets. 
..> Bricks > Verwalten > Icon-Manager
Ist aus 2 Gründen bei jeder Bricks-Site aufzurufen: 1. Alle Icon-Sets deaktivieren, die man nicht unbedingt benötigt und 2. ein eigenes Icon-Set anlegen, damit man an schnell und einfacher auf die Icons zugreifen kann, also diese einzeln in der Mediathek zu suchen.  

Das ist nämlich der zweite große Unterschied: selber verwaltete Icons werden nicht in einer Font-Datei, sondern ganz klassich in der Medithek verwaltet. Ein Bricks-Icon-Set ist also nichts weiter als eine Sammlung von Medien-IDs.

Dadurch ändert sich auch, wie das Icon auf der Website auftaucht. Links die Einbindung aus der Font-Datei (als CSS-Klasse), rechts direkt als SVG-Tag im HTML. Ja, mehr Code. Nein, nicht langsamer: weil ja 1. der Serveraufruf gespart wird und 2. auch die CSS-Klasse links erst mal gerendert werden muss.

Aus der Font-Datei:

<i id="brxe-uxzqhf" class="fab fa-wordpress-simple brxe-icon"></i>

Aus dem eigenen Icon-Set:

<svg class="" xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 24 24"><title xmlns="">project</title><path fill="currentColor" d="M19 4h-4.18a2.988 2.988 0 0 0-5.64 0H5a2.006 2.006 0 0 0-2 2v14a2.006 2.006 0 0 0 2 2h14a2.006 2.006 0 0 0 2-2V6a2.006 2.006 0 0 0-2-2m-7 0a1 1 0 1 1-1 1a1.003 1.003 0 0 1 1-1m-2 5l2.79 2.794l2.52-2.52L14 8h4v4l-1.276-1.311l-3.932 3.935L10 11.83l-2.586 2.584L6 13Zm9 10H5v-2h14Z"></path></svg>
Eine ganz wichtige Warnung (hier in blau) erscheint, wenn man ein Icon-Set deaktiviert: man kann keine Icons neu aus dem Set verwenden, bereits bestehende Einbindungen bleiben aber erhalten und damit besteht die Einbindung der woff2-Datei so lange, bis alle Vorkommen auf der Seite beseitigt werden.

Bereinigen der Einbindungen

Ist man nun in das rabbit hole gesprungen (das der Speed-Optimierung) will man natürlich auch alle jene Icons finden, die man so auf der ganzen Website vertreut verwendet hat. Und weil das eine eigentlich dumme Aufgabe und langweilig ist kommt wieder die AI ins Spiel, genauer der MCP Novamira der eine Staging-Kopie der Website mit der AI verbindet. (Hier mehr zu Novamira in WordPress).

Ich habe mich dazu entschlossen, mit die Verwendung der Icons nur auflisten zu lassen und diese händisch zu ersetzen. Es wäre zwar möglich, dass die AI machen zu lassen, aber hier kommt eine Eigenart des SVG-Formates ins Spiel: Eigentlich sind SVG-Dateien nur Textdateien, in denen eine Beschreibung steht wie das Icon aussieht (daher, weil Sicherheitsrelevant, auch immer das Rumgemurkse bis man SVG innerhalb von WordPress uploaden kann). Was genau aber in der SVG-Datei drinnen steht liegt am ersteller der Datei. Hat man nur eine Quelle ist das zumindest gleich. In meinem Fall sind es aber Logos, selber gezeichnete SVGs und Dateien, die ich vom SVG-Repo geladen habe (=absoluter Tip!). 
Der für uns relevante Unterschied liegt nun darin, dass manche SVG-Dateinen eine Darstellungsgröße beinhalten, andere aber nicht.

Das kann man übrigens manchmal bereits in der Mediathek sehen. Im Beispiel hier wird das Yoast-Icon schon in der Mediathek größer dargestellt als das Chalkboard-Icon darunter. Wir sehen links im Quellcode des SVGs 800px und rechts 1em. Diese Größen stehen in der SVG-Datei selber!
unterschiedliche SVG Dateien
Obwohl das 2 gültige SVG-Dateien sind verhalten sie sich verschieden. Das sieht man breits in der Vorschau.
<svg xmlns="http://www.w3.org/2000/svg" fill="#000000" width="800px" height="800px" viewBox="0 0 32 32" version="1.1"><title>yoast</title><path d="M21.523 1.977h3.422l-7.567 20.269c-1.937 5.417-3.981 7.578-7.403 7.76v-2.649c1.651-0.276 2.973-1.442 3.472-2.978l0.009-0.031c0.21-0.524 0.331-1.131 0.331-1.767s-0.122-1.243-0.343-1.8l0.012 0.033-4.416-11.347h3.109l3.139 9.822zM20.829 1.004l-1.642 4.564h-11.407c-2.469 0.007-4.468 2.006-4.476 4.474v11.909c0.008 2.469 2.007 4.468 4.476 4.475h1.869q-0.112 0.020-0.225 0.036l-0.425 0.059v4.475h0.489c0.034 0.001 0.074 0.001 0.114 0.001 3.114 0 5.795-1.856 6.997-4.522l0.020-0.048h12.079v-16.383c-0.008-2.324-1.78-4.231-4.046-4.454l-0.018-0.001 1.71-4.584z"/></svg>
<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 640 640"><title xmlns="">chalkboard-user</title><path fill="currentColor" d="M192 448c53 0 96 43 96 96c0 17.7-14.3 32-32 32H32c-17.7 0-32-14.3-32-32c0-53 43-96 96-96zM544 96c35.3 0 64 28.7 64 64v288c0 33.1-25.2 60.4-57.5 63.7l-6.5.3H332.9c-5.1-24.2-16.3-46.1-32.1-64H352v-32c0-17.7 14.3-32 32-32h96c17.7 0 32 14.3 32 32v32h32V160H192v57.3c-14.8-6-31-9.3-48-9.3c-5.4 0-10.8.3-16 1v-49c0-35.3 28.7-64 64-64zM144 416c-44.2 0-80-35.8-80-80s35.8-80 80-80s80 35.8 80 80s-35.8 80-80 80"/></svg>
Und weil das eben so ist, dass die SVG-Dateien selber unterschiedlich sind und ich ganz sicher war, dass meine Einbindung auch nicht einheitlich ist war die Entscheidung, diese gleich händisch zu ersetzen, damit ich dann fehlerhafte Darstellungs-Größen auch gleich korrigieren kann. Daher der Prompt:

auf stage.werkform.at werden für die icons oft fontawesome verwendet. Diese braucht aber recht viel speicher und ladezeit. Ich will die Icons duch custom svg ersetzen. Überprüfe, wo überall font awesome eingesetzt wird.

Font-Awesome-Nutzung auf stage.werkform.at

Ich habe die Datenbank (Bricks-Postmeta, Post-Content, wp_options) sowie die Child-Theme-Dateien durchsucht.

Umfang: 69 Icon-Instanzen, 33 verschiedene Icons, über 16 Seiten/Beiträge + Header/Footer-Templates

Wo Font Awesome tatsächlich als Frontend-Icon verwendet wird (Bricks icon-Feld)
[…]
Um mir die Arbeit zu erleichtern habe ich mir nicht nur die Liste erstellen lassen sondern diese auch mit den Icons selber und den Links dazu auf einer Seite zusammenstellen lassen. Damit habe ich bei der Gelegenheit auch Inkonsistenzen Bereinigt (zb. gleiches Icon in verschienden versionen (outline, full) oder auch verschiedene Icons gesehen, die eigentlich in der Verwendung durch nur ein Icon ersetzt wurden. Vorher waren die Icons über die Fontawsome-Sets in Verwendung:
FA- Set 1
Innerhalb von Brick kann man einfach wählen, welches Set man verwenden will.
Eigens Icon-Set anwenden
Hat man ein eigenes Set, kann man die Icons genauso anwenden wir bei den Schriftsets.
Nun wurde eben Schritt für Schritt jedes einzelne Icon ersetzt und bei Bedarf die richtge Größe (natürlich über eine CSS-Variable) eingestelllt. Bei in diesem Fall 69 Instanzen war das der einfachere Weg, als eine Entsprechungsliste anzufertigen und diese dann die KI abarbeiten zu lassen. 

Ausserdem sind KIs bei solchen batch-Aufgaben ziemlich langsam und/oder kostenintensiv, und kontrollieren muss man es ausserdem immer noch händisch. 

Aber: alleine das Auflisten und verlinken der betroffenen Stellen war eine große Arbeitserleichterung. Noch besser wäre es natürlich gewesen, von Anfang an auf eigene Icon-Sets zu setzen und nicht den bequemen Weg der Sets zu verwenden.
Anwenden eigenes Set Icons
Neben der Iconauswahl aus dem Set sind die Anzeigediemensionen die wichtigsten Optionen.

Fazit

Solche Kleinigkeiten sind wichtig: ein paar hundert K mögen nicht viel erscheinen, aber diese bei jedem Besucher einsparen zu können ist schon wertvoll. Abgesehen davon ist das natürlich wieder ein wenig näher an der optimalen Site, die wir ja als Karotte ewig vor der Nase hängen haben. Dazu kommt noch, dass man natürlich ein weiteres Mal daran erinnert wird, eine sorgfältige Planung inkl. Design-System als Grundlage für jedes neue Projekt zu sehen. Und bei bestehenden Sites hilft eben doch wieder mal die KI - nicht im kreativen Porzess oder der Erstellung, aber bei der Pflege und Optimierung.

Veröffentlicht am: 16. August 2026
Letztes Update am: 16. August 2026

Hinterlasse den ersten Kommentar