 So, wieder mal herzlich willkommen zurück nach der Kaffeepause. Ich hoffe, es sind alle gestärkt mit Koffein und wieder hell wach für unseren nächsten Vortrag. Ein Vortrag zu einem sehr spannenden Thema, ein brandaktuelles Thema offensichtlich, weil ich bekomme täglich mehrere Werbungen auf Facebook angezeigt, nämlich zum Thema Ladezeitenoptimierung. Und zu dem Thema ist heute der David Bongard bei uns. Der David ist Agenturleiter der Resonanz Online Marketing Agentur in Wien, betreut viele Kunden für die Weboptimierung, Ladezeitenoptimierung in dem Bereich. Ich habe gerade vorher gehört, dass jetzt viele Kunden aus dem Weinbereich hat, also sprich die Kunden, die wir uns alle wünschen, weil man muss ja die Produkte vorher testen, damit man sie dann richtig online präsentieren kann. Und ich bin jetzt schon total gespannt, was wir Neues hören über Ladezeitenoptimierung, wie wir das am besten machen. Bitte David, ich höre die gespannt zu. Danke. Danke auch von mir fürs Kommen. Ich muss mich gleich entschuldigen, meine Stimme klingt nicht immer so. Ich bin froh, dass ihr heute da ist, die Stimme. Und ich bin auch froh, dass ihr hier seid. Als Frage zum Einstieg, ihr wird gerne mal so ein bisschen Überblick bekommen. Wer von euch hat sich denn schon mal mit Ladezeitoptimierung beschäftigt? Wow. Also ich würde sagen, das sind so 98 Prozent. Wer von euch hat mindestens eine Webseite, die unter drei Sekunden lädt? Okay, gut. Warum seid ihr hier? Das ist zwei Sekunden werden. Alles klar. Ich gebe euch einen kurzen Überblick. Worüber wir heute sprechen, das Thema Ladezeitoptimierung ist ein relativ umfassendes und komplexes, weil es einfach so viele technische Bereiche von Webseiten betrifft. Ich möchte euch einen kurzen Überblick geben über die typischen Flaschenhälse, die Engpässe, da wo es langsam wird und euch ein paar Tools vorstellen, ganz kurz mit denen ihr herausfindet, warum ist meine Webseite langsam und wie gehe ich das Ganze an, dass das schneller wird. Dabei sind auch ein paar Plug-in-Tipps und ein paar Skriptipps. Die gibt es alle auch bei uns auf der Webseite. Ihr kriegt die Domainnache noch gezeigt. Ansonsten nehmt euch eine Packung von unseren Gummiballies, die draußen liegen, wenn ihr es noch nicht habt. Da steht es auch drauf. Da habe ich im Blog gestern schon mal den Vortrag gepostet, plus weiterführende Links und ein HTX-Skript, auf das wir auch noch zu sprechen kommen. Erste Frage, warum überhaupt Ladezeitoptimierung? Ist relativ leicht zu beantworten, es gibt eigentlich kein Argument dagegen. Es gibt eine Unmenge von Studien, die zeigen, dass schnellere Webseiten wesentlich besser performen. Um ein paar Sachen zu zitieren, die BBC in UK hat eine Studie gemacht, wo er sehr viel herausgefunden hat, dass für jede zusätzliche Sekunde, die die Seite braucht, um zu laden, 10% der Benutzerinnen verloren gehen. Das war jetzt nichts dabei, was so der Basiswert war, aber dann merkt man schon, okay, eine Sekunde ist tatsächlich ordentlich was wert. Bei DoubleClick von Google hat man herausgefunden, dass 53% Besuche von mobilen Webseiten abgebrochen werden, wenn die länger als 3 Sekunden laden. Da haben wir schon wieder diese 3 Sekunden, die kommen ein paar Mal vor. Google selbst nimmt die auch so als Best Practice Benchmark. Also 3 Sekunden unter drunter ist sehr in Ordnung. Alles, was drüber ist, ist nicht mehr so in Ordnung und ungefähr so gut kann man das Ganze dann auch greifen. Also die Frage, was ist eine gute Ladezeit, lässt sich offensichtlich relativ schwer beantworten. Niemand traut sich da festzulegen und wie man Ladezeit selbst definiert, ist auch noch so ein bisschen Waage, weil es gibt ja ganz viele verschiedene Stufen des Ladens seiner Webseite. Kommen wir nachher auch noch zu. Neben den Conversion-Raten sollte man natürlich auch nicht vergessen, dass die Nutzererfahrung auch zählt. Also gerade bei Webseiten, wo das Image eine Rolle spielt, die nicht nur rein funktional sind, geht es ja nicht nur darum, dass die Leute bleiben, sondern sie auch einen guten ersten Eindruck bekommen, weil den bekomme ich nicht zurück. Und wenn man natürlich eine Webseite präsentiert, die erstmal 8, 9, 10 Sekunden zum Laden braucht, ist natürlich klar, dass das irgendwie auf einen abferbt. Das wirkt nicht modern, das wirkt nervig und die Gefühle bleiben. Ganz nebenbei, möchte ich fast sagen, kommt da bei ein besseres Google-Ranking raus. Nebenbei deswegen, weil Google eine bessere Ladezeit nicht deswegen positiver sieht, weil einfach ihr da weniger Sekunden braucht, sondern weil wieder die Nutzererfahrung gut ist. Also was für die Google-Suche ein ganz entscheidender Punkt ist, ist natürlich, dass die Google-Nutzer mit dem Google-Such-Ergebnis zufrieden sind. Wenn wir damit zufrieden sind, kommen wir wieder, verwenden weiter Google und damit ist natürlich die Position am Markt weiter erhalten und gestärkt. Bedeutet, schnellere Ladezeit heißt ersten, sie kriegt eure Information schneller zu den Kunden. Zweitens, sendet ihr da noch ein Signal an Google, wir kümmern uns drum, wir kümmern uns um die Menschen, die auf unsere Webseite kommen. Die Realität sieht leider so aus, zumindest im Jahr 2018 in Deutschland. Best Practice wären wie gesagt drei Sekunden und wir sind in so ziemlich allen Branchen ordentlich drüber. Woran liegt, ist ganz klar, wir werden alle immer etwas anspruchsvoller, was das Internet geht, es wird multimedialer, die Webseiten werden komplexer. Es ist kein problem, eine wahnsinnig schnelle Ladezeit mit der statischen HTML-Seite, mit einer vierseite Text hinzubekommen. Aber wenn ich oben ein Slider habe mit Hintergrundvideos, wenn ich jede Menge Bilder darin habe, wenn ich unten eine Google-Map habe, die ich lade und dann vielleicht noch irgendwo ein YouTube-Video einbaue, dann wird das Ganze schon erstaunlich komplex und ohne, dass ich auch als Webseitbetreiber viel dafür getan haben muss. Wir wissen wie einfach das mit WordPlus geht hier und da mal ein Video reinzuschmeißen. Das hat aber Auswirkungen natürlich. Und dieser Anspruch wirkt sich dann eben auf die Ladezeiten aus und im Gegenzug versucht man dann das Ganze zu optimieren, um da wieder rauszukommen. Und das ist eigentlich so das Spiel, was gerade gespielt wird. Wir versuchen gute nutzerzentrierte Webseiten zu machen, die multimedial sind und gleichzeitig die auch noch schnell zu laden. Dabei nicht aus den Augen verlieren, sollte man eben im Wesentlichen geht es um die Besucher der Webseite und deswegen bedeutet auch schnell, nicht immer gleich schnell. Je nachdem, in welcher Branche ihr unterwegs seid, was eure Zielgruppen sind, müsst ihr entweder wesentlich schneller oder weniger schnell sein. Das ist vor allem auch eine Frage, was sind die Nutzer gewohnt, was wollen die Nutzer von eurer Seite, wie groß ist der Bedarf auf dieser Seite zu surfen und was macht die Konkurrenz? Warum wird ein WordPress langsam? Hat jemand Ideen, mag jemand was mal in den Raum werfen, was so typische Bremser sind bei der Webseite? Ja klar, Plugins, unsere Webseiten bestehen aus mehr oder weniger vielen Plugins. In dem Fall, man kann schon pauschal sagen, je mehr man davon hat, desto größer ist das Risiko, dass es langsam wird. Große Bilddateien definitiv auch ein Punkt. Wenn wir das Ganze ein bisschen näher ansehen, was passiert eigentlich beim Laden einer Webseite für die technisch Affinen unter euch, das ist jetzt wirklich sehr vereinfacht, mir ist das bewusst. Wir haben im Grunde drei Punkte, die eine wichtige Rolle spielen. Das ist zum einen der Server, der dafür zuständig ist, auf die Anfragen zu reagieren, die Webseite auszuliefern. Dann haben wir die Übertragung der Webseite. Hier sind wir zum Beispiel am Thema große Dateien. Langsamer Mobilverbindung, große Videos funktioniert nicht so super. Und am Schluss haben wir den Browser, der die Seite darstellen soll. Das ist das, was vielen nicht bewusst ist. Je komplexer das HTML und CSS, was ich hinschicke, und das JavaScript, desto mehr muss der Browser natürlich arbeiten, desto mehr muss auch das Betriebssystem an Leistung bringen. Das wird vielen von uns gar nicht so auffallen. Gerade auf Mobilgeräten. Wir sind alle irgendwie aus der Technikbranche. Wir haben wahrscheinlich eher higher end Smartphones. Und wir haben hier in Wien zum Beispiel eine super Verbindung. Wenn ich jetzt aber ein Mittelklasse handy nehme und irgendwo aus Land gehe, wo ich keinen 4G-Empfang habe, dann kann das schon völlig anders aussehen. Da kann es sogar sein, dass mein Facebook langsam ist. Weil einfach so viel JavaScript ausgeführt wird, dass mein Prozess richtig ordentlich läuft. Also auch das spielt eine Rolle. Im Detail. Die Antwortzeit des Servers hängt von vielen Faktoren ab. Zum einen haben wir natürlich ein Wechselspiel zwischen dem Leistungsanspruch der Webseite und der Leistungsfähigkeit vom Server. Und gerade bei günstigen Web-Spaces und shared Web-Spaces kann es natürlich sein, dass da ein ziemlich eng Pass ist. Ja, im Endeffekt ist mein Web-Space deswegen günstig, weil ich wenig Ressourcen zugeteilt bekomme. Also jeder von euch, der schon mal in einem Rechenzentrum war, weiß, dass er ziemlich high-tech angelegen hat. Dass er sich nicht unkomplex. Dann kommt kalte Luft aus dem Boden. Das ist tausendfach gesichert und so weiter. Und da stehen jede Menge Server drin. Das kostet ein Haufen Geld. Wenn ich jetzt für meine Webseite 90 Cent oder sowas im Monat zahle für mein Hosting, dann wird das wahrscheinlich kein sehr, sehr großer Teil von diesem Kuchen sein, den ich da bekomme. Das macht dann recht viel aus. Dazu kommt noch, dass shared Web-Spaces, gerade wenn sie günstig sind, wie in halt nicht nur meine Web-Seite, sondern ich teile mir die Ressourcen oft mit anderen. Ja, und die sind nicht dedicated unbedingt. Das heißt, die Rechenpower ist nicht nur für meine Seite und es kann durchaus sein, dass für demselben Web-Space andere Web-Seiten gerade viel Traffic haben und mich das dann bremst. Und ein ganz wichtiger Punkt, gerade im Moment sind veraltete Software-Versionen. Also das allerbeste Beispiel Ich weiß nicht, wer von euch ist schon auf der PAP-7-Nahreihe oder gibt es noch jemanden, der mit 5, 6 arbeitet? Ich hoffe nicht. Nicht nur wegen der Performance, was ihr hier seht, die Zahl der Requests per Second, also die Anfragen pro Sekunde, die verarbeitet werden können, sind sprunghaft angestiegen nach dem PAP-7 endlich gekommen ist, hat sich einfach massiv viel geändert und mit neuen Versionen steigt das auch weiter an. Und es gibt wahnsinnig viele Gründe, umzusteigen und auch jetzt mit diesen kleineren Release-Zyklen auf die neuen PAP-Versionen jeweils abzugraden. Zum Beispiel ist es so, dass PAP-7 end-of-life am Anfang dieses Jahres schon erreicht hat. Also wenn ihr auf 7.0 noch seid, da gibt es schon keine Sicherheitsupdates mehr. Und Ende diesen Jahres gilt das Gleiche für PAP-7.1 und das geht dann im Jahrestakt so weiter. Also es ist nicht wie früher, wo die PAP-5-Nahreihe irgendwann stehen geblieben ist und da mussten wir uns für Jahre damit begnügen. Die arbeiten jetzt schneller, die arbeiten wesentlich zeitnäher und das heißt auch für uns, dass wir da häufiger umstellen sollten. Wenn ihr mal auf PAP-7 schon umgestellt habt, erwartet euch da jetzt auch nicht so eine große Katastrophe. Ich weiß, diese Umstellung am Anfang war ein bisschen schwierig, da waren diverse Pluckins noch nicht nachgezogen, da hatte man einen Haufen Fehler. Das geht jetzt deutlich schneller. Ja, Optimierungsmöglichkeiten beim Server, einiges habe ich schon gesagt. Zum einen manchmal hilft auch einfach ein besseres Hosting, weg vom ganz kleinen Paket und ihr nehmt ein größeres Paket oder wechselt den Provider. Grad, wenn es halt keine Webseiten sind, die wirklich große Traffic-intensive-Seiten sind, muss das jetzt auch nicht ein dedicated Server oder sowas sein. Die Umstellung der PAP-Version, wie gesagt, easy und schnell gemacht mittlerweile. Was ihr außerdem überlegen solltet, ob auf eurem Server ein serverseitiges Caching vorhanden ist, dass vielleicht nicht aufgedreht ist. Ich weiß, dass es bei einigen Providern standardmäßig nicht so ist. Und da gibt es halt verschiedene Möglichkeiten, mindestens aber mal so ein Obcodecache, der normalerweise in PAP auch dabei ist, solltet ihr mal kontrollieren, ob der läuft. Das kann einen riesen Unterschied machen. Dann könnt ihr natürlich auch ordentliche Ressourcen-Fresser bei euch im System haben. Ein schönes Beispiel dafür ist bei WPML-Installationen mit String-Translation, dass dann oft das Feature aufgedreht ist, dass er die ganze Zeit und schaut bei jedem Seitenaufruf, ob es für die Text Domains neue Translations gibt. Und es ist ein ganz heißer Tipp, gerade wenn euer Backend wahnsinnig langsam ist und die euch fragt, was habe ich mit dieser Seite gemacht? Schaut es mal in die Einstellung von den String-Translations bei WPML, wenn ihr das nutzt und schaltet es einfach ab. Kenntseiten haben wir dann Ladezeiten im Backend von 10 Sekunden dabei rausgeholt, macht jetzt für den Endnutzer vorne keinen Unterschied, aber die Administratoren waren sehr, sehr erleichtert. CMS Caching, wir kommen gleich auch noch ein bisschen näher dazu, ist ein Must-Have. Schauen wir uns gleich noch an. Wenn ihr Glück habt, habt ihr auch schon Server, der mit HTTP2 ausliefert, das sind derzeit laut aktuellen Umfragen so zwischen 30 und 40 Prozent der Server-Landschaft erst, bringt große Geschwindigkeitsvorteile und CDNs sind hier auch noch ein Thema. Bereich Daten übertragen, wir haben es schon gehört, die Größe der Dateien. Die Anzahl der Einzeldateien spielt auch eine Rolle. Tendenziell je weniger Requests ihr habt an den Server, das ist der schneller geht das Ganze, weil jeder Request kostet potenziell ein bisschen was, insbesondere wenn ihr mit HTTP1 noch unterwegs seid. Und auch ein Thema, das nicht vielen bewusst ist, ist, dass die Zahl der DNS-Lookups, also wenn ihr viele verschiedene Domains anspricht, dass das auch eine Rolle spielt. Wenn ihr also, ich nenne, sagen wir JavaScript-Libraries einbindet, über CDNs, wie sie so halt empfohlen werden von jeder einzelnen Library und die laufen alle unter unterschiedlichen Domains, müssen die alle einzelnen angesprochen werden, da kann es sinnvoll sein, es entweder aus einem CDN zu nehmen oder sich das Ganze auf einen eigenen Server zu holen. Ja, Bildoptimierungsmöglichkeiten sind ziemlich simpel ehrlich gesagt. Wir kommen am Schluss bei den Plugins noch dazu. In vielen Bildern sind Metadaten drin, die können raus und viele Bilder können sehr stark optimiert werden. Ihr könnt auch viele nicht benötigte Dateien loswerden. Klassiker ist das Emoji Script, das mit WordPress mitkommt. Wenn ihr nicht unbedingt Riesenwert drauflegt, dass handgetippte Emojis in kleine Bildchen umgebastelt werden, könnt ihr direkt mal mindestens zwei Dateien loswerden und euch dadurch ein bisschen Ressourcen sparen. Genauso einfach lassen sich CSS und JavaScript-Dateien zusammenfassend und minifizieren und ein paar Server-Einstellungen, da habe ich bei uns im Block dann eben auch noch ein passendes HTX-Script hinterlegt und Link zum Weiterlesen, lassen sich relativ einfach setzen, dann wird es auch direkt ein Stück schneller. Später kriege ich, da gebe ich euch auch noch ein paar Tipps zum Asynchroneladen von Bildern, dem sogenannten Lazy-Loading, ist auch ein bisschen die Last reduziert. Letzte Engpass des Browser-Rendering, hier ist die wesentliche Information, das was ihr im Heter steht, das lädt der Browser erst mal und schaut sich das an. Und wenn ihr Sachen im Heter stehen habt, die ihr nicht wirklich sofort braucht, könnt ihr die eventuell in den Futter verschieben. Das gilt insbesondere für JavaScript-Dateien. So, wie schaut die Optimierung in der Praxis aus? Als erstes haben wir eine wahnsinnig große Auswahl von Kennzahlen. Ja, also es gibt neben der reinen Ladezeit diverse Metriken, die ihr verwenden könnt, um rauszufinden, bin ich besser geworden. Ja, die Ladezeit ist zum Beispiel auch so ein Wert, der schwankt, je nach Grad nach Server-Auslastung oder was gerade im Netzwerk los ist. Und deswegen gibt es anderen Maßnahmen, die meisten werden den PageSpeed-Score von Google kennen. Gibt es irgendjemanden, der nicht weiß, was der PageSpeed-Score ist oder noch nie von dem gehört hat? Okay, super. Genau, PageSpeed-Score, genau wie Wise Laws, was? Ach so, ich habe sie nicht verstanden. Aber das tut mir leid, dass ich in dem Moment ja sage. Ich bin sicher, dass nicht. Außerdem, es steckt so wahnsinnig viel in der Anwendung auch gar nicht dahinter. Was Google mit dem PageSpeed-Versuch, das versucht Yahoo mit Wise Law, nämlich Indizes zu bauen, die uns sagen, wie gut ist unsere Seite, relativ optimiert. Bin ich bei 50 Prozent der Optimierungsmöglichkeiten, bin ich bei 80 Prozent, bin ich bei 100 Prozent und da fließen diverse Kriterien rein. Ich werde das gleich noch ein paar Screenshots zeigen, was dort gemessen wird und man kriegt ein detailliertes Feedback, was man damit tun kann. Andere mögliche Metriken sind natürlich Ladezeiten. Da habe ich schon gesagt, da gibt es mehrere. Da haben wir das sogenannte Time-to-first-byte, also wenn die Zeit, in der der Server antwortet, seine erste Antwort gibt. Wir haben die Onload Time, das bedeutet, alles HTML ist da. Und wir haben die Fullyloaded Time, das heißt, die ganze Seite ist komplett da. Dazwischen gibt es noch eine beliebige Anzahl von Stufen, je nachdem, welches Tool man verwendet, wird anders gemessen. Das ist dann ein bisschen schwammig. Das Interessante an diesen ganzen Zahlen ist aber vor allem auch, dass es für uns relativ darum geht, die Seite schneller zu machen. Bei wenigen dieser Zahlen ist 100 Prozent möglich. Da gilt so die klassische 80-20-Regel. So ein bisschen eine Legende, dass man viele Dinge mit, was man bei vielen Dingen mit 20 Prozent Aufwand, 80 Prozent des Ergebnisses erreicht. Lässt sich jetzt wissenschaftlich natürlich nicht ganz validieren, aber es ist ein schönes Modell, um damit zu denken. Und das ist auch hier so, oft ist es so, dass Ladezeitoptimierung zu großen Teilen relativ schnell erledigt ist und die letzten Feinheiten, dass man dann noch die letzten 15 Prozent rausholt, die können dann oft beliebig viel Zeit brauchen, weil dann stellt sich plötzlich raus, oh Gott, ich musste das ganze Template umbauen. Ja, das ganze System läuft so nicht, ich muss die Plug-in zu wechseln oder so was. Und das macht es dann so ein bisschen mühsam. Deswegen aber auch die Einladung an euch, wenn ihr eure Webseiten optimiert, wenn ihr unbedingt ein Page-Speed von 100 Prozent haben wollt. Und es taugt euch total, macht es ruhig. Aber das ist eigentlich nicht worum es geht. Worum es geht, ist eine vernünftige konkurrenzfähige Ladezeit hinzubekommen. In der Zeit, die für euch vertretbar ist. Ob euch das gelingt, hängt von der ganzen Anzahl von Faktoren ab. Das ist jetzt nur zum einen natürlich der Ausgangszustand der Webseite. Ja, also mal angenommen. Ich gehe mal von aus, ihr baut so was nicht selber, aber übernimmt von von dem vorigen Dienstleister oder der vorigen Dienstleister in der Webseite, die hat 75 aktive Plug-ins und ein Multipurpose-Theme, was dann noch irgendwie aufgebohrt wurde. Dann kann das schon mal sein, dass ihr da einfach sehr, sehr viele Altlasten habt. Und dann fangen so lustige Dinge an, wie rausfinden, welches dieser Plug-ins wird überhaupt noch verwendet. Und das ist manchmal verdammt schwer. Wenn man den Kunden dann fragt, ja, ihr habt das Plug-in, das macht ungefähr das braucht ihr, das weiß der Kunde das halt auch nicht. Und ja, dann fangen dann so die lustigen Basics an, Def-Version aufsetzen und einfach mal die Plug-ins einzeln, die aktivieren wir so schauen, was passiert und so weiter. Also das braucht dann einiges an Einarbeitung. Es kommt natürlich auch ein bisschen auf euer technisches Know-How an. Ja, nicht jedem von uns wird das gleiche gelingen. Die einen sind eher auf der Plug-in eben unterwegs und haken die Checkboxen an und die anderen lesen sich auch mal den Code durch und passen den an. Und am Schluss kommt es natürlich öfters alles hin aus auf das Budget, das ihr habt, Zeit und Geld, das investiert werden kann. Und das ist eben auch immer eine Frage eigentlich des Business Values der Webseite. Wenn wirklich Geld drin steckt, macht das Sinn. Es kann auch erstaunlich viel Geld drin stecken. Beim PageSpeed-Tool von Google, bei den Google Insights, gibt mittlerweile einen Rechner, der euch ausrechnet für die einzelne Seite, nachdem die es geprüft haben, mit wieviel Sekunden Ladezeit minus, also dass die Seite schneller lädt, ihr wieviel Umsatz macht. Ihr könnt ja einfach den durchschnittlichen Wert der Einkäufe angeben, die Konversionrate, die Zugriff zahlen und dann steht dann da unten sowas wie 800.000 Euro oder so. Ich habe das mal mit geschätzten Konversionzahlen für Konradatee gemacht, da standen große Summen. Also das ist recht spannend. Bei einem kleinen Shop wirkt sich es natürlich nicht sofort aus, aber auf Zeit zählt auch das. Analysewerkzeuge gibt es wie Sandameer. Hier gibt es wirklich jede Menge. Ich habe ein paar rausgegriffen, mit denen ich schon gearbeitet habe und die mir ganz gut gefallen haben. Screenshot rechts ist von GT Matrix. Ich arbeite gerne mit GT Matrix, nicht nur, weil so positive grüne Zahlen oben kommen, das finde ich, es motiviert immer, sind wir sehr schön an der Optimierung, sondern man bekommt diese History und kann sehen, was hat sich getan. Weil relativ häufig ist es eine Schreiland-Error. Man macht mal seine Standard- Einstellung, man sieht, man schaut sich die größten Flaschen Hälse an, nimmt die raus und schaut dann, was hat sich verbessert und was kriege ich noch an Feedback. Oben in den Tubs kriegt ihr dann jeweils das Feedback, zum Beispiel von PageSpeed oder Weislow. Die haben das einfach per API dort angebunden und da kriegt ihr auch immer ein ganz detailliertes Feedback, was kann man dort machen, das verlinkt auch noch zur Hilfe Seiten. Das heißt selbst, wenn man sich nicht wirklich auskennt, man kann nachlesen, bei nicht allem versteht man dann, was da steht. Aber die größten Teile sind da sehr, sehr gute Stellung bereits eingebaut. Viele der Daten dieser Tools basieren mittlerweile auf der Lighthouse Library von Google und Lighthouse. Ich habe es heute im anderen Talk schon mal gehört, im Zusammenhang mit Accessibility bietet diverse Audits an und dabei ist auch ein Performance Audit, der euch sehr, sehr detaillierte Feedbacks gibt zur Ladezeit eurer Webseite. Der euch, ihr seht das rechts, diverse Metriken liefern, was die Ladezeitpunkte angeht, ihr kriegt unten sogar einen kleinen Verlauf des grafischen Aufbaus der Webseite zu den einzelnen Millisekunden. Und das Ganze können ihr auch einstellen, ob ihr das für Mobilgeräte testen wollt oder für Desktopgeräte und wie schnell die Verbindungsgeschwindigkeit sein soll. Und das ist wirklich sehr hilfreich, weil man es auch einfach so easy live in der Webseite machen kann, weil die Webseite auch nicht online erreichbar sein muss, weil es ja im Browser passiert. Was für konkrete Tools kann man verwenden? Ich denke, zunächst ein paar Grundlagen, die man sich anschauen sollte. Erstmal einfach mal den Verwaltungsbackend von eurem Server einloggen und schauen, findet ihr da was in Sachen Performance. Habt ihr Möglichkeiten, PRP-Versionen umzustellen auf was Neueres? Habt ihr Möglichkeiten, dort Caches zuzuschalten? Würde ich auf jeden Fall mal ausprobieren. Zusätzlich lässt sich PHT-Access relativ viel machen. Gerade im Bereich Caching-Header, dass der Browser Caching sinnvoller verwendet wird. Und schaut bitte in eure Theme-Settings. Gerade die großen Multi-Purpose-Themes haben oft Performance- Einstellungsbereiche. Da gibt es einige sehr, sehr schöne Beispiele, die das sehr gut machen. Und damit kann man oft viel bewegen. Wenn es selbstgekordete Theme ist, dann werdet ihr wahrscheinlich einen Überblick haben, was ihr dort so Performance-intensives tut. Das macht es natürlich ein Stück leichter. Thema Bilder. Tipp eins, vermeidet sie, wenn ihr sie nicht braucht. Also, wenn ihr Alkens noch als Grafiken einbindet in dem Gebel-Alkensfonds, wesentlich performanter ist und achtet auf die richtige Skalierung. Das sieht man leider wahnsinnig häufig. Dass einfach rübersehen wird, die Bilder passend zu skalieren und dann habe ich dann ein tausend pixelbreites Bild. Sollte dann spätestens, wenn ihr mit der Seite live geht, auffallen, was wir zumindest in der Agentur immer machen, wir haben so ein Qualitätssicherungsprozess und da läuft dann mal mindestens so eine PageSpeed-Audit drüber. Und die schreit dann natürlich ganz laut auf, wenn man plötzlich so ein 3MB-Bild, das so groß ist, rüber schiebt. Also, einfach die Funktion Add Image Size verwenden, passende Bildgrößen anlegen oder alternativ könnt ihr auch die Photonfunktion von Jetpack verwenden. Falls ihr Jetpack auf eurer Webseite einsetzt, da habt ihr nicht nun CDN eingebaut, sondern die Bilder werden auch direkt passend in der Größe vom CDN ausgeliefert. Dann müsst ihr die nicht regenerieren bei euch. Als Plug-in zur Bildoptimierung kann ich den ein bisschen kompliziert benannten EWW Image Optimizer empfehlen. Ist auch unter anderem deswegen angenehm, weil man nicht direkt irgendein Kontingent kaufen muss zum kleinen Rechner geht dort auch. Weil bei vielen Tools werden die Bilder Offsite optimiert und weil man damit auch Folder im Plug-in Verzeichnis zur Optimierung dazunehmen kann und eine Massenoptimierung machen kann. Das heißt, das lässt man einmal über die Medienmobilität rüber laufen und spart relativ viel ein. Weil dann werden zum Beispiel die Metadaten der Bilder entfernt und bei PNGs beispielsweise werden ganz ähnliche Farben einfach zu einer Farbe zusammengefasst. Da spart man zum Teil dann durchaus 50% Bildgröße ein. Zum Thema Jetpack zum Thema CDN und Lazy Loading Content Delivery Networks sagt das jedem was. Also Möglichkeit, eure Medien auf andere Server auszulagern, die performanter sind, die möglicherweise geografisch näher am Kunden sind. Da bekommt ihr mit dem kostenlosen Jetpack Plug-in auch kostenlos die Photonfunktion, die das im Grunde für euch komplett kostenfrei übernimmt. Es gibt wahrscheinlich bessere CDNs, aber das ist auf jeden Fall kostenlos und gerade für kleinere Webseiten ist das eigentlich nicht so lange drüber nachdenken muss. Zahl der Requests reduzieren, wichtigstes Mittel CSS und JavaScript minifizieren und zusammenfassen. Ich kann sehr empfehlen Out Optimize ist nicht die einfachste Methode. Man muss sich da oft ein bisschen reindenken. Man muss testen, ob es Fehler gibt. Wenn man die Teilen zusammenfasst, kann aber ordentlich viele Requests einsparen. Das gibt euch dann wieder Pluspunkte in den Audits. Wichtigster Punkt finde ich, keine Webseite sollte ohne Live gehen, ist das CMS Caching. Jedem klar, was sonst CMS Caching macht. Nein, gut. Wenn ich eine Webseite vom Server anfordere, zum Beispiel jetzt in WordPress, muss jede Menge Programmierung ausgeführt werden. Es werden Datenbankabfragen gemacht, um diese Webseite zusammenzustellen, diese einzelne Seite und dann wird die ausgeliefert. Und diese Last auf dem Server, dass das Ganze berechnet werden muss, die kann ich mir sparen und das machen und alles fähig ist. Es gibt V2-Cachings, in denen die Statische HTML-Dateien generieren, ablegen und beim nächsten Aufruf die fertige Datei ausliefern. Die Frage, die man sehen stellen sollte, ist, wie oft sollen sie refreshed werden? Wie oft ändern sich die Inhalter, das kann man in diesem Plugins wunderbar einstellen. Ich kann alle drei Wärmstens empfehlen. Beim W3-Total Cache ist der Schwierigkeitsgrad eher hoch. Da kann man viel mitmachen. Man kann auch viel damit kaputt machen. Super Cache Seiten möchte ich nicht gecached haben. Beispielsweise, wenn ihr einen Online-Shop habt, wollt ihr den Warenkorb nicht caschen. Ja, meistens wird das automatisch bei Vukummer so ausgeschlossen. Aber wenn ihr selbst das programmiert, solltet ihr daran denken, das kann es euch leicht passieren, dass die falschen Nutzer die falschen Warenkörbe gezeigt bekommen. Das wäre natürlich der Worst Case. Zum Abschluss, ganz kurz im Überblick, fünf Schritte für Einsteiger, wenn ihr das noch nie gemacht habt, das sind die Sachen, die ich euch auf jeden Fall raten würde. Server-Einstellung prüfen. HTXS Optimierung, das ist quasi Copy und Paste. Bei uns im Blog findet ihr wie gesagt ein Beispielskript. Das kopiert ihr euch einfach in die HTXS-Datei. Damit kriegt ihr auf jeden Fall einen Haufen Plus-Punkt und habt nahezu Null Arbeit. Es hat drei Sterne beim Schwierigkeitsgrad, weil nicht jeder weiß, wie an seine HTXS-Datei reinkommt. Ich bitte dazu, dann nachzulesen und auch ein bisschen über die Risiken und dass ihr wisst, wie ihr sie wieder raus werft, wenn ihr die Webseite abgeschossen habt. Der ist ohne Trial and Error geht es nicht und das ist aber auch das Lustige dabei, eben rauszufinden. Hat das jetzt funktioniert, was ich gemacht habe? Hat es einen Plus-Punkt oder ein Minus-Punkt? Weil nicht alles von diesen Optimierungsmaßnahmen macht die Seite nachher auch schneller. Manche treten sich so ein bisschen auf die Füße. Bildoptimierung, kein Grund zum Nachdenken, einfach mal installieren und loslaufen lassen, könnt ihr nur gewinnen. Out Optimize ist unterschiedlich schwierig. Je nachdem, wie komplex euer Theme ist oder eure Plug-ins, die ihr verwendet, kann es sein, dass es jede Menge Fehler produziert und es sehr, sehr schwer zu konfigurieren ist. In anderen Fällen ist es so, man dreht es auf und es läuft einfach. Das ist immer ganz unterschiedlich. Ja und beim CMS-Caching, wenn ihr euch nicht mit den Teils beschäftigen wollt, empfehle ich euch Supercash. Das hat eine super einfache Einstellung, wo ich eine Checkbox anhaken und dann läuft das grundlegend schon und von daraus gibt es dann auch mehr Einstellungen, die man sich so ein bisschen einarbeiten kann. Und wenn ihr sonst nichts macht, Punkt 5 würde ich euch in jedem Fall empfehlen, das ist die eine Sache, die einen Riesenunterschied macht, gerade wenn ihr auf einem etwas schwachbrüstigen Server unterwegs seid. Wenn ich mir die Ausführung von PAP weitgehend sparen kann und die Datenbank abfragen sparen kann, dann hole ich sehr, sehr viel Zeit dabei raus. Ich bedanke mich fürs Zuhören. Wenn ihr noch Fragen habt, gerne jetzt oder meldet euch einfach bei mir oder sprecht mich nachher an. Ja wunderbar David, ich sage herzlichen Dank, auch für mich wieder viel Neues dabei. Ich als ehemarke Tier, habe ich schon gesagt, als Profi. Gibt es Fragen von eurer Seite? Ich bin nicht der Frontend Profi, aber ich glaube, es gibt auch die Möglichkeit, sich die Eigenfond selbst zusammenzustellen. Genau, also wenn du einfach den gesamten Fronten nimmst von irgendeiner Librarian, dann ist das natürlich riesig und dann macht es keinen Sinn, da bin ich ganz bei dir, aber es gibt ihm die Möglichkeit, es reduzierter zu machen. Ja, das ist ein bisschen das Problem der Seams. Ja, richtig. Also das ist ein bisschen die Problematik, auch die einige Plugins haben, die hauen dann halt einfach alles rein und dann steht man nachher da und hat 90% Sachen, die man nicht braucht. Da macht es dann Sinn, da ein bisschen ins Detail zu gehen und da ist dann nämlich auch das, was ich angesprochen habe. Da kommt dann oft der Aufwand rein. Ja, ich habe es jetzt nicht im Kopf, es gibt ein Plug-in, das dafür sorgt, dass es nicht sofort eingebunden wird und man kann es auch behand programmieren. Wenn man einfach diese M-Bett nutzt, dann wird meistens der ganze Kram dann mit der Seite geladen, nach dem ersten Rendering meistens. Ich weiß aber, dass das, was zum Beispiel Google PageSpeed sich am meisten darüber beschwert, sind meistens die Google Produkte. Das ist ein bisschen absurd, aber sobald ich eine Map da drin habe, haut mir, dass die PageSpeed-Werte direkt durcheinander, sobald ich ein YouTube Video habe, auch. Das sind dann diverse Beschwerden, wo man nichts dran machen kann. Ich würde da raten, die YouTube-Videos erst reinzuladen, also es sind zum Beispiel solche Workarounds, die wir machen, erst reinzuladen, wenn sie wirklich abgespielt werden sollen. Das heißt, wir machen ein Vorschaubild und wenn man draufklickt, dann wird das Video ausgetauscht. Dann muss ich das nicht alles schon mit dem Laden der Seite reinladen. Insbesondere, wenn man mehrere YouTube-Videos hat, mit normalem M-Bett ist es absolut absurd, dann wird der ganze Kram für jedes Video neu reingeladen. Das kann man sich sparen, wenn man es selber reinprogrammiert, zum Beispiel über die JavaScript-App von YouTube. Ich denke aber, es gibt da auch Plug-ins. Also ich habe sowas gelesen, ich habe selbst noch nicht eingesetzt. Weitere Fragen. Ja, also klar, es kommt immer ganz drauf an, wie bildlastig man da ist. Also wenn wir mal was Bildschirmpfüllen, das hat auf 2000 Pixel und dann möchte man das dann auch noch auf Retina schön haben, dann ist man natürlich bei einer gewaltigen Dimension. Ich denke aber, das ist dann auch einfach eine Designentscheidung der Webseite. Also da kommt man nicht ganz dran vorbei. Was wenig bringt, ist radikal die JPEG-Kompremierung rauf, dann ist wieder bei der Optik weg. Das ich da sehr empfehlen kann, zum einen solche Optimierungstools, die das Ganze nämlich auch dann lossless hinkriegen, relativ viel Daten zu sparen und dann Lazy-Loading, dass das nicht direkt vom ersten Render mit lädt, sondern einfach danach, wenn die Webseite schon da ist. Das ist meistens der beste Kompromiss dafür. Sonst noch Ideen, Fragen, Diskussionseinwürfe. Wir haben es bei einer Seite laufen, bei einer anderen ausprobiert, da war aber die Bildqualität wichtig und da hat die etwas nachgelassen. Also man merkt es ein bisschen. Ja, macht Sinn. Ist auch bei dem einen genannten Plugin, bei dem EVW Image Optimizer, gibt es dann auch eine WP-Funktion, die generieren das automatisch und schreiben auch, das hat ja Access, um das automatisch auszutauschen in den passenden Browsern. Macht viel Sinn, es spart wahnsinnig viel Ladezeit. Qualität bin ich mir selbst noch nicht ganz so sicher, ob ich damit zufrieden bin. Es gibt diverse Plugins, die es können. Es ist glaube ich letzte Woche, ist ein Update rausgekommen. Ich bin nicht ganz sicher, ob vom EVW oder von Out Optimize, da ist ein Lazy-Loading jetzt drin, hier kagt meine Checkbox an. Ansonsten ist es auch bei Jetpack zum Beispiel dabei. Ja, also Jetpack kann ich Ihnen sofern empfehlen bei diesen Sachen, weil man hat so einem dieses Content Delivery Network, das CDN, nicht nur für Bilder, sondern auch für Statische Dateien. Das heißt, oft werden auch vom Theme einfach die CSS-Dateien dann schon aufs CDN ausgelagert und es ist eben das Lazy-Loading dabei. Ich habe bei ein paar Seiten ein bisschen Probleme gehabt, weil das CDN von Jetpack nicht ganz so viele Funktionen hat wie andere, aber das Lazy-Loading hat einen ordentlichen Eindruck gemacht und ist auch noch relativ frisch, ist glaube ich der einfachste Weg. In dem Fall ja, dann würde ich es nicht machen. Ja, das ist noch eine Frage des Lizenzrechts, natürlich. Ja, also ich meine, wenn die Verpflichtung da ist, die Metadaten drin zu lassen, damit sie identifiziert werden kann. Ja, also ich glaube, so pauschal kann man es nicht sagen, weil es in Privacy-Schild drin ist. Wie genau das im Detail ist, kann ich ehrlich gesagt nicht wirklich beantworten. Also das ist aber auch zum Beispiel eine Frage beim Thema Google Fonts. Darf ich die jetzt verwenden oder nicht? Die einen sagen ja, die anderen sagen nein. Also wenn ich sie über Google Fonts direkt einbinde zum Beispiel, kann ich jetzt so pauschal nicht beantworten. Ich weiß nicht, ob irgendwer von den WordPress-Leuten sich da besser auskennt, aber ich glaube von Jetpack ist eh jemand draußen, oder? Das ist ein Stand von Jetpack, die werden Sie sicherlich beantworten können. Oder auch nicht, aber wir hoffen einmal. Aber die kennen vielleicht wen, der es weiß. Bitte. Gute Informationen, super. Gut. Nachdem es jetzt keine Wortmeldungen mehr gibt, sage ich herzlichen Dank, David. Ich weiß jetzt, an wen ich mich wenden muss, wenn unsere Ladezeit nicht passt, wahrscheinlich passt, sehe ich nicht. Ich werde auch nicht vergessen, eine gute Flasche Wein mitzunehmen. Noch mal herzlichen Dank für deinen tollen Input hier. Ja, danke auch.