#071: Was macht eine schnelle WordPress Website aus? | m. Felix Arntz

In dieser Episode tauchen wir in das Thema Ladezeitoptimierung von WordPress-Websites ein.

Und am Anfang werden wir darüber sprechen, was Ladezeit und Performance eigentlich ist und wie man das am besten messen kann und welche Metriken sollte man achten.

Und danach werden wir uns noch anschauen, was sich in WordPress getan hat, im WordPress-Core über die letzten Jahre im Bezug auf Ladezeiten und Performance und wie man welche Maßnahmen setzen kann, welche Plugins man verwenden kann, damit man dann auch wirklich die Ladezeit der WordPress-Website verbessert und nicht nur die Einstellungen bei dem Caching-Plugin hochschraubt, damit man dann den Google PageSpeed Insights Test austrickst.

Herzlich Willkommen bei der 71. Episode der Dominik Liss Show.

Auf diesem Podcast gibt es WordPress und Business Talks.

Das heißt, wenn du WordPress in deinem Business verwendest, dann bist du hier genau richtig.

Weil in jeder Episode entpacken wir dir Skills, Stories und Geheimnisse der besten Experten aus der WordPress-Branche.

Und das Ziel des Podcasts ist dir dabei zu helfen, ein besserer Professional in der WordPress-Welt zu werden.

Heute bin ich schon sehr gespannt auf das Gespräch, weil wir unterhalten uns mit Felix Arntz.

Felix ist WordPress Core Contributor und gleichzeitig ist er auch WordPress Performance Team Rep.

Also, Also falls du mal zum Beispiel Plugins verwendet hast, wie das Performance Lab Plugin oder das SiteKit Plugin, da war Felix auf jeden Fall sehr aktiv dahinter und da wird er uns jede Menge erzählen.

Und zusätzlich ist Felix auch Senior Software Engineer bei Google, das heißt, er hat Einblicke in beide Welten und da bin ich schon sehr gespannt auf das Gespräch.

Aber Felix, bevor ich da noch zu viel erzähle, bitte kannst du dich auch selbst kurz vorstellen, den Leuten erzählen, wer du bist, was du machst und inwiefern arbeitet jetzt Google mit WordPress zusammen in Bezug auf Performance? Kannst du das vielleicht kurz erzählen und dann werden wir gleich ins Thema eintauchen.

Ja, ich kann mich mal kurz vorstellen.

Ich habe angefangen zu WordPress zu contributen vor knapp zehn Jahren und habe WordPress, also habe auch WordPress schon vorher natürlich als Entwickler benutzt und seit 2018 bin ich dann Teil von Google geworden.

Da wurde damals ein WordPress spezifisches Team auf die Beine gestellt und so bin ich dann zu Google gekommen und habe seitdem zwar in verschiedenen Dingen gearbeitet, aber im Prinzip immer an irgendetwas, was WordPress bezogen war.

Also zu Beginn war es für einige Jahre das SiteKit-Plugin von Google für WordPress, was ihr vielleicht kennt und seit 2021 haben wir uns dann sehr viel auf Performance in WordPress fokussiert.

Wir haben dann im Prinzip das WordPress Performance Team mitbegründet, also es ist dann ein offizielles Team des WordPress Projektes, wo sich die Contributor auf Performance spezialisieren und davon bin ich seitdem dann auch Teil gewesen Und so ist im Moment eben auch mein Fokus hauptsächlich auf Performance, war aber auch schon seit längerer Zeit vorher ab und zu mal wieder auf Performance fokussiert, bestimmte Features in WordPress Core zum Beispiel einzubauen.

Und ich fand es eigentlich ziemlich cool, weil das erste Mal, wo ich dich gehört habe oder dich gesehen habe, war bei dem Podcast von Greyd, also Greyd Conversations.

Und da werde ich die Episode auf jeden Fall unten verlinken, falls sich die Leute noch mehr von dir anhören wollen.

war eine wirklich coole Episode.

Und damit wir die Frage auch vielleicht vorab klären, also wenn die Leute jetzt denken, hey, du arbeitest bei Google und du hast was mit Performance zu tun, da musst du ja die ganzen Einblicke haben, wie der Google-Algorithmus dann die Pages rankt und wie das dann einfließt auf das Ganze.

Aber können wir vielleicht das kurz klären, weil du bist ja sehr in diesem technischen Performance-Team für WordPress drinnen, aber hast du da Einblicke in in den Google-Algorithmus und wie der das auswertet oder ist das ein komplett anderes Team, welches dafür zuständig ist? Ja, also das ist in der Tat ein komplett anderes Team.

Also ich habe, ich arbeite zwar eben an Dingen mit Performance bei Google und ich habe da auch viel mit Core Web Vitals zu tun, wie die im Detail definiert sind, et cetera, aber da geht es dann, was du gerade meinst mit Ranking, da geht es dann in Richtung Search und damit habe ich halt gar nichts zu tun.

Wir reden ja dann auch immer von einem Unternehmen mit über 100.000 Mitarbeitern, da weiß auch nicht jeder, was der letzte andere von den 100.000 Mitarbeitern macht und eben deswegen kann ich da einfach nichts zu sagen, wie dann genau die Performance das Ranking beeinflusst.

Und nicht, weil ich nicht darf, sondern einfach auch, weil ich nicht weiß.

Aber das finde ich super, weil dann können wir uns einfach auf die technischen Sachen fokussieren.

Und das finde ich irgendwie viel spannender, also für mich persönlich.

Und das, was wir gerne am Anfang, ich glaube, aufschlüsseln sollten, sind die Begriffe, damit wir die jeweils richtig verstehen und richtig verwenden.

Und da ist es auch mega interessant, überhaupt den Begriff Ladezeit einmal zu definieren.

Was fließt dir überhaupt mit ein? Wie kann man den Begriff Ladezeit verstehen? Und da gibt es dann noch den Begriff Performance.

Und diese beiden Begriffe werden oft als Synonyme verwendet, aber das ist ja im Endeffekt was anderes, weil ich habe es früher auch als Synonym verwendet.

Da mag ich mich aus der Gruppe auch nicht rausnehmen.

Aber könntest du von deiner Seite diese beiden Begriffe vielleicht für uns aufschlüsseln, was das jeweils bedeutet und wo die Unterschiede sind? Ja, klar.

Also, fangen wir mal mit Ladezeit an.

Im Prinzip ist das ja, kann man sich ja, man denkt sich ja darunter, das ist einfach die Zeit, wie lange es dauert, bis die Website geladen ist.

Aber welche Zeit, von was, von wann bis wann genau misst denn diese Ladezeit eigentlich, und was genau misst sie? Also, das ist dann doch etwas, da muss man ein bisschen mehr drüber nachdenken.

Gehen wir mal zum Beispiel 10 Jahre zurück oder so, bevor es die Core Web Vitals gab, historisch gesehen wurde oft zum Beispiel einfach die Zeit gemessen, wie bis alles auf einer Website geladen ist.

Und erst einmal klingt das natürlich irgendwie sinnvoll.

Man will ja einfach messen, wie lange es dauert, bis die ganze Website geladen ist.

aber das ist nicht unbedingt repräsentativ von der eigentlichen Endnutzer-Experience.

Ich kann das jetzt mal an einem Beispiel erklären, zum Beispiel, stellen wir uns mal zum Beispiel einen Blogarchiv vor, so ein typisches Blogarchiv von einer WordPress-Seite.

Da hat man ja, sagen wir mal, zehn Posts oder mehr untereinander aufgelistet, mit den Posttiteln und Featured-Image vielleicht und den eigentlichen Inhalt und wenn man dann dieses Website lädt, dann sieht man ja eigentlich in der Regel nur den ersten oder dann sieht man wahrscheinlich das erste Bild, die ersten Titel und vielleicht einen Teil von dem ersten Text.

Das heißt, ja alles was darunter ist, ist im Prinzip nicht wichtig für den Endnutzer in diesem Moment Und, ähm, natürlich, wenn der Nutzer dann runterscrollt, dann wird's irgendwann, dann ist es wichtig, dass der Inhalt geladen ist, aber für den ersten, für die erste Ladeerfahrung, ist es, sag ich mal, eigentlich irrelevant, wie schnell der, der zehnte Post geladen wird, zum Beispiel.

Und deswegen ist es gar nicht so repräsentativ jetzt, um einfach die gesamte Ladezeit zu messen, weil es einfach nicht so wichtig ist, bis alles geladen wird.

Es ist wichtig zu messen, wichtiger zu messen, wie lange dauert es, bis die Inhalte, die der Nutzer wirklich wahrnimmt, am Anfang geladen sind.

Und dazu hat dann, unter anderem dazu hat dann Google vor einigen Jahren die Core Web Vitals etabliert, die eben versuchen, Ladezeit und andere Dinge, auf die wir gleich auch noch eingehen, eben auf eine Art zu messen, die der Endnutzer-Erfahrung nahekommt.

Und, ähm, ja, und dann will ich auch nochmal kurz, will ich auch noch kurz darauf einschieben, zu dem, zum Punkt Ranking, und der, oder zum Punkt, zum Punkt der Performance, des Performance-Einfluss auf Ranking.

Ähm, ich persönlich sag dazu immer, ich weiß nicht, wie viel der Einfluss ist, und ich weiß nicht genau, wie, aber im Prinzip, Performance macht man ja nicht nur für Google Search, Performance macht man, um den Endnutzern seiner eigenen Website eine gute Erfahrung zu liefern, Und aus dieser Hinsicht allein ist es schon wichtig, eben diese Core Web Vitals zu messen und sich eben klar darüber zu werden, was ist eigentlich Performance.

Performance versteht man ja auch anders, je nachdem, von welchem Bereich man kommt.

Also im Marketing ist Performance zum Beispiel, wie gut konvertet jetzt meine Seite oder wie viele Conversions finden statt oder wie viel Geld verdient die? Von der technischen Seite her, Performance, es heißt Leistung, Power und eben dann auch zum Beispiel Ladezeit, also wie schnell ist die Website, also nicht nur in Bezug auf wie schnell wird die geladen, sondern wie gut kann man dann auch interagieren auf der Website, weil es bringt ja nichts, wenn die schnell geladen wird, wenn man dann bei einem Klick halt 5 Sekunden warten muss, bis die nächsten Blogartikel geladen werden und so weiter.

Und das ist dann der Unterschied, wenn ich das jetzt richtig verstanden habe, oder also Ladezeit ist halt wichtig, dass das ein Bereich von der Performance einfach.

Genau.

Also Ladezeit, die Ladezeit, wie sie von den Core-Web-Vitals definiert ist, da gibt es eine, ich nenne jetzt mal diese Metriken, die haben alle sehr verbose, sehr lange komplizierte Namen.

