 Okay, gut, dann starten wir auch schon. Alle, die jetzt noch reinkommen, ihr könnt euch einfach setzen, noch ist nicht viel passiert. Ich starte einfach mal ganz kurz mit einer Vorstellung. Ich bin der Jan, ihr habt mich vorhin ja schon beim Session-Pitch gehört. Ich bin bei Redboxes auch und deswegen habe ich auch das Thema heute gewählt, beyond PageSpeed, weil wir vor allen Dingen seit der Einarbeitung von Lighthouse in Google PageSpeed Insights wieder einen großen Peak mitbekommen haben bei Kunden, die jetzt nur noch Google PageSpeed Insights für ihre Seitenanalyse nutzen. Was ein super Tool ist, ich möchte auch gar nicht gegen Google PageSpeed Insights basten an der Stelle, aber ich werde es natürlich explizit vergleichen mit Webpage-Test und die Vorteile aufzeigen, die Webpage-Test hat an der Stelle. Das heißt nicht falsch verstehen, das Tool macht einen super Job. Für den richtigen Anbindungsfall ist das optimal, um die Seite wirklich einmal sich anzuschauen und zu gucken, wo kann ich noch dran drehen. Aber gerade, wenn man auch wissen möchte, wie schnell lädt die Seite eigentlich und wie schnell lädt die Seite in bestimmten Kontexten, ist es nicht das optimale Tool. Und es macht auf jeden Fall Sinn, sich mal mit Webpage-Test auseinanderzusetzen, auch wenn es hässlich wie die Nacht ist, aber es funktioniert. Und vor allen Dingen hat da tatsächlich auch noch Google nimmt aus diesem Test auch viele Ergebnisse raus und nutzt auch Webpage-Test für andere Testergebnisse, zum Beispiel, dass mittlerweile nicht mehr verfügbare Google-Test-My-Site für die mobile Optimierung hat auch komplett auf Webpage-Test.org aufgebaut. Das heißt, ich verarbeite hier vor allen Dingen die Erfahrungen, die ich auch aus dem Hosting-Support von uns gesammelt habe und das wird es auch so ein bisschen sein. Das heißt, ich gehe quasi dieselbe Schiene und mache einmal, was sind die Unterschiede, warum kann man Webpage-Test an der Stelle vielleicht besser nutzen, um die Seite noch tatsächlich schneller zu machen und nicht nur das Ranking zu verbessern. Hier habe ich auch schon netterweise eine Seite bekommen, die ich testen darf. Vielen Dank dafür nochmal. Das ist die Role24.de, die zeige ich hier einmal ganz kurz, um zu wissen, um was es geht. Kann ich auch einmal ganz kurz runter scrollen. Es ist auch sehr schön, weil wir tatsächlich sehr viel Bereich unter dem eigentlich in above the fold haben. Das heißt, das ist tatsächlich ein schöner Case, den man sich angucken kann. Wer von euch hatte seiner Seite mit dem neuen Google PageSpeed Insights schon mal analysiert und sich auch nach diesem Punktewerting und vor allen Dingen nach den Vorschlägen, die es macht, gerichtet an der Stelle, um die Seite zu optimieren. Okay, das sind wenige. Das ist ganz gut, weil dann können wir eigentlich einfach mal mit Google PageSpeed Insights anfangen und einmal ganz kurz drauf schauen, was das Tool eigentlich bringt. Dabei springe ich direkt mal in die Ergebnisse, weil tatsächlich ist die Maske relativ selbsterklärend. Ihr hakt einfach eure URL bzw. die Domain ein und bekommt dann das Testergebnis, was Google ausgibt für diese Seite. Da ist einiges mit drin. Früher sah das wesentlich leaner aus an der Stelle und ist natürlich jetzt ein erschreckendes Ranking, aber keine Angst. Das ist sehr gut, dass das so aussieht tatsächlich für meinen Case, den ich machen möchte. Und so sehen die Ergebnisse ungefähr aus davon. Das heißt, man bekommt mindestens immer eine Punktewertung von Google PageSpeed Insights und man bekommt hier unten die sogenannten Lab-Daten. Das sind tatsächlich Messwerte, die sich auf die Ladezeit beziehen. Und es gibt natürlich dann auch noch die Optimierungsvorschläge. Das sind dann die Empfehlungen hier weiter unten. Und da listet Google auf, was könnt ihr tun, damit die Seite schneller lädt und dass der Nutzer dann eben auch schneller das Gefühl hat, mit der Seite interagieren zu können an der Stelle. Weil das ist immer der relevante Punkt. Wenn es um Ladezeit geht, dann geht es ja immer darum, was empfindet der Besucher eurer Seite, wenn er auf die Seite geht. Und das optimale Empfinden ist natürlich, zack, die Seite ist da und ich kann direkt damit interagieren. Deswegen ist dieses Ergebnis auch so schön, obwohl es sehr viel rot hat an der Stelle. Weil das ein wichtiger Unterschied ist, den man auch verstehen sollte, wenn man mit zwei unterschiedlichen Tools arbeitet, gerade auch mit Google PageSpeed Insights und mit einem, ich nenne es immer gerne mit einem echten Ladezeit-Tool, dass die beiden Sachen nicht korrelieren. Das heißt, dieser Score, den ihr hier seht, der ist kein Indikator dafür, wie schnell die Seite tatsächlich lädt. Es gibt also keine direkte Korrelation in die eine oder andere Richtung, sondern es ist eher so ein Hint. Google hat noch sehr, sehr viel Optimierungspotenzial gefunden. Ob die immer Sinn machen, diese Vorschläge, das steht auf einem anderen Blatt, da möchte ich auch gar nicht mit anfangen. Ich habe nur am Rande gesagt, es gibt manche Optimierungsmaßnahmen von Google, die machen nicht immer Sinn. Die müssen auch nicht immer stimmen, deswegen sollte man die durchaus kritisch prüfen. Aber wie gesagt, viele Empfehlungen machen sehr viel Sinn und man sollte sich das auf jeden Fall auch mal auch in Detail anschauen. Was haben wir jetzt gesehen, was hier bei rauskommt? Jetzt könnte man denken, die Seite müsste noch massiv optimiert werden, damit dieses Erlebnis des Kunden tatsächlich gut ist. Ich habe die Seite jetzt gerade schon zum ersten Mal aufgerufen und auch ungecached war die tatsächlich schon schnell da. Ich mache jetzt zu Demonstrationszwecken einfach nochmal ganz kurz. Und zwar auch ungecached. Und dann können wir einmal sehen, wie schnell das Ding da ist. Und das hat gar nicht so dramatisch lange gedauert tatsächlich. Man sieht, das Nachladen, das verzögert hier die Browser reported Low Time an der Stelle. Und ich gehe jetzt mal ganz stark davon aus, dass das auch der Grund ist, warum Google PageSpeed Insights hier so rote Werte ausgibt an der Stelle. Die Seite ist jetzt nicht zwingend langsam oder schlecht, aber diese Browser reported Low Time ist natürlich fürchterlich. Deswegen ist sie auch rote. Man könnte jetzt denken, oh Gott, die Seite ist gar nicht zu benutzen. Stimmt aber im Endeffekt nicht. Wir haben es ja auch gesehen, wenn man sich jetzt auch hier einmal durchklickt an der Stelle, sieht man, der ist sofort alle Beitrag. Also da habe ich als Nutzer nicht das Gefühl, oh Gott, jetzt will ich unbedingt den Content lesen, aber er kommt einfach nicht und kommt einfach nicht. Sondern es liegt jetzt daran, wie die Seite rendered, dass dieser Wert so schlecht ist. Und deswegen ist es nämlich nicht so wichtig, dass man sich die Ladezeit an sich anschaut, sondern auch welche Ladezeit man sich anschaut. Und da kommt jetzt Google PageSpeed Insights ins Spiel, weil dieses Ding gibt einem nämlich wirklich alles aus, was man sich wünschen kann an Ladezeiten, also die berühmte Time to First Bite, die Rendering-Start- und Endpunkte und ganz viele bunte Balken und Striche, an denen man sich dann orientieren kann und die man nutzen kann, um seine Seite zu verbessern. Ich mache einmal einen kurzen Sprung und sage euch mal, wie das so aussehen kann an der Stelle. So sieht so ein typisches Ergebnis aus. Von Webpage-Test, man bekommt so ein Wasserfalldiagramm. Leider, ich habe es schon gesagt, das ist recht hässlich, tatsächlich nicht das Test-Tool. Das heißt, da hat man, es ist zwar sehr bunt, aber es ist doch sehr viel. Auch die Darstellungsvariante mit diesem Wasserfalldiagramm, die ist zwar sehr übersichtlich, aber man muss sich erst mal reinfuchsen, dass man es versteht. Und selbst wenn man dann drin ist, auch dann ist hier einfach super viele Zahlen, sieht man super viele Benchmarks und wenn man nicht weiß, worauf man achten muss, dann verliert man sich schnell. Deswegen geben wir jetzt erst mal noch einen Schritt zurück und schauen uns nicht direkt die Messergebnisse, sondern erst mal das Tool selber an der Stelle. Wie gesagt, früher war das mal ein Yahoo-Tool, glaube ich, und wurde dann von Google übernommen an der Stelle, wird jetzt auch weiter betreut von denen. Und das funktioniert ähnlich, wenn ihr vielleicht schon mal mit Pingdom oder mit GT-Metrics gearbeitet habt, das funktioniert im Grunde ähnlich. Ihr habt auch wieder hier euren URL-Schlitz, wo ihr halt eben eure URLs eingeben könnt, ihr testen möchtet, dann klickt ihr auf Start und dann spuckt ihr euch Ergebnisse aus. Die Herausforderung bei diesem Tool ist aber, dass man schon vor dem eigentlichen Test die richtigen Einstellungen vornimmt. Noch ein ganz kurzer Hinweis an der Stelle. Ich habe noch Folien zu der Session, die habe ich nur jetzt tatsächlich nicht vorlegen, weil ich die nicht mehr aktualisieren konnte. Wenn Sie jemanden interessiert über die Rateboxes Twitter-Händel, werde ich das auch nochmal zur Verfügung stellen, aktualisierter Form nach dem WorldCamp. Das werde ich auch mit dem entsprechenden Hashtag dann versehen. Das heißt, wer sucht, der findet dann auch an der Stelle. Wenn ihr so eine komplexere Maske schon mal gesehen habt, dann wisst ihr im Prinzip, gibt es drei wichtige Bereiche, auf die man sich jetzt konzentrieren muss. Das ist einmal das Serverstandard, über den man testen möchte. Das ist die Geschwindigkeit, die Bandbreite, die man simulieren möchte. Und das ist die Anzahl der Tests, die man fahren möchte. Das geht hier bei Webpage-Tests, geht das sehr, sehr schön, über schlicht ein paar Einstellungen an der Stelle. Ihr könnt das hier mal sehen. Man hat X Test Locations zur Auswahl, was super ist, weil so könnt ihr für eure Zielgruppe den besten Server einstellen. Für die allermeisten ist das einfach ein deutscher Serverstandard. Ein brasilianischer Server oder auch einer in Paris, der ist selten in irgendeiner Form wirklich praxisrelevant. Aber wenn ihr wollt, könnt ihr. Das ist sehr, sehr attraktiv an der Stelle. Sie haben auch teilweise, ich sehe das zum Beispiel bei Frankfurt. Da habt ihr auch mehrere Standorte. Und auch noch mal einen exotischen Standort, jetzt hier Falkenstein bei Nürnberg zum Beispiel. Das heißt, sollten die Tester mal voll sein, habt ihr auch Ausweichpotenzial an der Stelle. Das ist erstmal relevant, um den Nutzeraufruf möglichst präzise, simulieren zu können an der Stelle. Wenn ihr jetzt einen Übersiehserver nehmt, wie das beispielsweise bei Pingdim früher noch der Fall war, die haben jetzt auch viel mehr Test-Server, aber früher war das mal der Fall, da hat man immer mit dem New Yorker Server getestet. Da habt ihr einfach eine fürchterliche lange Time-to-first-byte. Die müsst ihr dann erstmal nochmal rausrechnen, bevor ihr überhaupt euch die Seite anschauen könnt. Deswegen ist dieser Server-Standort hier so wichtig. Die Bandbreite, das ist ein cooles Tool. Oder Connection heißt das bei Webpage-Test, um eine mobile Verbindung zu simulieren, weil es da eben nicht nur darum geht, die Seite dann mobil optimiert darzustellen, sondern auch über eine mehr oder weniger realistische mobile Geschwindigkeit. Der Erfahrung nach ist, was ihr hier so an 4G und LTE einstellen könnt, ungefähr vergleichbar mit dieser Cable-Geschichte. Ehrlicherweise lasse ich das immer auf Cable stehen. Ich spiele damit nicht viel rum, einfach nur damit ich so eine Baseline habe, an der ich mich orientieren kann. Es geht ja immer darum, dass man versucht, die Realität so gut wie möglich abzubilden und solche Sachen, ist halt sehr dynamisch, sagen wir es mal so, vor allen Dingen in Deutschland. Und jetzt kommt noch eine Geschichte, die tatsächlich super interessant ist, weil die andere Test-Tools in der Form überhaupt nicht anbieten, sondern es macht wirklich nur Webpage-Tests, wenn ich falsch liege, kuriere geht mich bitte, aber bisher habe ich es noch nicht gesehen, die Anzahl der Tests. Und das ist eine sehr, sehr coole Geschichte, dass ich auch immer den Leuten rate, wenn sie mich fragen, wie soll ich denn testen, und mache auch mehrere Tests. Warum? Wenn ihr nur einmal testet, dann kann das sein, dass ihr ein Ausreißer misst. Das heißt, da sind dann unter Umständen fürchterliche Ladezeiten drin, aber das war ein einmaliges Event, oder da sind gerade besonders viele Hits auf die Seite gekommen, und das ist gar nicht repräsentativ. Mit Webpage-Tests mache ich hier einfach fünf Tests hintereinander, bekommen natürlich auch die fünffache Menge an Daten, kann ich aber später dann aggregieren und kann mir ein Mittelwert ausrechnen lassen. Und wenn ich dann einen Ausreißer drin habe, ist das nicht mehr so dramatisch, das schafft auch nochmal viel Sicherheit, darin zu verstehen, was die Seite macht. Ich habe häufig Leute bei mir im Support, die sagen, ah, jetzt habe ich immer schon wieder so schlechte Werte, und gestern war das noch viel besser. Und genau diesen Wert kann man super darüber antizipieren, wenn man mehrere Tests hintereinander macht, weil man dann einfach mal sieht, okay, die Seite verhält sich im Schnitt eher so und nicht so. Auch das, das kam gerade der, genau der Kommentar aus dem Publikum, dass gerade bei Shared Hosting auch entscheidend ist, dass man unterschiedliche Tageszeiten anzestet. Das lässt sich jetzt tatsächlich mit der Standardmaske in dem Fall nicht aussteuern, da muss man sich dann wirklich hinsetzen und sagen, ich mache mal einen Mittagsmorgens und Abends beispielsweise, weil man einfach auch nicht, man weiß ja nicht, mit wem man noch einen Server sich teilt, und es kann tatsächlich sein, dass man mit Seiten auf dem Server ist, die morgens extreme Last haben und abends. Tobias? Das Cloud Hosting ist halt auch in der Praxis gesehen ein Shared Hosting. Das ist ein Server auf dem Wirtssystem und das kann auch bei gewissen Anbietern, gerade bei den Anbietern, die es als günstigen Preis anbieten, ist die Wahrscheinlichkeit ziemlich hoch, dass sie das sehr überbuhen und dementsprechend macht die Tests zu mehreren Tagen über allen Infrastruktur an, außer man hat also den Denizierte umgeben. Ja, ich fasse das nochmal ganz kurz zusammen, dann die nächste können wir da mit dem Handmikro machen. Das war nochmal die Aussage aus dem Publikum, gerade, dass das nicht nur beim Shared Hosting, sondern auch bei Cloud Infrastrukturen wichtig ist, wenn man nicht den eigenen dedizierten Server hat, dann sollte man auf jeden Fall auch mal so unterschiedlichen Tages, Nacht, wie auf Immerzeiten gucken und natürlich, je nachdem, auf welcher Infrastruktur man sich bewegt, kann auch die Zeitverschiebung hier unter Umständen eine Rolle spielen. Da ist die Erfahrung, man muss tatsächlich sich auch ein bisschen damit beschäftigen und unter Umständen ein bisschen rumspielen. Das hilft auch schon viel, das ist aber auch ganz gut, wenn die Tests dann viele Ergebnisse liefern, weil dann hat man, wenn man wirklich wissen möchte, was passiert, da in die Tiefe zu gehen und nachzuschauen und rumzuspielen mit den Tools. Okay, noch eine Sache, die ich auch immer sehr interessant finde, ist hier unten diese Zeile, dieser Repeat View, weil der eben auch das Caching antizipiert, was nicht nur auf dem Server, sondern auch im Browser stattfindet. Das heißt, wenn ihr hier diesen First and Repeat View einstellt und nicht nur den First View only, dann habt ihr quasi eine Simulation des erneuten Aufrufs mit gefülltem Browsercache. Auch das wieder super interessant zu wissen, weil ihr werdet gleich sehen, die Werte können sich teilweise massiv unterscheiden an der Stelle. Jetzt nehmen wir mal an, wir haben uns alles eingestellt und starten unseren Test jetzt. Dann wird es ein bisschen dauern, weil diese Werte erst mal durchlaufen müssen und dann bekommt ihr diese Zahlen, wie sie hier quasi. Da würde ich raten, ich mache jetzt mal einen kurzen Überblick darüber, was es bedeutet. Ich wollte ja eigentlich in die Ladezeit reingehen, deswegen es war jetzt sehr viel strukturelles Vorgeplänkel. Macht einfach mal mit eurer eigene Seite her und guckt euch wirklich mal an, was ihr in den einzelnen Bereichen findet. Ich gehe jetzt mal nur auf die drei wichtigsten ein. Und zwar ist das einmal die Summary, also das, was ihr bekommt, wenn ihr wirklich den Test dann durchgezogen habt. Das sind alle Testläufe einmal dargestellt mit dem Wasserfalldiagramm, der Ladezeit und so weiter und so fort. Und hier oben findet ihr einmal eine zufällig zusammengestellte Übersicht. Beziehungsweise ich glaube, sie ist gar nicht zufällig, sondern ist der beste niedrigste Run. Es ist glaube ich, es ist ganz wichtig, es ist nicht der Durchschnitt, es ist auch kein Media, sondern ihr seht da vorne an der Stelle seht ihr, dass das der 1. View von Run 2 ist und der Repeated View von Run 1 an der Stelle. Der ist super für den Überblick, weil da könnt ihr wirklich mal gucken, okay, diese Daten habe ich jetzt und diesen Daten sagt, schnappe ich mal jetzt und gucke mir den einmal einen Detail an. Dann gibt es nämlich noch den Waterfall View in den Details, da ist es wirklich für einen Run für den 1. oder für den Repeated View und da könnt ihr euch das wirklich im Detail, im Detail anschauen. Da werden auch wirklich nur die Werte für diesen einen Run ausgegeben in der Stelle. Und dann gibt es noch meine persönliche Lieblingsansicht die geplottete Ansicht und da steckt jetzt das Schöne mit diesen Mittelwerten drin. Wenn das nämlich klickt, dann wird es noch hässlicher aber ihr bekommt noch coolere Werte ausgegeben, weil jetzt bekommt ihr tatsächlich ein Boxplot mit den einzelnen Messpunkten. Ich mache mal ganz kurz noch die Einstellung und jetzt habt ihr, wenn ihr euch die Load Time anschaut, die Load Time ist immer die Zeit, die die Seite braucht nicht der Browser, aber in dem Fall der Test sagt, jetzt ist sie fertig gerendert und jetzt hat der Kunde beziehungsweise der Nutzer das Gefühl, das Ding ist fertig, jetzt kann ich damit endlich interagieren. Das Ding ist quasi so das, was man als die Ladezeit wahrnehmen könnte. An der Stelle ist es nur einer der Werte, aber es ist mit einer der interessantesten. Und ihr seht, dass in diesem Boxplot habt ihr jetzt für die Roten und für die Grünen jeweils drei Punkte und könnt ihr richtig schön sehen, die sind alle auf einer Linie, das heißt, wir haben keinen Ausreißer drin. Die Seite wird also wahrscheinlich auch, wenn ich das ganze 100.000 eine Millionmal mache, immer ungefähr diesen Wert ausgeben. Und das ist halt eben das Schöne an diesen Mittelwerten und die Werte, die ihr oben habt, sind jetzt auch Mittelwerte und keine Einzelwerte mehr. Das heißt, ihr habt hier das arithmetische Mittel, den Medien, wen es interessiert, auch noch die Standardabweichung und die Patientile, aber kann man eigentlich ignorieren, wenn man nicht wirklich in die Tiefe, in die Tiefe gehen möchte. Das kann ein Webpage-Test an der Stelle. Das heißt, so nutzt man das Tool, um hier wirklich nicht schöner, aber gute Werte zu bekommen. Und jetzt ist das Ganze, welche Werte wollen wir uns überhaupt anschauen, damit wir wissen, wie schnell lädt die Seite eigentlich. Welche Zeitwerte kann man sich hier schnappen, um einmal zu sehen, wie sich die Seite eigentlich verhält. Und dafür wechsel ich jetzt nochmal in diesen Waterfall-View zurück. Also nicht irritieren lassen, das sieht jetzt anders aus, aber da ist die Darstellung sehr, sehr schön. Ich muss ein bisschen scrollen, damit ich die Farbegehendbalken bekomme, weil das nämlich die Wichtigen. Webpage-Test gibt hier, wie gesagt, eine ganze Vielzahl von Messwerten aus, die auch wirklich viele bei der Seite aussagen. Das Wichtigste an der ganzen Stelle und die erste Kennzahl ist tatsächlich auch die Time-to-first-byte. Die Time-to-first-byte ist das, wo ihr am nächsten an die eigentliche Server-Response Zeit ran kommt. Die Seite hat einen Einfluss auf die Time-to-first-byte, also die Plugins und die Seams, die ihr installiert habt, während diesen Wert verzögern. Aber wenn der Server gut ist, dann wird der diesen Wert auch für Ringern verwendet. Die Time-to-first-byte, die findet ihr immer unter diesem jeweiligen Punkt, wird euch auch in der Aggregation entsprechend ausgegeben und dieser Wert von 209 Millisekunden ist sehr, sehr gut. Der wird auch von keinem anderen Test in der Form irgendwie bemängelt werden, sondern das ist tatsächlich ein sehr, sehr guter Wert. Das zeigt sich, da ist der Server richtig fix. Wenn wir jetzt einen anderen, Testlocation ausgewählt hätten, zum Beispiel in New York, dann würde dieses Ding ganz anders aussehen, weil dann eben erst die Kommunikation zwischen diesen beiden geografisch sehr weit voneinander entfernten Server anstatt finden müsste und dann würde sich dieser Wert verzögern. Ich habe direkt einen Kommentar oder habe mich zu eine Frage stellen. Ist das an? Hallo? Hallo? Ich habe es noch nie getestet von einem anderen Standort, aber wir haben ja vor dem Projekt Cloudware laufen. Insofern könnte ich mir vorstellen, dass es vielleicht auch von woanders gar nicht so viel schlechter aussehen würde. Das wäre zumindest das Ziel, genau. Das aber, man wird dann auch, nehmen wir jetzt mal an, wäre kein CDN davor geschaltet und es würde nachträglich davor geschaltet, würde man den Effekt auch sehen an der Stelle. Das ist dann auch die Erfolgsmessung dafür, okay, hat das was gebracht oder das nichts gebracht, zumindest bezüglich dieser Response Time. Dann gibt es noch diesen zweiten Wert, der sich hier als schöne farbige Linie angezeigt, und zwar als diese dunkelgrüne, ich muss noch ein bisschen dran zu summen, diese hier, die dunkelgrüne ist das nämlich. Dieser Wert zieht sich auch durch das gesamte Wasserfalldiagramm und der sagt im Grunde nach diesem Wert oder so lange dauert es bis hier was passiert auf der Seite. Das heißt, das ist so die Zeit, wo der Screen weiß bleibt und wo der Kunde beziehungsweise Nutzer davor sitzt und sich denkt und jetzt. Und Ziel ist natürlich diesen Wert soweit wie es so kommt, weil das bedeutet, es dauert nur sehr kurz bis der Nutzer wirklich was sieht und 700 Millisekunden, so hoch ist der Wert in diesem Fall, das ist auch so eine Zeit, das kriegt man nicht mit. Also ob das jetzt eine halbe Sekunde, eine dreiviertelte Sekunde oder eine Sekunde ist, man merkt es vielleicht unterbewusst, aber 700 Millisekunden, das ist im Prinzip sofort was da, da hat man sofort das Gefühl, dass was getan wird, wenn dieser Wert fürchterlich weit rechts liegt, also es lange dauert, dann kann es tatsächlich sein, dass die Leute abspringen, weil sie sagen, ja tut sich jetzt da noch was, kriege ich noch irgendwas zu sehen, mit dem ich arbeiten kann. Im Optimalfall natürlich ja, aber sie wissen es halt nicht und dann ist die Wahrscheinlichkeit, dass die Leute abspringen dann doch deutlich höher, da kommen dann diese berühmten Zahlen, die wir kennen von Amazon und Google, die sie getestet haben. Ich habe sie gar nicht mehr im Kopf, jede Sekunde erhöht, das Absprungrisiko um 17% oder wie sie auch immer war, ne. Hier wisst alle wovon ich rede Google hat da sehr schöne Case Studies aufgebaut. Übrigens stammen die Google Case Studies zu großen Teilen auch aus den Tests, die mitgefahren werden. Das heißt, wenn ihr hier Tests fahrt, dann sorgt ihr auch dafür, dass Google eine größere Datenbasis bekommt, um diese Benchmarks dann einzubauen. Nur so am Rande. Joa und dann habt ihr noch, nehmen wir vielleicht nur noch eine, diese Document Complete oder Load Time, das hat 2 Begriffe in dem Fall leider, das ist dann im Fall, wo man sagen kann, jetzt ist die Seite fertig geladen. Auch in diesem Fall, das ist super, dass wir den jetzt haben, können wir einmal zeigen, warum dieser Wert nicht zwingend das ist, was wir jetzt erlebt haben auf der Seite, sondern warum es wichtig ist, auch wenn man diese Werte hat, einmal in das Wasserfallen-Diagramm zu gucken, weil das Ding ist nämlich eine wahre Goldmine in der Information über eure Seite. Wenn ihr wisst, wie ihr das Teil lest, dann könnt ihr nämlich auch verstehen, ok, stimmen wir jetzt die hohen Zahlen oder muss ich das wuchten an der Stelle. In dem Wasserfallen-Diagramm seht ihr alle Requests, die eure Seite macht, und zwar von oben nach unten chronologisch. Jeder, der schon mal im Network View vom Browser war, kennt das Ding auch, ist halt nur anders dargestellt. Zugegeben ist es ein bisschen hässlicher als bei der Entwicklerkonsole, aber es ist schöner, weil man durchscrollen kann und nicht immer nur diesen winzigen Ausschnitt hat. Jetzt könnt ihr damit im Prinzip alles machen. Ihr könnt da auf den... Bitte? Alles gut? Sorry, dann habe ich Geister gehört. Ihr könnt also auf die einzelnen Requests draufklicken, könnt euch anschauen was wird hier eigentlich gerade gerendert an der Stelle. Könnt ihr massig in die Tiefe gehen, aber im Prinzip ist für das erste, für die ersten paar Maler, wo ihr mit dem Ding umgeht, im Prinzip interessant. Wo ist der Bauch? Wo findet das längste, das größte Rendering statt? Das heißt hier, das ist eher so eine P-Form an der Stelle. Ihr seht hier das... Ich mache das mal noch ein Teckengröße. Nachdem es anfängt zu rendern, kommen im Prinzip so Kleinigkeiten. Hier sind ein paar Style-Schieds drin. Dann kommt noch ein externes Style-Schied hier von Google Fonts und danach geht es an die Bilder. Und deswegen ist auch dieses Ladegefühl auf der Seite nicht 7,8 Sekunden oder was es hier war, sondern wesentlich schneller, weil hier schon nach... ja, ziemlich genau 700 Millisekunden, 600 Millisekunden schon Bilder anfangen zu laden. Das heißt, die Seite fühlt sich schneller an, weil der Buff the Fold-Bereich sofort da ist. Und das kann man hier eben sehr schön sehen. Die ersten Bilder kommen und dann ist sie für den Kunden erstmal, für den Nutzern erstmal fertig an der Stelle. Und dann ist der Rest, ist jetzt quasi technische Legacy, die muss auch noch nachgeladen werden, aber das ist jetzt in dem Fall so gut optimiert, dass man sagen kann, okay, aber ich kann sie schon nutzen. Und dann auch schon klicken und das nutze ich auch schon direkt loslegen mit dem Lesen. Das geht jetzt im Prinzip auch immer so weiter. Ihr seht jetzt die restlichen Ressourcen hier an der Farbe, könnt ihr mehr erkennen, was für eine Ressource es ist. Das heißt, ihr könnt zum Beispiel sehen, dass hier ganz viel JavaScript kommt und zwar ziemlich genau bei diesem Start Render-Event. Dann kommen noch ein paar Schriften extern, noch ein bisschen externes JavaScript. Und dann passiert lange nichts. Was liegt daran, dass die Request hier oben diesen blauen Balken bestimmen und nicht die weiter unten. Und dann wird noch ein bisschen was nachgeladen hier an der Stelle und dann ist die Seite aufgebaut. Und mit diesen Werten könnt ihr euch jetzt sehr sehr schon anschauen, wie eure Seite über dieses PageSpeed Ranking hinaus funktioniert. Und wenn ihr jetzt die Kombination macht zwischen Webpage-Test und Google PageSpeed Insights, dann könnt ihr auch sehen, machen denn die Vorschläge eigentlich sind, die Google PageSpeed Insights wenn ich also sehe, die Seite ist im Buff the Fold Bereich super optimiert, ist sofort da, lädt zwar technisch gesehen länger, okay, aber das passt, dann muss man nicht mehr groß ansetzen mit der Optimierung, wenn man dieses Optimierungsprinzip über alle Seiten hinwegziehen kann. Wenn man jetzt aber sagt, okay, ich habe tatsächlich ein Geschwindigkeitsproblem, dann macht das natürlich Sinn, hier wirklich in die Tiefe zu gehen und auch versuchen, jeden einzelnen Kennwert entsprechend zu optimieren. So, ich habe bis 25 Minuten, habe ich jetzt, ne? Das waren jetzt im Prinzip so mal die Grundwerte, wie funktioniert, ganz, ganz grob Webpage-Test und wie kann man es benutzen, auch die Ergebnisse, um einmal sich die Seite anzugucken. Und jetzt würde ich sagen, können wir einfach nochmal in Fragen reingehen oder auch in Erfahrungen, wenn ihr schon ein besseres Tool genutzt habt, oder mit einem anderen Tool bessere Erfahrungen gemacht habt, weil es schöner ist, weil es übersichtlicher ist, weil es irgendwas besser kann, jetzt wäre die Gelegenheit. Hi, was ist der Start Rendering Punkt? Du meinst, was das bedeutet, oder genau, also das ist im Prinzip der Bereich, wo sichtbares Rendering auf der Seite stattfindet. Das heißt, ab dann werden beispielsweise Bilder sichtbar geladen. Jetzt ist der relativ kurz, und das ist auch schon gecashed. Aber wir können es ja einmal probieren. Ja, man hat es jetzt nicht gesehen, aber im Prinzip, als es neu aufgeploppt ist, da war irgendwo der Start Render Bereich. Je nachdem, was hier auch passiert, kann es natürlich zu relativ unschönen Effekten kommen, wenn zum Beispiel eine Schrift nachgeladen wird. Lange nach dem Start Render, dann habt ihr diesen typischen Fondsprungen drin. Und solche Sachen sieht man übrigens dann auch sehr schön im, ich hab dich gesehen, sehr schön im Wasserfalldiagramm. Das Mikrofon einmal bitte nach hinten geben. Test? Okay. Folgende Frage, wenn ich dich als richtig verstanden habe, heißt es, dass dieser Webpage Test unterschiedliche Werte geben kannst, in den Google PageSpeed. Genau, richtig. Beziehungsweise, er hat eigentlich beziehen, die sich alle Tests beziehen sich immer auf dieselben Werte. Also auch ein Ping-Dim wird dir dieselben Werte mehr oder weniger ausgeben. Und auch Google PageSpeed Insights bezieht sich da schon irgendwie drauf. Der große Unterschied, warum die Ergebnisse teilweise so unterschiedlich sind, sind halt die Messparameter. Also das, was wir am Anfang gemacht haben. Wenn du dir auf deinen Fall richtig einstellst, dann bekommst du unter Google PageSpeed Insights an der Stelle. Also wie ist da entscheidender, ist das was? Okay, gehen wir mal davon aus. Die Werte sind fast identisch. Und Google sagt mir, okay, du hast eine Ladezeit von, was weiß ich, 3 Sekunden. Ist Mist, sozusagen. PageSpeed sagt mir aber, hey, du hast so gesehen, was für dich relevant ist, hast eine Ladezeit von, ich sag auch nicht optimal, aber 1x5 Sekunden. Ist besser. Wie kann ich das aber dann oder wo soll ich achten? Es dann entsprechend so zu optimieren, dass auch Google mir sagt, Jo ist in Ordnung, weil wenn ich mich jetzt nicht ganz irre, geht ja diese Ladezeit ja auch mittlerweile ins Ranking rein. Perfekte Frage. Weil genau das kommt immer als Anschlussfrage, wenn ich dann das, was ich gerade erzählt habe versuche, einem Kunden zu erklären und ja, dann musst du dich mal reinfuchsen. Dann machen sie das hoffentlich auch. Und dann ist das meistens die erste Frage, die kommt. Jetzt habe ich aber drei Tools benutzt und ich habe dreimal unterschiedliche Werte. Ich kann man die Tools nicht zwingend direkt miteinander vergleichen, sondern nur untereinander vergleichen. Das heißt auch, dass du dir im Prinzip einen richtungsweisenden Indikator hier aussuchen musst, an dem du dich orientierst. Wenn du also sagst, ich richte mich zum Beispiel nach der Webpage-Testzeit, dann bleib dabei, nehm das als primäre Optimierungs- als primäre Optimierungs-Kennzahl und geh dann danach und nehm den hier um deiner Seite schnell zu machen. Es ist dann, es ist nicht zwingend egal, aber es ist dann nicht mehr so wichtig, was andere Tools ausgeben, wenn die sich im gleichen Maße verbessern. Nehmen wir jetzt mal an, du hast eine unoptimierte Seite und du kannst noch eine Sekunde Ladezeit optimieren an der ganzen Stelle und Webpage-Test gibt dir an, eine Sekunde gewonnen, top. Und Google-Pages mit Insights gibt dir an, du hast gar nichts gewonnen an der Stelle. Du hast aber eine Veränderung vorgenommen und du kannst die auch sehen, weil die man auch dem richten, was auch das zeigt, was du gemacht hast. Das zeigt ja, dass Google-Pages mit Insights in diesem Fall in dieser theoretischen Messung irgendwas anders macht und gar nicht mitbekommt, was du gemacht hast an Optimierung. Und die Frage mit der SEO, mit dem SEO-Impact, das ist, da bin ich wahrscheinlich nicht der Richtige, um das in der Tiefel zu beantworten. Da gibt es ganz, ganz viele Caster, die ist drüber welcher Wert ist relevant. Es gibt viele, die darauf hindeuten, es ist gar nicht so sehr, die zweiten, also der Start-Render oder der, der hier page-complete-wert, wie heißt er? Gut, dass ich das alles auswendig kann. Document-complete-wert. Das weist eher darauf hin, aber sagen wir es mal so, wenn eine Seite fürchterlich lange braucht, um zu laden, dann hat die noch ganz andere Probleme. Dann wird sie unter Umständen in Timeouts laufen und das ist natürlich auch nicht gut für das Ranking. Also mein Tipp an der Stelle ist, wenn du die Optimierung startest, die Momentaufnahme, dann optimiere Miss wieder, optimiere Miss wieder und dann orientiere dich an einem primären Indikator, der dann dein Optimierungsindikator wird an der Stelle. Ich habe an einer Stelle noch eine Frage und dann vielleicht nochmal eine Ergänzung zu dem SEO-Thema, aber wir haben nämlich basierend auf dem Projekt und Tests gefahren um Korrelationen oder das, was wir alle denken zu wissen oder wissen, dass eben Ladezeiten mal messbar zu machen. Aber vielleicht zu Anfang erstmal meine Frage. Wir haben ja jetzt viele Werte gesehen für das Projekt. Unterschiedlich, ob Time to First Bite oder Start Render oder Document Complete. Hast du eine Ahnung, inwieweit die korrelieren oder beziehungsweise wie ich dann die Website-Geschwindigkeit in Analytics dazu in Verbindung setze? Weil wir können uns, wenn wir uns das Projekt anschauen, ich habe uns gerade mal reingeguckt, Analytics weist mir eine Website-Geschwindigkeit von 2,4 Sekunden aus. Die finde ich aber natürlich nirgendwo in denen werden. Gute Frage, habe ich ehrlich gesagt auch keine Antwort darauf. Ich weiß nicht, welche Ladezeit Google Analytics ja nimmt an der Stelle. Ich vermute ehrlicherweise, dass es irgendeiner Browser-Reported-Load-Time sein wird. Das könnte ich mir jetzt vorstellen, weil Google Analytics ja prinzipiell immer sehr schön auf Fallebene arbeitet, was die einzelnen Aufrufe angeht. Tatsächlich also diese 2,4 das ist jetzt genau der Fall, man hat auseinanderfallende Messergebnisse, also wird es ein unterschiedlicher Messmechanismus sein. Und das kann halt eben bedeuten, dass eine ganz andere Quelle herangezogen wird, zum Beispiel eben diese Browser-Reported-Load-Time. Wir können noch einmal ganz kurz schauen. Schnell meistens findet man solche Sachen dann gerne auch mal im gekäschten Aufruf, also in diesem hier, der jetzt aber auch natürlich massiv von diesen 2 Sekunden abweicht. Auch in dem Fall würde ich sagen, wenn ihr Analytics schaut und ihr Messer die Ladezeit orientiert euch einfach an dem Bild, wenn der besser wird, dann muss auch irgendwie die Seite besser geworden sein. Also sicherlich eher in die Richtung kommen. Und das ist immer so ein bisschen, glaube ich, das Problem bei Google Analytics, und auch bei den Helchspielen, Insights, von Google, dass man einfach gar nicht die Möglichkeit hat, das im Standard aufzuwerten. Und ich würde jetzt mal einfach berufen, dass die Linge dann von Amerika abgefragt werden, eher oder irgendwo anders auf der Probe haben. Und damit sind natürlich alleine die Ladelzeichen zu diesen Kotenkoten höher. Das sind häufig schon die Anwaltungen, die wir da gleich beeinflussen können. Sehr gut, der Hinweis kam gerade von einer anderen Person im Publikum noch, dass ja vor allen Dingen bei Programmen wie Analytics oder in dem Fall auch Google PageSpeed Insights nicht erkennbar ist, was die Messparameter sind. Insbesondere das Server-Standort. Das heißt, wenn der in Übersee liegt oder in einem anderen Rechenzentrum auch in Europa, dann können die Werte natürlich variieren. Plus noch ein Kommentar von mir. Ich gehe auch davon aus, dass die Wechsel an der Stelle. Die sind auch nicht immer konsistent gleich, sondern die werden in irgendeiner Form zwischen bestimmten festen Punkten hin und her springen, diese Messpunkte. Da muss man sich jetzt überlegen, ist es mir wert, das unter Umständen mal zu recherchieren und rauszufinden? Oder sage ich mir einfach, okay, ich habe halt diese unterschiedlichen Messwerte, mit den arbeite ich dann unter Umständen auch mit unterschiedlichen Fragestellungen. Das zum Beispiel für die Optimierung und für den groben Überblick darüber, wie die Masse an Leuten die Seite wahrnimmt. Vielleicht nochmal als Ergänzung, was ich gerade sagte. Wir haben für das Projekt mehrere Tests gefahren, applikationsseitiges Caching aktiv inaktiv, CDN aktiv inaktiv, das an drei oder vier unterschiedlichen Zeitpunkten getestet und haben da tatsächlich jetzt nachweislich die Korrelation quasi dargestellt, dass eine Halbierung der Ladezeit im gleichen Zeitraum zu einem Verdoppelung des Traffics, gerade eben im Bereich AMP und Google News Boxes, das ist ein News Portal, also tatsächlich die direkte Korrelation Halbierung Ladezeit, Verdoppelung Traffics im Messzeitraum. Also macht schon Sinn. Sehr cool, das sind auch wirklich interessante Use Cases, habt ihr dazu vielleicht eine Case-Type zugeschrieben, wenn irgendwie dokumentiert in irgendeiner Form? Also ich kann das immer empfehlen an der Stelle, weil... Das ist natürlich immer super interessant das dann auch zu sehen, weil gerade auch wenn es um den Traffi geht, sind es ja auch lange Zeiträume, die man betrachten muss und wenn man dann als Webseitenbesitzer selbst vor der Aufgabe steht, dann man weiß, jetzt muss ich erst mal ansetzen, dann muss ich erst mal warten, bis ich die Daten habe und es dann immer schön zu sehen, wenn man schon eine Case da hat, dass man so ungefähr ein Gefühl dafür bekommt, was kann ich erwarten an Verbesserungen und vielleicht streibe ich es in den nächsten Teil. Sehr gut. Perfekt, wäre auch eine Option dass das einfach morgen vorstellt. Ansonsten kann ich vielleicht noch ein bisschen typische Schmerzpunkte mit der ganzen Kiste vielleicht noch einmal ganz kurz referieren für die letzten 10 Minuten, die wir noch haben oder wann auch immer mich rausschmeißen. Ihr habt es ja jetzt auch schon gesehen, es ist relativ viel Input in relativ kurzer Zeit, das heißt wirklich, um sich mit dem Thema auseinanderzusetzen wirklich auch mal ran setzen, ein paar Tests laufen lassen auch mal gucken wie sich die verändern und vor allen Dingen auch in die Dokumentation von der Webpage-Test reingucken, die ist nämlich super die erklärt auch alle Werte die erklärt auch ganz sagen wir mal ungewöhnlich ungewöhnlich generierter Werte, wie zum Beispiel diesen Performance Index schauen wir mal ganz kurz, kurz in den Blick Perfekt, genau das habe ich gesucht hier seht ihr wirklich einmal ganz kurz definiert, was heißen eigentlich diese ganzen Messwerte, die man sieht also mein Webpage-Test ist gut dokumentiert und man kriegt es auch hin ohne vorwissen sich da in relativ kurzer Zeit einzuarbeiten und wenn man es dann kann dann hat man das ganz schnell ganz schnell durchgeballert so ein Test und hat vor allen Dingen aufgrund der Wasserfalldiagramme hat man dann teilweise sogar die Möglichkeit ich gucke einmal kurz drauf und ich sehe schon wo das Problem liegt natürlich cool, weil ihr auch eben solche Sachen erkennt wie ist die Seite zum Beispiel überhaupt über HTT-P2 ausgeliefert oder nicht das erkennt man sofort auf einen Blick wenn man weiß worauf man achten muss in dem konkreten Fall sieht man das daran, dass die ganzen Bilder hier parallel ausgeliefert werden wenn da noch HTT-P1 dahinter stecken würde wäre das hintereinander, das heißt das würde erst was eine gerendert, dann das andere gerendert das würde zwar nicht zur Ende gerendert aber dann sehe man so eine Stufen Darstellung und nicht eben Karten Mach mal kurz auf das Mikro Sehr gut, ja es ist 1,2 Was ich noch ganz cool finde bei Webpage Test ist und das gibt es auch nur da sind diese Videos Guter Punkt, die kann man nämlich auch mal schön in seinem Kunden zeigen wenn man sagt hier guck mal wie lange deine Seite lädt wenn einer nur 3G hat oder so kann ich mal sehr schicken die kann man sich sogar als GIF ausgeben lassen und das kann man speichern Richtig, das kann man, ihr habt das gesehen gerade in dem Waterfall-View ganz rechts in der Spalte findet man das und da hat man eben die Möglichkeit sich anzugucken zu welchem Frame zur welcher Sekunde sieht die Seite wie aus und das ist auch eine Supervisualisierungshilfe allerdings mittlerweile kann er das auch schon Früher ging das nur über die US-Server zumindest der Filmstrip-View der ist anscheinend jetzt auch schon über Frankfurt zustande gekommen und so besser das heißt, wir gucken nochmal ganz kurz wie es bei dem Video aussieht okay, das muss einmal ganz kurz rendern Super, dass das mittlerweile auch über den eigentlichen Test-Server geht, früher ging das leider nur über die US-Server, aber dann ist das wirklich ein sehr, sehr gutes Tool um den Kunden zu zeigen Pass mal auf, so sah das vorher aus und so sieht es vor allem jetzt aus sehr, sehr schön, prinzipiell dazu ist aber auch interessant Webhatch-Test hat immer die Möglichkeit komparative Tests zu machen wenn man eingeloggt ist, als Google-Nutzer speichert er die Testergebnisse ich kann dann die Ergebnisse von vor einer Woche mit denen von heute mit denen von in einer Woche vergleichen und kann dann zeigen, so hat sich das verändert können wir einfach das Video starten und so sieht das dann aus und da seht ihr auch jetzt, die Seite ist schon längst da aber das Ding rattert weiter weil hier halt immer noch im Below the Fold Bereich Sachen gerendert werden und erst jetzt ist er tatsächlich durch, auch das hilft nochmal deutlich beim Verständnis, was passiert eigentlich ja, ich habe nochmal eine Frage wie generell verhalten sich Webhatch-Tests und Page-Speed generell mit Below the Fold Content generell, wenn Bilder z.B. per Ajax nachgeladen werden wenn man das jetzt mal ganz konsequent sieht es sind 25 Bilder auf der Seite, jedes Bild braucht eine Sekunde zum Laden im Extremestall und es werden nur zwei Bilder angezeigt above the fold inwiefern beeinflusst das Page-Speed-Inside inwiefern stellt das Webpage hier Webpage-Test ich hab's immer noch nicht, ja inwiefern stellt das Tool das quasi da weil das ist ja dann quasi etwas, was der Nutzer also nicht direkt wahrnimmt was aber trotzdem eine gehörige Ladezeit ist die im Hintergrund halt passiert exakt, tatsächlich ist genau dieser Fall super um das genau einmal nachzustellen es wird zwar jetzt nicht über Ajax nachgeladen, sondern es ist einfach eine gute above the fold-Optimierung aber das wäre dann genau dieser Effekt dass die die Start-Werte, also die Time-to-Fast-Bytes und der Start-Render sind extrem kurz und dann hat man eine große Verzögerung bis man zu dem Document-Complete ist ich krieg's vielleicht heute auch noch ein Bestimm-Document-Complete-Wert bekommt das ist meistens so der Indikator dafür dass dann noch irgendwas below the fold geladen wird und man hat's ja auch gerade, ich geh nochmal kurz zurück im Video hat man's ja auch schon gesehen was der Effekt davon ist wenn er's nochmal kurz lädt und dafür ist er dann eben auch das Video und diese komparative Geschichte super geeignet wir starten das Ding und im Prinzip nach 1,2,3 Sekunden war die Seite da und alles was jetzt passiert, ist below the fold und so gibt's sich das dann wieder schlechte Ladezeit auf dem Papier aber in Realität eine sehr gute Performance weil er halt above the fold optimiert und bei Google Page with Insights muss ich leider passen ich hab keine Ahnung wie sich das auswirkt aber jetzt gucken wir nochmal ganz kurz ich hab's gesehen die Hand gucken wir nochmal ganz kurz da rein man sieht ja dass die Punktewertungen hier also wenn man nur danach geht grauenhaft sind und es wird auf jeden Fall sich in irgendeiner Form in dieser Punktewertung darstellen und ich glaube jetzt kriegen wir dazu noch Input ja ich wollte ganz gerne wissen gerade bei Seiten die ihr betreut oder unterstützt wo würdet ihr da sagen aus euren Erfahrungswerten ist es dort eher ein Architektonisches also wirklich von der Architektur ein Thema was im Prinzip aufbereitet werden muss oder kann ich da was ein Entwickler am liebsten immer machen, Performance drauf schmeißen und dann läuft es performanter ich glaube ich weiß nicht ob ich der einzige bin aber vielleicht stellt sich der ein oder andere Frage schön zu wissen wie es aussieht aber natürlich auch wo kann ich am ehesten um das natürlich zu optimieren Richtig ist auch eine wirklich wunderbare Frage weil auch die kommt natürlich von jedem Kunden dem man das erzählt wenn man gibt hier nur ein Werkzeug an die Hand um ein Problem zu erkennen, nicht um es zu lösen es ist ganz gemischt, manche Leute haben ich nenne es mal einen großen Performance-Schnitzer noch auf der Seite, dass sie z.B. SSL nicht anhaben und dann kein HTT P2 im Einsatz ist das ist easy aber bei vielen ist es dann tatsächlich so dass die Ladereinfolge kann halt optimiert werden und da gibt es kein Plug-in was das mal eben schnell macht und dann tatsächlich ran und die Seite einmal auseinander nehmen der Tobi kann aber dazu noch ein bisschen mehr Input geben der hat auch gerade das Mikro ja genau, ich bin Sys-Admin bei Redboxes und muss mich damit auseinandersetzen da gibt es wirklich tatsächlich kein goldenes Grundsätzlich wenn ich Tipps geben kann ist der erste Tipp den ich geben kann verzichtet so gut es geht auf Plugins, also nimmt nur die Plugins die ihr wirklich benötigt wir haben oft halt Kunden die haben 80 Plugins aktiv oder das ist halt noch also wir hatten auch schon wirklich mit 100 aktiven und dann kommen sie dann anrufen, dann am Freitagabend dann ja, wir sind heute an bei Galileo Fernsehen und was müssen wir denn jetzt machen damit heute Abend, das klappt alle und dann stehst du da und ich bin der Sys-Admin muss dann hart werden in der Schmeißen, in der Schmeißen gibt den ganzen Kiste dann 64 Canon, 80 Gigabyte RAM mit 10 Gigabit Leitung, ganz Internet und trotzdem 20 Request pro Sekunde und der Server ist down also das ist halt ich rate immer dazu generell halt auch beim entwickeln halt und beim Einsetzen von Plugins sucht euch erstmal eine gute Baseline an Plugins, habt die schon mal gut durchgetestet um vor allen Dingen jedes Plugin was hinzugeführt wird danach testen, also wir haben auch schon echt Fälle gehabt, da wurden da hatte der Kunde 60 Plugins gehabt und dann war es im Endeffekt nur ein Plugin was nur dafür verantwortlich war im Front, den sich dann mit Facebook da, mit den Likes da irgendwie zu verbinden, damit man das dann alles schon eingebunden hat und plötzlich lief die Seite also gerade auch so Plugins, die jetzt mit externen Dienstens zusammen arbeiten, die sind natürlich dann auch abhängig davon wie schnell sind die externen Dienste und nicht nur wie schnell ist der Einglister aber und das kann ich so als Regel mitgeben, also nacktes WordPress ist wirklich flott, muss man wirklich sagen aber mit den Plugins wird das Ganze nämlich dann problematisch und dann kommen natürlich nur so Sachen wie zum Beispiel Plugins, die dann halt Javascript optimieren und so weiter, das wird dann teilweise dadurch schneller teilweise wird es aber auch schlimmer und deswegen sage ich mal nur messen, messen, messen und während das Mikrofon übergeben wird habe ich noch ein kurzes Aditum dazu da ist es auch tatsächlich Überzeugungsarbeit, zum Einen wenn wir solche Leute im Support haben aber auch natürlich Überwindungsarbeit für euch selbst, wenn ihr da mal ran wollt, keine Angst davor auch mal eine Plugins auszuschalten und dann nach und nach jedes einzelne wieder anzumachen und mal zu gucken, was passiert. Ich weiß, das ist Frickelarbeit und das ist auch langwierig, aber es kann sich lohnen wenn man dann auf so eine Superbremse stößt hat man auf einmal eine ganz andere Seite Da kann man das zum Beispiel auch mit Skippen automatisieren Es kam gerade noch der Hinweis aus dem Publikum, dass sich über WPC-Li solche Geschichten auch automatisieren lassen, also das an und ausschalten von Plugins in dem Fall Ja, ich möchte noch nochmal kurz aus meiner Erfahrung berichten Ich bin ja im Bereich Suchmaschinenoptimierung tätig und wenn ich mit Kunden zusammen arbeite die wollen halt ihre Webseiten also nicht Großkoden, sondern eben mit WordPress arbeiten und Plugins benutzen und da habe ich mittlerweile selbst so ein Standardpaket Ich will gleich vorweg nehmen, selbst bin ich schon bei Gutenberg gelandet bei Gutenberg liefert mir alles ohne dass ich viel groß machen muss und beim PageSpeed Insight auch wertet über 90 sowohl in der Desktop-Version als auch in der Mobile-Version das ist eben auch ganz wichtig Mobile First Index ist in der Suchmaschinenoptimierung super wichtig dann fast ist der OnlySpeed Also, wir brauchen gar nicht darüber diskutieren, dass Ladegeschwindigkeit kein Seeo-Kriterium ist So, zu der wenn man jetzt hier so eine Liste kriegt von Google, was kann ich machen für die Beschleunigung der Ladezeit der Webseite also Caching-Plugins einschalten G-Sip einschalten Bilder komprimieren Bilder gleich ausliefern in dem Format wie es ausgespielt wird also so auch gleich hochladen und ja, CSS und Javascript-Dateien zusammenpacken das kann man alles mit Plugins machen Ich kriege einen Cut Genau, wir müssen jetzt aufhören auch das war noch mal ein sehr sehr guter Hinweis also die Standardoptimierungsmaßnahmen sollten auf jeden Fall durchgearbeitet werden ansonsten sehen das Ergebnis ja auch deutlich anders aus Das war's mit der Zeit, danke euch und