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. 🙂
Gab es da nicht neulich eine kleine Blogperformance-Erörterung, irgendwie erinnere ich mich daran 😉
Ich nehme das Thema nicht allzu wichtig, kaum ein Blog, das ich kenne, lädt besonders lange und schwerfällig. Solche Performanceprobleme spielen bei den heutigen Bandbreiten selbst in den Mobilnetzen nach meiner Erfahrung keine nennenswerte Rolle mehr.
Ich sehe das eher sportlich: Ein paar Performanceprozente herauszukitzeln ist eine Frage der Ehre, man kann sich selbst auf die Schulter klopfen, wenn einem ein paar wirkungsvolle Optimierungen gelungen sind.
Was Fonts angeht, habe ich im aktuellen Twenty Twenty-One eigentlich das Optimum gefunden. Es setzt schlicht Systemfonts des Nutzers (Surfers) auf dessen jeweiligem Gerät ein. Das wird immer gut lesbar aussehen, denn wer stellt auf seinem Gerät Schriftarten ein, die schlecht lesbar sind?
Auf meinen Surfgeräten jedenfalls sieht’s klasse aus.
Meistens habe ich in meinen Browsern den Download von Schriftarten geblockt, so dass meine eingestellten Systemfonts genutzt werden. Das garantiert mir sehr gute Lesbarkeit, egal, welche Schriftdesign-Erregungen manch einen Hobby-Webdesigner geritten haben mögen. Da ist mir in der Vergangenheit einiger Unsinn begegnet.
Für die Performance ist das sowieso die beste Lösung.
Übrigens, bei den kürzlichen Performance-Vergleichen fiel mir auf bzw. wieder ein, dass man bei Wordpress immer zwei Testläufe machen muss, um eine brauchbare Einschätzung zu bekommen:
Ein Lauf über die Homepage selbst, also den Blog-Loop und ein weiterer Lauf über eine typische Artikel-Seite. Deren Performance dürfte in aller Regel besser sein als die des Loops der Startseite.
Mir fallen die Themen nicht so in den Schoss. Einen Tag Corona, anderen Tag Webfonts bzw. Performance. Bisschen mehr Abwechslung wäre nicht schlecht.
Eigentlich wollte ich den Artikel von Simon nur zur Lektüre vorschlagen. Aber so kurz mache ich es meistens nicht. 🙂