Die Metric, die wichtig ist für die Ladezeit, heißt Largest Contentful Paint, kurz LCP, und die misst im Prinzip, wie lange es dauert, von dem Moment, dass der Endnutzer die Website lädt, bis zum Punkt, wo der wichtigste, größte Inhalt, der im ersten Viewport sichtbar ist, geladen ist.

Das heißt zum Beispiel, wenn man auf irgendeine Website geht, wo ein riesiges Bild, also so ein großes Hero-Image ist oder so, das ist ja sehr typisch, dann ist das in der Regel die Zeit, bis dieses Hero-Image geladen ist, die da gemessen wird.

Und das ist eben diese LCP-Metrik.

Es gibt dann aber, wie du schon sagst, auch andere Metriken, und das ist eben ein ganz wichtiger Punkt, daran zu denken, dass Ladezeit ist nicht gleich Performance.

Ladezeit ist nur ein Teil von Performance, auch im technischen Sinne, und ich kann jetzt kurz noch auf die anderen Metriken eingehen.

Es gibt im Prinzip drei, drei Core Web Vitals, die wichtig sind.

LCP ist eine davon, das heißt, technisch gesehen ist eine gute Ladezeit zu haben nur ein Drittel von was, nur was ein Prinzip für eine Performance in einer Website wichtig ist.

Das, der andere, die zwei anderen Punkte sind zum einen, die Performance von Interaktivität, also wie, wenn man mit der Website interagiert, wie schnell reagiert dann, was man da macht, zum Beispiel, sowas kann man immer am besten erklären mit Negativerfahrung, die Leute typischerweise damit haben, zum Beispiel, wenn man auf einer Website auf einen Button klickt, und es passiert nichts, und dann eine Sekunde später passiert etwas, oder zwei Sekunden später passiert etwas, das ist halt keine gute Nutzererfahrung.

Und ich denke jedes Mal, wenn ich dann sage, eine Sekunde, das klingt einfach nach nichts, aber wenn man das, während man mit dieser Website interagiert, ist eine Sekunde schon ziemlich lang, weil man eben erwartet, dass sofort etwas passiert, auch wenn man auf einen Button klickt.

Oder ein anderer Punkt, wo Interaktivität, wo man oft merkt, dass vielleicht eine Website nicht gut, keine gute Interaktivitätsperformance hat, ist, wenn man, wenn man irgendwo runter scrollt, und dann scrollt es aber so extrem ruckelig oder sowas.

Ja, das sind halt eben Dinge, wo man, wo man, wo irgendwas bei da nicht komplett im Reinen ist mit der Performance für Interaktivität.

Ja, dann ist es halt der Überladen mit JavaScript.

Wahrscheinlich, Und da wird im Hintergrund einfach so viel geladen, dass einfach der Browser nicht mit dem, mit dem Animieren, mit dem Rendern der Scrollings mitkommt, wenn ich das jetzt richtig zusammengefasst habe.

Genau, es kann sein, dass zu viel, es kann sein, dass da zu viel JavaScript gerade geladen wird, es kann auch sein, dass die JavaScript-Logik einfach viel zu viel macht und nicht darauf abgestimmt ist, auf andere Prozesse zu warten, die vielleicht wichtiger sind.

Das ist dabei ganz wichtig zu bedenken, denn einer der, im Prinzip das Wichtigste für Interaktivitätsperformance ist, dass eben die eigentliche Nutzer-Interaktion immer priorisiert werden muss.

Also, wenn ein Nutzer scrollt, dann soll das nicht davon aufgehalten werden, dass gerade, ich sag mal jetzt irgendwie, JavaScript irgendwelche Daten zu einem Analytics-Provider sendet, oder so, weil das ist einfach nicht so wichtig, wie die Nutzer eine gute Interaktivität zu bieten.

Diese, die Interaktivität, die wird dann im Prinzip gemessen durch eine Metric, die heißt Interaction, no, Interaction to Next Paint, äh, hat auch wieder einen langen Namen, kurz INP, oder I-N-P in Deutsch, ähm, und äh, ja, und dann kann ich noch kurz auf die letzte Metric eingehen, äh, die befasst sich damit, wenn Inhalte auf einer Website plötzlich sich verschieben, ähm, das heißt, ähm, kann ich auch wieder kurz ein Beispiel erklären, Wenn man zum Beispiel auf, sagen wir mal, auf einer Website ist ein Button, die Website, man merkt vielleicht schon, die Website lädt ein bisschen langsam oder so, und dann ist da ein Button, du willst den klicken, aber gerade wo du klicken willst, verschiebt sich der Button weit nach unten, und du klickst irgendwie woanders hin.

Im schlimmsten Fall auf irgendeinen App-Banner, wo du nicht draufklicken wolltest.

Und dann haben die deine Daten, die du draufgeklickt hast.

Genau.

Und das ist im Prinzip, Und die, äh, und die, solche, solche, so eine Erfahrung, das wird, das ist dadurch verursacht, dass irgendetwas geladen wurde, für den der Platz nicht reserviert wurde im, also das ist, klingt jetzt vielleicht erstmal ein bisschen kompliziert, aber, ähm, wenn man zum Beispiel ein, ein Bild, oder, ich mach jetzt vielleicht nur ein extremeres Beispiel, sagen wir mal, man lädt ein Video, das dauert ja in der Regel noch länger zu laden als ein Bild, ähm, und das Video hat halt irgendeinen gewisse Dimension, und man kann dem Browser im Prinzip mitteilen, hey, hier wird ein Video später geladen, also reservier da diese, keine Ahnung, 1920 mal 1080 Pixel oder irgendwas, und wenn du das aber nicht machst in deinem HTML-Code, wo das Video geladen wird, dann wird einfach kein Platz reserviert, und dann sobald das Video geladen ist, bewegt sich plötzlich alles, verschiebt sich plötzlich alles nach unten und das sorgt dann eben für so etwas, für diese Verschiebung von Elementen auf der Webseite, was eben auch sich negativ auf die User Experience auswirkt und somit auch Teil von Performance ist.

Ganz wichtig dabei ist, ganz kleines Nebendetail ist eben, das ist halt gar nicht zeitbedingt, da geht es halt wirklich nur um den Grad der Verschiebung der Elemente auf der Website und im Idealfall ist der 0. Ja, und das wird gemessen in einer durch eine Metric, die heißt Cumulative Layout Shift, kurz CLS.

Und so, das sind eben im Kurzen die drei Core Web Vitals, die zusammen eine gute Performance für eine Website ausmachen.

Wenn man jetzt zum Beispiel rein die Ladezeit messen mag, dann ist es, finde ich, ganz easy.

Also du misst Anfang und Ende, wann ist die Webseite komplett geladen, mit der Zeit und fertig.

Aber was Google da jetzt angefangen hat zu messen mit den Core Web Vitals, ist ja dann die User Experience, die du dann hast auf der Webseite.

Und so etwas zu messen ist ein Wahnsinn.

Also da musst du ja eigene Metriken erfinden, wie die das gemacht haben, weil es gibt ja keine Einheiten, nach denen du vorgehen kannst, um die User Experience zu messen.

Und deswegen finde ich das mega interessant und eine mega schwierige Aufgabe, das überhaupt zu machen und versuchen dann diese Metriken zu definieren und nach was misst man da und das Ganze.

Deswegen ist es immer gut, wenn man dann nicht das Ranking oder ein gutes Ergebnis beim PageSpeed Score dann im Kopf hat, sondern wirklich dann die User Experience, weil so kann man dann wirklich die Core Web Vitals in einem positiven Licht sehen und nicht so, hey jetzt ist dieser Wert orange oder rot, wie kann ich den grün machen? Sondern, hey, da passt dann anscheinend was nicht mit meiner Website.

Das hat einen negativen Einfluss auf meine Besucher.

Ich sollte mich darum kümmern und nicht, ey, der Wert soll einfach nur wieder grün sein oder so.

Und deswegen finde ich es immer wichtig, wie du das vorher auch schon gesagt hast, von der Seite der User Experience zu sehen und nicht nur, ey, das Zahlen, an welche man schrauben muss und in die Richtung Plugins installieren, um die Werte auszutricksen und das Ganze, sondern wenn man das wirklich versteht, dann will man die ja eigentlich verbessern, weil man dadurch dann den eigenen Besuchern etwas Gutes tut.

Genau.

Und genau, wenn du die Werte austrickst, dann hilfst du eigentlich niemanden, weil du du hilfst deinen Endnutzer nicht, dann das bringt auch nichts, dass du dann irgendwie ein Page Speed Score von 100 hast, weil ich sag mal, das interessiert andere Leute ja nicht unbedingt.

Was für die Endnutzer deiner Website wichtig ist, ist eben wie schnell werden die Elemente geladen, die sie sehen, und wie schnell werden, wie schnell reagiert die Webseite auf die Interaktionen und eben, ja, wie stabil ist die Webseite, dass sich da nicht die Dinge verschieben.

Und bevor wir dann in WordPress-spezifische Themen eintauchen, würde ich gerne noch ein Teil klären, weil wenn man jetzt zum Beispiel den Google PageSpeed Insights Test durchlaufen lässt, dann hat man ja den gesamten Score und dann die Lab-Daten und die Feld-Daten, also die Labor-Daten, die simulierten Daten und die Feld-Daten, die dann manchmal im oberen Bereich über dem Gesamtergebnis angezeigt werden und könnten wir auf die noch ein bisschen eingehen, weil wo ich dann das gelernt habe, was eigentlich der Unterschied ist, habe ich das ganze Thema Ladezeitoptimierung eigentlich viel besser verstanden, weil ich dann einfach angefangen habe, die Metriken korrekt zu interpretieren.

Aber bitte kannst du uns da kurz das aufschlüsseln, was da die Unterschiede sind und auf was man da eigentlich achten sollte? Ja, klar.

Also, wenn man den Page-Speed-Test macht, dann wird ja im Prinzip die URL, die man da eingibt, die wird dann halt live geladen, und die Werte, die man da in diesem Lab-Test, wie du schon sagst, siehst, das sind eben nur die Werte, die konkret diese eine Request, der da gemacht wurde, sowohl für mobil als auch Desktop, Ja, das ist einfach genau dieser eine Wert, der da rauskam, und dabei ist aber wichtig zu bedenken, dass eben die Performance von deiner Website oder diese ganzen Ladezeiten, die ändern sich extrem, für jedes Mal, wenn man die Seite lädt, wird man ein anderes Ergebnis bekommen, Und das kannst du auch schon austesten, mach mal innerhalb von mehreren Stunden den Test mit der gleichen Webseite, ohne da jemals eine Änderung auf der Website zu machen.

Und man wird da sehen, dass das Ergebnis immer etwas anderes ist in Sachen Ladezeit von diesem Lab-Test.

Und deswegen ist es wichtig, diese Daten, die man da sieht, diese Nummern da, die man da sieht, sind nicht unbedingt aussagekräftig, wie gut die eigentliche Performance in der Website ist.

