Vorab: Gelegentlich sollen ja noch andere mitlesen, weshalb meine Antwort ein wenig ausführlicher geworden ist – Sorry!
— — —
Browser können nur Schriftarten anzeigen, die
- mit dem Betriebssystem geliefert wurden,
- vom Benutzer nachträglich installiert wurden oder
- beim Aufruf der Website mit der Website mitgeliefert werden oder aus einer anderen Website in den Browser-Cache übertragen wurden.
Verwendet eine Webseite eine Schriftart, die nicht auf dem Computer mit dem verwendeten Browser vorinstalliert ist und auch nicht den Webfont mitliefert, fällt der Browser auf im Stylesheet angegebene Fall-Back-Schriften zurück. Steht im Stylesheet eine CSS-Regel
body {
font-family: "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
font-weight: 300;
}
prüft der Browser nacheinander, welche der genannten Schriften vorhanden sind und stellt die Webseite damit dar. Ist keine der Schriften vorhanden, wird die Webseite als letzter Fallback mit der Schriftart Times bzw. Times New Roman dargestellt, was dann zumindest merkwürdig aussieht.
Für den Fall, dass die Schriftart von der Website mitgeliefert werden soll, gibt es einmal die Möglichkeit, dass die Schrift lokal auf der Webseite gespeichert ist oder aus einer Sammlung mit Webfonts bei einem Drittanbieter geladen wird. Die Einbindung eines Drittanbieters ist sinnvoll, weil die Webserver für die Auslieferungen der Webfonts optimiert sind. Außerdem werden diese häufig auch von anderen Webseiten verwendeten Fonts im Browser-Cache zwischengespeichert, was einen erneuten Abruf überflüssig macht und sich deshalb positiv auf die Performance auswirkt (was nicht mehr übertragen werden muss, blockiert keine Bandbreite). Das erklärt auch den Erfolg von Google Webfonts.
Durch die Datenschutzvorgaben der Datenschutzgrundverordnung ergibt sich hier aber ein Problem: Beim Abruf eines Webfonts von einem Drittanbieter wird die IP-Adresse des Webseitenbesuchers an den Server des Drittanbieters übertragen. Dieser Drittanbieter könnte die besuchten Webseiten tracken und so für den Benutzer mit dieser IP-Adresse ein Profil erstellen, also genau das, was die DSGVO zu verhindern versucht. Viele Webseitenbetreiber argumentieren zwar, das die Verwendung von Webfonts von Drittanbietern ein (im juristischen Sinne) „berechtigtes Interesse“ darstellt, was grundsätzlich die Einbindung von Drittanbietern erlauben würde, aber dem kann entgegengehalten werden, dass Schriften auch auf dem Webserver vorgehalten werden können und spätestens beim Aufruf von Folgeseiten auch der Performance-Vorteil nicht mehr als Argument greifen würde. Damit ist die Verwendung von Webfonts von Drittanbietern also eigentlich nicht mehr statthaft. Uneigentlich ignorieren das viele Webseitenbetreiber, weil US-amerikanischen Webentwicklern die europäischen Datenschutzvorgaben vermutlich egal sind (gutes Beispiel sind das mit jeder WordPress-Version mitgelieferte Antispam-Plugin Akismet oder die Plugin-Grabbelkiste Jetpack), weshalb in Plugins und Themes auch munter weiterhin Webfonts von Drittanbietern eingebunden werden.
Theoretisch müssten deutschsprachige Anwender also z.B. Child-Themes erstellen und die Einbindung von Webfonts so umprogrammieren, dass statt dessen lokal (also auf dem eigenen Webserver gehostete) Schriftarten verwendet werden. Wie ein Google-Font heruntergeladen, auf dem eigenen Webserver installiert und in das CSS-Stylesheet eingebunden werden kann, hat Kirsten in diesem älteren Blogbeitrag sehr gut beschrieben: Google Fonts über den eigenen Server einbinden
Bei Plugins (wie in diesem Fall dem Pagebuilder-Plugin Elementor) kommt eine Erschwernis hinzu, die eine Anpassung zunächst fast unmöglich macht: Während für Themes Ergänzungen über ein Child-Theme möglich sind, gibt es für Plugins keine Möglichkeit, ein „Child-Plugin“ zu erstellen. Oft lassen sich zwar in einem eigenen Plugin Funktionen eines Plugins ersetzen, aber das ist nicht gerade das, was sich ein Einsteiger von einem „einfach zu bedienendem Content Management System“ wünscht.
Eine interessante Alternative sind Plugins, die beim Abruf von Webseiten die verwendeten Fonts selber zwischenspeichern und die Webseiten so ändern, dass bei einem erneuten Abruf diese zwischengespeicherten Fonts mitgeliefert werden. Hier gibt es einmal das bereits etwas ältere Plugin Self-Hosted Google Fonts (längere Zeit nicht mehr gepflegt, funktioniert aber einwandfrei) oder das aktuellere OMGF | Host Google Fonts Locally (das ich persönlich etwas komplizierter in der Anwendung finde).
Die von dir genannten Font-Awesome Webfonts sind Icon-Fonts, die statt lateinischen Buchstaben Symbole wie das Hamburger-Icon für mobile Webseiten ausgeben. Eine Übersicht aller Icons findest du hier: All 7.865 Awesome Icons
Die Font-Awesome-Icons laden sehr schnell und sind (vor allem, weil sie auf so vielen Webseiten vorkommen und damit in der Regel bereits im Browser-Cache gespeichert sind) im Gegensatz zu eigenen Bilddateien (jpg, png) sehr performant. Es überrascht also nicht, dass Elementor auf diese Fonts zurückgreift.
Die Entwickler haben sich aber löblicherweise die Mühe gemacht, diese Icon-Fonts im Plugin einzubetten: https://plugins.trac.wordpress.org/browser/elementor/trunk/assets/lib/font-awesome/fonts (was dann auch deine Frage beantworten sollte, wo die Fonts gespeichert werden). Damit solltest du dir, wenn dein Theme keine Fonts einbindet, über die Fonts aus datenschutzrechtlichen Gründen keine Gedanken mehr machen.
Bleibt dann noch die Frage der Performance. Wie du die Performance optimieren kannst, wird z.B. in diesem Beitrag beschrieben, der allerdings eine Lösung mit dem kostenpflichtigen (und sehr empfehlenswerten) Cache-Plugin WP Rocket empfiehlt: How To Preload Elementor Fonts. Wenn du eine kostenlose Lösung möchtest, hilft dir vielleicht dieser Thread weiter, in dem Frank Goossens eine Lösung mit seinem tollen Plugin Autoptimize aufzeigt: Preload Elementor Fonts.
Lesenswerter Beitrag zum Thema: Why Self-Hosting Google Fonts Isn’t Recommended
