Nach dem x-ten Projektaudit mit denselben Symptomen, CLS-Werte im roten Bereich, Caching-Konflikte, jQuery-Relikte in ansonsten sauber optimierten Stacks, haben wir aufgehört zu suchen. Das Lightbox-Problem ließ sich nicht einkaufen. Also haben wir es selbst gelöst.

Das Problem, das keiner benennt

Es gibt Dutzende WordPress-Lightbox-Plugins. Die meisten lösen ein triviales Problem mit einer Architektur, die nach Theme-Framework riecht, nicht nach Komponente. Ein Plugin, das serverseitig in Templates eingreift, eine eigene JS-Library nachlädt und sich gegen Lazy-Loading und Cache-Optimizer behaupten muss, ist keine Lösung. Es ist ein Risiko im Produktivbetrieb.

Die Probleme, die wir in Projekten immer wieder gesehen haben:

• jQuery als Pflichtabhängigkeit, auch wenn das Theme sie längst nicht mehr braucht
• CSS, das ungefragt globale Stile überschreibt
• Caching-Bruchstellen, weil das Plugin DOM-Zustände serverseitig voraussetzt, die clientseitig nicht mehr existieren
• Layout-Verschiebungen durch nachgeladene Stile im kritischen Renderpfad
• Kein sauberes Verhalten bei dynamisch geladenen Inhalten

Das sind keine Randprobleme. Das sind strukturelle Schwächen, die in Produktionsumgebungen mit echtem Traffic zu messbaren Performance-Einbußen führen.

Die Eigenentwicklung

Wir haben kein Plugin gesucht, das möglichst viele Features hat. Wir haben eine Lösung gebraucht, die in fremden Stacks läuft, sich nicht mit Caching-Plugins prügelt und den kritischen Renderpfad in Ruhe lässt.

Die Anforderungsliste war kurz. Und kompromisslos:

• Zero Dependencies. Kein jQuery, kein Framework, keine externen Ressourcen
• Kein serverseitiger Eingriff. Kein PHP, das DOM voraussetzt oder manipuliert
• DOM-Scan im Browser. Bildanker werden clientseitig gelesen, Originaldateien sauber referenziert
• Laufzeit-Injection. Die UI-Schicht existiert erst dann im DOM, wenn sie gebraucht wird
• Zentrales Event-Handling via Event Delegation. Ein Listener. Nicht hundert

Das klingt nach wenig. Es ist nach viel Arbeit.

Was dabei entstanden ist

Das Ergebnis ist kein Plugin mit Konfigurationsseite, fünf Skin-Optionen und Premium-Version. Es ist eine schlanke, eigenständige Komponente, die genau eine Aufgabe hat und sie nicht vermasselt.

Sie liest den finalen DOM, den der Browser nach allen Optimierungen, Lazy-Loading-Kaskaden und Cache-Transformationen übrig lässt. Sie setzt keine Voraussetzungen über die Serverarchitektur voraus. Sie stört nichts.

In Agenturbetrieb ist das der Unterschied zwischen einer Lösung, die in der Demo funktioniert, und einer Lösung, die unter Last, in fremden Themes und mit kaputten Plugin-Landschaften zuverlässig läuft.

Was das für WordPress-Projekte bedeutet

Die meisten Performance-Probleme im WordPress-Umfeld entstehen nicht durch eine einzelne schlechte Entscheidung. Sie entstehen durch die Akkumulation von Komponenten, die jede für sich akzeptabel wirken und zusammen das Fundament unterhöhlen.

Eine Lightbox ist kein kritisches System. Aber sie ist ein Indikator. Wer bereit ist, für ein Bild-Overlay eine jQuery-Abhängigkeit in Kauf zu nehmen, trifft diese Entscheidung auch woanders. Das Lightbox-Problem ist selten nur ein Lightbox-Problem.

Für uns nicht mehr. Und für Sie?

Quellen

• https://pwa.ist/warum-99-der-wordpress-lightboxes-schrott-sind/
• https://deliciousbrains.com/optimizing-wordpress-for-core-web-vitals/
• https://nitropack.io/blog/wordpress-core-web-vitals/
• https://github.com/archetyped/simple-lightbox/issues/982

Ich verwende große und vielfach bewährte Content Management Systeme am meisten WordPress, aber nicht ausschließlich. In den vielen Jahren im Netz habe ich auch so manchen Exoten wie Dolphin getestet, mit mehr oder weniger guten Ergebnissen. Im Prinzip habe ich schon mit fast jedem “großem” CMS und unterschiedlichster Shoppingsoftware “rumgespielt”. Das Resultat dieser Experimente ist, dass WordPress in Funktionsvielfalt und Designmöglichkeiten unschlagbar ist. In Spezialfällen können auch andere Systeme notwendig werden. Es kommt also immer auf den Zweck an, der erfüllt werden soll. Aktuell beschäftige ich mich mit “Headless CMS” und beobachte den Weg von WordPress hin zum “Blocks CMS“. Ich vermute es, aber in den nächsten Jahren kommen gewaltige Änderung auf Entwickler zu.

Alle bekannten CMS inkludieren vielfältigen Möglichkeiten diese durch Addons oder Plugins anzupassen. Auf Codeebene, praktisch aus Entwicklersicht, sind diese nichts anderes als Codefragmente, die zum “Hauptcode” (Core) hinzugefügt werden. Zusätzlich sind auch Templates und Themes ausschließlich mit Grafiken angereicherte Codefragmente. Setzt man nun verschiedene dieser Fragmente zusammen, entsteht schon allein dadurch dabei am Ende etwas zweckspezifisch völlig Neues. Ändert man dann noch umfangreich das CSS (teilweise hat “unsere Software” 1000 Zeilen eigenen CSS-Code) und optimiert man dazu im Core oder auf Pluginebene im Code selbst, komme ich nicht darum herum, dies als neue Software zu begreifen. Im Endeffekt bin ich natürlich eher Software-Designer als Software-Entwickler, aber das sucht ja bei Google keiner ;)…

Die Profis wissen sowieso wie man das herausbekommt und allen anderen erzähl ich gerne, welche Elemente ich in den einzelnen Produkten verwendet habe. Geheimnisse habe ich keine und die vielen Entwickler, die letztendlich “meine Software” ermöglicht haben, sind Helden in jedem ihrer Bereiche!