Für diesen Lab-Test würde ich sagen, der Hauptnutzen sind diese Empfehlungen, die da unten, oder sind nicht unbedingt die Empfehlungen, sind im Prinzip diese Punkte, die da stehen, die man an seiner Website verbessern kann.

denn die sind in der Regel nicht variabel, die ändern sich nicht bei jedem Request, das sind im Prinzip einfach so Hinweise, wo man sich vielleicht mal mehr mit beschäftigen sollte auf seiner Website.

Wenn es dann darum geht, die eigentliche Performance einer Website zu messen, dann sind eben diese Felddaten deutlich aussagekräftiger.

Diese Felddaten kommen, wenn sie in dem Page-Speed-Test angezeigt werden, das sind Daten, die kommen von den Nutzern von Chrome, die zu der Datenfassung der Opt-in angeklickt haben, Und das sind im Prinzip, wie alle möglichen Nutzer auf deiner Website die Performance wahrnehmen.

Und das ist, was man eigentlich messen soll, weil wir gehen wieder zurück zu dem Punkt, die User Experience ist ja im Prinzip das Wichtigste in Sachen Performance.

Und, ähm, und das ist auch in einigen Dingen eben wirklich, es ist in vielen Dingen eben wirklich relevant, äh, die eigentliche Nutzererfahrung zu messen, denn unterschiedliche Nutzer haben unterschiedliche Devices, haben unterschiedliche Network Connections, also zum Beispiel, ähm, und da kann es auch oft eben, da kann es auch oft zu Unterschieden führen, je nachdem, wo deine Nutzer sind, was, was, welche Art, ich sag mal, was für Nutzer das sind, ähm, kann es eben zu Unterschieden führen, was man bei seiner Website priorisieren sollte.

Ähm, ich sag mal, wenn alle, wenn alle deine Nutzer auf dem neuesten iPhone, oder was weiß ich, dem wären, dann ist zum Beispiel die Ladezeit wahrscheinlich besser, als wenn sie auf irgendwelchen, äh, 100-Euro-Telefonen sind, ne? Also so, und dann gibt's aber andere Punkte, wie zum Beispiel diese CLS, also diese Layoutstabilität, was ich eben benannt hab, da ist zum Beispiel die Qualität des Geräts nicht sehr wichtig für.

Das heißt, dafür mach ich jetzt mal einen Extremfall, sowas gibt's in der Regel nicht, aber sagen wir mal, alle der Nutzer haben ein super gutes Gerät, Super schnelles Gerät, dann ist eben die Ladezeit wahrscheinlich schon ganz gut.

Und vielleicht ist es dann relativ gesehen wichtiger, sich auf den CLS zu fokussieren.

Wenn das nicht so gut aussieht.

Auf der anderen Seite, vielleicht haben der Nutzer eher irgendwelche schwächeren Geräte, dann ist wahrscheinlich die Ladezeit schlechter.

Und das klingt jetzt vielleicht erstmal etwas verwirrend, aber es ist nicht, es ist gar nicht immer unbedingt genau, es gibt nicht den einen Wert, wie gut deine Website ist, weil einfach für jeden Nutzer kann das anders sein, je nachdem, was die für ein Gerät benutzen, ob die gerade zu Hause im Wi-Fi sind oder irgendwo im Zug im Internet, das kennt man ja sicherlich, dass darauf die Verbindungen schlechter sind, und es gibt einfach nicht den einen Wert, man muss deswegen eben gucken, was für Probleme haben deine Nutzer in Sachen Performance.

Und so kann man dann herausfinden, okay, auf diese Metrik sollte ich mich vielleicht mehr fokussieren als auf andere.

Das war für mich so der Aha-Moment, wo ich dann gemerkt habe, hey, Google misst ja die Daten mit.

Also wirklich in einem Browser.

Das heißt, wenn man jetzt zum Beispiel solche Tricks macht wie, hey, lad das ganze JavaScript erst nach der ersten Interaktion, das bekommt Google da noch mit, wieviel JavaScript im Endeffekt geladen wird und wieviel dann ausgerendert wird und das Ganze.

Und auch wenn man jetzt zum Beispiel Third-Party-Skripte mit einem Cookie-Banner versteckt oder so, dann bekommt das Google ja später, nachdem das die Leute akzeptieren, auch mit, was da ist im Hintergrund geladen wird.

Deswegen kann man da, ich sage jetzt mal, ein bisschen tricksen, aber im Endeffekt, wenn die Feld-Daten wirklich für die Performance der Website ausschlaggebend sind, dann kommt man nicht drumherum, das einfach gescheit zu machen und da einfach sich Gedanken zu machen, was sollte eigentlich nach Buch da sein, was ist in der Realität, wie schaut der simulierte Test aus, aber vor allem wie schauen dann die wirklichen Lab-Daten aus.

Und kann man da irgendwas machen, wenn man zu wenig Traffic hat und die Daten oben noch nicht angezeigt werden, weil die Daten werden erst angezeigt, wenn man wirklich viel Traffic hat, wo man ein, wie sagt man das, kein Mittelmaß, aber einfach den Durchschnitt nehmen kann von den gemessenen Daten in den Chrome-Browsern, aber wie komme ich an die Daten, wenn dieser Bereich oben bei mir noch nicht angezeigt wird? Kann ich mich dann nur auf diesen simulierten Test verlassen oder kann man da irgendwas machen, damit man die Feld-Daten herausfindet oder ungefähr einen Richtwert hat, ob man gut abschneidet bei den Core-Web-Vitals oder nicht? Bevor ich darauf antworte, will ich noch kurz auf dein Beispiel eingehen mit dem Tricksen.

Das ist noch ein guter Perfekt, um nochmal darauf zurückzugehen auf eben Ladezeit und Interaktivitäts-Performance.

Denn wenn man alles JavaScript zum Beispiel, wenn man es erst lädt nach der ersten Interaktion, dann hast du halt, sag ich mal, die Ladezeit ausgetrickst, aber auf Kosten der Interaktivität, weil wenn, sagen wir, die erste Aktion ist dann Button-Klick, und dann wird alles JavaScript geladen, dann wird wahrscheinlich dieser Button-Klick einige Zeit brauchen, bis die Website darauf reagiert, weil man im Prinzip alles da zu diesem Punkt ausgelagert hat.

Das heißt, es ist nicht, es kann zwar manchmal hilfreich sein, bestimmte Dinge tatsächlich zu verzögern, und nicht direkt zu laden, aber gleichzeitig das als allgemeine Lösung, ich meine, wir haben ja schon gesagt, das ist in der Regel, sowas machen Leute in der Regel, um äh, so einen Algorithmus auszutricksen, aber ähm, für, aber für den Endnutzer hat man im Prinzip das Problem nur an eine andere Stelle verschoben.

Ähm, und, und der einzige Grund, warum man den Page Speed Score damit austricksen kann, ist eben, weil das eben, wie gesagt, ein simuliertes Request ist, Das heißt, da wird im Prinzip fast nur, da kann halt fast nur die Ladezeit gemessen werden und ein ganz bisschen irgendwelche Interaktivität, die am Anfang passiert, weil ja eben ein simuliertes Request interagiert nicht mit der Website, aber deine Endnutzer, die klicken Buttons, die scrollen und sowas und das macht halt eben dieses simulierte Google Requests nicht und so kann man damit den Score austricksen, aber wie gesagt, das bringt einem, das bringt einem selbst eigentlich nichts und den Endnutzern wahrscheinlich schadet es denen eher, als dass es ihnen hilft.

Also man kann dann eher dem Kunden ein Screenshot schicken, schau deine Webseite ist schnell, es ist im grünen Bereich, der gesamte Score, bitte abhaken, Rechnung schicken und fertig.

Aber im Endeffekt, wenn man sich damit näher beschäftigt und dann einmal abwartet, bis die Feld-Daten kommen, können dann andere Ergebnisse auf einen zukommen und dann kann der Kunde unter Umständen enttäuschen.

Genau, die Feld-Daten, die Feld-Daten selber, aber diese drei Metriken, LCP, INP und CLS, die haben auch ähm, bestimmte Werte, wo man sagt, wenn der Wert besser als das ist, dann hast du im Prinzip eine gute Performance.

Ähm, und, ähm, ja, das sind halt, äh, ich, oder, da werde ich jetzt nicht im Detail drauf eingehen, was genau diese Werte sind, aber man sieht dann, wenn man diese Felddaten aufgelistet sieht, dann sieht man in der Regel vielleicht so einen Balken mit grün, gelb, rot, und wo dann genau dein Punkt ist, wird dann, ist dann irgendwo auf diesem Spektrum und im Idealfall ist es überall im grünen Bereich.

Dann, wenn, sobald das so ist, kann man sagen, dein Website hat eigentlich eine gute Performance.

Es ist aber eben wichtig, dass es immer noch ein Spektrum, das heißt, du kannst wahrscheinlich die Performance immer noch verbessern, um sie noch besser zu machen.

Es gibt dann keinen, es gibt eben keinen Page Speed Score 100. Also das wäre, das wäre, wenn alles auf Null ist beim Core Web Vitals, aber das ist unmöglich, weil eben ein Website zu laden braucht Zeit.

Im Idealfall möglichst wenig Zeit, aber es braucht halt Zeit.

Also die ganzen Screenshots auf LinkedIn und da war ich auch dabei, die dann gepostet haben, so hey, mein Page Feed Score ist auf 100. Das ist eigentlich, ja, nice to have und um das mal herzuzeigen, aber im Endeffekt kann es nie auf 100 sein, weil irgendeine Zeit geht immer in Anspruch, damit die Website geladen werden kann.

Genau und es ist einfach schwer zu sagen, ob diese 100 beim PageSpeed Score legit sind, weil man so viel Effort in seine Website-Performance reingesteckt hat, dass eben auch die eigentlichen Core Web Vitals gut sind oder vielleicht hat man es nur gemacht, um irgendwie den Wert hochzukriegen und da ist der, das ist deutlich einfacher als die eigentlichen Core Web Vitals zu verbessern.

Ja und jetzt werden wir da noch ein bisschen technischer, weil damit wir auch das Thema abschließen, hast du mir auch im Vorgespräch gesagt, dass es ja auch dieses Web Vitals JS Package gibt.

Genau.

Und dann auch den Crux Report, RAM und so weiter.

Also das waren jetzt viele Buzzwords oder nicht Buzzwords, viele Fachbegriffe, aber könnte man das kurz zusammenfassen, damit wir dann ins nächste Thema eingehen, damit die Leute überhaupt einen Ansatz haben, eh, wie kann ich überhaupt an die Feld-Daten rankommen? Genau, also die, wenn die Daten einem beim PageSpeed-Test dargestellt werden, dann sind das Daten von CrUX, also Chrome User Experience Report, das ist dieser Report, wo Google die die Daten von den, die anonymisierten Daten von den Nutzern bereitstellt.

