 So, vielen lieb Dank, dass ihr am Nachmittag den Wikia noch gefunden habt, freut mich doch auch zu dieser späten Stunde noch ein paar Bekannte und neue Gesichter zu sehen. Mein Name ist Jantil, vielen Dank für die Einführung. Ich bin, so nennt man es im Neudeutschen, glaube ich, am idealsten DevOps. Das heißt, ich bin eigentlich Programmierer ursprünglich und mache jetzt nur noch Hosting und Serverbetreuung bzw. den Betrieb und praktischerweise von WordPress. Wenn man sich so im Leben mit größeren, mittleren, kleineren Firmen, Webseiten, Projekten auseinandersetzt, dann kommt man halt an viel vorbei. Vielen Dingen, die einem die Augen öffnen, viele Dinge, die einem den Atem rauben und viele Dinge, die man gerne mit anderen teilen möchte, weil es doch Kleinigkeiten sind, die das Leben von vielen besser machen können. Was ich in dieser Zeit leider genauso oft sehe, sind immer wieder unendlich viele Werbeversprechen von Firmen, die einem anpreisen. Wir haben den Heiligen Graal gegen Haarausfall, gegen langsame WordPress-Seiten. Wenn man sich nur aber ein bisschen mehr mit der Thematik beschäftigt, wenn man in die Technik einsteigt, wenn man anfängt, Dinge zu hinterfragen, dann kann man solche Sachen recht schnell entlarven. Den Titel Mitzbastas habe ich in diesem Fall sehr bewusst gewählt, weil es einfach wirklich darum geht, Mythen zu entlarven, aufzudecken, zu zeigen, was steckt hinter dem Marketingversprechen und bringt es euch wirklich was. Im Idealfall habt ihr in einer halben Stunde ein großes Verständnis dafür, was WordPress Performance heißt, und zwar nicht in dem Philosoph, den Casper Hübinger uns für den nahe gebracht hat, sondern in einem technischen Sinne, quasi auf der Ebene darunter, die er nicht angehen wollte, sowie zwei Ebenen weiter darunter. Sollte ich zu technisch werden, stellt kurze Fragen, gerne während des Vortrags oder auch am Ende, es könnte sehr technisch werden, aber das gehört dazu und ich glaube, dafür sollte keiner von euch Scheue haben. Nach diesem kleinen Intro eine Pyramide, eine Pyramide, die mit Dingen gespickt ist, an denen ihr alle wahrscheinlich schon mal vorbeigekommen seid. Es sind die einzelnen Bestandteile, die euren Server ausmachen, die euer Hosting ausmachen und auf den WordPress nachher läuft. Wenn man sich jetzt anschaut, was langsam sein kann, ist das wie bei einem Auto. Wenn man sagt, das Auto ist langsam, warum ist es langsam? Na was kann langsam sein? Die Reifen können langsam sein, der Motor kann langsam sein. Vielleicht habe ich vergessen, meine Frontscheibe einsetzen zu lassen und der Ruf der Stand ist zu hoch. Dasselbe ist bei WordPress der Fall. Es gibt sehr viele Ebenen, auf denen etwas langsam oder nicht performant sein kann. Die Kernfrage ist jetzt natürlich, welche dieser Ebenen sollte man angehen. WordPress selbst läuft auf der mittleren Ebene quasi als Software, die auf PHP und SQL aufbaut und auf WordPress drauf sitzt dann wiederum eure Teams. Teams im Sinne von einer Ansammlung von HTML, CSS, Javascript. Einfach mal wirken lassen und im Hinterkopf abspeichern oder gleich wieder vergessen. Nun, bevor wir noch ein wenig in die Technik eingehen, habe ich hier ein kleines Schaubild zum Thema, wie läuft denn überhaupt eine Anfrage zu einer WordPress-Seite gemacht? Das als Verständnis, was passiert denn, wenn der User in seiner Browser, in seinem Browser eingebt, nirnberg.wordcamp.org. Der Browser geht an den Server, in dem Fall der Webserver, der Webserver denkt okay, net kann ich nichts mit anfangen. Ich habe hier ein WordPress-Sitzen, schiebt es weiter an WordPress. WordPress selber merkt ja, okay, habe ich da, muss ich weiterschieben. Sprich, wir haben sehr, sehr viele Spieler, die in diesem Zyklus aktiv werden. Wir haben sehr viele Zwischenstufen, die durchlaufen werden. All diese Zwischenstufen kosten Zeit, Leistung. Und all diese Zwischenstufen muss man sich betrachten, wenn man überlegt, wo kann ich denn optimieren? Und wo macht es Sinn? Optimierung, das vorweg, kann eine verdammteure Sache sein. Oder extrem günstig, wenn man weiß, wo man optimiert und wo es sinnvoll ist. Ich möchte jetzt einfach mal kurz diese Kette durchgehen, und zwar sehr technisch, und die einzelnen Komponenten, die wir uns hier angeguckt haben, performance-technisch beleuchten. Dabei ist nämlich immer die Frage, was ist denn gerade langsam? Ich habe mir mit Sparsesalber mal die Mühe gemacht, und habe mir mit Profilingtools und Analysewerkzeugen eine WordPress-Seite genommen, und genau diese Schritte analysiert. Sprich, wo wird wirklich Leistung benötigt? Wo ist etwas im Performance, und wo kann man natürlich was sparen? Was wir hier haben, ist die Antwort auf die Frage, ist mein Server zu langsam? Server im Sinne von Hardware, CPU, Arbeitsspeicher, Festplatte. Das ist einfach ein echtes Beispiel aus einem unserer Systeme. Das oben links ist die CPU-Auslastung. Wie man sieht, ist dort quasi nichts los. Wenn ihr also auf den Gedanken kommt, dass eurer dedizierter Server zu langsam ist, seltenst. Aktuelle Hardware hat so viel Performance, dass ihr eine Hochlast-Seite, vielleicht mal irgendwie ein Ausleistungs-Szenarien-Comp, wo es interessant wird, bei kleinen und normalen WordPress-Seiten geschenkt. Wenn ihr es da schafft, eine moderne Server-CPUs auszulasten, macht ihr irgendwas verkehrt. Der zweite Bereich und Rechtsarbeitsspeicher. Auch da muss ich einmal kurz zeigen, was die Auslastung ist. Das ist hier unten der grüne Bereich, also massig Luft nach oben. Auch in der Regel ein Fall, werdet ihr keine Probleme mit haben für eure normalen WordPress-Welden. Wo gehen wir also weiterhin? So, wir sind jetzt bei der Pyramide in der untersten Ebene. Der User fragt die Seite an. Wo könnten wir also weiter schauen, wenn wir den Web-Server schon ausgeschlossen haben auf Hardware-Ebene? Naja, gucken wir doch einfach mal, was passiert, wenn man eine reine HTML-Webseite lädt. Sprich, reines HTML auf dem Server und nichts dazwischen. In diesem Fall ist das Beispiel mit den Chrome Developer Tools extrahiert, ein nettes Werkzeug, um sich mal ein Bild davon zu verschaffen, wie lange er dann seine Seite lädt. Und in dem Fall eine total simple HTML-Seite Twitter Bootstrap rein, ohne Großanforderungen, 100 Millisekunden. Okay, da scheint es also keine Probleme zu geben. Da scheint nicht langsam zu sein. Auf demselben Server, jetzt einfach mal ein WordPress. Okay, das sieht anders aus. Einerseits ist eine Null hinten angekommen. Wir sind also bei einer Sekunde statt 100 Millisekunden. Und darüber hinaus haben wir auch 61 Request statt halt wenig. Request sind die Anfragen, die halt an Dateien, Bildern, CSS, ja, was Kripte, die hergeschickt werden. Ist in dem Fall, kann man sich anschauen, kann schlimm sein, muss es aber nicht. Nun ist also die Frage, was passiert dazwischen? Wo ist der Unterschied zwischen einer normalen HTML-Seite und WordPress? Was macht das Ganze ohne den Faktor 10 langsamer? Wenn man sich da jetzt mit weiteren Tools einfach mal einen Einblick verschafft, und fragt, ja, was passiert denn in dieser Sekunde? Das ist nämlich die Kernfrage, die man sich stellen sollte. Was passiert in dieser Sekunde und was kann ich davon schneller machen? Dann kriegt man eine schöne Grafik raus, die im Endeffekt zeigt 600 Millisekunden. Der gesamten Ladezeit ist in PHP. PHP berechnet eure Seiten. PHP macht, dass das heimgeladen wird. PHP lädt die WordPress-Funktion. Jedes eurer Plugins ist über PHP eingebunden und arbeitet dort. Okay, 600 Millisekunden. Das sind 60 Prozent der gesamten Ladezeit. Wenn ich also irgendwas optimieren möchte, dann doch bitte da. Hier oben drauf, MySQL, das sind die Datenbankabfragen. Das sind die Daten, die Werte, alles, was ihr dort eingespeichert habt, die WP-Options, sprich, Einstellungen, die ihr macht. Weitere 200 Millisekunden gehen da drauf. Was dann noch bleibt? 800 bis 1000 Millisekunden, sprich, 100 bis 100 Millisekunden. Das ist relativ gering. Das ist nämlich die Zeit, die ihr in der Server braucht, um die Daten anzufragen und die Daten wieder zurückzuschicken. In dem Fall, wenn ich euch jetzt frage, wo würdet ihr optimieren, was würdet ihr machen? Ihr würdet euch das PHP angucken, richtig? Bevor wir jetzt an konkrete Performance-Optimierungsmechanismen gehen und uns auch einmal einen konkreten Beispiel anschauen, warum in der Werbung so viel Scheiße erzählt wird und warum sie euch überhaupt nichts bringen, sind da noch drei Annahmen, die ich jetzt aufgrund der Zeit nicht weiter ausführen möchte beziehungsweise nicht, die der hier darstellen kann. Aber wir müssen davon ausgehen, dass WordPress an sich recht performant ist, wie was es tut. Da sitzen Leute daran, die Ahnung haben von dem, was sie tun. WordPress selber auf einer nackten Seite, ohne Pluckens und Teams, wird niemals so viel Zeit brauchen, wie ausgestattet mit Teams und Pluckens. Das ist vorweg. Das Zweite ist, wenn man sich fragt, wo man denn optimieren kann. Wenn ich Teams und Pluckens von irgendwelchen Drittanbietern habe, Team Forrest oder irgendwas, dann kann ich an deren Code erst mal nichts ändern. Kann heißt, natürlich kann ich es machen. Es wäre aber saudämlich, weil jedes Update diesen Code natürlich wieder überschreibt. Gibt es da einen Nutzen, eigenen fremden Code zu bearbeiten? Nicht wirklich. Sprich klare Empfehlung, lasst die Finger davon. Muss man als gegeben hinsehen und die Entscheidung, da wäre dann eher ein anderes Team oder ein anderes Pluckens zu verwenden, statt in deren Code reinzugehen oder den Autor dazu zu bewegen, seinen Code besser zu machen. Aber das macht ja leider den Code des Autors nicht besser. Es macht vielleicht die Endfunktion besser. Aber du setzt ja noch was obendrauf. Wir erinnern uns PHP-Ladezeit, das ist das, was wir reduzieren wollen. Noch mehr PHP-Code dafür? Komm ich am Ende noch drauf. Und das Dritte, ganz klare Empfehlung, wenn ihr Optimierung machen wollt, macht sie da, wo ihr sie am besten einsetzen könnt. Also direkt an der Wurzel. Wir hatten jetzt das Beispiel mit den Plucknen, das finde ich, das grenzt sich da sehr schön drauf. Kann man machen. Aber das Problem direkt an der Wurzel, nämlich im eigenen Pluckens zu lösen, also in dem eigentlichen Pluckens zu lösen, in dem eigentlichen Team zu lösen. Da ist das Problem. Wir wollen ja keine Workarounds schaffen, wir wollen nicht die Häuser nebenan aufbauen, sondern wir wollen das Kernproblem lösen. Und zwar da, wo es für uns machbar ist und da, wo es performant ist. So, jetzt kommt, glaube ich, der interessante Teil. Schauen wir uns doch mal an. Welche Optimierungsmaßnahmen, die aktuell so durch die Medienwelt geistern, die ihr in Blocks findet, die ihr in irgendwelchen Marketinggroschieren seht, wirklich sinnvoll sind. Disclaimer vorweg. Ich beziehe mich hier auf die 99% der WordPress-Seiten, die nichts weiter sind als eine WordPress-Website, die weder eine riesige BodyPress-Community sind, noch ein Pool mit Millionen von Aufrufen am Tag. Es geht wirklich um die ganz normale WordPress-Website. Das ist eine wichtige Prämisse, weil sich diese Betrachtung, die jetzt folgt, wirklich nur darauf bezieht. Es kann sein, dass bei einer riesigen Webseite andere Optimierungsmaßnahmen viel mehr bringen und auch sinnvoll sind, aber halt für die Breite allgemeinheitlich. Content Delivery Networks. CDN. Ein sehr schönes Thema. Content Delivery Networks versprechen, dass sie eure Seite beschleunigen, indem man CSS, ja, was Grip-Bilder, auf irgendwelche Server irgendwo in der Welt verteilt und diese eure Daten schneller ausliefern können. Aha. Und das machen die wie? Naja. Wenn ihr eure Seite in Deutschland hosted, Kunden in Deutschland habt, was bringt es euch, wenn eure Daten in China, Amerika und vielleicht aus der Radiant vorgehalten werden? Überhaupt nichts. Es gibt laut Aussage von diversen, kommen wir gleich zu, dort diversen CDN-Betreibern genau zwei Anwendungsfälle. Ich hatte mich da glücklicherweise mal mit den technischen Leitern von Level 3 unterhalten können. Nämlich das eine, wenn ihr weltweit Daten austeilen wollt, also eure Kunden sitzen weltweit, dann sind CDNs natürlich super. Und der zweite Anwendungsfall sind große Dateien. Sprich, ihr habt ein Video, das ihr unbedingt über eure Server verteilen wollt oder ihr habt Software mit 5, 600 MB. All das, nämlich diese beiden Anwendungsfälle, sind das, wo die CDN-Anbieter selber sagen, dafür bringt es das. Für andere Anwendungsfälle, naja, ganz davon abgesehen, dass man die Daten des Users in die USA schickt, nach Asien, wo auch immer dieses Server stehen. Ihr habt also keine Kontrolle mehr darüber, wo eure Daten liegen. Und der User hat noch weniger Kontrolle darüber, wo er seine Daten herbekommt, weil er muss sie ja haben. Also du meinst, wenn du deine komplette Seite in ein Content-Device-Network verschiebst und nicht nur die statischen Ressourcen, wie ja, was Kript-CSS und Bilder, dass du dann eine höhere Sicherheit erreichst. Definitiv, da bietet sich ja Cloud-Crayals-Anbieter immer sehr an, der das anpreist. Genau. Genau, aber primär regt das dann ja auf DDoS-Angriffe. Also wenn Millionen Anfragen kommen und die Seite angreifen. Tradoff, ihr schickt eure User immer über Server von Cloudflare, die, was weiß ihr, wo immer stehen. Muss man wissen. Also ich glaube, das ist der Anwendungsfall, der die meisten trifft. Und Cloudflare, ich bin da zu viel gespalten. Muss man für sich entscheiden. Ich finde es immer fragwürdig, wenn man den User erst zu jemand anderen schickt, bevor zu einem selber kommt. Polisiert, die ich zumindest so auch nicht nachvollziehen kann. Der Moment für zum Beispiel Jack Ferry, da dringend CDN ist halt, wahrscheinlich hat der Nutzer, dass er schon ein Browsercash war, und da auch schon geladen wurde. Und dadurch findet dieser Request hoffentlich gar nicht mehr statt. Ich finde es interessant, dass du den Datenschutzaspekt direkt im Satz mit ich lagere Herrn Jack Ferry, was bringen könnte, rein auf der Technik lesen. Genau. Thema Caching. Also ist kontrovers. Ich persönlich vertrete die Meinung, meine Daten sollten bei mir bleiben. Es geht keinem was an, wo meine User gerade sind. Und wenn ich irgendwelche Daten mit dem CDN wäre immer datenschutz thematisch hoch präsent. Wer aktuell den Vortrag... Wie bitte? Ja, es ist ein gravierender Unterschied, ob du deine Daten aktiv einbildest. Also wir gehen nach so tief ins Detail rein. Lass uns das gerne danach besprechen. Ansonsten wird das hier nichts. In dem Fall habe ich ein Unicorn Index geschaffen. Der Unicorn Index soll über die Präsentation euch klarmachen, welche Sachen sind sinnvoll und welche sind es nicht. Und in diesem Fall ist definitiv ein Mythos, dass CDNs für diesen Anwendungsweg wirklich Performance-Gewinne bringen. Im Worst Case machen sie es eher schlimmer. Warnisch. Warnisch ist es jetzt so ein Hype-Thema. Rede ich gerne drüber. Warnisch wird als Allheil-Lösung betrachtet, weil es eine serverseitige Software ist, die eure Webseiteninhalte nimmt, sie zwischenspeichert und an den User rausgibt. Und zwar viel, viel schneller als WordPresses kann. In der Theorie vollkommen richtig. 20% der User, die hier sitzen und die eine einfachere Workplace-Seite haben, ist Warnisch überhaupt nicht zu gebrauchen. Warum? Warnisch auf demselben Server zu betreiben, wie eure Workplace-Institution, heißt nur, dass sich da jetzt zwei Software-Stacks, nämlich PHP und Warnisch, um euren Arbeitsspeicher prügeln. Warnisch auf eurem eigenen Server zu betreiben, heißt, ihr müsst jemanden finden, der den betreiben kann. Das ist nicht einfach. Warnisch heißt auch, es macht einfach irgendwas. Und in dem Fall, ganz klare Empfehlung, ist eine nette Idee. Aber ich glaube, und bin der festen Überzeugung, ich habe noch keine einzelne Seite gesehen, bei der ein Warnisch für eine kleine Seite auch nur irgendwie gerechtfertigt wäre. In dem Fall definitiv Warnisch löst für eure normalen Webseiten keine Probleme. Wenn euch irgend ein Hoster andrehen will, dass Warnisch die Lösung an der Probleme sei, in der Regel nicht. Warum das so ist, kommen wir gleich zu. Es geht auch deutlich einfacher auf eurem Server-Regeln und erreichen mit viel weniger Aufwand. Mit Bordmitteln, mit einfachen Einstellungen, und mit Wissen, dass ihr alle habt, wenn ihr WordPress öfter benutzt. Klar, in die Probleme definitiv, man muss halt schauen, wie man ihn sinnvoll einsetzen kann. Die Frage war, bis zu der Anmerkung war, dass große Seiten in die Problematiken, die hier aufgeführt sind, natürlich auch eingeschlossen sind. Das stimmt. Natürlich, jedes Software ist komplex. Bei größeren Projekten kann man aber eher den Punkt erreichen, das ist das Aufbau der Einsatz. Okay? Super. Dann immer noch der Lieblingspunkt mehr Hardware. Man kann jede Ressourcen-Probleme im Performance-Problem mit Hardware lösen. Es ist nur eine Frage des Geldes. Da ist zum Teil was dran. Stimmt aber im ehrlicher Weise auch nicht, weil die Performance-Probleme, wie wir vorhin gesehen haben, meistens nicht durch irgendwelche Lastprobleme kommen, sondern viel, viel tiefer in das Software liegen. Und was auch immer der an Hardware hinstellt, bringt nix. Worüber man nachdenken kann, war die ganz klare Empfehlung, wenn ihr ein Root-Server habt oder ein V-Server oder irgendwas in der Richtung und der Vertrag ist alt. Denkt darüber nach, mal einen neuen abzuschließen. Die Hardware verdoppelt ihre Leistung alle ein, zwei Jahre. Wenn eure Verträge älter sind, dann kriegt ihr da in der Regel für Null-Aufpreis. Weil die Verträge der Hardware-Anbieter, sprich eurer Hoster, ja auch regelmäßig neu gemacht werden, der einzige Punkt, der wirklich sinnvoll ist und was bringt, sind SSDs. Bringt sowohl für euer PC zu Hause, für ein Laptop was, bringt auch im Server massiv was. Heißt, wenn ihr echte Server habt, fragt euren Anbieter, ob der SSDs drin sind, wenn nicht, besorgt euch SSDs für die Teile. Da sprechen wir jetzt nicht um, es wird ein bisschen schneller, sondern das bringt so richtig was. Ansonsten neue Hardware, nice try, aber wir haben andere Mittel, das besser hinzukriegen. So, in dem Fall, nein, besser der Hardware ist auch nicht die Lösung des Problems. Dann geben wir einen Punkt, der von vielen immer sehr als Beratung verkauft wird. Für eure kleinen WordPress-Webseiten ist das totaler Overkill. Der Ansatz mag richtig sein, dass man mit Performance-Optimierung, einer Software, also am Webserver, an PHP, Dinge erreichen kann. Für eure normalen WordPress-Webseiten verbrennt ihr da aber Geld, wie Sau, was ihr verzielt, der dann was bringt, wenn ihr alles andere schon gemacht habt. Alles andere sind die Sachen mit dem Unicorn Index 4. Wir sind immer noch bei 2, da geht noch was. Also ganz klar, Server-Konfiguration ist was für Profis. Wenn ihr nicht wisst, was ihr da tut, lasst am besten die Finger davon. Da kann man nämlich auch verdammt viel mit kaputt machen. Und wenn ihr irgendwelche betreuten Pakete habt, werdet ihr auch keinen Zugriff auf die Software haben. Oder überhaupt keinen Zugriff auf die Software. Und wahrscheinlich wollt ihr das auch gar nicht, oder? Ich glaube nicht. Lasst das mal Leute machen, die gerne im Dreck spielen. So, in dem Fall, nein, das ist auch nicht unser Allheilmittel. Jetzt begeben wir uns in die Spitze der Pyramide. Optimierungen an Bilddateien, an CSS-Dateien, bei der Einbindung, da sind Sachen, die man als M7 lösen kann. Heißt jetzt, wenn ihr das M7 nicht selber entwickelt habt, kommt ihr nicht ran. Wenn ihr da keinen Zugriff zu hart, dann müsst ihr diesen Weg auch gar nicht gehen wollen. Ist also was, wenn ihr das M7-Auto seid, hingegen, steckt die Zeit da rein. Folgt den Anleitung, die ihr im Internet findet, die ihr in den üblichen Tutorials findet. Wo bindet man idealerweise Bilder ein? Wo bildet man CSS ein? Wie macht man das? Liefert eure Teams mit gepackten CSS und Javascript aus. Man kann damit unglaublich viel optimieren. Allerdings ist der Aufwand dahinter extrem hoch. Wenn man halt einerseits nicht weiß, was man tut, oder wenn man da selber keinen Zugriff drauf hat. So als Team-Autor könnt ihr da aber echt viel richtig machen. Es nachträglich zu machen, weil meine Seite gerade langsam ist, eher nicht. In dem Fall bewegen wir uns auf ein Unicorn-Index von 3 zu, weil persönlicherweise ist das wirklich gut, aber Aufgabe des Team-Outdoors. Was ihr übrigens auch machen könnt, nervt den Team-Autor. Wenn ihr ein Team gekauft habt, nervt ihn, dass er seine Teams verbessert. Die Tools für, die nennen sich Google PageSpeed. Viele von euch werden das kennen. Das gibt es als Web-Anwendung oder als Placken für Google Chrome zum Beispiel. Der schaut über eure Seite drüber und zeigt euch genau solche Sachen. Wo sind Bilder schlecht eingebunden? Wo sind Daten nicht komprimiert? Was kann ich generell besser machen? Den Test durchzuführen kostet genau 0 Wissen. 1 bis 3 Minuten eurer Lebenszeit. Und liefert viele Erkenntnisse, die mit ein bisschen Aufwand gut umsetzbar sind. Als Team-Autor sollte man das Tool kennen und als Team-Autor sollte man diesen Sachen dann auch folgen, weil es sind sinnvolle Vorschläge. Meistens weiß Google ja was gut ist, auch wenn sie nicht immer die besten Absichten dahinter haben. Jetzt gehen wir in eine Richtung um Schade, der Unicorn-Index ist schon da. Verdammt. Komprimierung. Wir bewegen uns jetzt langsam in die Bereiche, dass man mit einem eigenen Einsatz verdammt viel reißen könnte. Komprimierung ist nichts weiter als das technische Zusammenpacken von Dateien, was ihr kennt, wie ihr in ihren ZIP-Archiv erstellt. Das kann der Web-Server für euch machen. Was passiert da? Man muss im Apache genau eine Einstellung setzen, das ist eine Zahl, die man in die HT-Access schreiben kann. Im Engine X kann man das auch zentral konfigurieren. Und dann nimmt der Server sich die Daten, die er generiert, packt die zusammen, entfernt alle Leerzeichen und das heißt für euch mal ebenso on-the-fly nebenbei, dass ihr ungefähr 80% der übertragenen Daten eurer Webseite einspart. Wenn ihr nicht komprimiert und eure Seite war vorher im B groß, dann kommen vielleicht noch 2-300 KB durch die Leitung. Lange Zeit war das verpönt, weil es wo viel CPU-Leistung gefressen hat. Wir erinnern uns zurück an das erste Charakter-CPU-Leistung, kostenlichst drauf geschissen. So, in diesem Fall Komprimierung trifft alles, was seit Textdateien sind. Und daher ist es quasi fast alles. Ja, was kript CSS, HTML, was bleibt denn noch? Bilder, genau. Aber das ist halt auch nicht so schlimm, weil JPEGs in der Regel bereits komprimiert sind. Wir hatten eine Frage. Wir hatten gerade die Frage, ob es Unterschied zwischen G-Zip und Modiflate gibt und in dem Fall Nein. Die Algorithmen dahinter sind hindänglich bekannt und ob du da jetzt noch ein Prozent mehr oder weniger rausholst, ist im Endeffekt total banal. Im Endeffekt ist das ja nur, das eine ist Standardmechanismus vom Server und das andere ist noch eine eigene Implementierung über eine Patchy-Modul. Sprich, Empfehlung wurde eher dahin G-Zip zu benutzen, weil das nicht am Modiflate von der Patchy hängt. Aber es ist Banane, was du dann nimmst. Du wirst in beiden dieselben Ergebnisse bekommen, wenn der eine besser wäre als der andere, dann hätt sich eins von beiden durchgesetzt. Das ist wie Cola und Pepsi. Geben das, was er am liebsten mag. Caching, Komprimierung sind unterschiedliche Dinge. Caching kommen wir gleich zu. Schön, dass du uns ansprichst. Unicorn Index 4. Komprimierung, also Pluckin komme ich auch gleich zu. Aber Komprimierung im Idealfall benutzt dafür kein Pluckin. Schaltet es im Server ein. HTXS EngineX-Config. Generell Probleme an der Wurzel lösen. Pluckins sind nicht die Lösung. Pluckins sind immer ein Drum herumarbeiten. Und ihr erinnert euch 600 Millisekunden PRP 200 MySQL 200 Auslieferung. Da gibt es ein Pluckin für. Ein Pluckin ist PRP. Findet ihn Fehler. Da kommen wir gleich aber noch zu. Das nächste Thema, Browsercaching. Auch schön. Auch das ist etwas, das macht der Web-Server für euch. Das macht euer Patchy. Das macht der EngineX für euch. Was müsst ihr machen? Die Browsercaching-Config. Nur sagen, lieber Web-Server wenn der Kunde vorbeikommt, sag ihm doch mal, dass wir hier Dateien haben, die er sich erst nächstes Jahr wieder abrufen muss. Sternchen muss man aufpassen. Wenn ihr jetzt ein N7-Update habt oder sich irgendwie Dateien ändern und der Web-Server hat dem Kunden gesagt, hol dir das nächstes Jahr wieder. Was macht man denn dann? Weil dann fragt der Browser das Kunden im Cashroom. Detailprobleme, großer Vorteil. All diese Probleme mit, ich habe so viele große CSS und ja, was Grip-Dateien. Werden damit komplett banal nach dem ersten Seitenaufruf. Die Dateien sind beim Browser des Users angekommen, werden dort gespeichert. Und was heißt das für ihn? Er muss ihn nicht mehr runterladen. Diese Dateien könnt ihr komplett aus eurer Rechnung rausnehmen. Er fragt nur noch mal kurz nach, er hat sich da was geändert, der Web-Server wird sagen, und der Browser zeigt dann einfach, was er hat. So, spart sich also, das gesamte nachladen, traumhaft. Wenn ihr jetzt überlegt, dass ein normales Team mit mindestens 1-2 CSS-Dateien kommt, die 18 Pluckins, die er verwendet, jeweils noch eine CSS-Datei mit reinbringen und ja, was Grip-Dessumiert sich, verdammt. Sondern habt ihr vielleicht beim ersten Ladeaufruf, wenn ihr gut seid, vielleicht 1,3 Sekunden und alle folgenden Aufrufe dann vielleicht noch 6-700 Millisekunden. Weil es einfach eine riesige Latte an Sachen gibt, die man nicht mehr runterladen muss. Einrichtungsaufwand, 2 Minuten. Wenn ihr eure FDP-Daten nicht dabei habt, sind es vielleicht 5. Aber das ist lächerlich wenig für den Ertrag, den ihr dadurch bekommt. Wenn ihr dieses Problem mit Updates von Dateien angehen wollt, dann einfach nur als Stichwort in den Raum quaschen, worgen Cash-Buster. Bei WordPress seht ihr, dass das bei WordPress immer per Fragezeichen die Version der aktuellen WordPress-Version angehängt wird in den Dateien. Ansonsten habt ihr halt irgendwann ein Update und wundert sich, warum den ganzen User sich melden oder was nicht läuft. Ja, Browser-Cache löschen. Auch ein guter Tipp, wenn mal irgendjemand etwas sagt im Sinne von, das sieht bei mir sehr komisch aus. Immer erst den Browser-Cache löschen. Und danach fragen, have you tried turning in off and on again. So, jetzt gehen wir in die Zandenebenen. Ein wenig mehr Aufwand, da hat eben der Kollege auch gefragt, gibt es da Pluckins für? Ja, da gibt es da Pluckins für. Ja, gibt es. Und wir bewegen uns jetzt auch wirklich in die großen Grün der Performance-Optimierungs-Möglichkeiten, die ihr in der Regel auf eurem Server ohne Probleme implementieren könnt. Es gibt da diverse Pluckins, namentlich zu erwähnen, während da Cacheify, W3 Total Cache oder WP Super Cache. Ich persönlich schwöre auf W3 Total Cache, weil es all das macht, was man will und weil es einfach verdammt viele Konfigurationsmöglichkeiten hat. Wer aber mit dem einfachsten Weg von Caching, von Server-Setting Caching arbeiten will, der ist mit Cacheify von der deutschen Workforce-Community entwickelt, einfach auch gut bedient. Also klare Empfehlung in diese Richtung. Server Caching, was ist das überhaupt? Warum ist das so genial? Wir hatten vorhin Themen wie Warnisch, wir hatten immer so gesprochen, da ist irgendwas, wenn ich diese 600 Millisekunden in jedem Request wegbekomme, dann habe ich aber nur noch 400 Millisekunden, die diese Auslieferungszeit benötigt. Ich will auch also den PHP-Code weg haben. Server Caching heißt, da essen Pluckin, das nimmt sich einmal die Seite, erzeugt sie und macht daraus eine stinknormale pupslangweilige HTML-Seite. Geil. So, jetzt kommt der User an und was macht dann der Server, da ist halt der Schritt der Konfiguration sehr wichtig. Statt WordPress anzufragen, WordPress geht nicht da, man holt PHP, WordPress erzeugt eine Seite, geht da auf den Server, findet die HTML-Datei und gibt die HTML-Datei zurück. WordPress bekommt davon nichts mit. PHP wird nicht aufgerufen. Es ist alles gut. In dem Fall muss man halt wirklich einmal den Server dazugehen, konfigurieren, dass der Server zuerst guckt, gibt es eine HTML-Datei, wenn nein, dann gehe an WordPress HTML-Datei, HTML-Datei zurück, fertig. Die Pluckins kümmern sich um die gesamte Erstellung der HTML-Datei, um die neue Erstellung der HTML-Datei, die Pluckins löschen die HTML-Dateien, wenn es ein Update gibt. Man muss da natürlich bei dynamischen Content sauer aufpassen. Dynamischer Content ist in dem Fall ein Shop oder eine Community, BodyFest oder ein Easy-Digital-Download, ein Warenkorb, irgend sowas. Weil auch die Sachen können gecached werden. Und wenn der nächste User den Warenkorb sieht, dann ist das nicht schön. Sollte die Auftragsentwickler sein, wird das eure Kunden nicht freuen. Da müsst ihr also aufpassen. Fehler haben viele gemacht. Und die Lösungen für solche Caching-Fehler sind halt in der Tat diese 3, die hier dran stehen. Caching ist eine Schichtkomplexität. Ihr könnt den Cache vielleicht reingucken, vielleicht nicht, je nachdem, wer implementiert ist. Man muss da halt wirklich 2-mal überlegen, wo jetzt ein Fehler hängt, wenn es ein Fehler gibt. Jede Schicht an zusätzlicher Komplexität macht es halt schwierig. Wenn ihr immer ihr neues Software oder irgendein weiteres System habt, das Content vorhält oder dass halt eure Version von alten Blog-Posts drin hat. Ja, sieht der User jetzt das, was bei mir in WordPress drin ist? Oder sieht der User vielleicht ihr habt es gehört? Wenn ihr so was einsetzt und ihr habt mal Probleme damit, dann denkt daran, da hat der Jan mal was gesagt. Aber ansonsten, das sind alle Sachen, damit kann man leben. Damit kann man sich arrangieren, das ist vielleicht eine Anpassung im eigenen Arbeitsworkflow. Aber das ist nichts, was ein großer Hindernungsgrund ist, Caching einzusetzen. Ganz im Gegenteil. Es ist genauso wie wenn man PRP einsetzt und da halt irgendwelche Zeichen vergisst. Dann ist die Seite halt kaputt. Wenn man es weiß, kann man es relativ schnell beheben. Das hatten wir eben auch schon. Und daher vielen Dank für diese passende Überleitung. Es gibt viele tolle Pluckins, die meinen, sie können Code optimieren. Es gibt viele tolle Pluckins, die meinen, sie können eure WordPress-Seite besser machen. All diese Pluckins haben gemeint, dass sie in PRP geschrieben wurden. Und all diese Pluckins haben gemeint, dass sie das Problem schlimmer machen, was ihr eigentlich lösen wollt. Sie bringen euch vielleicht irgendwelche Funktionen zur... Ich hab keine Ahnung. Das mag stimmen. Aber ihr gekauft euch das natürlich, dadurch, dass dann die WordPress-Seite insgesamt langsamer wird. Einfach mehr PRP-Code, mehr Pluckins, höhere Fehleranfälligkeit. Irgendwann wird das Becken langsam. Irgendwann wird die Seite vorne langsam. Und Pluckins an sich sind halt nicht die Lösung, um eure Performance-Probleme zu lösen. Da, wo man sie lösen kann, sollte man sie direkt am Server lösen. Das ist die Apache-Konfiguration. Das sind die Ebenen darunter. Pluckins findet, die irgendetwas Tolles machen. Ganz klarer Empfehlung. Schaut euch inhaltlich an, was sie tun. Und fragt vielleicht einfach mal nach, ob man das nicht auch einfach über eine RTXS-Regel lösen kann. Griff ist das Beispiel Rewrite Rules. Es gibt tolle Pluckins, die euch das komplett in PRP lösen. Das ist die dümmste Idee ever. Das sind Sachen, die man in die Konfiguration vom Server eintriegt. Der macht das in einer Millisekunde und fertig ist das Ganze. Man muss, um einen blöden Rewrite zu machen, dann ist das eine ziemlich blöde Idee. In dem Fall also, Optimierungspluckins nutzen, nein, wird bedacht, Caching-Pluckins nutzen, auf jeden Fall. Und generell, was ihr tut, denkt dran, euer größter Fein ist PRP-Put. Und wann immer ihr merkt, dass euer Workplus langsam wird, ist es entweder die Anzahl der Pluckins oder noch viel schlimmer, aber es gibt eine Qualitätsunterschiede. Heißt, wenn ihr drei Pluckins für denselben Use-Case habt, die als Beispiel ein Formular ändern, kann es sein, dass das eine so schlecht programmiert ist, dass es eure gesamte Seite langsam macht. Probiert das aus, guckt euch an, was da funktioniert für euch und denkt immer daran, Pluckins sind das, was Workplus langsam machen. Workplus an sich ist nicht langsam. Optimiert mit Bedacht und optimiert. Und nun geht hin und genießt die letzten Vortrag des Tages. Gibt es noch Fragen? Ich kann nicht die ganze Seite cashing, aber teile der Seite zu cashing. Eine Frage war, ist es sinnvoll, bei vielen Datenmangapragen ein Fragmentcaching einzuführen, sprich Fragmentcaching heißt, ich casche keine kompletten Seiten, sondern zum Beispiel, neben die Startseite, ich habe das in einem Template und ich casche davon alles außer, zum Beispiel eine persönliche Anrede. Das ist dynamischer Content. Ist absolut sinnvoll, allerdings funktioniert das nur, weil jemand das entwickeln muss. Davon abgesehen ist das eine grandiose Lösung, weil es einfach Flexibilität ermöglicht. Bringt natürlich auch wieder auf der Gegenseite mit sich, dass man speziell einen Code dafür schreiben muss. Aber alles, was man caschen kann, funktioniert. Es gibt ja auch noch Datenbankcaching und Objektcaching. Es hilft alles. Das ist ja ein Wölternschutz, dass du ohne Stress einbauchst. Hier nochmal der Hinweis, WP Transients gibt es, es gibt den WP Objectcache, dass du auf dieser Seite um halt eure Pluckins und euren Code für cashing vorzubereiten. Guckt euch da mal rum. Ich glaube, Ralf ist auch gerne als Gesprächspartner bereits seine Erfahrungen zu teilen. Super. Weitere Fragen oder Diskussionsansätze oder da hinten. Die Frage war, wie kann man die Performance bei dynamischen Seiten optimieren. Davon halt einen Servercache, einen HTMLcache nicht greift. Sprich, da wo ich eigentlich immer neue Seiten habe. Wir haben genau den Fall mit einer ziemlich großen Bodypress-Community mit inzwischen knapp 10.000 aktiven Mitgliedern. Kleinig Mini Facebook quasi. Und in dem Fall kann man von der Seite nichts caschen. Gar nichts. Wenn man etwas caschen wollen würde, dann hat man immer die Gefahr, dass da irgendwelche dynamischen personalisierten Inhalte drin sind oder es einfach zu Problemen kommt. Man muss den Code optimieren. Das heißt, da musst du wirklich in die Anwendung reingehen und schauen, was sind die Funktionen, die viel Leistung fressen und die optimieren. Sprich, Datenbankabfragen kann man auf alternative Wege noch deutlich verbessern. Du kannst Funktionsaufrufe auslagern und du musst halt schauen, dass du möglichst viel vom Programmcode in den Objectcache bekommst oder beziehungsweise in den PHPcache. Also der Centopcache zum Beispiel. Andere Chancen hast du da nicht. Gehört? Es war gerade noch die Ergänzung mit Inhalte per Ajax nachladen, weil wir es noch ein paar Cache ausgeben lassen. Weil der Ajax Call über Admin Ajax wird nie gecached. Technisch gesehen erstmal gar nicht. Die Frage in dem Fall war, wie kann ich denn, wenn ich aus Versehen das Browser caching für JavaScript und CSS aktiviert habe und jetzt doch eine Änderung habe, wie kann ich dem User denn das Update zukommen lassen, ohne ihm eine Mail schreiben zu müssen. In dem Fall technisch erstmal gar nicht. Wenn man dem Browser sagt, ich bin ja cachebar, dann folgt er dem auch ziemlich blöd. Die einfache Lösungen sind diese Cache-Buster. Sprich die Einbindung der Teile ändern und irgendein Parameter ranhängen. Fragezeichen, Version ist gleich 1.3.5.6 statt der alten Version. Du musst dem Browser quasi dazu bringen, dass er denkt, es wäre eine neue Datei. Danach caching egal und die Parameter hinten dran sind für ihn mit Datei-Inhalt. Ansonsten keine Chance. Gut so. Ansonsten hättest du wieder Probleme, wenn das dann doch wieder neu wird und es kann nicht neu laden soll. Ja. Nee, daher auch, wenn ihr Code selber entwickelten, so was Cache-Buster einbauen, an die Versionsnummer hängen und dann wirklich caching auf ein Ja. Wenn sich da an den Placken im Sieben nichts ändert, freuen sich eure User und eure Website-Geschwindigkeit auch. Darum links, ah. Das Ergebnis wird funktionieren. Also Out Optimize war die Frage, was wir zusammenfügen. Wenn man keine andere Wahl hat, dann führt es zum Erfolg, wenn man es mit caching einsetzt. Sprich, wenn man die Dateien einmal zusammen komprimieren lässt und dann statt 20 Ja, was gibt uns CSS-Dateien nur noch eine oder zwei hat, das funktioniert so lange, lange man es hat nur einmal erzeugt und der Browser in die Seite hat und immer wieder ausliefert. Wenn das Placken immer wieder laufen muss, weil wir kein caching haben, ist das totaler Müll, die betrifft den ersten Seitenaufruf. Danach sind die Daten im Cache und werden nicht erneut abgerufen. Dann ist es egal, ob es 1 oder 20 sind. Dann ist es vollkommen ideal und unwichtig, ob die dann jetzt 100 Kilobyte in einer oder 10 mal 10 Kilobyte sind, weil sie sind im Browsercache. Unter dem Aspekt, ich würde mich freuen, wenn Plackenentwickler und Siemenentwickler bei sowas mehr aufpassen und selber bereits diese Pakete ausliefern, um das Problem an der Wurzel zu lösen, sprich mehr Bewusstsein dafür bei sich selber aufbauen, dass ich ja bereits so ein Paket liefern kann. Warum soll denn der User erst das Problem quasi lösen müssen? Der im schlimmsten Fall überhaupt nicht weiß, was er da zusammenpackt und was das Ergebnis ist. Also ihr holt euch gleich eine totale neue Fehlerquelle rein. Ja, absolut. Also sinnvoll, ja. Aber meistens kommen ja die Großteil der CSS-Mia, was gibt es aus dem Steam, was wir da nachgeladen werden, wo irgendwelche Drittanbieter-Libraries mit drin sind, wo dann irgendwelche jacquery-Pluckins mit reinkommen, irgendwelche jacquery-UI-Elemente oder noch ein Front-Awesome nachgeladen wird. Und das ist einfach total müßig, dass der User sich da beschäftigen muss. Das ist im Steam-Entwicklungsprozess ein Schritt im Bildprozess, wo man dann sagt, mache mir meinen 7.min.punkt irgendwas und der User ist glücklich. Und wenn ich dann auch fünf Pluckins habe und nachher sechs Dateien habe, dann bin ich glücklich. Und es ist halt vom Gewinn her marginal. No way. Da ist es dann auch wieder ein bisschen mühzig. Genau. Da weiß gerade der Hinweis, Kontakt vom 7.min.punkt springt eine Option mit, dass man das CSS-Mia, was Grip nur auf den Seiten auch nachlädt, wo man es braucht, ist ein hervorragender Punkt, warum solche Pluckins, die den Crew zusammenmanschen, die man hätte, zu nicht gemacht. Dadurch, dass man denkt, ah, da ist ein CSS, fange ich mir mein Gesamt-CSS. Auf einmal ist dann der Code überall mit drin. Und da ist halt der Punkt, die einzigen Personen, die wissen, wie und wo CSS und ja, was Grip ausgespielt werden soll, sind eigentlich die Entwickler dieses Codes. Und kein User kann komplett durchdringen, wie denn die Einbindung, wo gelöst ist. Also, in meinen Augen sind die Pluckins halt von der Idee her gut, setzen aber an einer komplett falschen Stelle an. Pest oder Cholera? Ein bisschen. Oder Pepsi? Oder Pepsi. So beschrieben, dass die NL, weil die meisten Automaragisse auch direkt ein Auto Minifall machen, manche Jaras Grip Cousins so beschrieben, dass das nicht funktioniert und da direkt ein Fehler geworden wird. Hinweis noch, wenn ein Minifall bei diesem Komprimieren gemacht wird, spricht der Teil, wenn kleiner gemacht und zusammengepackt, dann kann es euch aus auch Jaras Grip Code geben, aber auch immer. Man kann sich da auch neue Fehler reinholen. Ganz klar. Es gibt ja inzwischen auch, gerade in der Entwicklung, also in der Agenturgeschäft, quasi so Lade, as Loading Budgets, wo man sich sagt, okay, ich habe jetzt für die Startseite 210 Kilowatt. Der Ansatz, mit dem ich packe alles zusammen, läuft dem dann halt komplett entgegen, weil man dann eher schaute, wie kann ich möglichst wenig, was ich wirklich brauche, auf der Seite ausspielen, statt hat viel auf einmal. Bei den heutigen Internetanbindungen tun Request halt weniger weh, als die Ladezeit in der Seite gerendert wird, ob das da ist. Das ist ja das, was Sie garantiert kennen. Es gibt ja auch Seiten, die sind da, könnt ihr schon was machen, aber die Funktion laden erst nach und nach. Der Ansatz, wo halt das HTML-Rendering schnell ist. Das kann man auch dann erreichen, und dann Asynchron nachlädt. Also da, ob definitiv gut dahin sein ist. Und auch wenn HTT-P2 jetzt als neues Protokoll genau diesen Ansatz fährt, dann wird das ja schon die richtige Richtung sein. Da sitzen kluge Menschen hinter, da sitzen Menschen hinter, die sich mit Xanom beschäftigen, als Spezifikation zu schreiben, um wie unser Internet funktioniert. Also warum nicht deren Ideen aufgreifen und für unsere Zwecke nutzen. Und dann auch noch die Benefits von dem HTT-P2 mitbringen, dass er diese Möglichkeiten von dem dynamischen Nachladen auch hat. Wenn man eine große Datei hat oder große Quellen, kann man es nicht nutzen. Danke für den Hinweis. Das, was ich gezeigt habe, gilt für alle PHP-Versionen. Der Test ist mit PHP 5.6 gemacht. PHP 7 gegenüber 5.6 bringt halt irgendwas von von 1,5 bis 2, irgendwas Paralleistungen, wenn man Glück hat. Je nachdem, von wo man kommt, ist die Leistung dann 4-8-mal so groß, von einem PHP 5.2 oder 5.3. Aber losgelöst davon, wir haben PHP als großes Feld, wo wir optimieren können. Und das können wir relativ einfach. Bei den anderen Faktoren können wir nicht einfach optimieren. Wir können nicht den Weg des Users von seinem Internetanschluss hin zum Server kappen. Da ist halt so ein langes Kabel, das einmal vielleicht um die halbe Welt geht. Da ist sein Telekomanschluss, der mit 16 Mbit bepreist und 2 liefert. Da können wir halt nichts machen. So, PHP, da können wir ran. Aber PHP 7 ein guter Punkt. Klar, aktuelle Software. Immer aktuelle Software verwenden. Leistungsgeschwindigkeitsverbesserung kriegt man darüber mit, ganz davon losgelöst, dass es glatter Selbstmord ist, alte Version auf Web-Server zu verwenden. Und zu PHP 7 sei gesagt, es ist zwar produktiv und stabil, es gibt aber noch genug Ecken und Kanten, wo es bei WordPress Plugins knallt. Wenn ihr also auf PHP 7 wechseln wollt, dann habt ihr halt Zeit. Ansonsten habt ihr irgendwann das Problem, dass ihr auf weiße Seiten lauft und euch fragt, man habt doch nichts gemacht. Ansonsten, PHP 7, aktuelle Software-Version gibt dem den noch ein halbes Jahr bis Jahr Zeit, danach super. Dann werden aus den 600 Millisekunden vielleicht 400 oder 500. Okay, vielen Dank.