So leidenschaftlich ich hier an meinem Blog herumbastle, die Grenzen sind eng gesteckt. Mir fehlen die Basics, um gewissen Geheimnissen der Technik und des Webdesigns auf die Schliche zu kommen. Das muss ich an dieser Stelle auch mal sagen: Gut, dass es das Internet gibt. Dort kann sich jede*r nach Lust und Laune Hilfe holen.
Am Ende ist das, was ich mache bzw. versuche halt nichts anderes als das altbewährte Spiel von Versuch und Irrtum. Das zog sich übrigens wie der berühmte rote Faden durch meine berufliche Laufbahn. Lebenslanges Lernen? Sicher! Aber nur, wenn man sich selbst darum bemühte.
Trial and Error
Es war nicht schlecht, wenn ich “damals” als Excel – Koryphäe um Rat gefragt wurde. Als ich in Rente ging – vor jetzt bereits 5 Jahren – habe ich mir eine stattliche Code- und Formelsammlung, die im Lauf der Jahre zusammengekommen ist, mit nach Hause genommen. Auf meinem Rechner hatte ich Microsofts aktuelle Office-Version. Ehrensache.
Seither habe ich bis auf eine Ausnahme den Fundus nie mehr gebraucht. Die Programme habe ich längst deinstalliert bzw. mein Abo gekündigt. Die paar Tabellen und Charts erstelle ich mit Google – Tabellen. 🙂 Bei aufkommenden Diskussionen verteidige ich – wohl aus alter Anhänglichkeit – MS-Office. Mit keiner anderen Tabellenkalkulation wären derart komplexe Pivot-Tabellen aber auch andere Auswertungen zu erstellen. Die Konkurrenten hatten (jedenfalls bis 2015) nichts Adäquates zu bieten.
Ich schweife wieder mal ab.
Performance – Ticks
KollegInnen, die ab und zu die Performance ihres Blogs testen wollen, stoßen vielleicht auch auf Begriffe, die zunächst mal nichts weiter als böhmische Dörfer sind. Wie kann man etwas beheben, wenn man nicht einmal versteht, was die Performancetools uns verraten? Allein auf die Werte zu starren, kann einigermaßen frustrierend sein. Andererseits hat man solche Probleme meist gar nicht, wenn man nicht zu viele Plugins laufen lässt oder ein gut getestetes WordPress-Theme ohne Anpassungen einsetzt. Nur – ich gehöre nicht zu denen, die so vorgehen. Das wäre ja nur der halbe Spaß, den ich am Bloggen hätte!
Es gibt tolle Tools, die uns Bloggern helfen, ihre WordPress – Installation flottzumachen. Dazu gehören Cache – Programme wie WP-Rocket, das ich seit Jahren sehr gerne verwende. Oder auch das Plugin “Perfmatters“. Man muss nicht solche Premium-Plugins einsetzen. Es gibt ja durchaus leistungsstarke und kostenlose Alternativen.
Achtung im Childtheme
Experimente in einem Childtheme, auch wenn sie sich nur auf wenige CSS – Zeilen beschränken, können zu unerwarteten Fehlern führen. Hier im Blog taucht – ich möchte schon sagen, von jeher – eine übermäßige “DOM – Größe” auf. Die Zahl ist mit über 1200 Elementen einigermaßen beeindruckend.
Vermutlich hat das damit zu tun, dass ich auf Gutenberg-Blocks stehe und seit einer Weile gleich zwei Premium – Plugins (Stackable und Generateblocks) einsetze, die vielleicht eine Rolle spielen könnten. Ich habe gelesen, dass es wenig zielführend ist, diesem “Phänomen” auf den Grund zu gehen. Ich könnte es probieren, in dem ich auf beide Plugins verzichte und Gutenberg – wie es viele aus bis heute andauernder Entwickler-Gutenberg-Renitenz tun, einfach mal abschalten. Einen Teufel werde ich tun!
Gute Performance – wenigstens bei den Messergebnissen
Mir reichen die Werte, die ich (zugegebenermaßen mit viel Aufwand) herausgekitzelt habe:
Bei Blogs, die ein “Cumulatives Layout Shift” aufweisen, könnte es an den verwendeten Schriftarten liegen. Ich hatte das zuerst nur vermutet. Mein Verdacht (nach einigen Experimenten) wurde durch diesen ausführlichen Beitrag des Performance-Spezialisten Simon Hearne bestätigt.
Webfonts können Layoutverschiebungen verursachen
Die auf der Hand liegenden Gründe für solche Verschiebungen sind die Platzierung von dynamischen Elementen oder unbedachte Anpassungen im (Child-) Stylesheet (Menüs, Bildgrößen, Höhen, Breiten u.s.w.). Simon schreibt hier, dass ein weiterer Grund mit einem Thema zu tun hat, auf das man in diesem Zusammenhang nicht gleich kommt.
Ja, es geht um Webfonts. Wichtig ist, dass Fallback-Fonts für das Rendern vorgesehen werden. Instinktiv richtig gemacht habe ich zum Beispiel, dass ich bei selbstgehosteten Fonts seit Langem grundsätzlich ein “font-display: swap;” mitgebe und das ich diese Fonts immer direkt unter der Hauptdomain speichere (keine tiefe Verschachtelung). Google Fonts wird die Methode “font-display: swap” immer angehängt, während es bei Typekit-Schriftarten optional ausgewählt werden muss. Vergisst man dies, erhält man einige %-Punkte schlechtere Noten bei den Performancetests.
Fonts von wo?
Ich glaube übrigens, dass die Verwendung von Typekit-Fonts im Gegensatz zu früher ™ zu einer besseren Performance führt als Google Fonts von deren Servern. Da man auch via Typekit eine Menge Google-Fonts auswählen kann, ist diese Lösung einen Versuch wert. Ich binde Typekit-Fonts mit diesem Eintrag in das Stylesheet ein: @import url("https://use.typekit.net/lsr6zqu.css");
Wichtig ist, die Auswahl “font-display: swap” in den Typekit – Fonteinstellungen nicht zu vergessen. Benutzt man WP-Rocket und/oder Perfmatters kann man im Setup einstellen, dass Google- oder Typekit-Fonts vorgeladen werden (s. Abb).
Daneben können die Fonts, die vorzuladen sind (Preload), dort in dieser Form eingegeben werden:
/fonts/xyz_regular.woff
/fonts/xyz_italic.woff
/fonts/xyz_bold.woff
/fonts/xyz_bold_italic.woff
Vielleicht lest ihr interessehalber mal den Beitrag von Simon. Das lohnt sich wirklich. Ich meine, falls ihr gerade Probleme mit den verflixten Layoutverschiebungen und schlechten Performancewerten haben solltet. 🙂