Im Prinzip, ja, so eine Zusammenfassung für jede Website, die darin vertreten ist, kann man dann sehen, da kann man dann eben sehen, ja, wie gut war mein LCP, wie meine INP und CLS und auch ein paar andere Metriken.

Aber, wie gesagt, da haben wir jetzt schon gesagt, das hat eben, das haben eben nur Websites, die ab einem gewissen Popularitätsgrad, wenn man es nicht hat, dann muss man im Prinzip, dann muss man diese Daten selber sammeln.

Diese Daten nennt man dann auch RUM, Real User Metrics, und die kann man mit bestimmten Tools zum Beispiel erheben, also auf, und eine Möglichkeit davon, Open Source das zu lösen, ist, es gibt ein Web Vitals JavaScript, es gibt eine Web Vitals JavaScript Library, Die wurde auch ursprünglich von den Leuten geschrieben, die auch direkt an den Core-Web-Vitals arbeiten.

Kann man sich auf GitHub zum Beispiel runterladen oder anderswo.

Und das ist ein ganz kleines JavaScript-Modul, was man in der Webseite einbinden kann, was dann automatisch diese Metriken, LCP, INP, CLS und auch andere, wie man will, eben, es gibt auch andere Web-Vitals, die vielleicht weniger wichtig sind, aber die man auch da noch erheben kann.

Diese Daten werden dann da alle erhoben, komplett konform mit den Standards, wie das gemacht werden soll, und man kann die dann an irgendeinen Analytics-Provider senden, zum Beispiel.

Das kann Google Analytics sein, das kann aber auch irgendein anderer Analytics-Provider sein, also das Web Vitals JS selbst stellt da im Prinzip nur eine API bereit, um diese Daten zu erheben.

wo die dann hingesendet werden, ist da nicht selbst integriert.

Das heißt, da kann man sich mal die Dokumentation angucken, wie man das dann mit verschiedenen Providern verbinden kann, und ja, und so kann man dann die Daten sich später selber angucken, von den eigentlichen Nutzern, die man hat.

Es gibt auch Firmen, die das für einen machen, die halt irgendwie komplette Solutions anbieten, wo man dann dafür bezahlen kann, dass die es einem lösen, dass man es nicht selber aufsetzen muss.

Das sind im Prinzip zwei Möglichkeiten, um an diese Daten zu kommen.

Ja, ich werde auf jeden Fall alle Ressourcen, die wir jetzt erwähnt haben, unten verlinken.

Deswegen, falls dich das interessiert, die Weltdaten jetzt frühzeitig anzuschauen, wie das alles dann, wie die Website performt und was dann diese Werte sind, dann werde ich das unten verlinken, kannst dir gerne anschauen, was das dann ist und wie du das verwenden kannst.

Und jetzt wäre es mega cool, wenn wir einfach in WordPress eintauchen könnten, in das, was sich alles in WordPress getan hat über die letzten Jahre.

Und ich meine, ich werfe dich da jetzt einfach ins kalte Wasser, aber könntest du uns vielleicht da kurz mitnehmen, so hey, was ist die Entwicklung in Bezug auf Performance bei WordPress gewesen über die in den letzten Jahren, was hat sich getan und ja, was passiert da alles im Hintergrund bei WordPress eigentlich? Ja, wir haben, ich hab, bin ja schon am Anfang kurz darauf eingegangen, unser Team bei Google hat im Prinzip vor, oder im späten 2021, das WordPress Core Performance Team mitbegründet und in diesem Team sind halt unter anderem wir und einige andere Contributors arbeiten zusammen an eben die Performance von WordPress zu verbessern und auch ein wichtiger Punkt davon ist auch eben mehr dieses Bewusstsein zu schaffen für Core Web Vitals, wie man die Performance richtig misst und generell auch für eben die Verbesserung, die wir in WordPress Core machen wollen, die Performance zu messen und da gehen wir nochmal kurz auf das Messen zurück, das heißt, wenn du wenn du zum Beispiel eine, wenn du irgendeine Performance Verbesserung machen willst, dann ist es eben wichtig, erstmal zu gucken, in so einem Lab, in so Lab, Labortest, sag ich mal, wie viel verbessert das wirklich, können wir wirklich damit rechnen, dass das die Performance verbessert, und wenn ja, wie viel, wir haben dann auch, wir haben dann auch öfters, am Anfang eines Jahres, oft irgendwie verschiedene Ideen gehabt, das könnten wir machen, das könnten wir machen, um die Performance zu verbessern, und dann können wir, haben wir oft diese unterschiedlichen Ideen alle mit, alle im Labor gemessen, so, wie viel würde das die Performance besser machen, und auf dieser, eben auf dieser Basis können wir dann priorisieren, was sollten wir wirklich umsetzen, was ist am wertvollsten umzusetzen, denn natürlich gibt's extrem viele Ideen, um Performance zu verbessern, aber es ist eben, wir haben ja alle, Alle Ressourcen, die wir haben, sind endlich, und deswegen muss man immer gucken, was ist am meisten wert jetzt, dass wir wirklich daran arbeiten.

Und dann eben auch, wenn dann irgendetwas im WordPress Core released wird, dann wollen wir auch danach, messen wir danach auch immer ja so gut, wie es möglich ist, wie viel hat das jetzt denn eigentlich die Performance verbessert.

Und ich kann jetzt mal ein paar kurze Pointer geben, über die letzten Jahre, was da so zum Beispiel passiert ist.

Einer der Dinge war zum Beispiel, im WordPress 6.3 wurde zum Beispiel Fetch Priority eingeführt.

Also, das ist ein Attribut, was besser kontrolliert, was wer auf seinem Browser sagt, wann das wichtigste Image, das wichtigste Bild auf der Seite geladen werden soll.

Und das ist zum Beispiel einer dieser Punkte, das ist sehr wichtig für die LCP-Metric, also für die eigentliche Ladezeit, die der Nutzer erfährt, denn wenn eine Webseite gerendert wird vom Browser, dann muss der Browser erstmal das Layout rendern, um zu wissen, welches Bild ist denn jetzt das Wichtigste, und das muss dann ja wirklich zuerst geladen werden.

Aber wir reden hier ja von Millisekunden, oder von Hunderten von Millisekunden, das heißt, klingt erstmal wieder kurz, aber es macht einen großen Unterschied später bei der eigentlichen Performance, das heißt, dieser Layout-Rendering-Prozess, der braucht halt auch eine gewisse Zeit, und erst danach weiß der Browser, welches Bild ist das Wichtigste auf der Seite.

Und mit dem Fetch Priority Attribut zum Beispiel, kann man dem Browser mitteilen, dieses Bild hat die höchste Priorität, lad das sofort, bevor du überhaupt das Layout gerendert hast, und was dann eben dafür sorgt, dass sobald das Layout gerendert ist, auch das Bild hoffentlich schon geladen ist, oder zumindest schneller, weil es schon währenddessen geladen wird.

Das ist eine dieser Features, die in WordPress 6.3 dann gelandet waren, dass das automatisch versucht, eben dieses Bild zu identifizieren und direkt dem Browser mitzuteilen, und das hat dann auch entsprechend für einige Performance-Verbesserungen geführt.

Dann gibt's auch, es gibt auch ab und zu eben viele, es gibt eben viele kleinere Dinge, wo wir irgendwelche Bugs finden, oder, ja, nicht Bugs finden, wo wir irgendwelche kleineren Dinge verbessern, oder beheben, die die Performance verbessern können, zum Beispiel haben wir irgendwann gemerkt, dass eben dieses Emoji Loader Script.

Ich weiß nicht, wer von euch das kennt, aber es gibt, WordPress bindet immer ein Emoji Loader Script ein, out of the box.

Und dieses Emoji Loader Script hatte einen gewissen Prozess da drin, der ab und zu länger als 50 Millisekunden dauern kann, und das ist dann genau dieser Threshold, wo im schlimmsten Fall eine dieser, eine Interaktion des Nutzers wirklich negativ geblockt, blockiert werden kann dadurch.

Und das war eben dann zum Beispiel etwas, das wir dann in einem WordPress Release mal behoben haben, was dann auch, was dann eben die Interaktivität von solcher Seiten verbessert.

Und ja, eine späteren Release, WordPress 6.5, gab's dann zum Beispiel Performance Translations, da wurde komplett auf Server-Seite die Übersetzungs-Engine von WordPress überarbeitet, was dann eben effizienter macht, Übersetzungen zu laden, das heißt, alle Websites, die nicht auf en-us sind, sind dann davon im Prinzip auf Server-Seite schneller geworden.

Das sind so ein paar Beispiele aus den letzten Jahren, was wir eben im Performance-Team in WordPress eingebracht haben.

Spoiler, in zwei Wochen kommt ja WordPress 6.8 raus.

Also zwei Wochen, also wir nehmen das ein bisschen früher auf, deswegen ist 6.8 wahrscheinlich schon draußen, aber wollte das nur ein bisschen reinschieben einfach nur.

Ja, also und jetzt im aktuellen 6.8 Release, da kommt dann ein neues Feature, das heißt Speculative Loading.

Das im Prinzip, das verbessert die Performance, indem es erkennt, ja, indem es im Prinzip erkennt, auf gewisse Art und Weise, wo wird der Nutzer jetzt wohl als nächstes draufklicken, oder auf welche URL wird der Nutzer jetzt wohl als nächstes navigieren, und es kann dann diese URL etwas früher anfangen zu laden.

Wenn du zum Beispiel auf einen Link klickst, auf eine WordPress-Seite, dann ist in der Regel ziemlich klar, dass du diese Seite, die da verlinkt ist, besuchen willst.

Und der eigentliche Klick, bis die Navigation erfolgt, da reden wir aber wieder von einigen Millisekunden, hundert, vielleicht hunderten Millisekunden, und durch Speculative Loading fängt dann eben der Browser sofort an, die Seite zu laden.

Das heißt, man spart sich dabei einige 100 Millisekunden im Idealfall ein, was dann die Performance von allen Requests im Prinzip verbessert.

Außer dem ersten Request, wenn du auf einer Website landest, da wusste der Browser nicht vorher, wo du dahin kommst, aber im Prinzip hilft es bei der Performance für alle möglichen Navigationen auf deiner eigenen WordPress-Seite.

Ja, weil leider in WordPress habe ich oft das Gefühl, dass sich das etabliert hat, so ja, installier dir ein Caching-Plugin und danach wird das irgendwie schon und da finde ich mega cool, dass du uns das jetzt erklärt hast, was da alles im Hintergrund passiert ist über die letzte Zeit, weil da merkt man wirklich so alleine, was das im Performance Lab Plugin passiert, also dass man jetzt sich dann auch die Möglichkeit aktivieren kann, ohne Third-Party-Services, dass man jetzt WebP-Formate, AVIF-Formate und so weiter generieren kann auf dem Server selbst und nicht über irgendein Third-Party-Tool, wo man sich dann noch Credits kaufen muss und so weiter.

