Container-Queries in CSS – ein Ausblick

Am 11. Februar 2021 war es soweit: die CSS-Working-Group hat in einem Meeting das Thema Container-Queries mit »RESOLVED: Define container queries […]« beendet. Damit ist beschlossen, dass Container-Queries in der CSS-Spezifikation CSS Containment Module Level 3 spezifiziert werden. 🎉

Falls ihr euch jetzt fragt, »Was sind Container-Queries und warum freut sich Florian so darüber?«, findet ihr die Antwort in diesem Beitrag.

Wie man sehr große Netzwerknutzlasten in WordPress vermeidet

Lucy Beer ist ein waschechter WordPress-Profi. Mit ihren Beiträgen und Trainings hilft sie WordPress-Anwender/innen seit Jahren, schnelle, sichere und zuverlässige Websites zu bauen. Passend zu Simons Post aus der letzten Woche haben wir diesen Beitrag mit Lucys freundlicher Erlaubnis aus dem Englischen übersetzt. Die originale Version findet sich auf webtrainingwheels.com.

Wenn du Google PageSpeed Insights zum Testen deiner Website verwendest, siehst du die Warnung „Sehr große Netzwerknutzlasten vermeiden“, wenn die Gesamtgröße deiner Seite 1,6 MB übersteigt.

Das klingt erstmal technisch, ist aber tatsächlich eine der Empfehlungen, über die du als Website-Besitzer/in die meiste Kontrolle haben kannst. Im Gegensatz zu einigen PageSpeed-Empfehlungen kannst du das selbst beheben!

Mit Netzwerk ist in diesem Fall die Verbindung zwischen dem Browser deiner Besucher/in und dem Server, auf dem deine Website gehostet wird, gemeint. Die Nutzlast sind alle Dateien, aus denen deine Website besteht – Schriften, Bilder, CSS-Dateien, JavaScript-Dateien usw. – die vom Server zum Browser heruntergeladen werden müssen. Jede dieser Dateien hat eine Dateigröße in KBs (Kilobytes) oder sogar MBs (Megabytes). Die gesamte Dateigröße aller Ressourcen für die Seite ist die Nutzlast deiner Website.

Hat WordPress ein Performance-Problem?

WordPress ist langsam und kann, wenn überhaupt, nur mit viel Glück und Sachverstand halbwegs flott betrieben werden. So verhält es sich zumindest, wenn man einem der hartnäckigsten Gerüchte glauben schenkt, die um das verbreitetste CMS der Welt dieser Tage im Umlauf sind.
Schauen wir uns also einmal an, wie schlimm es um WordPress wirklich bestellt ist.

Kurzer Exkurs zur Performance

Wenn wir von der Performance sprechen, geht es vereinfacht gesagt darum, wie schnell eine Website nach dem Aufruf durch einen Browser dargestellt wird. Dabei spielt die eigentliche Ladezeit tatsächlich fast eine nachrangige Rolle, weil wir inzwischen oft von einer gefühlten Ladezeit ausgehen. Websites sind in der Regel schneller, je weniger Daten übertragen werden und je weniger Rechenaufwand zur Darstellung des Inhalts nötig ist.

Block-Editor-Konfiguration mit der theme.json

Bisher ist es teilweise (sehr) frustrierend, einzelne Block-Optionen im Editor zu konfigurieren oder zu deaktivieren. Wollten wir etwa, dass für unterschiedliche Blöcke unterschiedliche Farbpaletten zur Verfügung stehen, müssten wir aktuell einige Umwege in Kauf nehmen. Und um zum Beispiel die Ausgabe der Initialbuchstabe-Option beim Absatz-Block zu deaktivieren, hilft nur das Ausblenden mit CSS, das auch nicht so einfach ist, weil die meisten Optionen nur sehr generische Klassen haben (zum Beispiel die Initiale-Option …).

Doch am Horizont erscheint, als Retterin in der Not: die theme.json (beziehungsweise aktuell noch experimental-theme.json).

Wie viele WordPress-Plugins sind zu viele Plugins?

Hartnäckig hält sich das Gerücht, man dürfe WordPress nur mit einer bestimmten Maximalanzahl von Plugins betreiben, bevor die Stabilität, Geschwindigkeit oder Sicherheit einer Website beeinträchtigt wird. Aber stimmt das wirklich?

Ein Strauß von Faktoren

Tatsächlich gibt es nicht die eine magische Zahl aktiver Plugins, die eine Website in die Knie zwingen würde. Angefangen bei unzähligen Konfigurationsmöglichkeiten beim Hosting bis hin zu konkreten Eigenschaften der eingesetzten Plugins sind hier einfach keine allgemeingültigen Aussagen möglich.

So könnte eine WordPress-Site hunderte Plugins aktiv haben, die durch aktives Caching der Ausgabe auch bei hohen Zugriffszahlen praktisch keine Auswirkung auf die Ladezeit der einzelnen Seiten haben. Genauso gut wäre aber auch eine Website denkbar, die trotz erstklassigem Hosting von nur einem einzigen aktiven Plugin mehr oder weniger lahmgelegt wird.

Das Durchkoppeln, oder: nutzt mehr Bindestriche!

Bei meinem Praktikum in der t3n-Redaktion hat sich bei mir eine mir vorher unbekannte Rechtschreibregel eingeprägt, die eben schon vorgekommen ist: die Nutzung des Bindestrichs zum Verbinden von Komposita, das Durchkoppeln.

Seitdem fällt mir auf, wie wenig dieses Prinzip zumindest in meinem Umkreis genutzt wird (vielleicht liegt der Ursprung bei angloamerikanischen Vorbildern, wie auf der grammis-Seite »Die Besonderheiten der Kompositaschreibung« vermutet), und ich nerve Simon regelmäßig mit Hinweisen darauf, wenn ich Texte von ihm gegenlese und beispielsweise ein WordPress Theme statt WordPress-Theme finde, oder Open-Source statt Open Source (es wäre zu einfach, wenn überall ein Bindestrich hingehören würde, deshalb wird bei zusammengesetzten Fremdwörtern mit Adjektiv am Anfang kein Bindestrich gesetzt – ein weiteres Beispiel wäre Social Media. Wenn so ein Sonderfall allerdings Teil eines Kompositums ist, wird alles gekoppelt, etwa die Open-Source-Software).