 Ich atme ein bisschen krass. Liegt an dir. Herzlich willkommen zu meinem Vortrag, wie du dein WordPress für hohe Lastfit machst. Ich arbeite bei Raidboxes. Das ist ein Webhoster. Wir spezisiere uns auf WordPress. Und wir haben öfter Kundenanfragen. Ey, ich bin bei ... Die Höhle des Löwen. Ey, ich bin bei Galileo. Reicht meine Seite dafür. Das ist natürlich eine richtig, richtig geile Frage. Grundsätzlich nein. Ist immer ungefähr das erste, was ich in der Support-Share antworte. Danach gucke ich mir die Seite an. Und sehe, nein, es reicht tatsächlich nicht dafür. Es hat meist verschiedene Gründe. Auf diese Gründe möchte ich eingehen. Ich habe nur ca. 35 Minuten eingeplant. Weil wir dann eine kleine Frage-Antwortspieche am Ende machen. Über Lieblingsfarbe, Geschlechtskrankheiten und so was. Aber deswegen habe ich nur 35 Minuten eingeplant. 10 Minuten ist eine Fragerunde. Und in der Zwischenzeit erkläre ich euch, was wir grundsätzlich, oder was ihr grundsätzlich optimieren könnt, damit eure WordPress-Seiten für hohe Last gut sind. Zusätzlich habe ich noch ein Artikel geschrieben, der nächste Woche auf unserem Blog veröffentlicht. Der geht wirklich in die Tiefe mit Datenbankoptimierung, was Quarries sind, was man noch beachten sollte. Würde ich danach auch nochmal reingucken, weil das ist hier ein grober Umriss. Und dann geht es nochmal in den Artikel in die Tiefe. Alles klar. Grundsätzlich habe ich einen 15-Punkt-Plan, der wiederum in einem 7-Punkt-Oberplan gepfelt. Und die 7 Punkte sind einmal Planung, Infrastruktur optimieren, das Backend optimieren, das Frontend optimieren, Offside optimieren, Test & Reporting und am Ende die Liveschaltung der Erfolg. Wir kommen zum Punkt 1. Dazu gehört die Zeit in der Planung. Grundsätzlich sage ich immer, nehmt euch 4 Wochen Zeit Minimum. Manche sagen 2 Wochen. Ich sage 4 Wochen, warum sage ich 4 Wochen? Ganz einfache Geschichte. Eventuell musst du zum Beispiel dein Hosting wechseln, dein Domain umziehen und dann ist da ein Domain-Lock auf deiner Komm-Domain und du kriegst dich nicht rechtzeitig umgezogen und dann ist alles im Arsch nicht Wolle. Zusätzlich musst du natürlich das mit deinem Team absprechen, mit dem Marketing-Team, mit den Leuten, mit denen du zum Beispiel brechen musst, warum du so viel hohe Last bekommst und auch noch eventuell mit deinem Entwickler, wenn du nicht selbst einer bist. Das ist alles etwas, was sehr viel Zeit braucht. Unter anderem auch der nächste Punkt, also Unterpunkt viel mehr in der Planung ist eventuell eine Rechstrukturierung, Rechkonzeptionierung. Zum Beispiel solche Sachen wie brauchst du wirklich deine Monitoring-Tools wie Matomo Pumba oder Google Analytics in deinem Wordpress-Dashboard. Muss das wirklich sein? Kannst du das nicht off-site haben ohne, dass dein Wordpress weiter belastet wird? Solche Grundsatzfragen musst du stellen und musst die wirklich mit deiner Materie mit deiner Seite auseinandersetzen. Wenn du das getan hast mit allen Leuten durch geplantet hast, kommt der allerwichtigste Punkt meiner Meinung nach. Das ist Hosting, natürlich sage ich das als Hosting-Witarbeiter, aber es ist so. Leute, come on. Da ist es natürlich wichtig, in erster Linie auf ein Hoster zu setzen, der keine Limitierung deines Tarifs hat. Zum Beispiel keine Limitierung des Traffics oder ich sag mal Shared Hosting auf einem kleinen Miniserver und du klaust natürlich den ganzen anderen Kunden im Zweifelsfall Speicher- und CPU-Zeit. Das ist natürlich blöd oder die klauen es dir. Das ist für dich natürlich blöd. Das heißt, du sollst auf jeden Fall dich rechtzeitig mit deinem Hoster in Verbindung setzen und sagen, hey, wie sieht's aus? Ich bin dann und dann erwarte ich viel Last, 60.000 Pageviews oder sonst irgendwas. Geht das in diesem Tarif? Geht das in diesem Plan? Brauche ich mehr CPU? Brauche ich mehr RAM? Brauche ich sonst noch irgendwas? Die meisten Männische Hoster sind natürlich super gerne beantworten und dich dahingehend beraten. Wir hatten allerdings auch schon Kunden, die sind dann zu unseren Kunden geworden, weil deren Hoster gesagt hat, oh, da können wir dich nicht null unterstützen. Wir machen kein Webdesign. Guck, wie du klarkommst. Wenn ihr so ein Hoster vor euch habt, es ist definitiv Zeit zu wechseln. Die komme ich wieder zum Punkt Zeit. Ihr müsst den Umzug planen. Ihr müsst höchstwahrscheinlich die Domain umziehen. Ihr müsst gucken, wie das mit den E-Mails ist. Ihr müsst gucken, wie das, ob ihr noch ein CD-Ende geforteschaltet habt. Etc. Deshalb nochmal 4 ganze Wochen. Was wir öfter machen, einen Kunden kommt und sagen, ich bin bei die Höhle des Löwen, ich nenn es einem Kindmann beim Namen und dann kommt dann ein Ausstrahl, wir erwarten viel Treffig. Dann gucke ich mir den Tarif an und sage, geht nicht in deinem Tarif. Dann sage ich, wir stufen dich für die Zeit der Ausstrahlung und vielleicht noch 2-3 Tage nach hoch. Du zahlst halt weniger Geld und du brauchst wirklich nur die Zeit, wo du wirklich das bekommst. Machen auch viele Hoster, kann ich wirklich nur empfehlen. Egal ob ihr es bei uns macht, woanders wirklich fragen, gibt es die Möglichkeit von temporären Upgrades. Nächster Punkt, auf den ich jetzt nicht exizit eingehen, ist Autoskalierung. Was bedeutet, dein Server kriegt automatisch mit, oh shit, da kommt ganz viel rein, ich muss die Tore weiter öffnen, ich muss mehr RAM, ich muss mehr CPU schrauben, auch ein supergeiles Bild, wenn man es richtig eingerichtet hat, aber da kann ich erst mal Ticket drauf eingehen, das wäre ein ganz eigener Vortrag. Er hat mit eurem Hoster gesprochen und er sagt, alles klar, cool, den und den Tarif empfehlen wir? Nein. Hätte ich vielleicht Eingangs erwähnen sollen, die Frage war nämlich, ob wir was anderes sehen sollten als diese Seite? Nein. Ich halte meine Vorträge gerne sehr unvisuell, damit ihr A nicht abgelenkt wird und mir auch zuhört und B, versuche ich, kann ich jetzt auch ein bisschen mehr mit Interaktion, ich bin nicht so eingeengt von irgendwelchen Folien. Es gibt noch eine zweite Folie, da sieht nicht nur das Bild die ganze Zeit, aber es gibt auch ein anderes, und zwar ein Live-Test. Ihr habt alles mit eurem Hoster geklärt, ihr seid total glücklich. Was ist das nächste, was kommt? Was willt ihr sagen? Irgendwelche Ideen. Okay, dann sage ich es euch einfach. Kein Witz, ein Backup. Backup, deshalb, weil jetzt kannst du, musst du anfangen, in die Tiefe deiner Seite zu gehen und du musst einen Code rumfummeln, musst DNS Records ändern. Gut, da gibt es nicht, wir gehen Backup für, aber alles, was jetzt passiert, sollte als Versionierungsbackup vorliegen. Wenn du z.B. sagst, okay, dieses Plug-in brauche ich gar nicht mehr, dann schmeiß ich das mal raus, mach vorher ein Backup, weil später merkst du, oh Scheiße, ich brauche das doch, mein Checkout funktioniert gar nicht mehr, Kunden können nichts kaufen. Solche Geschichten. Okay, cool. Einsätzlich immer legt euch Versionierungsbackups an. Also solche Geschichten wie Plug-in-Updates, Team-Updates, PRP-Versionwechsel und solche Geschichten. Wenn das Backup einmal steht, top. Ich mach da, hab da. Hatta, cool, alles klar. Backup, hatta, cool, super. Da gibt es zwei Möglichkeiten. Möglichkeit Nummer eins. Da muss ich ein Obst ausziehen. Ja, okay. Da muss ich mir jetzt ein bisschen lauter reden. Es gibt zwei Möglichkeiten, Backups zu machen. Einmal natürlich die Backups über Plug-ins. Kennen wir alle WP Backup. Zum Beispiel werde ich auch ein Artikel weiter erläutern. Dann haben wir ein paar Vorschläge. WP Backup ist auch von den Kollegen von... Was regst du? Ich meine natürlich Backup-WP Entschuldigung. Supertool von deutschen Entwicklern. Datenschutzgerecht. Top, top. Kann ich nur empfehlen. Allerdings, natürlich in der Zeit, natürlich in das privaten Speicherplatz weg. Entweder direkt auf deinem Web-Post oder du musst es runterladen oder du musst es woanders im FSPP speichern oder in der Cloud, was eventuell nicht DSGVO konform sind, ist bei allen Backup-Pluck-Ins so. Deshalb gibt es natürlich Hostar, die schon integriertes Backups-System mit drin haben. Wo du zum Beispiel per One-Click sagen kannst, jetzt habe ich ein Plug-in geändert. Nicht in das Backup-Pluck-In geändert. Alles klar, Backup-Anlegen. Ich kann weitermachen. Das Boot-Spiel, das Backup-Heil. Zusätzlich, automatische Backup kann ich auch nur empfehlen. So, jetzt haben wir die Grundsätze erst mal erklärt, was wir vorher machen sollten, bevor wir ins eigentliche gehen. Das Einliche, das Eingemachte, ist das Caching. Caching ist ein Riesenthema, das ist der Faktor Nummer eins. Wenn es darum geht, seiten schnell die Serverlast auszuliefern, weiß hier irgendjemand nicht, was Caching ist. Supergeil, da muss ich das nicht erklären. Wenn ich sich nicht getraut habe zu melden, ich erkläre es nochmal mit einer netten Milchanalogie und meiner Mutter im Artikel. Ihr könnt ja alles nochmal nachlesen. Danke Mama. Wenn das Caching vernünftig funktioniert, dann ist grundsätzlich schon einiges getan. Und zwar sehr viel getan auf unserer Website. Das bedeutet, die Serverlast wird reduziert, weil wir haben weniger Requests und ein weiterer Vorteil ist, die Sachen werden so oder so schneller ausgeliefert, weil wir nicht immer wieder den selben Kram neue Requests haben müssen als Server. Es gibt nur zwei Dinge, die ein bisschen problematisch sind an der ganzen Geschichte. Vor allen Dingen, wenn du für solche Sachen wie die Höhe des Löwen oder sonst was optimierst, du hast meistens ein Produkt. Du hast also meistens ein Shop, du hast meistens einen Warenkorb und du hast meistens eine Kasse. Das heißt, Kasschen würden irgendwelche Kunden kaufen irgendwelche Sachen, die sich nicht in den Warenkorb gelegt haben mit irgendwelchen Daten, die ihnen nicht gehören. Das heißt, diese Seiten sind nicht cashbar. Sind sie einfach nicht. Es gibt Elemente auf den Seiten, die cashbar sind, aber nicht diese Seiten an sich. Das ist natürlich ein riesen Problem. Denn dort, im wichtigsten Teil, wo halt wirklich die Produkte gekauft werden, könnte es eventuell zu großen Lasten kommen. Das heißt, alles vorher muss so optimiert werden, dass das Caching und dass der Server kaum Last hat. Darauf möchte ich jetzt... Ich sage mal, noch nicht eingehen. Ich zeige das gleich am Live-Beispiel, warum das so wichtig ist und dann wieder so hoffentlich klar. Zusätzlich ist es ganz wichtig, in meiner Meinung nach, dass wir bestimmte Dinge minimieren. Zum Beispiel CSS-Dateien und JavaScript-Dateien. Gerade bei JavaScript-Dateien, die dynamische Request senden, ist es wichtig, dass die JavaScript-Datei schnell geladen wird. Und bei CSS-Dateien, die sowieso nur dafür da sind, irgendwas hübsch zu machen, eben dasselbe. Das heißt, wir installieren uns Plugins, wie zum Beispiel Minify.js oder Minify.css oder mein Lieblings-Plugin Merge, Minify und Refresh. Das reicht eigentlich im Runde genommen schon, um solche, ich sage mal, temporären statischen Dateien wirklich vernünftig zu cashen, dass wir das dann auch noch mehr werden können. Zum Beispiel als kleine Minidatei. Request werden minimiert, weil auch viele CSS und JS-Dateien zusammengefasst werden können. Zu einer großen, nur die muss geladen werden. Wir haben wieder ein paar Request weniger. Zum Beispiel alle CSS-Dateien von WooCommerce, von WooCommerce Germanize, von WooCommerce Checkout, WooCommerce Card etc. zusammenfassen. Zu einer CSS-Datei haben wir nur einen Request, anstatt vier. Und so ziehe ich die ganze Seite. Es ist nur zum Fehl. Meine Lieblings-Teile. Datenbank aufräumen. Wie wir alle wissen, besteht der größte Teil von WordPress-Inhalten. Abgesehen jetzt natürlich von Bildern und Videos aus Datenbank, also Texten in der Datenbank, um es ganz salopp zu sagen. Als allererstes machen wir ein Backup. Dann schauen wir uns an, was eigentlich Queries sind. Hat jemand eine Ahnung, was Datenbank Queries eigentlich sind? Richtig. Also, man sendet ein Request und bekommt eine Anfrage, eine Server wird eine Anfrage gestellt und der Server gibt eine Antwort. So ein Query kann unter anderem sehr, sehr, sehr lang sein. Und das ist ganz gefährlich. Wir hatten ein Shop, der aber optimal konfiguriert, der ist trotzdem daum gegangen, weil ein Produkt in den Warenkorb ein so unendlich langen Request also ein unendlich langen Query-Spring generiert hat, dass der Server einfach zusammengebrochen ist. Das ist weiterhin ein dynamischer Request. Du landest dann auf der Warenkorb-Seite und dieses Ding war 4MB groß. Es war ein verdammter String, der 4MB groß war. Bitte was? 10MB Antwort. Was? Was ist das denn jedes Mal ein E-Book oder was kam dann an? Alles klar. Ich erzähle euch mal ganz kurz, wie diese 4MB Request zustande kam. Es wurde über jedes Produkt iteriert. Jedes Produkt, was der Kunde hatte, wurde darüber iteriert und alle Produkte wurden mit in den Warenkorb gelegt, aber nur das aktive wurde als aktiv im Warenkorb gekennzeichnet. Ja. Ja. Ja. Also die Frage war, in WooCommerce ist es ja meistens so, egal in welchem Shop plug-in, dass solche Queries schon generiert werden und wie man so was ändern kann. Das kann dein Programmierer beziehungsweise. Im Normalfall passiert sowas nicht. Normalfall sollte sowas gar nicht passieren. In WooCommerce generiert auch im Normalfall nicht solche 4MB Queries. Man kann sich aber so was angucken. Man kann sich auch zusammen machen. Und wenn man sieht, das Ding ist riesig oder lang, wenn ich z.B. eine Aktion aus Führer wie Produkt in Warenkorb erledigen, schreibt man den Entwickler an oder wechselt ganz das Plug-in. In dem Fall, was passiert ist, der Entwickler hat diesen Fehler überhaupt erst gebaut. Weil für Tracking Tools wollte er gucken, welche Artikel alle in Warenkorb passen. Ich habe keine Ahnung. Aber da gibt es auf jeden Fall Möglichkeiten. Wir wissen jetzt, was ein Query ist und was passiert, wenn man Scheiße baut. Was kann man denn machen, damit es richtig läuft? Als Allererstes guckt man sich wirklich an, wie wird denn, wenn sich solche Queries generiert? Dafür gibt es ganz Tolle, das zeige ich mal eben, da gibt es ganz, ganz Tolle Abfragen für, die nicht in meiner Präsentation sind, was aber kein Problem darstellen sollte. Es gibt nämlich einen WP-Config-Eintrag, der man hineinschreibt, und dann endet man eine kleine Sache in seiner Functionspap, die Codes gibt dann alle zum Kopieren. Und man kann sich wirklich alle Queries auf der Seite als Administrator anzeigen lassen und sieht, wie lang ist dieser Query-String und was beinhaltet der. Gott sei Dank ist es meistens ein kompletter Clatex, wie zum Beispiel Name, Fragezeichen, sonst irgendwas. Und man sieht alles klar, dieses Ding beinhaltet alle Produkte oder dieses Ding beinhaltet dieses Produkt in den Warenkopf liegen mit dem Artikelbeschreibung zum Beispiel Mütze Rot. Und dann sieht man, okay, das ist ein regulärer Request, der geht klar, wenn dann aber steht, diesen Artikel in den Warenkopf legen, Mütze Rot, nicht Mütze Grün, nicht Mütze Blau, nicht Mütze Pink, nicht Mütze Lila. Ja, genau, richtig. Dieser Request ist definitiv zu lang. Also, alles etwas tiefer, wie schon gesagt, das gibt es alles in dem Artikel, genau eingehen. Reif ich das nur kurz an, aber vielen Dank für die Frage. Du hast noch eine Frage. Ja, cool. Kannst du theoretisch machen, ist extrem unsinnig, meiner Meinung nach, weil du kannst dir ja, weil du müsstest jedes Mal in die Datenmangel sehen, was wurde zuletzt geändert. Die Query String natürlich reinziehen, aber wozu, wenn du es dir direkt im Frontend anzeigen lassen kannst, Query Monitor. Wozu? Das Schöne ist, es gibt aber Plugins, wie der Kollege Daniel gerade schon sagen wollte, wie zum Beispiel den Query Monitor. Der Query Monitor zeigt dir halt wirklich an, was passiert da gerade. Macht nichts anderes als dieses Code Snippits, was ich vorgestellt habe, nur halt schon fertig als Plugin im Frontend, sondern im Backend deines WordPresses. Aber ganz wichtig, wenn ihr den Query Monitor befindet, vergesst nicht ihn wieder zu den Installieren. Hatten wir auch schon, war auch unschön, aber naja. Das ist ein grober Anriss, was Datenbank aufräumen angeht. Eine Sache, die mir auch ganz wichtig ist, ist Müll in der Datenbank. Müll in der Datenbank, wie zum Beispiel in der WP Options, die Seiten unendlich lange laden. Weil sie durch alles drüber müssen und gucken, oh, darf der das eigentlich? Oh, hier ist noch so ein AskMed- Activation-Kommentar von irgendwann, oh, da muss ich noch mal reingucken. Das ist ganz schön schlecht. Da habe ich mal vier Hauptgeschichten runtergeschrieben. Und die wirklich absoluter Müll sind und einfach auf der Website und der Datenbank nichts mehr zu suchen haben. Das sind einmal die Kommentare, die schon als Spam gekennzeichnet wurden und im Spam-Bereich liegen. Die werden trotzdem noch logischerweise in der Datenbank gespeichert. Braucht ihr eh nicht, ist Spam, kann weg, fertig. Mein Lieblingsthema, Revisionen. Revisionen von Beiträgen, Seiten und Entwürfen. Die meisten Leute wissen nicht, dass man Revisionen auch limitieren kann oder gar ausschalten müssen. Niemand hier braucht unendlich viele Revisionen seiner WordPress-Beiträge. 20 Revisionen, was Revisionen sind, ist allen bekannt? Super. Aber ja, noch nicht so ganz. Ja, zum Beispiel Entwicklungsstände, aber in diesem Fall von Beiträgen, von Seiten und Entwürfen. Genau, richtig. Wenn du nämlich zum Beispiel jetzt einen Beitrag schreibst und an mehreren Tagen diesen Beitrag schreibst, hast du ganz schön viele Revisionen meistens da drin, nachdem, wie es eingestellt ist. Und das ist ganz schön viel. Die haben 30-40 Revisionen pro Beitrag und da ist überall was in der Meta von dem Post das einfach auch mal bestimmt 30 MB einnimmt, weil da diese ganzen Strings mit drin sind. Kann also auch weg. Was Nächstes weg kann? Dinge im Papierkorb. Braucht keine Sau, weil es in Papierkorb. Fertig. Und mein Liebling, Beitrags- und Kommentarmetadaten wie die schon lange abgelaufen sind. Ist alles was etwas was deine Seite extrem runterzieht gerade bei so Sachen wie Ausstrahlung, wo du wirklich jedes Quentchen Performance brauchst ist es wichtig die Datenbank aufzuräumen. Ich habe da ganz schön viel zugeschrieben in meinem Artikel, aber es gibt ein TLDR, also too long didn't read. Ladet euch das Placheln WP Optimize runter und lasst es laufen. Was kommt vorher? Ganz genau. Wir spielen das Spiel jetzt gleich so ein bisschen durch. Sehr, sehr gut. WP Optimize macht schon ganz viel von diesen Geschichten. Also geht halt wirklich rein und sagt, Jo weg damit brauchst du nicht mehr. Es kommen Meter, das Ding brauchst du auch nicht mehr. Leg dir vor eine Liste an. Das sind die Sachen, die ich gerne löschen würde und aufräumen würde. Raus damit. Kann ich nur empfehlen. Was ist wieder eine Frage? Wie hoch das Risiko ist, dass dieses Placheln die Sachen aufräumt, die du nicht loswerden willst. Ich hatte es noch nie muss ich sagen, dass das Placheln etwas zerschossen hat. Allerdings was machen wir vorher? Backup, ganz genau. Genau. Wenn du ein Backup hast ist es sowieso egal. Dann probier das einfach wirklich rum und es gibt manche Sachen, die sind einfach safe und manche Sachen werden zum Beispiel als orange markiert. Pass hier auf. Wenn du das wirklich bereinigen willst, dann guckst du dir noch mal an, kannst du dir direkt ein Placken anzeigen lassen und dann schweißt du es raus. Kannst auch die manuelle Methode hingehen, die habe ich im Artikel geschrieben. Dies lang, dies langwierig, aber dies zu einer Prozent sicher, weil du musst ja ungefähr alles angucken. Dann haben wir Datenbank aufgeräumt. Jetzt sind wir schon mit den Updates von was? Updates deiner Software. Bevor ich von Beaten weggehe, ja. Wie sinnvoll sind Optimierungen, wie zum Beispiel Indices hinzufügen innerhalb der Datenbank? Das ist deine Frage richtig? Super. Alles klar. Es kommt ganz drauf an wie deine Struktur aufgebaut und welche Plugins du hast. Wenn du es wirklich schaffst, die Queries vernünftig zu indizieren und einen großen Index aufbauen kannst, der explizit sagen kann, das gehört dazu und das gehört dazu, ohne dass die Strings zu lang sind, ist es super. Aber das ist schon eine Sache, da musst du tief in die Datenbank. Was ich empfehlen kann, für solche Geschichten ist hinzugehen und bestimmte Plugins, wie zum Beispiel der Allerzibliote Revolution Slider, mal nachzugucken, was er zum Beispiel an Indices hinterlegt. Dann kann ich nur empfehlen, bei diesem Plugin mal hinzuschauen, weil, was er nämlich macht, in CSS-Klassen zu definieren in der Datenbank. Ja. Ich lass das mal so stehen, die Kollegen aus Köln von Team Punch wissen sicherlich, was sie tun. Aber ich kann nur empfehlen auf solche Sachen mal zu achten, also Indicierung, also Indices hinzufügen, kann man auf jeden Fall machen, wenn man weiß, was man tut. Ja. Okay, noch was zum Thema Datenbanken Okay, dann geben wir zum Update. Updates deiner Software. An allererste und wichtigste Software ist der Motor von WordPress, der da ist. Weiß es jemand? Hi. PHP, ganz genau. Jetzt können wir zu zweit ein Folie. Yay! Folie Nummer 2. Ich habe ein paar Request-Tests mit PHP laufen lassen auf einer WordPress-Seite, die ich euch gleich auch vorstellen möchte. Das sind ja die Request pro Sekunde, die PHP in einer bestimmten Version ausgeben kann. Holy shit, war das geil. Das Geil ist, die Seite LEAF, ursprünglich auf PHP 5.6. Also, ein WooCommerce-Shop im Jahre 2018 auf PHP 5.6. Könnt ihr euch natürlich vorstellen, so schnell habe ich das Ding auf PHP 7 gebracht. Mehr als das Doppelte. Mehr als das Doppelte. Das war schon richtig geil. Und das kann man grundsätzlich sagen, versucht immer, die Seite, die live gestellt wird, auf die höchste PHP-Version zu bringen. Dass es dabei Schwierigkeiten gibt, dazu kommen wir gleich. Das ist grundsätzlich erstmal meine Empfehlung. Wie ihr seht, es kann nur besser werden. Also, PHP 7.0 kann schon mehr als doppelt so viele Request pro Sekunde ausführen, wie PHP 5.6 und das in der Hälfte der Ladezeit, die PHP 5.6 braucht. Das Schöne dabei ist, das heißt, das Schöne. Das Gute dabei ist, wenn wir die PHP-Version upgraden, kommen wir zwangsweise nicht herum herum, sondern abzudaten. Alles klar, WordPress abzudaten und auch deine Pluckins und Teams abzudaten. Ich habe nur noch 10 Minuten, und dann geht es in die große Fragerunde. Deswegen fasse ich das alles ein bisschen kürzer zusammen. Pluckins und Teams sind natürlich, es ist ein Muss, abgedeht zu werden, genauso wie WordPress. Wir haben natürlich Sicherheitslücken, die geschlossen werden. Wir haben Performance-Updates, wir haben Feature-Updates ganz genau. Vorher, vorher und nachher. Super. Dann, ich springe jetzt ein bisschen, wie gesagt, wenig Zeit. Gerne auch nach dem Vortrag, könnt ihr mich fragen stellen, super gerne. Nächstes Thema, was viele vergessen, sind Broken Links. Broken Links, sagt ihr. Matthias, haben Broken Links mit meiner Serverlast zu tun? Gar nichts. Aber das Böde ist, wenn die User abspringen, dann kann man dann klicken können, wie zum Beispiel Produkt-Infos. Es ist auch nicht schön. Es geht nicht auf die Performance, die Last, weil die 404 Seite wird so höchstwahrscheinlich gekäst sein. Aber, wenn der User sagt, okay, ich möchte jetzt diese Mütze in grün haben, Moment, wie sind die Maße dieser Mütze? Schade, ich kann kein Produkt-Teil anglicken, weil die Links broken sind. Dafür gibt es Pluckins, lasst die Finger von diesen Pluckins. Das ist meine persönliche Meinung, und die hat sich über die Zeit auch bestätigt. Es gibt eine ganz tolle Website, brokenlinkcheck.com Gebt da einfach eure URL ein, löst ein Capture und der iteriert durch alle Links deiner Seite und sagt dir, ob ein 404 oder sonst irgendein Code, der kein 200er ist, zurückkommt. Total geiles Tool. Wirklich der Hammer. Warum mag ich Pluckins nicht? Weil die Pluckins meistens noch im Frontend mitlaufen. Und wenn ihr das nicht wieder deinstalliert, haben wir natürlich wieder ein bisschen Last auf allem. Dann ist auch ein Punkt, den reiß ich nur kurz an, weil der sehr programmatisch ist. Lazy Loading, vor allen Dingen von Javascript-Dateien. Boah, ist das wichtig. Im Warenkorb, wenn ihr im Warenkorb in der Kasse seid, also die Seiten, die wirklich nicht gecashed werden. Da sollte man darauf achten, dass man manche Scripts, die man erst ziemlich weit unten benötigt, beim Runterscrollen, auch erst dann LED. Wenn man es für mich nicht tut, hast du echt schon ganz schön viele Requesters, 300, 400 Request manchmal. Und das zieht natürlich die Server-Laster runter. Ein weiterer Punkt, Security Pluck-In. Security Pluck-In, aber es zieht doch mal eine Seite runter. Ja, natürlich. Zum Teil deine Seite runter. Aber, hast du Bock gehackt zu werden? Hast du Bock, mit Huawei befallen zu werden? Hast du Bock, ganz viele Angriffe auf XML, RPC zu bekommen, weil du keine Web-Application Firewall hast? Während deiner Sendung live? Hast du nicht. Was machen wir? Nachdem wir und bevor wir in Security Pluck-In insoliert haben? Ganz genau. Mein Liebungspunkt, Punkt 11, den Bezahlvorgang Optimieren. Was heißt das genau? Bezahlvorgang Optimieren bedeutet vor allem, du guckst mal wirklich, was alles an den Quests geladen wird, im Warenkorb und im Checkout. Wie gesagt, sind die beiden ungecashisten Seiten und die schlimmsten. Und guckst du an, brauche ich das wirklich? Dann habe ich noch ein Miniatur-Bild meines meiner Mütze im Warenkorb, welches nur so groß angezeigt wird, aber in Wirklichkeit 2.000 mal 2.000 Pixel geladen wird. Brauchst du höchstwahrscheinlich nicht. Zusätzlich soll das dir auch dein Checkout-Programm mal anschauen, oder dein Plug-In. Buco-Mers intern macht das ziemlich super, aber bestimmte Plug-In-Anbieter laden unendlich viele weitere Quests. Zum Beispiel das Ursprungspluck-In von PayPal, hat 30, 40 Mütze in die Quests, die absolut verbündend waren, also macht natürlich auch kein Spaß vor. Da sollte man wirklich immer darauf schauen, brauche ich diese Sachen im Checkout und wenn ja, kann ich das drüber was anderes lösen. Ich persönlich empfehle immer Stripe. Stripe hat eine super einfache Einbindung oder ein Buco-Mers-Pluck-In, hat unendlich viele Zahlungsmöglichkeiten für den Endnutzer und ist super easy zu bedienen, auch als Nicht-Programmierer. Und läuft super schnell. Das überspring ich alles sehr wichtiger Punkt ein Content-Delivery-Network ein CDN ist allen bekannt was ein CDN ist und was es macht. Geil, super, dann muss ich das nämlich nicht erklären. Wir hatten Fälle vom Kunden bei dem war alles optimiert trotzdem hat die Seite enorm Probleme Kurzfassung durch ein CDN wurden sie gelöst, weil das CDN ein weiterer Cash für deine Endkunden ist dein Server entlastet und die Request minimiert. Ja, also wie passive Inhalte also wie nicht passive Inhalte aktive Inhalte durch ein CDN verbessert werden nahezu gar nicht. Das brauchst du aber gar nicht, weil die ganzen weiteren passiven Inhalte zum Beispiel hier mal das Beispiel Cloudflare so gut durch Railgun und andere Erweiterungen vorgecashed werden, dass die ganzen aktiven Inhalte wie zum Beispiel die Sessions allein durch eigenes Serverlast ausreichen weil der meiste Kram wird woanders geladen und das ist auch der Vorteil, das heißt der wichtigste Kram wird über dein Server abgehandelt während der andere unwichtig Kram wird zum Beispiel Bilder, Texte, sonst was hinterlegte Dateien von dem CDN ausgeliefert werden und dadurch dann Server entlastet wird. Super einfach habe ich es ist super einfach zu konfigurieren habe ich sogar eine Anleitung im Text. Du wolltest es auch noch mal fragen. Die Tochter Karte malen lassen ist immer in Ordnung. Ich habe im Vorfeld im Mai mal mit den Entwicklern von einem diesen OSM das schöne an Cloudflare ist, sie haben die GD per A-Regung. Es gibt bei Cloudflare auch ein WordPress Plugin, was du installieren kannst welche zum Beispiel zum Cookie-Konsent mit eingefügt wird. Ganz easy gesagt. Gut, wir sind fast am Ende bleiben noch 3 Dinge Nummer 1, Stress-Testing schon mal gemacht. Welche Tools habt ihr benutzt? Okay, super. Ich benutze sehr gerne Loader I.O. Loader I.O. ist eine Website wo du die Almen kannst und du musst deinen Server verifizieren meistens durch eine einfache Text-Satei oder man kann es auch per DNS-Rekord und dann kannst du wirklich Last-Test drauf fahren. Kannst sagen, ich möchte so und so viel Kleines auf die Seite ballern lassen innerhalb dieser Zeit. Funktioniert super und man kann wirklich sehen, wann wird es kritisch. Man macht es deshalb am Ende weil man dann sehen kann, wo muss ich noch optimieren. Auch super für solche Geschichten ist normales Testing, so was wie in der Google, Pingdome, Web-Page-Testware im Wasserfall da ja erst mal sieht okay, alles klar, diese Ressource dauert ewig, diese Ressource brauche ich extrem lange da muss ich was dran tun. Wieso habe ich da einen 6MB-Bild auch alles schon vorgekommen. Dann, wir können nicht als Web-Designer, Webmaster, Produkthoster immer und überall gleichzeitig sein deshalb Reporting, auch ein ganz wichtiges Tool. Reporting macht nichts anderes, als zu gucken ist die Website online ist die, weil sie offline ist. Wichtig dabei, stellt das Ding nicht auf alle 5 Sekunden Hola Agalle A2 Sekunden. Hab ich auch schon gehabt, kann ein Server auch zum Absturz bringen, wenn man es falsch konfiguriert 5 Minuten reichen vollkommen ist meine persönliche Erfahrung. So, dann sind wir beim allerletzten Punkt. Ja. Ich nehme dafür entweder die kostenfreie Pläne von Pingdome oder von Abtime-Robot. Die Frage lautet ich nehme, welche Tools ich verwende. Abtime-Robot, Abtime-Robot, sehr gut. Alles klar, das finde ich auch gut. So, jetzt sind wir beim allerletzten Punkt. Ich komme leider nicht mehr zur Demonstration, aber wer Bock hat, kann sich die nachher am Rayboxer Stand mit mir einfach mal angucken und da zeige ich euch mal, wie ich so was optimiere bei uns. Komm ich leider nicht mehr zu, aber können wir gerne hier nach nochmal in Ruhe machen von mir aus auch in der Mittagspause dessen kann ich später. Was stellt sich, was der allerletze Punkt ist? Der Kandidat hat nur noch eine Wunde. Macht am Ende, bevor ihr alles abschließt, nochmal ein ganz großes Backup, denn selbst wenn live dann eure Seite crasht, könnt ihr jederzeit zu dem Standpunkt hin, wo alles tiptop war. Das passt ja wirklich auf die Minute genau. Jetzt kann man in die Fragerunde gehen. Irgendjemand noch Fragen, die er noch nicht zwischendurchgestellt hat, oder wenn mich irgendjemand mit irgendwas anderen löchern. Nö. Allsonsten würde ich das nämlich wie folgt machen. Ja. Okay, die Frage lautet, ob man die Domain, wenn man sie z.B. in Amerika oder sonstwo registriert hat, aber auf dem deutschen Server betreibt, auch umziehen sollte, oder rechtesten DNS-Record zu erinnern. Eine sehr gute Frage habe ich noch nie gehabt den Fall. Im Zweifel würde ich sagen, reduzier einfach die Last und ziehsinn auf dem deutschen Server um. Die Antwort war relativ einfach, wenn du uns die Enden nutzt, ist das kein Problem. Daniel. Ja, DNS-Cache, genau. Auch noch der Antwort von Daniel zu DNS-Cache greift. Sonst noch eine Fragerunde. Antwort oder Anmerkungen. Ich glaube, ich komme leider nicht mehr dazu, den Test komplett durchzuziehen, weil solche Sachen wie PHP-Änderungen dauern manchmal live. Deswegen würde ich den Fall gleich mit euch live bei uns am Stand machen, wer Interesse hat. Wir können uns auch eine Zeit aussuchen. Oder wir machen es heute Abend alle mit alkoholisiertem Kopf. Oder ich mache es zweimal und ihr vergleicht dann und werden wahrscheinlich mehr Swear-Worther fallen. Aber ansonsten. Okay, alles klar. Einer unserer Gründer, liebe Torben, der sagte noch, wir suchen tatsächlich noch Leute. Wir suchen Web-Entwickler, Sales, suchen wir System Admin, Werkstudent, ja. Also wer Bock hat auf ein geiles Hosting-Unternehmen und Bock hat sich mit mir über Dinge zu streiten, wie verlegt man richtig Kabel, dann ja. Du hast eine Frage. Ich habe hier Besietenkarten. Die kannst du dir gleich mitnehmen. Da gehst du einfach auf die Web-Zeiten oder gibst Block-Einträge. Kannst du den Newsletter abonnieren oder klickst nächste Woche einfach auf den Block? Alles klar. Oder unser zweiter Gründer, Schmireit dazwischen. Hi, Johannes. Okay, vielen Dank fürs Zuhören. Ich hoffe, ich konnte euch in der kurzen Zeit ein bisschen was zeigen. Ansonsten der Rest kommt ausführlich in dem Artikel. Lesezeit ca. 1,5 Stunden, muss ich dazu sagen. Wie gesagt, der ist sehr ausführlich. Vielen Dank fürs Zuhören. Vielen Dank.