Ich will keinen fetten Bock mit Käse! Gut und danke, ich denke du weisst sehr gut wovon du sprichst, das beruhigt mich.
Früher war das alles nicht so dynamich und mehr statische feste html Seiten. Kaum PHP das sich die Inhalte zusammensuchen und berechnen musste. Klar, das geht viel schneller. Heutzutage hast aber Designs das sich anhand des Screens anpasst ind Breite und Layout und dynamische Inhalte.... Spielereien und FUnktionen die damals nicht möglich waren. Das kostet leider Ladezeit. Virtual Server is auch schon bischen viel Power. Je nach V-Server jedenfalls. Den muss man ja auch optimieren und so. Macht dir das jemand? Sonst wäre ein guter Webspace bei einem Hoster wie Estugo oder so vielleicht sinniger. Und günstiger vielleicht auch noch. Nur mal so gefragt, wieviel Besucher hat dein Shop den Schätzungsweise später mal? Wird dein Shop, wenn du ihn mit Gambio fertig hast und live stellst von vielen Stammkunden und so sofort aufgerufen , ersetzt also den alten sofort und muss den Trafic direkt aushalten oder ist eher wenig los? Dann kann man viel mehr nachher optimieren wenns schon angelaufen ist.
Moin, sorry das ich mich jetzt erst melde, war im Urlaub. Wir haben seit Anfang des Jahres das Modul wieder im Betrieb. Bis Dato gab es keine weiteren Probleme mit Google & Co. Die obere Info ist schon etwas älter, hätte ich hier mal berichtigen sollen ;-)
Das Modul kann ich nur empfehlen. Gerade die neuen Versionen der Gambio-Shops sind sehr langsam geworden. Jedenfalls ist das so bei uns gewesen. Mit den neuen Theme-Versionen will man auch die neuen Möglichkeiten der Gestaltung nutzen und die Seiten mit vielen Bildern bestücken. Da war es bei uns so, dass die Seiten fast 3 bis 4 Sek. gebraucht haben. Jetzt mit dem neuen Modul sind die Seiten Ratz-Fatz da. Für alle die auch viele Inhalte, Bilder und Contents in ihren Seiten haben, schaut euch mal das Modul an. Ich bin begeistert. Edit: Mit einem Cronjob auf dem Server geht der Aufbau des Caches automatisch. Der erste Aufbau hat gerade mal 162 Sek. gedauert, bei 1513 Seiten.
... persönlich kann ich es nur empfehlen, evtl. Vorbehalte hin-oder-her, wenn die Website erstmal fertig ist. Von ehemals 2.5 Sek auf 0.06 Sek Ladezeit - wüsste nicht, wie man es mich angemessenen Mitteln sonst auf die Reihe bekommt. Daneben achte ich immer noch auf möglichst datensparsame Darstellung auf der Website. Komprimieren & Resizen was die Tools hermachen und was noch gut aussieht. Aber jeder soll frei entscheiden dürfen, ob es für ihn/sie etwas nützt.
der Gedanke ist schon nicht schlecht, wir hatten das Modul vor kurzem auch mal getestet. Das Problem ist nur, in der Beschreibung steht beim Cache erstellen "Das kann einige Minuten dauern" , was maßlos untertrieben ist, bei uns hat das 11 Stunden gedauert, weil wir ca. 17000 Links in der Sitemap haben. Und das musst du nach jeder Webseitenänderungen neu machen, weil sonst ständig das alte Zeug ausgegeben wird. Zudem war danach noch unser Webspeicher übervoll, wodurch wir hätten noch zusätzlich Speicherplatz bezahlen müssen. Wir sind auch mittlweile ohne Modul mit unseren Werten zufrieden. Die Seite liegt immer so bei 85 , die meisten Unterseiten zwischen 90-100 , und der LCP bei 2,1 . und wir testen grundsätzlich nur mit dem Speedtester von Google
Das ist Sicherheit so nicht richtig. Nochmal kurz etwas Aufdröselei: Das Modul zur Ladezeitoptimierung cached Seiten komplett. Bei Abruf werden die nicht mehr live errechnet, sondern vorab und dann als immergleiche Seite sofort ausgespielt. Das ist schneller als die Errechnerei just in time, es killt nur Zufallselemente in der Seite. Wenn alle immer die gleiche Seite kriegen, gibt es zum Beispiel keine Startseiten mit zufällig wechselnden Produkten mehr. Auch einige andere normal dynamische Elemente der Seiten fallen da rein, das geht nicht gleichzeitig. Das ist der grosse Pferdefuß, dem mehr Geschwindigkeit als Haben entgegensteht. Das Modul fasst auch nicht alle Teile einer Seite an, sondern im Kern nur das eigentliche HTML Dokument. In einem anständigen Hosting mit normal gut optimiertem Shop braucht das live Erzeugen des Dokuments pi mal Daumen 300ms = 0,3 Sekunden. Contentseiten liegen ähnlich bis etwas schneller, Kategorien je nach Szenario normal zwischen 250-500ms. Startseiten, als mit komplexeste Aufgabe liegen in einem schlanken Shop bei 300ms für das Dokument, wenn man die vollknallt kommen aber auch mal 800-1000ms raus. Diese Aufgabe kürzt das Modul im Messmittel auf konstant etwa 25ms. Das ergibt einen mittleren Ladezeitvorteil in einem Spektrum von pi mal Daumen 300ms bis 950ms, abhängig vom Szenario und der jeweiligen Seite. Danach müssen immernoch Assets geladen werden, also statische Dinge. Das sind Javascripte, CSS, Schriften, Bilder,... der ganze Vorgang kommt on top und bleibt in jedem Fall trotzdem da. Eine relevante Gesamtladezeit von Seiten in 0,06 Sekunden ist also praktisch unmöglich, nie im Leben. Das ist sicher nicht böse gemeint, aber da verhohnepiepelt dich deine Messmethode. Niemand sieht so schnell eine Webseite. Die 2,5 Sekunden sind dann auch sone Frage für sich. Wenn das einem gesamte Seite (Dokument + alle Assets) meint, wäre die Ladezeit keine Katastrophe. Nicht perfekt, aber auch nicht schlecht. Ich würde hier aber davon ausgehen, dass mit 0,06 Sekunden die irgendein Blödsinnstool misst nur das Dokument ohne Styles, Bilder usw. gemeint ist, dann wären 2,5 Sekunden eher mies, weil der Rest dazu käme, was beim Nutzer dann bei vermutlich 4s endet. Das verprellt nicht jeden Kunden, aber wird Umsätze sicher nicht steigern. Was ich hier am Ende sagen will ist: Das Modul ist gut, ich mag das Modul und was es bewirkt, das passt für so einige. Ich finds nur doof, dass schon insgesamt relativ systematisch immer wieder von vielen falsch beschrieben wird was das kann und wieviel da am Ende herauskommt, das liegt sehr oft deutlich über der Realität. Man muss also wissen was das Ding ist und sollte nicht erwarten, dass das zaubert, das kann keiner. Und man muss wissen, was damit nicht mehr geht, das hab ich oben gerade extra nochmal beschrieben. Wenn man das ganze dann mal etwas realistisch anschaut, wirds immernoch für viele interessant sein, aber hoffentlich mit realistischeren Horizonten beworben, das fände ich angebracht und bessere Entscheidungsgrundlage.
EInen großen Vorteil unterschlägst Du: Das Modul erzeugt aus allen PNG- oder JPEG-Bildern neue Bilder im WEBP-Format, welche um zwischen 60% und 90% komprimiert werden.
Ja, jein... Es ist etwas komplizierter. Und man erreicht normal keine 60-90%. 60% ist üblicherweise schon hochgegriffen. Nehmen wir mal das "gute alte" JPEG. Auch da ist ja verlustbehaftete Kompression durchaus eine Option, allerdings wirds auch mal Pixelmatsch wenn man zu stark am Regler schiebt. In einem augenfreundlichen Bereich davor gibts aber schon relativ starke Grössenunterschiede. WebP hat denselben Mechanismus, bei freilich andere Kompressionsalgorithmen. Die sind komplizierter, aber auch besser im Ergebnis. Angenommen du vergleichst gut eingestelltes JPEG mit gut eingestelltem WebP auf mittlere Bildgrössen, dann sind 25-30% kleinere Bilder näher an der Realität. Für 60 - 90 Prozent bräuchtest du einen Labortest, der so real ist wie Verbrauchswerte beim Autokauf... Was das am Ende für eine Seitenladezeit ausmacht ist dann abhängig vom Objekt, vor allem von Mengen und Grössen der eingesetzten Bilder. Das ist um eine Erwartbarkeit in eine Formel bzw Zahlen zu fassen etwas komplexer. Man muss dann Annahmen treffen was für eine Verbindungsgeschwindigkeit ein Kunde/Besucher hat, sich ansehen wieviel Bilddaten über die Leitung gehen, dann kann man die benötigte Übertragungsdauer ausrechnen. Man kann dann auch die Datenmenge einfach mal 25% oder 30% herunterskalieren und dafür die Vergleichszeit ausrechnen. Gehen wir mal ganz praktisch rein, mit einem Beispiel... Erstmal für Thema 1, Ladezeit des HTML-Dokuments drücken und erwartbare Vorteile für die Gesamtladezeit einer Webseite mit besprochenem Modul herausfinden. Ein Screenshot aus meinem Browser mit einem hervorragenden Gambio Shop für Reinigungsutensilien: Das Bild entstammt meinem Firefox, in dem ich mit F12 die Konsole geöffnet habe und für die hier spannende Messung den Netzwerktab geöffnet hab. Der Browsercache ist oben per Haken deaktiviert, damit jeder Aufruf garantiert "kalt" ist, das sollte man dann machen. Dann einem die Seite aktualisieren, und man bekommt Messwerte. In diesem speziellen Fall hab ich noch was gemacht, was das Messbild eigentlich verfälscht, aber nicht unerwähnt bleiben soll: Ich hab Christians Googleeinbindung geblocked. Die lädt ca 3 Sekunde nach dem Seitenrendern verzögert Daten nach, genauer versucht sie dann noch Tracking zu betreiben. Ein Kunde sieht das nicht, für den ist die Seite schon lange reaktiv und nutzbar. aber jedes Ladezeittool der Welt, besonders dafür zu schlecht gestrickte wie ieben Pagespeed Insights, wird sehen da passiert noch irgendwas, also waren wir nicht fertig, also kommt das in die gemessene Ladezeit. Das hat mit echter Welt oder Sachverstand so wenig zu tun wie irgendwas und ist darum per URL Blocking (rechtsklick auf die entsprechende Requestzeile in der Auflistung der Konsole, versteht Sternchen als Joker...) blockiert. Fürs konkrete Beispiel: Das HTML Dokument der Artikelseite hat bis zum Browser 409ms gebraucht. Ich hab ein paar mal nacheinander gemessen, es ging auch mal in 350ms aber auch mal in 500ms, etwas Schwankungen sind durchaus normal. Aktuelle Shopversionen müssten etwas fixer sein, aber dieser Shop auf gutem Server braucht fürs Dokument nun 400ms. Unten steht eine Gesamtladezeit von 1,2 Sekunden. Das Modul von Werbemarkt kann aus den 409ms etwa 25ms machen, macht eine Beschleunigung von 384ms. Aus den 1,2 Sekunden Gesamtladezeit gesamt würden 0,81 Sekunden werden, das ist das was geht. Eine kleine Anmerkung dazu: Mit meiner 250mbit Leitung hier in meinem Homeoffice hab ich natürlich eine schnell Leitung vor mir. Das Modul spart die Leistung serverseitig, der Vorteil beim cachen des Dokuments ist statisch. Der Server beginnt früher eine Antwort zu senden, danach ist immer alles abhängig von der Bandbreite des Nutzers. Noch ein fixes Zahlenspiel: Die Seite ist wie man unten ablesen kann ca 1,6MB gross. Nehmen wir einen üblen Fall und ein Kunde hat DSL 1000, dann kann er mit 125kb/s bzw. 0,125MB/s Daten empfangen. Bei so einer Leitung dauert der Abruf einer 1,6MB Webseite (1600kb geteilt durch 125kb/s=) 12,8 Sekunden für die reine Datenübertragung. Dazu kommt ontop die initiale Wartezeit bis der Server die Antwort abschickt, die das Modul optimiert. Wir reden hier dann ohne Modul über 12,8s+0,4s=13,2s oder mit Modul 12,8s+0,03s=12,83 Sekunden. Jetzt der zweite Faktor: WebP und JPEG/PNG. Deine getestete Webseite enthält ca 1,1MB Bilder, Zahl schnell aus Pingdom geholt: Wir nehmen jetzt mal an deine Bilder sind "herkömmlich gut optimiert, wir könnten mit WebP durch den Formatvorteil einen zusätzlichen Optimierungsgrad von 30% erreichen, das ist wie gesagt plausibel, dann würden aus 1,1MB durch den Wechsel 0,77 MB. Auf einer schnellen Leitung ist eine Messung da eher witzlos, das sieht niemand raus. Auf meiner DSL 250.000 Leitung (=31250kb/s oder ca 31MB/s) wären das beides bequem unter einer 0,1 Sekunden, auch der worst case Fall. Da pfeift kein Schwein nach. Nehmen wir nochmal den DSL 1000 Fall, der hat mehr Futter, bleibt etwas mathematisch... Wir können davon ausgehen, dass weder gzip noch Deflate Transportkompression auf der Leitung einen nennenswerten sichtbaren Einfluss haben. Was schon gut gepackt ist, kriegen die beiden für den Weg über die Leitung nicht mehr kleiner. Wir können damit davon ausgehen, dass der Platzvorteil von WebP direkt von dem jetzt gemessen Datenvolumen der Seite 1:1 heruntergeht. Die Beispielseite wird dann statt 1,58MB mit bislang 1,1MB JPEG Bildern eher ( 1,58MB - ( 1,1MB - ( 1,1MB *0,7 ) ) = ) 1,25MB gross sein. Die Ladezeit für die Bilder als Teil der Seite sinkt dann von (1,1MB * 0,125MB/s = ) 8,8 Sekunden auf ( 0,77MB * 0,125MB/s = ) 6,16 Sekunden, das ist auf der Leitung ein Unterschied von 2,64 Sekunden. Zusammen mit den ca 0,37 Sekunden aus dem Caching des Dokuments runden wir grosszügig mal auf 3 Sekunden Ladezeit Beschleunigung für Leute mit lahmer Leitung. Zusammenfassend: Jemand der eine schnelle Leitung hat sieht von all dem so oder so ziemlich wenig. Das "fertige" Dokument aus dem Cache wird sich am stärksten auswirken, weil die Bilder in der Menge so oder so ratzfatz (0,1 Sekunden hier...) gehen. Gesamt kommt die Person auf 0,8 Sekunden Ladezeit statt 1,2 Sekunden. Er wird beide Zeiten schlicht als zügig empfinden. Für jemand mit bilderbuchtauglich langsamer Leitung ( DSL 1000 ) wirds deutlicher. Von 13,2 Sekunden gehts runter um 0,37 Sekunden beim Dokument und 2,64 Sekunden für die Bilder, das sind gesamt 10,06 Sekunden. Das rettet nicht alles für die , ist aber sicher notabel.
@Wilken (Gambio) das ist ja alles schön und gut von dir beschrieben, wie sieht es den mit Mobil Geräten aus, Android IPhone etc.. die Core Web Vitals in der Google Search Console werden für die Mobilen Daten gemessen und ausgewertet. Ich denke da gucken die meisten hier nach? Meist ist das Problem mit LCP länger als......
Nur beschreibs doch den anderen Fischen besser Sind auch beides valide Punkt, wird aber nicht auf ewige Zeit Shops mit dem Modul allein vorbehalten bleiben. Macht eigentlich keinen drastischen Unterschied in der Betrachtung. Was haste für Unterschiede? Du hast inzwischen in vielen Handies in unseren Industrielängern relativ passabel Rechenleistung, also geht das Rendern einer Seite im Gerät relativ gleich schnell. Du hast kleinere Displays, das macht aber nicht sofort direkt was für die Ladezeit. Lazyloading, das Hartwig gerade ansprach ist am Desktop und Handy gleichermassen praktisch. Was Sinn machen kann ist für Handies mit kleinerem Screen kleinere Bilder liefern, mit srcset behafteten Bildern und Bildcontainern, das ist aber eine Diskussion, die wir hier auch noch gar nicht hatten... Was dann noch bleibt ist eventuell schlechter Handyempfang. Wer irgendwo unter anständigem UMTS/LTE/5G Empfang steht hat normal was brauchbar fixes. Datenvolumen ist sekundär interessant, weil Leute nach Volumen zahlen, aber das ist Humanismus an den Nutzern. Wer schlechten Empfang von irgendwas hat, bei dem nutzt auch hohe Optimierung wenig...
Core Web Vitals sind Google-Ranking-relevant. Mit dem Modul Ladezeitoptimierung von werbe-markt.de habe ich laut google den Test bestanden, ohne Modul nicht. Allein das reicht als Grund, das Modul jedem Gambio-Nutzer zu empfehlen. Auch die Ladezeiten haben sich radikal verbessert.