Schriften — klein, lokal, ohne Sprung.

Warum Schriften bremsen.

Eine Schrift wird erst entdeckt, wenn das CSS verarbeitet ist, das sie anfordert — sie startet also spät. Gleichzeitig wird sie früh gebraucht, nämlich für den ersten sichtbaren Text. Diese Lücke ist das Problem.

Dazu kommen zwei Folgewirkungen: Wartet der Browser mit der Textdarstellung, verschlechtert sich das LCP, wenn das größte Element Text ist. Zeigt er stattdessen sofort eine Ersatzschrift und wechselt später, verschiebt sich der Text — und das verschlechtert das CLS (LCP, CLS).

Lokal ausliefern.

Schriften von einer fremden Quelle kosten zusätzlich Namensauflösung und Verbindungsaufbau, bevor überhaupt eine Datei übertragen wird. Beim ersten Besuch sind das schnell einige hundert Millisekunden — genau dort, wo es am meisten weh tut.

Vom eigenen Server geladen entfällt das: Die Verbindung steht bereits. Dazu kommt, dass der Zwischenspeicher der Browser heute pro Website getrennt arbeitet — die alte Hoffnung, eine Schrift sei schon von einer anderen Seite her vorhanden, trifft nicht mehr zu.

Und es löst die datenschutzrechtliche Frage gleich mit: Beim Laden von einer fremden Quelle wird die Adresse des Besuchers dorthin übertragen, und das ist ohne Einwilligung heikel (Schriften lokal einbinden).

Formate.

Praktisch heißt das: nur WOFF2 ausliefern. Wer noch die alten Formate mitschleppt, hat Dateien auf dem Server, die niemand mehr abruft — und manchmal Einbindungen, die sie trotzdem anfordern. Das ist ein häufiger Rest aus alten Themes.

Schnitte reduzieren.

Hier liegt die größte Einsparung. Eine Schriftfamilie mit neun Stärken, jeweils normal und kursiv, sind achtzehn Dateien. Gebraucht werden fast immer vier: normal, fett, kursiv und fett-kursiv — oft sogar nur zwei.

Prüf das konkret: Welche Stärken kommen auf deiner Seite tatsächlich vor? Wenn das Theme Überschriften in 700 und Text in 400 setzt, brauchst du 300, 500, 600 und 800 nicht. Jeder weggelassene Schnitt spart eine Datei und eine Anfrage.

Verzichte außerdem auf künstlich erzeugte Varianten: Wenn der Browser eine fette Variante aus einer normalen Schrift selbst berechnen muss, sieht das schlechter aus und kostet Rechenzeit. Lieber den echten Schnitt laden — oder die Stärke gar nicht verwenden.

Zeichensatz zuschneiden.

Eine vollständige Schriftdatei enthält oft tausende Zeichen für Dutzende Sprachen — Kyrillisch, Griechisch, erweitertes Lateinisch, Symbole. Für eine deutschsprachige Website braucht man davon einen Bruchteil.

Ein Zuschnitt auf den lateinischen Grundbereich plus deutsche Sonderzeichen reduziert die Datei erheblich, oft um mehr als die Hälfte. Viele Schriftanbieter liefern bereits zugeschnittene Fassungen; sonst gibt es Werkzeuge dafür.

Achte dabei auf das, was du tatsächlich brauchst: Umlaute und Eszett selbstverständlich, dazu Anführungszeichen, Gedankenstrich und Euro-Zeichen. Bei mehrsprachigen Websites entsprechend die anderen Bereiche — besser getrennte Dateien je Sprachbereich als eine riesige (Mehrsprachigkeit).

Anzeigeverhalten.

Die Voreinstellung vieler Browser entspricht der ersten Zeile mit einem kurzen Zeitfenster — also: eine Weile gar kein Text. Das ist fast nie gewollt.

Für die meisten Websites ist Tauschen richtig: Text ist sofort lesbar, und der Wechsel fällt bei gut gewählter Ersatzschrift kaum auf. Die vierte Zeile ist interessant, wenn Tempo wichtiger ist als die exakte Schrift — dann sehen Besucher auf schlechten Verbindungen dauerhaft die Systemschrift, aber sofort.

Ersatzschrift angleichen.

Der Schritt, der den Layoutsprung beseitigt. Wenn Ersatz- und Zielschrift unterschiedlich breit und hoch laufen, verschiebt sich beim Wechsel der Text — manchmal um mehrere Zeilen.

Moderne CSS-Eigenschaften erlauben es, die Ersatzschrift in Größe und Abständen so anzupassen, dass sie denselben Platz einnimmt wie die Zielschrift. Dann ist der Wechsel praktisch unsichtbar, und CLS fällt auf null.

Das ist etwas Tüftelei — man vergleicht beide Darstellungen und justiert die Werte, bis sich nichts mehr bewegt. Für die Hauptschrift lohnt sich das, für selten genutzte Zweitschriften selten.

Vorladen.

Mit einem Vorlade-Hinweis startet der Browser die Schrift, ohne auf die Verarbeitung des CSS zu warten. Das verkürzt die Lücke deutlich.

Zwei Regeln: Nur für Schriften, die sicher im ersten sichtbaren Bereich gebraucht werden — meist eine oder zwei. Und nicht übertreiben: Wer sechs Schriften vorlädt, konkurriert mit dem Kopfbild um die Bandbreite und verschlechtert das LCP.

Symbolschriften.

Ein häufiger blinder Fleck. Eine komplette Symbolschrift wird geladen, um drei Pfeile und ein Telefonsymbol darzustellen — das sind oft mehrere hundert Kilobyte für vier Zeichen.

Besser sind einzelne SVG-Symbole, direkt in die Seite geschrieben oder als kleine Dateien. Sie sind winzig, scharf, per CSS einfärbbar und barrierefreundlicher, weil sie einen Namen bekommen können. Wenn eine Symbolschrift bleiben soll, dann zugeschnitten auf die tatsächlich verwendeten Zeichen.

Prüf das: Lad die Seite, sieh in der Netzwerkanalyse nach Schriftdateien und zähl, wie viele Symbole du tatsächlich siehst.

Systemschriften.

Die radikalste und manchmal beste Lösung: gar keine eigene Schrift. Stattdessen die Schrift des jeweiligen Systems — die ist sofort da, kostet nichts und sieht auf jedem Gerät heimisch aus.

Für eine Marke mit eigener Typografie ist das keine Option. Für eine Website, deren Schrift ohnehin beliebig gewählt wurde, ist es eine ehrliche Überlegung — besonders für Fließtext. Ein häufiger Mittelweg: eigene Schrift für Überschriften, Systemschrift für den Fließtext. Das spart die Hälfte und bewahrt den Charakter dort, wo er auffällt.

Prüfweg.

1. Netzwerkanalyse öffnen, nach Schriften filtern.
2. Zählen: Wie viele Dateien, wie groß, von wo?
3. Abgleichen: Welche Schnitte kommen auf der Seite wirklich vor?
4. Format prüfen — nur WOFF2?
5. Mit gedrosselter Verbindung laden und auf den Textsprung achten.
6. Nach Symbolschriften suchen.
7. Nach der Umstellung alle Seitentypen durchsehen, ob Zeichen fehlen.

Punkt sieben ist wichtig nach einem Zuschnitt: Wenn ein Zeichen fehlt, zeigt der Browser es aus einer Ersatzschrift — das fällt im Fließtext kaum auf, in einer Überschrift sofort.

Wenn du nicht weiterkommst.

Wenn deine Seite auf Schriften wartet oder der Text beim Laden umspringt. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.