Deswegen finde ich es mega cool, dass WordPress in diese Richtung geht und dass ihr da so einen großen Wert drauf legt, da einfach das voranzuschieben, diese Themen.

Und an der Stelle vielen Dank dafür, weil ohne euch würde wahrscheinlich WordPress nicht so schnell funktionieren, wie es funktioniert und das sind dann eben diese Details, die du erzählst auch mit dem Emoji-Skript, also an das würdest du gar nicht denken und das ist eine Kleinigkeit, die im Endeffekt wahrscheinlich null Auswirkungen hat für den End-User, aber wenn du zehn von solchen Kleinigkeiten findest, dann hat das dann schon eine Auswirkung und das ist, finde ich das, worauf es dann wirklich ankommt.

Und auf das Performance Lab Plugin, was kann das eigentlich noch, weil das hat ja, finde ich, ein riesen Potenzial, da Sachen zu implementieren, die WordPress an sich noch nicht hat.

Weil da habe ich auch gesehen, zum Beispiel die Option mit dem Object Caching und so weiter.

Ist das noch immer aktuell, arbeitet sie dran oder was sind jetzt so die aktuellen Features, was ist die Zukunft von dem Performance Lab Plugin und wenn das sich irgendwie ausprobieren, wenn das irgendwer ausprobieren möchte, worauf kann er, worauf kann er oder sie sich freuen? Genau, also das Performance Lab Plugin, kann ich noch kurz ein bisschen Hintergrund zu geben.

Das ist ein Plugin, was das Performance Team eben etabliert hat und auch maintained.

Es hat im Prinzip am Anfang als Plugin gestartet, aber es ist mehr oder weniger eine Suite von Plugins.

Also, es gibt das eigentliche Performance-Lab-Plugin und das, wenn ihr schauen wollt, was es dafür, was die ganzen unterschiedlichen Features sind, die es da gibt, dann würde ich euch empfehlen, auch das Performance-Lab-Plugin mal zu installieren.

Das ist aber im Prinzip dann so ein Hub, worin man die ganzen anderen Features listet und diese aufgelistet sieht und sie dann einzeln aktivieren kann.

Und diese Features selbst sind aber auch WordPress-Plugins, also eigene WordPress-Plugins.

Das heißt, dieses Performance-Lab-Plugin ist im Prinzip so das Mutter-Plugin, sag ich jetzt mal, wo die anderen Plugins von verlinkt sind und was es einfach macht, eben die ganzen die ganzen Features zu aktivieren.

Man kann aber auch einzelne von diesen eins unter Plugins sich installieren, um nur die etwas spezielle Feature zu bekommen.

Ja, wie du schon gesagt hast, eins der ersten Plugins war eben das Modern Image Formats Plugin, das eben erlaubt WebP zu generieren, mittlerweile auch AVIF, was ja noch deutlich verbessert ist, ein verbessertes Format ist im Vergleich zu WebP in Sachen Qualität zu Dateigroße Verhältnis.

Ähm, dann, ähm, ja, es gibt, äh, es gab da das Speculative Loading Feature, wovon wir gerade erzählt, äh, wovon ich gerade erzählt habe, das jetzt in WordPress Core kommt, ähm, das war zu Beginn auch ein Plugin, also es ist auch, das ist auch immer noch ein Plugin, ein Plugin, als, als Teil dieses Performance Lab Programms, ähm, ähm, denn der, der Grundgedanke mit diesem Performance Lab, ähm, Programm ist, ist, dass wir diese Features im Idealfall irgendwann gerne in den WordPress-Core mergen werden würden.

Und in Plugin-Form erlaubt es eben, dass Nutzer das testen können, dass es direkt im Core gemerged werden muss.

Und so kann man dann auch Feedback bekommen von den Nutzern und sehen, was da vielleicht noch verbessert werden muss.

Und so ist zum Beispiel jetzt bei Speculative Loading gekommen, dass es in den letzten Monaten in den WordPress-Core gemerged wurde.

Das Plug-in selbst wird weiterhin existieren, das Speculative Loading Plug-in wird auch weiterhin noch existieren, denn es hat ein paar extra Optionen, wie man, dass man die Speculative Loading, dass man das Speculative Loading Verhalten umkonfigurieren kann, zum Beispiel.

Das hat halt WordPress Core noch nicht, und zusätzlich hat auch das Speculative Loading Plug-in ein Standard, als Standardeinstellung eine Konfiguration, die noch deutlich performanter ist als die von WordPress Core.

Das haben wir jetzt aber erstmal aus Risikominimierung erstmal noch nicht in Core reingetan.

Das Standardverhalten im Core ist erstmal etwas, ich sag mal, konservativer.

Und beim Plugin ist es aber noch deutlich performanter, und wir hoffen dann natürlich, dass in der Zukunft vielleicht in 1, 2, 3 WordPress Releases mehr, dass wir dann noch mehr Daten bekommen und Feedback bekommen, dass vielleicht dieses Verhalten von dem Plugin auch noch in den Core übernommen werden kann.

Aber jetzt gibt es ja diese Regel oder diesen Mythos, der sich etabliert hat, je weniger Plugins, desto besser.

Wenn das jetzt eine Plugin-Suite ist von diesen Performance-Optimierungen, wenn ich das jetzt mal so grob zusammenfassen kann, dann installiert man sicher drei bis fünf verschiedene Plugins, aber irgendwo habe ich gehört damals so, irgendwer hat mir gesagt, je weniger Plugins, desto besser und das spricht dann eigentlich gegen diese Regel.

Aber wenn man sich da ein bisschen unter der Haube das anschaut, was versteckt sich hinter dieser Regel, je weniger Plugins, desto besser? Ist es so, dass das einfach von Haus aus immer sein muss, also verwende nur deine fünf Plugins deines Vertrauens oder wenn man das versteht, wieso die Regel erschaffen wurde, kann man dann auch die Regel brechen? Ich glaube, ich würde im Großen und Ganzen sagen, dass das ein Irrglaube ist, dass weniger Plugins einem helfen.

Es kommt immer genau darauf an, was die einzelnen Plugins machen, wie das die Performance einen beeinflusst und da kann man leider nichts Konkretes zu sagen, dass das jedes Plugin ist anders, ähm, in, ich sag mal, wie gut es bestimmte Performance-Kriterien beachtet oder nicht beachtet.

Ob man, ob man jetzt, ich kann jetzt, ob man jetzt zum Beispiel ein Plugin hat, was 20 Features hat, oder 20 Plugins, die alle jeweils ein Feature haben, sofern die Implementierung von diesen Features alle genau gleich ist, dann macht es wirklich 0,0001% Unterschied oder so.

Also, es ist irrelevant für die Performance, ob man es so oder so hat.

Ich persönlich bin ein Fan von Plugins, die eine Sache tun, und eine Sache, ich sag mal, in Englisch sagt man immer, one thing and one thing right.

So, das ist, das finde ich, ist oft ein besserer Weg, eben dann qualitativ hochwertige Plugins zu bekommen, weil sobald du 20 Dinge in einem Plugin tust, wird das Plugin komplexer, und es ist dann, und einfach, es wird immer, es wird bei mehr Features und bei mehr Komplexität, wird es eben auch komplizierter, das weiterhin performant zu halten, und weiterhin bei all diesen Features auf diese unterschiedlichen Aspekte zu achten.

Es gibt natürlich oft, es gibt natürlich oft große Suites, wo irgendwie ein Plugin ganz viele Features hat, und da muss man dann aber eben in jedem Einzelfall darauf gucken, wie ist das, was macht das für meine Performance, hat das trotzdem alle möglichen Performance Best Practices beachtet oder lädt das irgendwie 20 Skripte auf jeden Admin, auf jeden Frontend Screen und dann sollte man sich das zweimal überlegen.

Ja, voll weil das, warum sich diese Regel, glaube ich, etabliert hat, ist, wenn ein Kunde sich komplett nicht auskennt, dass man dem sagt, so hey, installier nicht blind dieses Plugin, also je weniger Plugins, desto besser, aber wenn man sich ein bisschen schon damit beschäftigt mit dem Plugin und weiß, was da ungefähr geladen wird, also ich sage jetzt mal, wenn das Plugin für das Suchen und Ersetzen von Texten in der Datenbank aktiv ist, wird das keine Auswirkungen auf die Ladezeit der Website haben, weil das halt nichts im Frontend dazugibt an JavaScript, CSS und Daten oder in den Render-Prozess von WordPress irgendwie eingreift.

Und da muss man sich ja wirklich ein bisschen damit beschäftigen, die Materie verstehen, damit man dann einschätzen kann, hat dieses Plugin einen positiven oder negativen Einfluss? Hast du da für dich oder können wir da für die Zuhörer und Zuschauerinnen da vielleicht irgendwelche, eine grobe Regel definieren, wo man, wie man das einschätzen kann, ob ein Plugin sich negativ auf die Ladezeit meiner WordPress-Website auswirken kann, oder muss man das einfach technisch verstehen und nur dann kann man das ungefähr einschätzen? Puh, das ist eine komplizierte, ist ein kompliziertes Thema.

Ich wünschte, ich hatte eine gute Antwort, aber in der Regel ist es leider so, dass man möglichst mehr im Detail schauen muss, was macht das Plug-in eigentlich under the hood.

Und was man versuchen kann, ist zum Beispiel, bevor man ein Plug-in aktiviert und nachdem man das Plug-in aktiviert hat, könnte man zum Beispiel mal solche, so einen Page-Speed-Test laufen lassen und auch mal nicht unbedingt auf die Daten zu gucken, sondern eher, ob da irgendwelche Empfehlungen neu aufploppen, nachdem man das Plugin installiert hat, weil das wäre zum Beispiel ein Signal, dass das Plugin irgendwas nicht macht, was nicht gut ist für die Performance, aber das ist immer noch, ich sag mal dann, das ist zumindest eine Möglichkeit, da so eine Idee zu bekommen, ohne konkret in den Code des Plugins zu gucken.

Ansonsten, wenn man, auch wenn man zum Beispiel mal den HTML Code angucken will, könnte man schauen, was werden da für Skripte geladen und da könnte man dann vielleicht auch in seiner Browser-Konsole, könnte man da noch genauer reingucken, was werden da für Skripte geladen, wie groß werden die, da gibt es schon einige Möglichkeiten, aber es gibt leider nicht so eine Regel, wo man irgendwie sagen kann, das und das ist problematisch bei einem Plugin, ist es schwierig allgemein zu machen.

Ja, bei den Caching-Plugins an sich, weil ich habe halt eher den Eindruck, hier ein guter Page-Speed-Score ist dann eher so eine Nebenwirkung, so ein Nebeneffekt, wenn man alle Sachen gut macht, sauber aufsetzt und auf eine gute User-Experience schaut im Frontend, dann wird automatisch ein guter Page-Speed-Score rauskommen, da muss man die nicht extra irgendwie hochschrauben oder hochkitzeln.

