 So, herzlich willkommen zur letzten Session vor den Closing Remarks. Luzi kommt aus dem Bündnerland, er arbeitet dort, wo andere Ferien machen. Aber statt des gemütlich zu nehmen, setzt er alles daran, bei seiner Arbeit schnelle Webseiten zu erstellen und auch die Webseiten schnell zu erstellen und natürlich auch gut und genau zu kommunizieren, sowohl intern wie auch mit den Kunden. Und damit das funktioniert, setzt die PER24-Agentur auf Scrum, ein Projektmanagement-System oder Framework, das bei komplexen Problemen gut, iterativ Lösungen bringt. In der Softwareentwicklung ist das heute standart, aber immer mehr nimmt das auch in anderen Bereichen zu und ich freue mich sehr, dass Sie nach eigenen Angaben die erste und einzige Kommunikationsagentur aus dem Kanton Graubünden sind, die zu 100% mit der agilen Projektmethodie Scrum arbeiten. So Performance-Probleme in der Kommunikation und in der Projektaffektion lassen sich mit Scrum lösen, in direkt. Jetzt geht es aber um Performance-Probleme in WordPress und wie man diese analysieren und lösen kann. Bühne frei für Luzi. Danke. Ich stelle mich auch noch kurz vor. Mein Name ist Luzi Stadler. Ich bin Geschäftsführer per PER24 GmbH und hier ein paar Stichworte noch zu mir. Mehr als 15 Jahre Erfahrung mit WordPress, Chefexperte für Informatikberufe im Kanton Graubünden und Klagos, Dinge, die wir wichtig sind oder das ich mache im Bereich der Informatik. Gut, ich habe einen langen Vortrag vorbereitet. Ich muss jetzt noch schneller machen, damit wir vorwärtskommen. Überblick gehen wir darüber hinweg. Alles, was ich in diesem Vortrag hier noch zusammengetragen habe oder euch vorstellen werde, findet man auch auf dieser Webseite supportwp.se aus der Speedoptimierung. Dort habe ich noch eine Zusammenfassung von allem Wissen, dass ich zusammengetragen habe, um diesen Vortrag hier vorzubereiten, ist hier auf dieser Webseite dann noch in einer anderen Form zu finden. Ihr wisst es alle Speed, oder man sagt gerne Speed Matters, weil wenn eine Webseite schnell ist, ist das sehr wichtig, weil das führt dazu, dass die Besucher länger auf der Webseite verweilen, dass sie eine bessere Suchmaschinenranking erreicht und auch die Verkaufsabschlüsse, sei es bei einem WooCommerce Shop, auch die mehr Leads generieren, einfacher ist, wenn die Webseite schnell performt, schnell lädt. Ihr kennt das wahrscheinlich, oder wir kennen es sehr gut als Agentur, viele oder häufig kommen immer wieder Kunden auf uns zu, mit diesem Foto oder diesem Screenshot, hey, meine Webseite ist langsam. Das ist Ihr Metrik, Sie hören von irgendwo her, die Webseite ist langsam, es gibt ein Speedtest für diesen Aus und dann kommen Sie mit dieser Metrik auf uns zu und behaupten, Ihre Webseite sei langsam. Und hier dazu zu dieser Grafik können wir als Agentur immer schwierig etwas damit anfangen, weil wir wissen, dieser Wert hier, den man hier sieht, ist nicht repräsentativ für den gefühlten Speed einer Webseite. Diese Metriken messen zwar verschiedene Messwerte, jedoch ist das nicht der gefühlte Speed von einer Webseite. Bei diesem Speedtest, den Bekannten ist es ein Blackbox-Test, d.h. dieser Test nimmt überhaupt keine Rücksicht auf die technischen Informationen oder wie das technisch umgesetzt wurde, sondern es ist eine Sicht von außen, ohne dass die inneren Abläufe, die passieren, das System kennt diese nicht. Und dazu kommt auch, dass dieser Speedtest mit einem Testsystem ausgeführt wird, wie hier beschrieben mit einem Moto G4 aus dem Jahr 2016 mit 2 Giga RAM und 1,5 Gigahertz Prozessor. Das bedeutet, für uns in der Schweiz wenige Personen haben ein Handy mit einer so schwachen Konfiguration. Nicht unbedingt repräsentativ, d.h. wenn wir diesen Speedwert bekommen, werden wir lernen, wie gehen wir damit um, wie interpretieren wir diese Speedangaben, die wir hier sehen, damit wir unsere Webseite flussendlich tatsächlich schneller machen können. Hier noch auch ein bisschen blasphemisch dargestellt. Die Sicht von Kunden, wenn sie uns diesen Screenshot schicken mit dem Speed, ist so, sie kennen nur, es gibt ein Kleint, irgendwo im Internet eine Webseite, ein Server, und alles dazwischen ist magic. Magie, die irgendwo abläuft. Wir als WordPress Entwickler, wir wissen aber, dass dieses System, auch hier immer noch einfach dargestellt, viel komplexer ist. Wir haben nicht nur den Kleint, sondern wir haben X verschiedene Systeme, die bei einem Aufruf dieser Webseite hier involviert sind. Darum geht es auch bei der Speedoptimierung vom Website, dass es gibt hunderte, nicht hunderte, aber sehr viele verschiedene Ansatzpunkte, die man wählen kann, wo optimiere ich die Webseite, oder wo muss ich optimieren, damit die Webseite schneller geladen wird. Dazu kann man diese Hilfsmittel, wie vorhin erwähnt, hinzuziehen und damit gewinnt man die Informationen, gewisse Informationen, die relevant sind und wichtig sind bei der Speedoptimierung. Wie schon vorgestellt, haben wir hier PageSpeed inside, der Lighthouse Test, den man durchführen kann, denn die Kunden auch sehr gerne zu durchführen und uns die Informationen schicken. Dann empfiehlt sich auch das Query Monitoring von das WP Plugin, die Log-Files, die man überprüfen kann auf dem Server, wo man Informationen gewinnen kann, insbesondere bei Datenbanken, ob sie diese problematisch sind. Und wir haben dann die, die das zum Verfügung haben, die ein sehr spezielles Hosting haben, ein teures Hosting haben, vielleicht sogar die Möglichkeit, die Server-Ressourcen bei einem Aufruf zu überwachen. In vielen Pällen hat man das nicht zur Verfügung, also wenn man auf einem Sherrod Hosting ist, hat man diese nicht, diese Informationen. Darum gehe ich darauf jetzt auch nicht rein. Gut. PageSpeed inside, einfach, dass man das versteht, was messen wir mit diesem Test und wann oder wo gibt es uns die Anweisung oder die Hinweise, wo wir optimieren müssen. Und man sieht links auf der Grafik die verschiedenen Messpunkte, also First Contentful Paint, oder was bedeutet das und wie interpretieren wir diese Informationen korrekt. Das heißt, wenn wir mit dem First Contentful Paint messen wir, wann das der erste Teil aus der DOM gerendert wird und tatsächlich damit begonnen wird, die Webseite aufzubauen. Die erste Information, dass diese Seite geladen ist. Und dieser Wert, wenn dieser hoch ist, haben wir einen guten Indikator dafür, dass wir serverseitig Optimierungen vornehmen müssen. Das heißt, haben wir dort einen First Contentful Paint von zwei Sekunden, dann müssen wir nicht diese Optimierungen, die er uns hier vorschlägt, durchführen, um den Speed zu verbessern. Weil das bedeutet, der Server ist langsam, sagen wir mal, das bedeutet, wir müssen zuerst unsere Datenbank optimieren, unsere Serverressourcen optimieren. Im Gegensatz dazu haben wir dann Largest Contentful Paint, der uns dann misst oder als Messwert zurückgibt, wie lange geht es, bis das größte Element gerendert ist von einer Webseite. Und wenn man dort einen sehr hohen Wert würde das bedeuten, wir müssen vielleicht unseren Content nochmals überdenken. Die Inhaltelemente. Wir können dann tatsächlich am Content beginnen mit der Optimierung. Der weitere Wert hier noch, der Total Blocking Time, den man auch sieht, dieser misst dann die Gesamtzeit, wie lange die Webseite damit verbringt, um JavaScript auszuführen und das Rendering der Webseite zu machen. Wenn dieser Wert sehr hoch ist, muss man darüber nachdenken, haben wir zu viel JavaScript, SVG, das gerendert werden muss. Das heißt, wichtig für uns, diese Werte richtig zu interpretieren, dass wir das lernen sollten. Wir bei uns, wenn wir eine langsame Webseite haben, benutzen gerne das Plug-in Query Monitor, das man im WordPress Repository findet, wenn er herunterladen kann, weil häufig Performance Probleme daherkommen, dass die Datenbank abfragen oder auch der PHP-Code nicht optimiert ist. Die häufigsten Probleme, die wir haben, sind langsame Queries oder schlechte programmierte Schleifen, die immer wieder die gleichen Abfragen ausführen, mehrfach der gleiche Content geladen wird. Das erkennt man hier mit dem Query Monitoring eigentlich sehr zuverlässig, indem man dort nachschaut, findet man sehr langsame Abfragen, die problematisch sind. Das heißt, wenn wir die Optimierung angehen, müssen wir uns zuerst immer daran denken, wo muss ich optimieren. Wo finde ich den richtigen Optimierungsansatz? Liegt das hier beim Code, bei der Datenbank Queries, ist es der Inhalt der Webseite? Haben wir schlichtweg zu viele zu komplizierte Inhaltelemente auf unserer Webseite, die ein totales Rendering ein minutenlanges, fast schon Rendering benötigen oder liegt es an den Serverressourcen? Ein paar Beispiele habe ich hier, nämlich noch zusammengefasst, genannt mit strukturellen Schwachstellen der WordPress-Tatenbank, die ein paar Probleme hat, und wenn die einum diese bekannt sind, kann man das vorbeugen, dass man die Inhalte ein bisschen cleverer strukturiert. Das erste, das kennt ihr wahrscheinlich und das macht WordPress auch als so sehr flexibel, ist die Postmetatabelle, in der alle Daten von unseren Posts abgelegt werden. Diese ist sehr, sehr clever aufgebaut, in Bezug auf die Skalierung einer von WordPress, weil es sehr einfach ermöglicht, X-Plugins zu entwickeln und das System um neue Funktionen zu erweitern. Das Problem aber von dieser Datenbank ist diese Key Value, dass das eine Key Value Storage ist, also dass die Daten nicht in dem Sinne, wie wir es als Informatiker machen würden, wenn wir es auf dem Reisbrett planen würden, sie sind nicht in einer optimalen Normalform, wie man sagt. Die Daten würde man so in einem optimierten System nicht ablegen. Das Problem ist hier, dass man bei einer Query, wenn man das technisch beachtet, man kann keine Datenbankquery schreiben oder keine optimale Datenbankquery schreiben, um alle Informationen gesamthaft aus der Datenbank zu lesen. Darum sieht man auch im Query Monitoring, macht WordPress sehr viele einzelne Requests an die Datenbank um diese Optionen, um diese Metadaten, diese Metainformation aus der Datenbank zu laden. Und um das da dieses Problem zu lösen, man muss jetzt hier noch dazu sagen, dass dieses Problem natürlich nur bei Webseiten auftritt, die sehr viele Informationen zusätzlich in die Postmetatabelle speichern. Bei einer normalen Block ist diese Optimierung nicht zwingend, jedoch wenn man intensiv mit Metabox, Advanced Custom Fields und solchen Plugins arbeitet, lohnt es sich, hier ein zusätzliches Plugin zu installieren, dass diese Daten in eigene Tabellen speichert. Das heißt, Metabox zum Beispiel bietet diese Möglichkeit, die Daten statt in die Postmetatabelle abzulegen, in eine separate Tabelle zu legen. Und das hilft uns beim Auslesen, bei der Programmierung, dass wir nur eine Datenbankabfrage machen müssen, um die gesamten Informationen auszulesen. Zweites Problem von WordPress ist die Hierarchie der Taxonomien. Dort kennt WordPress diese Parent-Child-Struktur. Das ist bei allen Taxonomien so, die man in WordPress erstellt. Man wählt immer ein Parent. Das heißt, wenn wir eine tiefer schachtelte Struktur erstellen, erfordert das beim Auslesen der Informationen potenziell sehr, sehr viele, exponentiell viele Schleifen, die durchlaufen werden müssen, um diese Informationen auszulesen. Und diese Problematik trifft man häufig auch bei WordPress Shops, weil diese Shops häufig möchte man nur alle Childs, also alle Produkte einer Kategorie anzeigen, wenn man auf die Hauptkategorie klickt, sondern wenn man die Hauptkategorie klickt, möchte man alle Produkte anzeigen, die in der Hauptkategorie und in allen darunter liegenden Kategorien vorhanden sind. Das heißt, wenn man das macht, muss man im Hinterkopf haben, dass dieses dazu führen kann, dass sehr viele Schleifen durchlaufen werden, dass er langsam performance führen kann. Und hier ein einfaches Problemlösung ist einfach nicht mehr als 2 Hierarchiestufen zu verwenden, oder zumindest im Hinterkopf haben je mehr Hierarchiestufen ich einführe, je potenziell längsamer wird meine Webseite und besonders bei WooCommerce Online Shops ist das ein ganz einfaches einfacher Trick, hier nur 2 Stufen 3 aber nicht sicher nicht 7 Hierarchiestufen anzuwenden. Die bekannten WooCommerce Filter Plug-in also gibt ja eine Unzahl von diesen Plug-ins diese lösen dieses Problem indem sie eine Indexierung der Produkte vornehmen, darum wenn man die mehr als 2 Hierarchiestufen verwenden will bei den Taxonomien, sollte man darauf bedacht sein vielleicht einen Index zu erstellen und die Daten schneller wieder gelesen werden können und 3. Problem vom WordPress das kennt man auch wahrscheinlich jeder der mal ein bisschen ein Verzeichnis aufbauen wollte das Problem, das WordPress keine Best Practice kennt für die Beziehungen Beziehungen, Datenbank Beziehungen jedes System in der Informatik wenn man auf der grünen Wiese anschauen kann kennt jede Datenbank Beziehungen zueinander WordPress löst dieses nicht oder kennt das nicht und gelöst wird dieses über Plug-ins wie zum Beispiel Advanced Casting Fields, Metabox, Jet Engine und so weiter um diese Relations zu erstellen und jetzt haben wir das Problem, die Problematik das Problem das wir vorhin gesehen haben diese die Postmeta dass dort die Daten alle in diesem Key Value abgelegt werden dass wenn wir jetzt das noch zusätzlich benutzen um unsere Relations um unsere Datenbank Verknüpfungen darin zu speichern dass das potenziell noch mehr Probleme macht bezüglich dem Speed der Website und darum empfiehlt sich auch hier wenn ihr mit Relations arbeitet lagert diese Relationen nicht in diese Tabelle ab in Postmeta sondern bringt diese in eine zusätzliche Tabelle wie es zum Beispiel Metabox oder die Jet Engine vorschlagen dort legen wir diese in spezielle Abtabellen hier mach ich jetzt ein bisschen vorwärts ganz viele verschiedene Möglichkeiten Ansatzpunkte die es bietet wenn man sich mit WordPress Speed Optimierung befasst und grundsätzlich die Erfahrung die wir gemacht haben ist die häufigste Probleme die wir bei unseren Kunden haben wenn sie zu uns kommen und sagen meine Website ist lang ist das Hosting und Webhousing zu wenig RAM, zu wenig CPU zur Verfügung stellt das heisst die erste und offensichtlichste Ding das man machen kann ist der Wechsel vom Webhousing zu einem Anbieter der genügend oder für WordPress geeignet ist dazu gehören alle diese Punkte genug CPU, genug RAM möglichst performant sein logischerweise und sie sollte über eine SSD Hard Disk verfügen das Hosting was nicht alle machen gut oder ihr kennt diese Hostings als gute Anbieter sind es gibt viele diese Anbieter hier die auch diesen Event sponsoren mich nicht aber diesen Event kommen wir noch zu diesen Optimierungsmaßnahmen gehen wir diese 1 zu 1 durch die verschiedenen Ansatzpunkte jeder kennt diese Graphic Caching verschiedene Möglichkeiten des Cachings wird gerne als Ansatz verwendet wenn es darum geht die Webseite zu optimieren das heisst wir haben verschiedene Ansatzpunkte wir können beim Browser wir können den Web Server wir können die Datenbank in diese Cache Auslagen und ich werde jetzt in der Folge verschiedene Optimierungsmaßnahmen präsentieren und euch zeigen unsere Erfahrung wie nützlich das diese Performance Optimierung sind und wie einfach diese anzuwenden sind Browser Caching das bedeutet das man mit der Performance Optimierung direkt ein Caching einführt das ist super easy einzurichten wie ihr wisst und es bietet praktisch keine Nachteile das ist das einfachste wenn man mit der Performance Optimierung beginnt beginnt man damit ein Browser Caching zu aktivieren so wie es zum Beispiel die bekannten WordPress Speed Optimierung in der harte Access Date machen WP Rocket und so weiter nehmen ja diese automatisiert vor man kann diese auch manuell einfügen wir haben das Page Caching hier haben wir schon gesehen oder wie das Page Caching bedeutet das man das seitens der eine HTML Version der Webseite erstellt das wird automatisch mit einem Mittels eines Plugins gibt viele von diesen Plugins auch über WP Rocket ist bekannt aber auch Fastest Cache und so weiter ganz viele WordPress Plugins diese Funktionalität bieten für eine dynamische Webseite die sehr viele Informationen immer wieder verändert darstellen muss ist diese Art von Caching nicht geeignet d.h. dort macht man schlechte Erfahrungen weil der Cache sich ständig wieder erneuern muss diese Art von Caching eignet sich für sehr statische Webseiten für Blocks für Webseiten in denen es sehr wenig Änderungen daran gibt die Unternehmenswebseiten bei denen nicht Änderungen gibt ein Webverzeichnis das Daten aus verschiedenen Quellen immer wieder aufbereitet ist diese Art nachteilig dafür hat man hier relativ einfach mit der Installation man installiert ein Plugin und in vielen Fällen bei einfachen Blocks bei einfachen Webseiten erreicht man damit auch eine Verbesserung der Speed teilweise sogar eine große Verbesserung Fehlerpotenzial von dieser Art ist auch nicht zu unterschätzen teilweise ergeben sich durch diese Art des Cachings auch Probleme auf der Webseite wir haben das Datenbank Caching das einerseits ein sehr großes Potenzial bietet wenn man bei dynamischen Webseiten sind für dynamische Webseiten für statische Webseiten wiederum hier nicht ein riesiger Performancegewinn zu erwarten ist der Vorteil von diesem Caching ist was man will die Datenbankabfragen zwischenspeichert wenn häufig wieder die gleichen Abfragen gemacht werden müssen wird der Datenbank Server entlastet und der Webseite allgemein verbessert häufig also z.B. Redis oder Memcache und so weiter sind nicht verfügbar bei vielen Hosting-Anbietern per default warum man das nicht geeignet immer einsetzen kann das ist auch eine Optimierungsmethode für sehr große Webseiten mit großen Verzeichnissen für kleine Webseite einige Hosting-Anbieter kennen das NGINX als Reverse-Proxy zu verwenden das wiederum eine einfache gute Methode ist um den Speed einer Webseite zu verbessern und auch hierbei kann man wiederum sagen dass die Verbesserungspotenzial hier das hilft hier die Webseite schneller zu machen dass wir die Webseite nur einmal wird der ganze Prozess der Code prozessiert wird dann an den Proxy gegeben und dieser spielt beim nächsten Wiederholtenbesuch diese schon bereits ausgeführte Programmcode aus und gibt diesen zurück an die Webseite an den Kleinen hierfür braucht es dann ein zusätzliches NGIN auf Seiten von WordPress weil diese Header die Header-Informationen die der Zwischenspeichern ermöglichen der Webseite von NGINX müssen gesetzt sein müssen dort eingerichtet sein die beste Methode eigentlich um eine um eine große Webseite die sehr dynamisch ist zu caching ist diese Einrichtung eines Fragments cachings caching bedeutet dass wir hier nur einen Teil der Webseite beispielsweise zum Beispiel die letzten beliebtesten Produkte eines Online-Jobs dass man diese Abfreige zwischenspeichert bedeutet beim Wiederholtenbesuchen der Webseite werden die beliebsesten Produkte nicht immer neu aus der Datenbank geladen sondern diese beliebtesten Produkte sind dann aus dem Cache geladen das bietet ein sehr enormes großes Potenzial um diese Datenbank abzutragen zu minimieren und dadurch den Speed zu verbessern Nachteil davon ist natürlich sehr aufwendig im Vergleich zu anderen Methoden zu implementieren das heißt wir als Techniker müssen dort diese einzelnen Fragmente sehr genau definieren damit das dann mit dem Caching gut funktioniert CDN man kennt es und muss ehrlich sagen für mich immer wieder das Thema CDN ich bin nicht jetzt Enthusiast von CDN warum ich kann euch das auch noch genau erklären warum ich nicht der große Fan bin warum wir hier in der Schweiz die meisten Kunden sind ihr Scopis Schweiz die Kunden, die Webseiten punktser Domains sind ausgelegt für Kunden aus der Schweiz ein CDN ist ja dafür da dass er die Inhalte der Webseite auf der ganzen Welt verteilt damit die Anfrage dann zum Beispiel wenn sie aus Amerika kommt nicht in die Schweiz geleitet wird und von hier eine Antwort erwartet bei uns ist das ich sage mal in der Theorie sogar vielleicht nachteilig ein CDN zu verwenden wenn man 90% der Treffig aus der Schweiz kommt weil die CDNs die allermeisten nicht in der Schweiz hier einen Serverstandort haben zumindest vielleicht in Frankfurt diese Sicht haben befinden das heißt in der Theorie benutzen wir CDN haben wir 90% Treffig aus der Schweiz wir diese weiter nämlich nach Frankfurt und sie bleiben nicht hier in der Schweiz darum für mich ist CDN nur oder für euch auch ich denke es ist nur relevant wenn man eine Webseite pflegt die tatsächlich internationale Treffig hat Auslagern ins Ausland nach Amerika die Daten wenn man keine Besucher aus Amerika hat wenig sinnvoll auch der Performance-Gewinn ist nicht enorm vom CDN natürlich hat man sehr sehr viele Treffig aus dem Ausland ist das eine geeignete Methode um diese um dies zu aktivieren ein weiterer Nachteil für uns auch für unsere Kunden häufig es ist zusätzliche Kosten die sie tragen müssen dafür ein minimer Gewinn möglicherweise den sie davon gewinnen könnten ein Page-Bilder und Inhalte hier kommen wir noch zu einer weiteren Optimierung der Webseite weniger technisch sondern jetzt auch praktisch an der Umsetzung der Webseite und hier habe ich ein paar Stichworte noch zusammengetragen nämlich ohne Page-Bilder ist die Webseite am schnellsten logischerweise weniger das wir machen je schneller ist die Webseite und dann würde ich als zweiten Grundsatz nehmen Gutenberg ist schneller als andere Page-Bilder und wenn ein anderer Page-Bilder würde ich nur Elementor wählen der Page-Bilder lädt natürlich zusätzliche Assets zusätzlich es werden Hunderte von zusätzlichen Hooks ausgeführt was die Gesamtperformance der Webseite verlangsamt darum bei der Wahl der passenden Page-Bilder sollte man immer darauf bedacht sein einen Page-Bilder zu wählen der möglichst wenig Ballast mit sich bringt hier das wären nur meine Empfehlungen ihr habt vielleicht andere Erfahrungen die ihr später nachher mit mir gerne teilen könnt weitere einfache Maßnahme bedeutet das reduzieren der Webseite und hier ich als Techniker andere als Grafiker in unserer Firma wir haben immer ein bisschen Konflikte Sie wollen ein Fancy-Design möglichst viel und wir Techniker wollen eine schnelle Webseite und das ist häufig nicht im Einklang weil jedes spezielle Inhalts-Element beispielsweise ein dieses Slider es ist schön ein Slider die wir auf der Webseite haben wir haben auch von unserer Startseite auch ein Slider und ein Video drauf aber das ist natürlich macht die Webseite langsam die Ladezeit wird durch das langsam im Prinzip kann man hier sagen optimieren bedeutet reduzieren je weniger das wir übermitteln müssen je weniger Informationen wir übermitteln müssen die Webseite lernt ganz logisch eine Webseite von ANO 2000 die ist heute super performant das heißt als Maßnahme hier immer wieder die Inhalts-Elemente auch zu hinterfragen, zu ersetzen oder auch zu entfernen besonders gilt das auch für die Startseite der Webseite die Startseite ist häufig ein Zusammenzug der ganzen Webseite und hat sehr viele Inhalte die der Besucher wahrscheinlich gar nie sieht ich habe die Grafik hier nicht drin aber auf der Webseite die ich euch gezeigt habe sieht man das wie wenig Treffig tatsächlich bei gewissen Webseiten auf die Startseite gehen teilweise ich habe das Beispiel von dieser Shopping-Total-Webseite die wir pflegen, da geht 99% der Treffig geht nicht auf die Startseite 99% geht irgendwann auf eine Unterseite von der Webseite darum muss man sich schon bei dieser Webseite dann ein bisschen fragen wie viel Inhalt tatsächlich auf der Startseite relevant ist müssen wir diese Web diese Startseite so langsam muss diese so langsam laden gut weitere Maßnahmen noch einfache Maßnahme GZIP, Komprimierung auch das wir erledigen euch diese Plugins wie Webperocket oder automatisch ein bisschen Code in die Hartexester-Datei speichern erledigt Thema überhaupt einfach eingerichtet geringes Risiko für Fehler und geeignet für alle Arten von Webseiten auch gleiches noch für die Experiohedders die man setzen kann das ist relativ einfach einzurichten zu setzen und wird benötigt dann wenn man mit NGINX als Reverse Proxy einsetzt muss man diese Experiohedders haben, weil nur dann weiß er ob er die Datei aus dem Car schladen muss oder ob er die Anfrage direkt weiter an den Apache Server leitet mit dem NGINX als Reverse Proxy hat man sehr effizientes Mittel um die Performance zu steigern weil die Anfrage nicht mehr also geht eine Anfrage an die Webseite und diese wurde schon vor ein paar Sekunden einmal angefragt muss WordPress überhaupt nicht wird WordPress überhaupt nicht mehr aufgerufen das heißt der NGINX leitet die Anfrage nicht mehr an den Apache nicht mehr an WordPress ausgeführt, sondern der NGINX liefert die Antwort direkt zurück ohne dass unser Server in einer Form belastet wird es ist ein sehr effizientes Mittel um den Speed zu verbessern von der Webseite besser auch geeignet als diese Caching Plugins die Page Caching machen auf der Webseite dass diese HTML-Dateien aufbereitet und vorbereitet können wir noch die PRP Version ich weiß nicht ich habe jetzt den Release nicht genau angeschaut von WordPress 6.2 ob PRP 8 tatsächlich zu 100% unterstützt wird weil jedes Mal wenn ich dort noch in die Specifications gehe und lese sehe ich dass es noch ein paar Teile gibt die noch nicht mit PRP 800% die kompatibel sind jedoch unserer Erfahrung nach kann das ein Performance-Vorteil bringen PRP 8 schon einzusetzen es ist mittlerweile ein mäßiges Risiko eine Webseite auch mit PRP 8 zu betreiben und ist natürlich ein ganz einfaches Mittel jedoch bietet es momentan ein gewisses Fehlerpotenzial dass man wenn man es umstellt benutzt man PRP 8 muss einem bewusst sein man kann nicht alles testen man weiß oft nicht ob vielleicht auf irgendeiner Unterseite irgendein Plug-in irgendein Problem hat mit der neuen PRP Version dann kennen wir das auch beliebte Jobpixel und so weiter die Daten die Bilder komprimieren automatisiert und auch hier diese Plug-ins sind einfach effizient einzurichten empfehlen sich weil sie auch ein geringes Fehlerpotenzial haben wenn man diese benutzt bietet sich gut an um die Performance der Webseite auch zu verbessern ein großer großer Performance-Vorteil bietet Lazy-Loading von Bildern sehr empfehlenswert das einzusetzen insbesondere auch bei Online-Shops die ja sehr häufig auf der Produkt- Seite, auf der Shop-Site sehr viele Produktbilder laden und das ist auch das Risiko heute ist ein bisschen ein Fehlerpotenzial da wenn es über JavaScript ausgeführt wird die modernen Browser unterstützen Lazy-Loading auch schon von sich aus, wenn man den richtigen Attribut setzt auf die Bilder empfiehlt sich also im Code sowieso wenn ihr etwas selber programmiert beim Lazy-Loading dort zu aktivieren minimieren und jetzt kommen hier noch ein paar Sachen die ich nicht empfehle zu machen oder die wir bei uns tatsächlich immer nur Probleme gemacht haben diese Plug-ins Hummingbird, WP-Rocken, Auto Optimize und so weiter das schlagen sie immer vor minimais oder minimieren der Dateien noch zusätzlich das häufig führt das zu Fehlern auf der Webseite und der Performance-Gewinn durch das minimieren der Dateien ist sehr klein das Fehlerrisiko hier gegen das den Speed-Up-Vorteil abzuwägen lohnt sich nicht und das kennt ihr vielleicht auch Combining das größte Fehlerpotenzial das überhaupt eine Optimierungsmaßnahme bietet ist Combining in Kombination mit minimieren von Daten noch extremer für mich ein No-Go braucht es nicht auch mit HTT-P zwei Version ist das überhaupt nicht mehr notwendig und man holt dort wenig Speed hinaus weil der Speed-Test von Google das vorschlägt bitte, bitte macht das aber es bringt nichts im gefühlten Speed-Optimierung und auch sehr effizient für die Speed-Optimierung ist das Asynchroneladen das Deferred Loading von Assets hier einzusetzen leider ein Hacky noch bei WordPress weil es diese Option noch nicht bietet von diesem Asynchroneladen noch zwei Folien dann haben wir noch kurz den echten Grundjob einzurichten das die eine der einfachsten und zuverlässigsten Möglichkeiten den Speed von WordPress zu verbessern gut, dann danke ich euch für die Aufmerksamkeit ich musste schnell durch die Folien durchgehen ich muss das danke eigentlich nicht nur an euch sondern an die Organisation hier von diesem Work-Camp ich bin wirklich überrascht und, nein, nicht überrascht aber sehr froh dass das alles so gut organisiert wurde von euch hier danke, grosses Danke Danke dir mal Lützi Fragen? Es ist aktiv, ja nur eine Anmerkung Du hast das Side Health Check das SQL Query Plug-in angesprochen ich weiß nicht ob du das gesehen hast es gibt seit dem Cloudfest Hackathon letzte Woche ein MariaDB SQL Query Plug-in wo die MariaDB Foundation aktiv auch mitentwickelt WordPress falls du das nicht kennst oder jemand anderes auch noch nicht kennt vielleicht mal reinschauen gute Anmerkung erst mal vielen Dank für deinen Vortrag ich fand ihn echt cool vieles gelernt oder noch meine Erinnerung geholt ich habe dir noch mal eine Frage ich muss sich kurz gucken ich habe gerade mal ein Peach Speed gemacht welcher Wert das jetzt noch mal war der, der mich da interessiert hat und zwar war das, glaube ich, der irgendwas mit Time to First Bit oder Time to First Bite oder sowas die anderen Werte waren jetzt nicht mega gut, aber auch nicht mega schlecht der wird jetzt bei mir bei meinem Test besonders hervorgehoben worden als besonders beschissen kannst du mir da irgendwie sagen worang das jetzt liegt oder an welchen Stellenmenschrauben man da möglicherweise dran drehen sollte weil ich meine ich habe das eine verstanden diesen First Contentful Paint Wert der sagt, glaube ich, nicht richtig verstanden habe wann die Webseite quasi nach wie vielen Sekunden der Ladevorgang abgeschlossen wurde richtig? Nein, das das bedeutet nicht, dass der Ladevorgang komplett abgeschlossen ist sondern es ist die Annahme oder das größte Element auf der Webseite ist zu diesem Zeitpunkt dann fertig gerendert okay, also irgendwie das heißt, das ist das häufig dann der Slider oder auf der Seite und dieser Time wie hieß der, was hätte ich gesagt Time to First ich meine einen anderen ich meine einen anderen nee der steht nee, Moment ach Moment, ich habe das doch noch offen Temp to First Bite ja genau da ist er gar nicht drauf da ist er gar nicht drauf also wenn ich das bei... Ah, die nehmen das ein bisschen anders Quitty Matrix wie Page Speed oder so etwas ich meine hier, dieser Time to Interactive nee Moment kurz auf jeden Fall geht es darum das ist genau das ist auch wieder etwas, was serverseitig etwas geendet werden muss und wo du auf der Seite selbst nichts ändern kannst was besser wird aber Google differenziert diese Werte irgendwie, glaube ich Moment, es ist eine sehr spezifische Frage also bei Google wird ausgegeben ein First Contentful Paint Wert ein Interactive to Next Paint und ein Time to First Bite TTFB, nennen sie den also da gibt es halt diese Unterscheidung, also Largest Contentful Paint Potele First Contentful Paint und eben nochmal diesen Time to First Bite oder ist das dieser warte für Dinger gut also vielleicht noch einfach kurz abschließen zu sagen wenn der First Contentful Paint hier also das die erste die erste Bereich hoch ist, bedeutet das dass da die Webseite der Server sehr lange hatte um die Webseite zu prozessieren bis er sie dann zurückgeben kann das deutet daraufhin, dass die Datenbank abfragen zu wenig optimiert sind das PHP zu lange arbeiten muss, oder dann bekommt man hier einen negativen Wert, weil dann weiß man das Rendering, also nein das Prozessieren seitens des Servants war sehr langsam und wenn die anderen Werte dann hoch werden, bedeutet das das liegt dann am Content der Worte für mich ist die Vertrag auf dieser Time to First Bite jetzt eher in Richtung Contentoptimierung also der Webseite selbst ein Indikator ist oder ob es darum geht, dass mein Webprost da möglicherweise scheiße ist ja das heißt an Optimierung auf der Webseite kann ich da so viel machen wie ich möchte ich kann diesen Wert nicht positiver beeinflussen natürlich wenn du Elemente löscht und das Richtige erwischt ist ja vielleicht dann die Dauer, wie lange das ausgeführt werden muss, auch kürzer logischerweise klar, wenn ich meine Webseite komplett in die Hand trete und lösche, dann hat er nichts zum Rendern dann ist klar, aber ist es schon eher ein Indikator, dass sich was an den Stellschrahmen des Servants selbst ja, dass dort vielleicht eine Datenbank abfragen sehr sehr langsam ist oder eher langsam, eine und wenn du dieses Element dann aus dieser Webseite wird die Gauss-Omte-Performance besser weil dann alles klar aber wenn die anderen Werte so im Mittelwert sind und der jetzt ein totaler Ausreißer ist dann ist es eher ein Indikator dafür, dass sich irgendwo an dem hohen Ding eine Stellschraube drehen ist gut ist sonst noch Fragen ich hätte eine Frage zu der Nummer mit den Page-Bildern und zwar warum unbedingt wenn dann Elementor weil ich habe immer geglaubt oder gesagt bekommen auch Elementor ist einer der Page-Bilder oder beziehungsweise ein Page-Bilder der halt immer wieder alles lädt und bei jedem Seitenaufruf und deshalb eben sehr langsame Seiten produziert quasi ist natürlich auch ein bisschen eine Erfahrung, die wir gemacht haben natürlich, es gibt verschiedene solche Page-Bilder wir haben einfach die Erfahrung gemacht bei uns, dass gewisse von diesen Page-Bildern nicht nicht optimal sind nicht gut, nicht performant sind ich kenne nicht alle ich habe nicht mit jedem Inhaltseditor den es gibt jemals gearbeitet aber wir kennen einige verschiedene und warum bietet sich dann Elementor besonders gut an, weil es bietet schon eine große Vielfalt an Möglichkeiten, die man mit Elementor hat und es ist ein in sich geschlossenes System dass man nicht mehr sehr viele zusätzliche Plugins braucht wenn man dann noch Element Packs dazu nimmt natürlich diese laden dann teilweise noch wieder andere Abhängigkeiten dazu aber nur Elementor und Pro ist in sich ein gut abgekoppeltes Ökosystem dass in den letzten Monaten und Jahren auch immer in den letzten Monaten in den letzten Monaten und Jahren auch immer mehr auf Performance verbessert wurde aber ich bin kein Glühender habe keine Verbindung mit Elementor oder so ist einfach persönliche Erfahrung vielen herzlichen Dank ich weiss du hättest noch mal eine Frage aber bitte spreche das nachher ab weil wir sollten für die closing remarks langsam Schluss machen herzlichen Dank