Support » Allgemeine Fragen » Allgemeine Frage zu Schriften und deren Speicherort in WP

  • Gelöst rosenkohl

    (@rosenkohl)


    Hallo zusammen,

    ich verstehe das Handling der Schriften in WP nicht. Vielleicht kann mir jemand das eine oder andere näher bringen.

    Ausgangssituation:
    WP 5.5.3 mit
    OceanWP und
    elementor 3.0.15

    Es sollten bewusst keine googlefonts verwendet werden.
    Im Customizer sind google-Schriften deaktiviert, Schrift-Unterarten Latin aktiv und unter Typographie überall „Arial, Helvetica, sans-serif“ eingestellt.

    Im elementor bei „Globale Einstellung“ überall Arial, Primäre Schnitt 600, Sekundäre Schnitt 400, Text Schnitt 400, Accent Schnitt 500
    Fallback Font Family: Sans-serif

    Ich verwende auf den Seiten als Typographie nur die global angelegten Schriften.

    Google Pagespeed macht mich nun auf eine Schrift aufmerksam, die einmal mit preload eingebunden und zum zweiten sichtbar bleiben soll:

    wp-content/plugins/elementor/assets/lib/font-awesome/webfonts/fa-solid-900.woff2

    Ich frage ich nun, was das für eine Schriftart ist und wo die eigentlich gewünschte „Arial“ abgelegt ist.

    In dem genannten Verzeichnis befinden sich folgende Schriften jeweils mit den Endungen eot, svg, ttf, woff, woff2
    fa-brands-400
    fa-regular-400
    fa-solid-900

    Außerdem konnte ich folgendes Verzeichnis mit exakt den gleichen Schriften ausfindig machen:

    wp-content/themes/oceanwp/assets/fonts/fontawesome/webfonts

    Arial finde ich nirgends.

    Soweit ich verstehe, muss ich für die Anwendung von Font-display eine Fallback Schriftart angeben, die zunächst geladen werden soll. Also z.b. meine Arial. Allerdings lese ich das auch immer nur in Verbindung mit Google-Schriften von extern.

    Frage also, wo sind die Systemschriften abgelegt und an welcher Stelle steuert man, ob die fa-solid-900 aus dem einen oder dem anderen Verzeichnis gewählt wird?

    LG

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)
  • Arial finde ich nirgends.

    Kannst du auch nicht. Arial ist eine Schriftart, die auf so ziemlich allen Systemen (Linux, Windows, etc.) vorhanden ist. Browser benutzen diese Systemschriften, wenn man keine andere Schriftart im CSS eingetragen hat.

    Hallo,

    In dem genannten Verzeichnis befinden sich folgende Schriften jeweils mit den Endungen eot, svg, ttf, woff, woff2
    fa-brands-400
    fa-regular-400
    fa-solid-900

    … diese Dateien haben mit der Schriftart Font Awesome zu tun. Das sind allerdings in der Regel Icons, die auf der Webseite verwendet werden.
    Vermutlich möchtest du Google Fonts wegen der Datenschutzbestimmungen nicht einbinden.
    Du kannst allerdings die Schriftart auch lokal einbinden. Wie das funktioniert, wird z. B. hier oder hier beschrieben.
    Viele Grüße
    Hans-Gerd

    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

    Thread-Starter rosenkohl

    (@rosenkohl)

    Oh, wow. Vielen Dank für die schnellen und so ausführlichen Antworten.

    Nach Bscu und Hans-Gerd war bei mir schon der erste Groschen gefallen. Auf der getesteten Seite sind Iconboxen und ich hab die Icons nicht als Schrift gewertet. Das ist der Grund für die Meldung.
    Dass man googlefonts auch lokal einbinden kann, hab ich schon gelesen, da wollte ich mich irgendwann mal einlesen. Im Moment genügt mir Arial, ganz schlicht zum Rumprobieren.

    Die Erklärung von Bego Mario Garde hat die weiteres Halbwissen von mir zusammengefügt.

    Ein Childtheme habe ich eingerichtet und dort Prelaod ohne Plugin hinbekommen.
    Autoptimize hab ich im Einsatz, das hat die Seite schon deutlich schneller gemacht. War mir nicht bewusst, dass dort die Preloadfunktion enthalten ist. 🙂

    Ich möchte möglichst viel ohne Plugins machen und lernen, wie das alles funktioniert.
    Dieses Font-Display wird mich jetzt noch etwas beschäftigen.

    … und einiges andere sicher auch, ihr werdet also noch mehr von mir lesen 🙂

    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.

    Bedeutet das, dass ich beim Einsatz von Elementor die Google-Fonts und damit auch die Google-Font-Server-Verbindung nicht los werde? Bisher glaubte ich, dass ich die Verbindung zum Google-Server mit einem Child Theme zu OceanWP los werden könnte und mir bisher nur die richtigen Einstellungen fehlen, da es mir noch nicht gelungen ist. Wenn es aber für Elementor keine Lösung gibt oder ich keine finde, werde ich wohl das ganze Projekt aufgeben müssen, denn meine/unsere Seiten müssen definitiv DSGVO-konform werden!

    Dazu hatte ich im nächsten Absatz etwas geschrieben:

    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. …

    Ja, das hatte ich gelesen. Aber wenn das mit dem Elementor nicht geht, dann werde ich wohl eher aufgeben oder mich auf das originäre WordPress beschränken müssen. Dann würde ich aber wieder ganz am Anfang stehen, denn welches andere Plugin bietet Elementor-ähnlichen Funktionsumfang?…..und ich rede nur von der Free-Version. Ich bin gemeinnützig, also unentgeltlich unterwegs und es besteht der Anspruch, keine Fixkosten auszulösen.

    Ich bin zwar auf diese Seite hier gestoßen und wenn ich es richtig einsetzen könnte (noch fehlt mir dafür das Know-How), auch dann werde ich nicht von dem Google-Font-Server getrennt. …..der verstehe ich es nur nicht?

    Aber wenn das mit dem Elementor nicht geht, dann werde ich wohl eher aufgeben oder mich auf das originäre WordPress beschränken müssen.

    Ich empfinde das „originäre WordPress“ (vor allem mit Blick auf die angekündigte Weiterentwicklung) nicht als Beschränkung, ganz im Gegenteil. Für mich sprechen sehr viele Argumente gegen Elementor.

    Ich möchte zum Abschluss hier noch über meine Lösung berichten:

    Das Plugin OMGF Optimize My Google Fonts hat mir auf Anhieb die Googel-Fonts lokal eingebunden und die Verbindung zu fonts.google.apis.com wird nicht mehr aufgebaut. Somit sollte mein Projekt, zumindest in dem Punkt, der DSGVO genügen.

    Ich habe auch noch ein weiteres Plugin gefunden, das wohl genau dasselbe macht und noch simpler erscheint. Selbst habe ich es nicht mehr ausprobiert, weil ich befürchte, dass bei der Deaktivierung von OMGF irgendwelche Reste verbleiben könnten, die mir das Leben dann wieder erschweren könnten. Muss natürlich nicht, aber sicher ist sicher. Auf jeden Fall gibt es zum Plugin Self-Hosted-Google-Fonst ein hervorragendes Video und das sogar auf Deutsch.

    Video Self-Hosted-Google-Fonts

    Danke an Bego Mario Garde für die tolle Erklärung zu den Fonts!

    • Diese Antwort wurde geändert vor 2 Jahren, 11 Monaten von Wolle.

    Da stimme ich gerne zu: Self-Hosted Google Fonts ist länger nicht mehr aktualisiert worden, läuft aber auf einigen Websites von mir ohne Probleme. Das andere Plugin OMGF | Host Google Fonts Locally finde ich in der Bedienung geringfügig komplizierter, aber dafür konnte ich es bei einem Projekt einsetzen, bei dem ich mit dem anderen Plugin nicht zurecht gekommen bin.

    Den Thread habe ich als „gelöst“ markiert.

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)
  • Das Thema „Allgemeine Frage zu Schriften und deren Speicherort in WP“ ist für neue Antworten geschlossen.