Und da ist, finde ich, das, welche Rolle dann Caching Plugins spielen.

Das ist, finde ich, auch wie so ein Pflaster, was man dann auf die Symptome draufkleben kann.

Oder einfach so diese Cherry on Top, die man dann so drauf geben kann und so, ich habe alles schön und sauber aufgesetzt.

Aber um das noch ein bisschen zu verbessern oder eine Spur zu tunen, kann man dann auch eben Caching-Plugins verwenden mit den ganzen Zusatzfeatures, mit dem Optimieren von CSS und JavaScript und so weiter.

Das packe ich jetzt mal auch in den Begriff Caching-Plugins, weil das einfach, glaube ich, umgangssprachlich auch verwendet wird in der Hinsicht, dass in einem Caching-Plugin nicht nur Caching inkludiert ist, sondern auch andere Optimierungen.

Wie gehst du mit dem Thema um? Ist das so, dass du das anders siehst? Siehst du das ähnlich oder würdest du das von einer anderen Perspektive betrachten? Ja, also in Sachen Caching, es stimmt ja schon, was du sagst, dass Caching-Plugins beinhalten oft nicht nur Caching als Features.

Oder es gibt oft Plugins, die vielleicht, vielleicht haben die mal vor 10, 15 Jahren als Caching-Plugin angefangen und sind dann aber immer mehr zu einem allgemeinen Performance-Suite, zu einer allgemeinen Performance-Suite geworden und haben dann solche Features wie JavaScript minimieren und sowas, ne.

Also, wenn man konkret auf Caching selbst, dazu würde ich sagen, wichtig dabei ist zu bedenken, dass, wie du schon sagst, es ist ein Pflaster.

Ich würde sagen, es ist ein nützliches Pflaster, aber man muss trotzdem wissen, wofür ist es ein Pflaster.

Und zwar Caching, das eigentliche Caching-Feature eines Caching-Plugins sorgt ja zum Beispiel in der Regel dafür, dass dann, ja, das sorgt im Prinzip dafür, dass der ganze Ladeprozess von WordPress selber minimiert wird und man einfach statisches, sagen wir mal, statisches HTML bekommt und das ist deutlich schneller zu laden.

Es ist aber wichtig zu bedenken, dass das nur die Ladezeit auf dem Server verringert.

Auf dem Server, also beim Hosting-Anbieter oder so, da wird dann, sagen wir mal, da wird dann die Ladezeit verringert.

Und das ist definitiv nützlich, weil um auf Server-Seite die Ladezeit zu verringern, da gibt es ansonsten im Prinzip nur zwei Möglichkeiten.

Du bezahlst mehr für deinen Hoster, oder du musst irgendwie ganz klein klein an WordPress Core und allen möglichen Plugins versuchen, irgendwelche serverseitigen Prozesse zu verkürzen, aber das haben wir auch teilweise, da muss ich kurz einschieben, haben wir auch bei WordPress Core eine Zeit lang versucht, aber und auch eben da einige auf dem Papier Erfolgsresultate gehabt, aber es hat nicht sehr viel gemacht im Endeffekt an der Performance der eigentlichen WordPress-Website, sodass wir dann diesen Effort, diese Priorität irgendwann ein bisschen eingestampft haben, weil es einfach nicht genug Wert gebracht hat und im Prinzip, ich kann das jetzt nochmal, um jetzt nochmal darauf zurückzugeben, ein Caching-Plugin verbessert eben die Server-seitige Performance, aber ganz viel von der eigentlichen LCP-Performance ist Client-seitig, Das heißt, wenn deine, wenn das HTML schon beim Endnutzer angekommen ist, dann müssen ja noch JavaScript geladen werden, CSS geladen werden, das Layout muss gerendert werden, die Bilder und sonst was, äh, äh, Schriftarten müssen geladen werden eventuell, Da gibt's ja ganz viele Dinge, die dann noch geladen werden, und dabei hilft Caching gar nicht.

Ähm, also, das Caching an sich, ähm, hilft dabei nicht.

Also, Browser Caching würde vielleicht helfen, aber auch erst beim zweiten Request, aber nicht beim initialen.

Genau.

Aber das konkrete Caching, was man ja von einem Caching Plugin zum Beispiel bekommt, das wäre nur auf Serverseite, das heißt, das ist dann dabei im Prinzip nicht relevant.

Und, ähm, ja, das, wie gesagt, ich sag nochmal, das ist, es ist ein nützliches Pflaster, denn zum Beispiel, sagen wir mal, du hast eine, sagen wir mal, deine Website braucht drei Sekunden zu laden, komplett im LCP, für die LCP-Metric drei Sekunden, Und sagen wir mal, davon ist eine Sekunde, die, oder dafür sagen wir mal, dafür ist 1,5 Sekunden die Serverseitige Zeit.

Dann installierst du vielleicht irgendwie Caching, eine Caching-Lösung, und so hast du dann auf Serverseite, sagen wir mal, nur noch 500 Millisekunden statt 1,5 Sekunden.

So hättest du dann deine Ladezeit auf, von 3 Sekunden auf 2 Sekunden verkürzt.

Das heißt, das ist gut, aber du hast dann nicht deine Performance-Probleme alle behoben.

und du hast nur auf der Server-Seite im Prinzip die Performance-Probleme deutlich verringert.

Ja, und andere Features, die solche Plugins oft haben, wie du schon sagst, zum Beispiel JavaScript minimieren oder CSS minimieren, da muss man immer, ich finde, da muss man wieder auf den Einzelfall schauen, wie viel das nützt oder wie wenig es nützt.

Ich glaube, bei vielen traditionellen WordPress-Seiten ist es schon hilfreich, eben wenn, wenn, das kommt, da kommt es aber wieder einfach nur darauf an, wie die Plugins und das Theme, was man nun nutzt, selber dem Performance Best Practices folgen oder nicht.

Im Idealfall machen sie das, und dann braucht man so ein Performance Optimierungs-Plugin eigentlich nicht, weil Plugins selber schon sein JavaScript und CSS im Idealfall minifizieren sollten, zum Beispiel.

Ich weiß, andere Dinge, die oft solche Performance-Plugins beinhalten, ist zum Beispiel JavaScript und CSS, mehrere Dateien in eine Datei zu verbinden.

Das gab's, das ist historisch bedingt, das war irgendwann mal eine Performance-Best-Practice, aber heutzutage nicht mehr.

Das heißt, wenn ihr heute in irgendeinem Plugin diese Option seht, dann würde ich empfehlen, die nicht anzuklicken.

Ist das einfach wegen dem HTTP 2 oder 3, dass das alles in einem Tunnel halt geschickt werden kann? Genau.

Bevor es HTTP 2 gab, da war es mal so, dass man möglichst wenig Dateien laden sollte, aber heutzutage macht das eigentlich keinen großen Unterschied mehr und es ist sogar in gewisser Hinsicht besser, im Gegenteil sogar besser, mehrere kleinere Dateien zu laden.

Ähm, ganz wichtiger Punkt dabei ist nämlich, wo werden diese Dateien geladen? Das heißt, das ist, und das finde ich, ich glaube, da würde ich sagen, das ist meiner Meinung nach einer der größten Performance-Probleme in WordPress, die man oft sieht, ist das, wenn Plugins oder Themes irgendwie all sein JavaScript in eine große Datei packen, dann wird diese eine Datei ja auf jeder URL im Frontend geladen.

Und da hast du Fehler.

Sagen wir, du hast da irgendwie, vielleicht hast du da irgendwas drin, wie man das mobile Menü lädt, oder du hast da irgendeinen Button, um nach oben zu scrollen, oder sowas, der dynamisch erscheint, oder versteckt wird, oder, aber das sind, du hast dann teilweise Features, die sind nur auf einzelnen Seiten wichtig, aber du lädst trotzdem dieses JavaScript auf allen URLs deiner Website, und das sorgt dann im Prinzip dafür, dass unnötig JavaScript geladen wird.

Es wäre dann eben besser, nur das JavaScript für jedes einzelne Feature zu laden auf nur den URLs, wo das jeweilige Feature benutzt wird.

Und da spielt uns natürlich dann der neue Blockeditor von WordPress in die Hände, weil bei dem Classic Editor mit den klassischen Themes und so weiter wurde meistens einfach alles geladen.

Und jetzt kann man mit den Blocks bestimmen, welches JavaScript, welches CSS zu welchem Block gehört, und dann wird im Frontend halt nur das CSS, nur das JavaScript von den jeweiligen Blocks dann ausgespielt.

Genau, da würde ich, also diese neue, es gibt, also das ist ja gar nicht mehr so neu, aber seit, was weiß ich wie lange, seit drei Jahren oder so, gibt es ja jetzt das Full-Site-Editing, dass man eben Block-Themes haben kann, und die sind aus Performance-Sicht wirklich sehr sehr hilfreich und sehr effizient.

weil dann eben das gesamte Theme aus Blocks besteht und diese Blocks haben im Prinzip als Best Practice in der Block, in der Implementierung schon eingebaut, dass die einzelnen JavaScript-Dateien und CSS-Dateien per Block definieren können.

Und so kann dann WordPress automatisch sehen, ok, welcher Block ist hier, welche Blocks sind hier auf der Seite, und dann nur die CSS- und JavaScript-Dateien laden, die für diese Blocks wichtig sind.

Und so hast du im Prinzip wirklich die ungenutzte JavaScript ziemlich minimiert.

Und das wäre jetzt zum Beispiel ein, ich weiß, es ist ein großer Prozess, um von einer klassischen WordPress-Theme-Seite auf eine Block-Theme-Seite umzuziehen, also es ist ein großes Investment.

Aber an sich kann ich es aus Performance-Sicht definitiv empfehlen.

Und da, wenn man, oder gerade wenn man jetzt eine neue Seite anfangen würde, dann würde ich empfehlen, mit einem Block-Theme zu beginnen.

Da du dann viele von diesen Dingen, für die du vielleicht sonst irgendein Performance-Plugin installieren würdest, was auch in einem gewissen Sinne immer irgendwie ein Pflaster ist für verschiedene Probleme, ähm, brauchst du dann oft nicht mehr.

Also, Caching auf Serverseite bleibt wichtig, ähm, wie gesagt, es behebt nicht all deine Probleme, aber es ist trotzdem ein wichtiger Bestandteil, ähm, aber wenn du, aber wenn du zum Beispiel, wenn du ein Block-Theme benutzt, ähm, und dann auch idealerweise Plugins, die Blocks, die das Verhalten von Block-Themes unterstützen im Prinzip, dann brauchst du wenig, dann brauchst du eigentlich kein extra Performance-Plugin, was irgendwie Dateien minifiziert oder besser lädt oder so, weil WordPress Core das dann schon richtig macht eigentlich.

Ja, und diese ganzen Caching-Plugins, die wirklich so eine Performance-Suite an Features mit sich bringen, das ist, finde ich, dann auch immer so eine Medaille mit zwei Seiten.

