Ich sollte aus meiner Manie etwas machen. Oder es zumindest versuchen. Ich spreche vom permanenten, manche werden stattdessen penetranten sagen, Herumbasteln an meinem WordPress-Theme von GeneratePress – übrigens auch an der Performance.
Dieses WordPress-Theme ist immerhin seit Jahren das Gleiche. Trotzdem ändert sich ständig was. Manchmal täglich. Ich sollte, wie Claudia es mir mal geraten hatte, Screenshots machen und diese an geeigneter Stelle zeigen. Schade, die habe ich nicht. Wie es sich gehört, versuche ich bei all den Umbauarbeiten, die übrigens nicht mittels eines der vielen Maintenance – Plugins „versteckt“ werden, sondern live mit allen Tücken begleitet werden können, die Tests nicht zu vernachlässigen. Das kostet am Ende oft mehr Zeit und Nerven als das Herumfuhrwerken selbst.
An anderer Stelle teste ich zusätzlich und stelle – was sonst – dort die gleichen bzw. üblichen Probleme fest. Möchte man die Performance im „grünen Bereich“ halten, so sind vor allem zwei Faktoren entscheidend.
1. Fotos
Die Auslieferung der Fotos findet hier im Blog i.d.R. im *webp – Format statt. Dazu nutze ich seit einigen Jahren das Plugin von Imagify.
2. Fonts
Natürlich will ich nicht den immer noch zahlreich vorhandenen Abmahnanwälten zum Opfer fallen. Daher sind auch hier längst alle Fonts lokal gehostet. Die entsprechenden Werkzeuge, um sich im Google Font – Angebot umzuschauen bzw. die Fonts einzubinden sind zahlreich. Ich nutze am liebsten den „Google Font Helper„.
Bei der Übernahme der vom Font Helper übernommenen Einträge für eure style.css ist erst kürzlich ein Eintrag hinzugekommen, der meiner Erfahrung nach Auswirkung auf die Performance des Blogs haben kann. Es handelt sich um font-display: swap; Diesen Eintrag hatte ich bis dahin grundsätzlich manuell hinzugefügt. Er verhindert, dass Googles Speed-Test meckert. Fehlt dieser Eintrag (auch bei selbstgehosteten Fonts), so werden die Schriftarten erst angezeigt, wenn die Seite komplett geladen ist. Dies wird als Flash of Invisible Text (FOIT) bezeichnet.
Achtet darauf, dass die URL-Einträge im unteren Teil dieses Beispieles korrekt sind. In meinem Fall muss ich die beiden Punkte vor dem Pfad löschen, weil ich aus mir heute unerfindlichen Gründen die Fonts gleich auf der ersten Hierarchieebene unterbringen wollte. Ich meine, ich hätte gelesen, dass dieses Vorgehen performancetechnisch besser sei. Das Verzeichnis befindet sich bei mir also nicht im Ordner: wp-content oder unterhalb meines darin befindlichen Themeordners, sondern auf der gleichen Ebene wie z.B. der Ordner wp-content. Meine Vorgehensweise hat den Vorteil, dass ich mit den gleichen Pfaden ggf. auch aus anderen Themes auf mein Font-Verzeichnis zugreifen kann. Der Pfad bleibt gleich. Wären die Fonts im Theme-Verzeichnis, sähe dies anders aus.
Font-Display: swap;
Sollten die Fonts allerdings mit entsprechenden Plugins (Perfmatters) vorgeladen werden, so erübrigt sich der Eintrag. Steht er allerdings einmal im Eintrag der style.css, denke ich, ist man auf der sicheren Seite.
Wenn Sie einen System-Font-Stack verwenden, müssen keine Schriften auf die Seite geladen werden! Das ist ziemlich groß! Es beseitigt auch jede FOUT (Flash of Unstyled Text) oder FOIT (Flash of Invisible Text) Hässlichkeit. Unsere Website verwendet Systemschriftarten, und ich wette, Sie haben es nicht einmal bemerkt. Das stimmt; Diese Seite lädt keine einzige Schriftart. Link folgenWie man WordPress beschleunigt (Optimierungen für Core Web Vitals im Jahr 2023)
Woorkup
So sehr ich schöne Schriftarten liebe, so sehr muss ich darauf hinweisen, dass mehrere verschiedene Fonts im Blog die Performance negativ beeinflussen. Hier habe ich zurzeit nur zwei verschiedene im Einsatz. Eine davon gehört zum Font-Stack meines Themes. Er sieht so aus:
-apple-system, system-ui, "system-ui", "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
Kostet gleich mehrere Prozente
Lediglich für einige Überschriften nutze ich einen anderen Font (MuseoSans700 bzw. MuseoSans900). Ändere ich den Verweis auf die Standard-Fonts (s.o.) fallen die Performancewerte von Pagespeed sofort um ein, zwei Punkte. Nimmt man weitere Fonts hinzu, verschlechtern sich die Werte zusehends.
Sieht man regelmäßig auf die Werte, die z.B. die Google – Messungen ergeben, stellt sich schnell ein gewisser Frust ein. Ich bin jedenfalls kaum zufriedenzustellen mit dem, was Pagespeed mir verrät. Besser gesagt, ich verstehe einfach nicht, welche Stellschrauben zu drehen wären, um die Seite noch besser zu machen. 🙂
Werte für meine Startseite
Links: Computer, Rechts: Mobil
Warum ist der Wert für die mobile Ausgabe immer schlechter als der für den Desktop? Ehrlich? Ich habs bis jetzt nicht verstanden. Erklärende Texte gibt es schon genügend. Aber ich verstehe nicht, was die Autoren da schreiben. So halte ich mich fest an den Dingen, die ich nachvollziehen und vor allem selbst gestalten kann. Das sind nun einmal zum jetzigen Stand Fotos und Fonts.
Diese guten Werte beziehen sich auf die Startseite. Die Posts oder Pages sind noch einmal ein ganz anderes Thema. In meinem Fall fallen die Werte je nachdem deutlich ab. Es kommt darauf an, welche Elemente im Beitrag verwendet werden. Ich halte es nicht so, dass ich vor der Freigabe eines Artikels auch noch auf die Google Pagespeed – Werte sehe. Mir reicht es schon, wenn ich mich damit herumquäle, einen einigermaßen guten SEO-Wert zu erreichen.
Beweggründe – alles nur Spaß
Bestimmt fragen sich einige Leserinnen und Leser, wieso ich in diese Dinge überhaupt so viel Zeit bzw. Ehrgeiz stecke. Die Antwort ist einfach. Ich habe Freude an den Sachen und immerhin lerne ich – wenn auch langsam – immer etwas hinzu. Und auch das macht mir Spaß. Meinen Zugriffszahlen, kann ich mal ganz uneitel sagen, schaden meine vielen Versuche nicht. Sie stehen und fallen eher mit irgendwelchem Content, der mal gelungen und mal daneben ist. Jedenfalls schließe ich das einmal aus den Zahlen. Das nächste Projekt wartet schon. Oder auch nicht.
Block Themen und die CSS-Eigenschaft font-display – Horst Scheuer