Also einerseits cool, weil Plugins wie zum Beispiel WP Rocket, da kann man einmal die Option anhaken, das JavaScript erst nach der ersten User-Interaktion laden, also wenn jemand mit der Maus irgendwas anklickt, die Maus bewegt oder scrollt und so weiter, aber dann gibt es ja auch die Realität von den WordPress-Projekten, dass zum Beispiel Elementor ganz oft verwendet wird als Page-Builder und da habe ich dann die Erfahrung gemacht, okay, bei den Block-Themes ist das super, weil da kann ich zum Beispiel das Feature aktivieren, aber das JS, was für das Burger-Menü zuständig ist, für das mobile Burger-Menü, wo man anklickt und dann kommt das Dropdown-Menü für Mobilgeräte, dann kann ich das als Ausnahme hinzufügen, damit wenn dann der User einfach auf dem Handy auf das Burger-Icon klickt, dass nicht erst dann das JavaScript geladen wird, sondern für dieses spezielle Element, das JavaScript schon da ist, aber bei diesen komplexen Page-Buildern wird das zum Teil auch schon in separaten Javascript-Dateien geladen, aber diese Javascript-Dateien hängen voneinander so stark ab, dass du einfach alles laden musst oder nichts und das ist das, womit ich ein Problem habe, dass es theoretisch haben die das aufgesplittet auf mehrere Javascript-Dateien, aber praktisch kann man das einfach nicht trennen, weil es dann zu lauter Fehlern in der Browser-Dev-Konsole kommt und dann musst du entweder alles laden von dem Pagebuilder oder nichts und die Erfahrung habe ich gemacht, also wenn da irgendwer zuhört oder zuschaut und einfach besser weiß, wie man das einstellen kann oder wie man das vermeiden kann, bitte, da wäre ich sehr dankbar für die Infos, aber ich habe leider keine bessere Lösung gefunden, als einfach nur, wenn man eine gute User Experience liefern möchte, muss man einfach sehr viel einbusen halt von diesen Performance Nachteilen von den großen Plugins, wie zum Beispiel Page Builder, die dann einfach sehr viel JavaScript und CSS mit sich bringen.

Genau, das bestätigt, damit bestätigst du eigentlich auch diesen Punkt, den ich eben meinte, dass oft die Plugins nicht Dateien splitten, dass sie alles in einen Script packen.

Das ist ja im Prinzip, was du gerade meinst, was Elementor dann zum Beispiel macht und so ist es, so fällt es dann halt schwer, irgendwie nur einen Teil zu laden, den man wirklich braucht.

Und das führt ja dann wieder, was du meintest mit dem mobilen Menü, das ist ja auch wieder ein gutes Beispiel dafür, warum will man das am Anfang laden? weil es eben im direkten Viewport des Nutzers wichtig ist.

Und das führt dann vielleicht zurück auf den Punkt über LCP, den wir ganz am Anfang benannt haben.

Es ist eben wichtig, dass das, was der Nutzer sofort sieht, eben direkt verfügbar ist und schnell geladen ist, aber nicht.

Und den Rest, den kann man dann halt auch ein bisschen verzögern.

Ja, weil ob dann zum Beispiel der Button für das Abschicken des Formulars jetzt sofort geladen wird, diese Interaktion von dem Button, ist eigentlich für eine Person, die zum ersten Mal die Website besucht, eigentlich völlig egal.

Das kann erst geladen werden, wenn man erst so im Formular scrollt zum Beispiel.

Und da spielen dann diese Maßnahmen mit Lazy Loading und so weiter eine Rolle, aber da haben wir leider nicht genug Zeit, um in diese Themen auch einzutauchen.

Was mich persönlich interessiert, vielleicht können wir das ganz kurz irgendwie anschneiden, weil wir da schon eine Zeit lang reden.

Das haben wir noch nicht vorher besprochen, aber das ist mir dann spontan eingefallen, weil das größte Performance-Problem, was, glaube ich, WordPress hat, aus meiner Sicht, jetzt rein von der Struktur her, wie es aufgebaut ist, ist gleichzeitig auch ein riesen Vorteil, wieso es so in meinem vollwertigen CMS wurde, ist einfach dann diese, wenn sich jemand da technischer ausgenommen und mal in die Datenbank reingeschaut hat, dann weiß er oder sie, wovon ich jetzt spreche, Dann ist z.

B.

das der Fall, dass alle Posts, alle Beiträge, Seiten, Custom Post Types in einer Datenbanktabelle gespeichert werden und alle post_meta Felder in einer zweiten Datenbanktabelle gespeichert werden, aber alles in einer, d.

h.

wenn du viele Custom Post Types und viele verzweigte post_meta Felder hast und so weiter, dann bläht das halt diese beiden Datenbanktabellen extrem auf.

Und es wäre halt mega cool, wenn man pro Posttype dann noch eine eigene Tabelle hat, aber ich verstehe, wenn man ein generisches CMS erstellen möchte, dass das nicht immer so leicht möglich ist, aber habt ihr dieses Thema intern mal irgendwie bei euch gehabt, so hey, da wollen wir mal mit dem was machen, oder ist das schon so stark in WordPress verankert, dass es halt kaum möglich ist, da irgendwas in dieser fundamentalen Struktur eigentlich noch was zu ändern? Ähm, ja, ich glaube, letzteres definitiv.

Also, es ist, äh, ich glaube, da, ich sehe da nicht, keine großen Chancen, dass sich das irgendwie verändern lässt, ähm, ohne extrem viel Backward-Compatibility, äh, zu brechen.

Ähm, ähm, abgesehen davon, ich, ähm, ich, ich sehe das, Also ich sehe das auch aus technischer Sicht, aus Engineering Sicht, sehe ich das auch als ein Problem an, aber gleichzeitig würde ich sagen, dass es eben für die eigentliche Performance einer Website nicht so, gar nicht so zentral ist, weil zum einen es gibt, also es ist natürlich zum einen, es kommt wirklich auf die Skalierung an, wie, also von welchen Webseiten reden wir hier, wenn man eine Website hat mit ganz vielen Usern oder wenn man eine Website hat mit tausenden Blogposts und tausenden Seiten und all sowas, dann wird da irgendwann natürlich die Serverseite, die Datenbankanfragen langsamer werden, aber ich glaube auch, dass oft dann die Seiten, die so viel Inhalt haben, sind auch oft Seiten, ja, die dann irgendwann dann eben entsprechende Budgets für Hosting bereithaben, um das weniger Probleme zu haben, aber ich, im Großen und Ganzen ist das ja dann, da kann man, man kann eben trotzdem vorbeugen, indem man zum Beispiel Object Caching benutzt, so da kann man ja, das ist ja noch ein speziellerer Level von Caching, was nicht die ganze Seite cached, wie beim typischen Caching, was die meisten Caching Plugins bereitstellen, sondern eben was im Prinzip alle möglichen Datenabfragen, Datenbankabfragen cached, ähm, das kann man zum Beispiel nutzen, sodass dann diese Datenbankabfragen für ein normales Page-Load im Frontend gar nicht mehr gemacht werden, ähm, und, ähm, das ist eben die eine Möglichkeit, damit umzugehen, und natürlich Full-Page-Caching würde ja weiterhin diese Datenbankabfragen gar nicht machen, weil, weil noch nicht mal diese Logik laufen lassen würde.

Wo diese, wo solche Datenbank- äh, Performance-Probleme wirklich wichtig sind, würde ich sagen, ist dann eher im Admin-Bereich, oder wenn man halt gar kein Caching hat im Frontend, was ich aber niemandem empfehlen würde, aber wenn man halt gar kein Caching hat, oder im Admin-Bereich ist, wo es eben kein Caching gibt, in der Regel, da ist dann wirklich die serverseitige Performance deutlich wichtiger, ja, und wenn man da, wenn man dann, ja, wenn man dann ganz viele Posts hat, dann bleibt halt, glaube ich, einem wirklich nicht viel übrig, außer Object Caching, das geht auch im Admin oder eben, ja, man muss schauen, wie kann man entweder, ja, irgendwelche Hosting-Optimierung machen, um schnellere Datenbank-Anfragen zu bekommen, oder in gewissen Fällen, das ist dann aber schon sehr technisch im Detail, kann man vielleicht irgendwie die Datenbank selber manipulieren, zum Beispiel irgendeinen extra Index hinzufügen für ein bestimmtes Feld in der Datenbank, damit dann vielleicht die Resultate schneller da sind.

Ich würde sagen, das ist ein hauptsächlich nur ein Problem für Seiten, die sehr viel Inhalt haben und dann auch hauptsächlich eben ja im Backend oder wenn man irgendwelche Membership-Seiten hat, wo die Leute, wo halt irgendwie alles, der ganze Inhalt nicht gecached werden darf, wenn man eingeloggt ist oder sowas.

Das sind halt so Fälle, wo das wichtig ist.

Ich würde sagen, für die meisten Websites, wo die eben einfach Frontend für irgendwelche Endnutzer bereitstellen, die dann die Website browsen und damit interagieren können, da würde ich dem gar nicht so viel, ja, so gar nicht so viel Einfluss beimessen.

Ja, es sind dann, glaube ich, eher Spezial-Use-Cases, wo du zum Beispiel einen Checkout hast, wo sich das per Javascript dann in den Warnkorb hinzufügt oder wenn du ein Grid von Posts hast und bei mehr laden werden die Artikel dann, die weiteren Artikel auch mit Javascript geladen, damit dann die Seite nicht neu geladen werden muss und so weiter und dann kommen glaube ich solche Sachen ins Spiel, wobei man kann auch sicher auch viel eben mit Object Caching spielen und so weiter.

Ich meine, über Object Caching können wir sicher noch eine eigene Episode machen, weil das so ein Monstrum an Thema ist, wo ich dann selbst persönlich noch nicht so gut durchblickt habe.

Und es ist ziemlich schwierig, dann auch das Object Caching so aufzusetzen, dass es auch wirklich funktioniert und dass es wirklich was bringt.

Deswegen meinte ich, das ist wahrscheinlich ein Thema für eine andere Podcast-Episode.

Ich glaube, ich glaube, ich kann natürlich, ich glaube, vieles von diesen Best Practices in Sachen Object Caching, aber selbst das reguläre Page Caching.

Ich glaube, im Idealfall sind das Sachen, die ein Hosting-Anbieter irgendwie anbietet.

Also, ich weiß, das kriegt man leider in der Regel nicht für, keine Ahnung, 5,99 Hosting oder so.

Da liefern die sowas in der Regel nicht mit, aber je nachdem, was man für eine Seite hat, wenn die größer ist, je nachdem, wie viel Budget dahinter steckt, sollte man vielleicht auch schauen, dass man bei Hosting-Anbietern solche Lösungen mit Beinhalt mitbekommt, weil wenn so etwas vom Hoster direkt eben angeboten wird, dann muss man sich nicht damit bemühen, es selber aufzusetzen, aber nicht nur das, es ist in der Regel deutlich integrierter in deren ganzen Hosting-Stacks, sodass es besser funktioniert, selbst dann besser funktioniert, als wenn du es selber korrekt aufsetzen würdest, sag ich mal, außerhalb aus deren Ökosystemen, ne.

Und das ist ein wichtiger Punkt bei Full-Page-Caching.

Ich würde sagen, wenn dann eigentlich die einzige Möglichkeit ist, bei Full-Page-Caching ein Plug-in dafür zu installieren, dann würde ich sagen, tu das.

Aber wenn dein Hosting-Anbieter irgendwie Full-Page-Caching bereitstellt, dann benutze das anstelle von einem Caching-Plug-in.

Passt.

Sehr cool.

Da haben wir, finde ich, mega viele Themen abgedeckt in dieser Podcast-Episode.

Es kommen dann jetzt noch ein paar ganz kurze Abschlussfragen.

da gehen wir einfach ganz nach dem anderen durch und dann haben wir es geschafft.

Das erste, wo ich dir gerne den Spotlight geben würde, falls du irgendwas eben bewerben möchtest, in den Spotlight stellen möchtest, dann wäre jetzt der perfekte Zeitpunkt dafür.

Ja, ein Plugin, wo ich kurz drauf eingehen kann, das auch Teil des Performance-Plugins ist, das heißt Optimization Detective, klingt erstmal ganz spannend, Optimisierungsdetektiv, also das ist ein Plugin, was aus meiner Sicht wirklich revolutionär ist, aus Performance Sicht, das im Prinzip läuft es im Hintergrund über deine Webseite, im Frontend und findet und erkennt im Prinzip Dinge, die für die die Performance nötig sind, von während der eigentliche Endnutzer deine Website besucht.

Also es lädt ein sehr kleines Script und erkennt dann im Prinzip zum Beispiel, welches Bild ist auf diesem Viewport das LCP-Image und dann kann es diese Daten, sendet es dann zurück zu WordPress und kann dann die folgenden Requests entsprechend optimieren.

Also, es lernt im Prinzip von wie die eigentlichen Endnutzer deine Website benutzen und verbessert somit die Performance.

Und das ist eine Idee, mit der wir, die wir jahrelang grob im Kopf haben und irgendwie niemals den Mut hatten, es wirklich anzugehen, aber mittlerweile haben wir ein Plug-in dafür.

Er hat mein Kollege Weston Ruter ganz viel dran gearbeitet, hauptsächlich.

Also, shout out to him.

Und das ist, ja, Optimization Detective ist auch Teil von Performance Lab.

Es ist im Prinzip ein Development Framework, was andere, was dann diese Funktionalität, die Grundfunktionalität bereitstellt, und dafür gibt es dann Extensions, die heißen dann so, Da gibt es im Moment zwei offiziell, die heißen Image Prioritizer und Embed Optimizer.

Das sind alles dann Plugins, die findet man von Performance Lab Plugin aus auch verlinkt.

Ich glaube, das ist aus Performance-Hinsicht wirklich eine große Innovation.

Und ich würde es euch empfehlen, mal auszuprobieren und mal die Performance vorher und nachher testen.

Das sollte da definitiv einen Impact haben.

Na, da bin ich schon sehr gespannt, weil vor allem dieses Detektiv-Plugin, das ist für mich persönlich jetzt auch neu und ich habe eigentlich sehr viele Use Cases, wo ich es verwenden könnte.

Also da bin ich schon sehr gespannt auf das Testen und ja, ich werde dann alles natürlich in der Beschreibung verlinken, das heißt, klicke einfach da drauf, da kommst du zu den ganzen Plugins, zu dem Repository und ja, zu allen Informationen, die wir jetzt erwähnt haben, kommst du dorthin.

Zu den abschließenden Bullet-Fragen, dann sag einfach das Erste, was dir in den Kopf schießt und dann gehen wir gleich zu der Nächsten.

Weil, wenn du jetzt gerade zuhörst, dann siehst du das nicht, aber hinter dem Felix ist da noch so ein Lego-Set oder eine Kollektion von Lego-Sets und vielleicht wird das dann in diese Frage einfließen oder in diese Antwort, weil wenn es WordPress, Google, das Performance-Team nicht gäbe, was wäre dein Alternativberuf? Puh, ähm.

.

.

So würde das irgendwas mit Lego zu tun haben, oder nicht? Ach, du meinst, wenn ich gar kein Entwickler wäre oder Engineer? Zum Beispiel, ja.

Äh, tatsächlich, äh, Musik.

Okay.

Und die.

.

.

Sorry, dass ich jetzt so ein bisschen drauf rumreite, aber die Lego-Wand hinter dir, da hast du mir erzählt, dass das halt Special Editionen sind, gell? Genau, das ist so eine Serie, die heißt Modular Buildings von Lego, die bringen jedes Jahr ein Gebäude davon raus und ich kaufe sie seit 2010, also Platz wird langsam knapp.

Ich habe auch einen Deal mit meiner Frau gemacht, dass ich dieses eine Gebäude pro Jahr kaufen kann, weil wenn ich alles Lego kaufen würde, was ich gerne kaufen würde, das wäre deutlich zu viel.

Und so haben wir einen Deal gemacht.

So ist der Platz, der benötigt ist, hält sich noch in Grenzen.

Aber ich sage immer, ich glaube, ich habe trotzdem einen ganz guten Deal gemacht, weil 2050 würde es ziemlich viel Platz brauchen.

Ja.

Und einmal im Jahr hast du dann einen Lego-Tag.

Genau.

Zweite Frage.

Was ist das nervigste WordPress-Feature? Das Nervigste? Hm, das ist eine schwierige Frage.

Ich finde definitiv eine der nervigsten Sachen aus technischer Sicht ist das URL-Rewrite-System, was WordPress hat.

Wenn man da, das ist, jedes Mal, wenn man sich damit irgendwas coden muss, das ist eine Katastrophe, damit umzugehen.

Ähm, aus End-User-Sicht, ähm, weiß nicht.

Das passt für dich, also für dich rein subjektiv war das gedacht.

Ja, ja, ja.

Ansonsten sag ich immer gerne, ich hab irgendwann mal herausgefunden, dass es eine Funktion in WordPress Core gibt, die heißt is_new_day, und die Funktion vergleicht zwei Variablen current_day zu next_day.

Und das ist die sinnloseste, ich sag immer, Das ist die sinnloseste Funktion, die WordPress beinhaltet.

Aber interessant wirst du wissen, ob dann die Serverzeit verwendet wird oder diese lokale Zeit, die in WordPress eingestellt ist.

Ach so, ja, Zeit ist auch aus Entwicklersicht ja immer ganz schlimm, gerade auch in WordPress damit umzugehen.

Vielleicht kann man das als Parameter ergänzen oder vielleicht gibt es den Parameter schon.

Ich werde diese Funktion finden, und das ist dann meine Contribution zum WordPress-Projekt.

Dritte Frage auf einem anderen Spektrum.

Was ist dein Lieblings-WordPress-Feature, jetzt abgesehen von der einen Funktion? Mein Lieblings-WordPress-Feature.

Ja, Ich meine, das ist ein ziemlich großes Feature, aber ich würde sagen, ähm, ja, halt Block-Themes oder dieses Full-Site-Editing, da gibt es zwar immer noch, da gibt es zwar viele Probleme, die ich auch sehe aus Endnutzer-Sicht, die da noch gelöst werden müssen, aber als Fundament, also als Fundament, finde ich, ist das eine deutlich bessere Lösung, als wie WordPress historisch funktioniert hat.

Und ich weiß, da werden vielleicht jetzt viele mir nicht zustimmen.

Und ich kann auch verstehen, wieso, weil eben da noch viel gelöst werden muss, weil es eben deutlich neuer ist.

Aber ich glaube, wenn wir noch einige Zeit warten, sag ich mal, dann ist das irgendwann in einer deutlich besseren Position als das klassische WordPress jemals war.

Ja, und das fände ich extrem gut zu beobachten.

immer dann, wenn das noch nicht der Normalverbraucher, sag ich jetzt mal, so ein großer Fan davon ist, aber wenn man die Developer beobachten, wohin die neigen, dann habe ich bis jetzt noch keinen Developer kennengelernt, der sagen würde so, ah, Block-Editor, das ist der komplette Blödsinn und wenn dieses Feedback gekommen ist, dann einfach von den Leuten, die sich damit wahrscheinlich noch nicht so intensiv beschäftigt haben, aber wenn du da ein bisschen antauchst, dann ist das einfach so geil und da bin ich großer Fan davon geworden, also kann ich nur unterschreiben.

Wenn man nach diesem Prinzip geht, beobachte wohin die Developer sich bewegen, dann ist es finde ich ein guter Indikator, dass WordPress in Zukunft sich auch von der End-User-Gruppe dann auch in die Richtung bewegen wird.

Obwohl jetzt so gegebenermaßen noch nicht zu 100% fertig ist das Produkt, aber es tendiert schon sehr stark in diese Richtung.

Gibt es noch irgendeine finale Message, die du an die Zuschauer und Zuschauerinnen, Zuhörer und Zuhörerinnen weitergeben möchtest? Ich glaube, wir haben eigentlich ziemlich viel ja schon heute gesagt, also mir fällt gar nichts Zusätzliches ein, einfach nur, ja, denkt an die End-User-Experience mehr als an den Page-Speed-Score, würde ich sagen, als Fazit vielleicht.

Ja, und probiert das Performance Lab Plugin aus.

Genau, das Performance Lab Plugin und die ganzen Unterplugins davon.

Genau.

Dann vielen, vielen Dank Felix.

Es hat mich sehr gefreut, dass wir uns jetzt so in der Form digital kennengelernt haben, weil wir sind ja relativ weit entfernt.

Ja, Europa, USA und ist ja nicht so nah beieinander.

Aber du bist dann beim WordCamp Europe dabei dieses Jahr in Basel? Genau.

Okay, dann sehen wir uns vor Ort.

Ich habe mal, jetzt ist das, wenn die Aufnahme rausgeht, dann ist er schon ein bisschen her.

Aber ich habe mir vor kurzem die Unterkunft gebucht und so weiter.

Das heißt, da bin ich auf jeden Fall auch dabei und dann sehen wir uns vor Ort.

Wahrscheinlich dort bei dem Google-Stand, während wir uns irgendwo über den Weg laufen.

Ja, auf jeden Fall.

Cool.

Freut mich schon auch.

Dann sehen wir uns dort.

Und ja, viel Erfolg.

Bei dir ist ja in der Früh, bei mir ist ja am Abend.

Also da, ja, schönen Tag noch, viel Erfolg und wir sehen uns dann.

Danke.

Ja, dir einen schönen Abend.

Danke!.