Eigentlich wollte ich mich an der Diskussion nicht beteiligen, aber ich habe gedacht, ich schreibe doch noch einmal etwas dazu. Ich bin zwar kein "Admin" oder so "tief" in der technischen Welt, dass ich hierzu etwas sagen kann, aber ich habe in den letzten 15 Jahren E-Commerce gelernt: Eine Cloud und damit auch die Gambio Cloud, funktioniert immer etwas anders als die Self Hosted Variante. Wir haben einen unserer Shops von Sh*pware zu Gambio übertragen, klar hätte man auch zu Sh*pify oder anderen Systemen gehen können, aber es war eine bewusste Entscheidung für ein System, welches schon seit mehreren Jahren am Markt ist und aus Deutschland kommt und einen "guten" Unterbau hat. Natürlich gibt es vor allem in der Cloud viele Abstriche, aber da gebe ich Wilken vollkommen recht. Gambio muss sicherstellen, dass der Cloudshop nach einem Update reibungslos läuft. Allerdings bin ich dann als Shop Betreiber auch dazu "verpflichtet" mich an die "Standards" zu halten, wenn ich zum Beispiel CSS Formatierungen aus dem Stylesheet nutze, die eigentlich nicht dazu da sind, dass diese an dieser Stelle verwendet werden. Das geht übrigens auch bei anderen Cloud Shops für mehrere Hundert Euro im Monat in die Hose, wenn dann ein Update durchläuft und die Ursprungs-CSS im Rahmen des Updates geändert wird (deswegen haben wir es bei Gambio auch nicht mehr gemacht ;-)). Manchmal würde ich mir natürlich auch wünschen, dass zum Beispiel Google Analytics 4 früher integriert worden wäre - für uns ist das fast fatal, dass wir es heute in unserem Shop immer noch nicht nutzen können, gleiches gilt für den Tag Manager. Hier wäre ein breites Cloud-Plugin-Portfolio sicherlich toll, aber - oftmals verwendet man dann selbst nur drei Stück und die anderen 1.000 Stück sind dann nur schön mit anzusehen. Aus der, nennen wir es mal "Gewährleistungssicht", ist das aber für alle Parteien ein Kampf, wenn ein Cloud-Update näher rückt und die Entwickler vielleicht die Freigaben nicht schaffen. Hier haben wir bei anderen Shop Anbietern auch schon gesehen, dass es dann eben Cloud-Plugins und Self-Hosted Plugins gibt. Es ist also eigentlich überall das Gleiche. Denn das Schlimmste ist, wenn der Shop steht. Allerdings glaube ich noch nicht daran, dass wir nach einem Shop Update in der Cloud massiv Kunden verlieren werden. Meiner Meinung nach - und das sage ich jetzt vor meinem anstehenden Update - liegt das vielleicht daran, dass wenn man Google Ads nutzt, dass dort noch die "falschen" oder "alten" Conversions hinterlegt sind oder aber... Es ist so langsam Sommerzeit... 30°C... Ich sitze auch auf dem Balkon mit einer Tasse Kaffee und bestelle gerade keine Dinge im Netz, weil mir danach gerade nicht ist. ;-)
das Thema wird schon seit Jahren hier durchgekaut und da ist wirklich die einfachste Lösung eine Importdatei , funktioniert bei mir schon seit jahren Problemlos
ich nutze keine Google Ads. Ich verkaufe auch über eine andere Plattform. Dort sind die Bestellungen gleich geblieben... Egal.... Das Thema kam hier schon einige Male, dass Shopbetreiber über Besucher- und Bestellrückgang nach Update geschrieben haben. Unterm Strich ist es dann entweder das Wetter oder es heißt "um diese Zeit ist es immer so".... ok, das leuchtet mir ein.
Los! Da hilft es nicht eine eigene Meinung zu haben.[/QUOTE] Das wird schnell in Wortklaubereien abdriften. Nehmen wir statt Meinungen den Begriff fachliche Abschätzungen auf den ich konkretisieren würde. Ich hab Meinungen als Begriff gebraucht weil wir immer mehr liefern wollen als nur trockenen Fachhumus. Natürlich muss das Gesamtbild stimmen, sonst passiert etwas schlechtes. Es ist aber auch totaler Unfug jedem Vorschlag von irgendeiner Google Seite als harte Währung zu nehmen und dem dann wie ein Lemming nachzulaufen. Das tut so nicht. Erstmal gibts schon mal nicht das Google, sondern eher die Googles, Mehrzahl. Das ist ein Riesenladen mit einem Haufen Abteilungen, die alle unterschiedliche Dinge machen und sich nicht immer abstimmen. Und was da gut für Google Shopping ist muss noch nichtmal gut fürs Google Ranking in den SERPs sein, das ist nicht alles auf einen einzelnen Google Standard abgestimmt. Mitunter ist das schon da widersprüchlich und Kohärenz da eher nur ein Wunsch. Wär ein guter, zieht aber nicht, es ist kein erreichter. Extra Vorsicht dann noch mit Tools wie Pagespeed Insights/Lighthouse: Die Vorschläge dort sind oft hyper-generell und universalistisch und sollen dann für jede Webseite gelten, ganz egal was das für eine ist. Bestimmte Stossrichtungen von Webseiten haben aber andere Gesetze als andere, weil die Verwendung anders ist, das Nutzerverhalten und der Content dort anders ist, das bedingt dann das die besten Regeln für die beste Webseite hier anders sind als dort, also auch und natürlich abweichen können von dem was da steht. Plumpes Autobeispiel: Grosse Kofferräume sind sehr gut! Kaufe dir einen Kombi! Schnelle Autos sind sehr gut! Kaufe dir einen Ferrari! Mit Amphibienfahrzeugen können Sie sogar über das Meer fahren! Kaufen Sie ein Amphicar! Da sollste dann schon mal einen Ferrari Kombi mit Propeller kaufen. Du siehst, dass das Quatsch ist, aber würdest du das auch bei technischen Webseitenregeln sehen? Wir ja, auch bei Details, darin sind wir ausgebildet. Und dann würde sich auch da die Frage stellen: Passen diese Tipps eigentlich zu deinem Anwendungsfall? Vielleicht brauchst du ein Wohnmobil für dein Ziel oder ein Lastenrad. Vielleicht ein Elektroauto, vielleicht Rollschuhe. Wüsstest du bei Fortbewegungsmittel ebenfalls wahrscheinlich ziemlich schnell für dich, aber wüsstest du das so genau bei Webseiten? Wir haben da fachlich begründbare und erklärbare Sichtweisen, wenn man uns denn reden lässt. Sicher ist: Folgt man trotzdem alles "guten Tipps" von Pagespeed Insights, baut man oft die spezifisch schlechtere Webseite. So formuliert antworte ich Nö. Das lässt mir zuviele andere Spielregeln ausser acht. Ausserdem gibts da Gewichtungsfragen, also die Frage wie gross der jeweilige Impact von Gegenheiten ist. Wenn wir nun aber darüber reden wer Regeln macht, dann ist das keinesfalls allein und in Hauptsache Google. Es gibt auch juristische und regulatorische Regeln, UX Regeln, ökonomische Regeln und viele weitere Quellen. Selbst wenn wir das Gespräch auf den schmalen Gesichtspunkt von Webseitengeschwindigkeit eindampfen: Es sind viel mehr Dinge die Regeln vorgeben. Zum Beispiel gibt die DSGVO einige Regeln her, die nicht erlauben ohne weiteres bestimmte Dinge zu tun, die Seiten schneller machen könnten. Das ist bei Bildern zum Beispiel null der Fall, aber bei anderen Ressourcen kann man die manchmal nicht mal eben vorab laden und damit das Rendering beschleunigen, gibt Haus. Und es gibt "Regeln", die kann man auch mal getrost informiert ignorieren. Die haben real fast keine Auswirkungen, sind also getrost zu vernachlässigen. Am interessantesten für einen Diskurs sind die Dinge, die nur etwas bewirken, aber eher sehr wenig. Ob die dann ein Muss sind oder nicht kann man vortrefflich und ewig lang streiten. Beispiel: Google interessiert eigentlich n Pupsdreck was jemand für Bildformate nutzt. JPEG, PNG, WebP, alles schnurzpiepe solange Google die Bilder überhaupt versteht, der Crawler somit durchkommt und die Nutzererfahrung am Ende stimmt. Das ist einfach nicht Bildformatabhängig. Machen wir den einen kurz aber mal wieder etwas tiefer: Nutzer und Google präferieren schnelle Webseiten. Geschwindigkeit ist auch ein Google Rankingfaktor. Es gilt aber auch: Es gibt sehr viele weitere Rankingfaktoren und das Gesamtbild am Ende machts. Man weiss auch sicher, dass Content nach wie vor King ist, guter oder schlechter Content einer Seite hat einen um Faktoren (!) höheren Einfluss auf ein Ranking als Geschwindigkeit. Anders gesagt: Für ein Ranking ist Geschwindigkeit nur die Kür nach dem man alles andere geprüft im Griff hat, um das letzte bisschen zu holen. Aus Nutzersicht ist Geschwindigkeit eine gute Sache. Real machts dann mehr Spass eine Seite zu benutzen, das hält Leute auf der Seite, das macht dann im Falle eines Shops leichter und häufiger Verkäufe im Vergleich zu lahmen Enten. Weiviel machen nun Bildformate aus? Ich hab eben mal eine Artikelseite eines Shops aus der Cloud genommen, auf der ich sowieso gerade unterwegs war und dessen Namen ich denke ich nennen darf, und zwar diese hier: https://www.schmatzepuffer.com/trixie-kuehltasche-Mr-Polar-Baer-personalisiert.html Meine Firefox Konsole macht gerade 1-2 komische Sachen (ich hab immer die tagesaktuellste Vorabversion...), aber eine Kerninformation von da hab ich gegengecheckt und zeig ich mal von da: Die Artikelseite enthält 37 Bilder mit insgesamt 1064kb oder 1,064MB Grösse. Webserver benutzen für die Übertragung Kompression, vereinfacht gesagt zipped also der Webserver die Bilder vor der Auslieferung und der Browser unzipped die Dinger wieder vor der Anzeige. Das kann inzwischen eigentlich jeder Webserver und jeder Browser und das senkt die Grösse der Übetragung. Von den 1064kb bleiben dann 140kb über, die real übertragen werden müssen, wenn die Seite das erste mal aufgerufen wird. Bei Folgeaufrufen würden schon bekannte Bilder aus dem Browsercache kommen und das viel kleiner machen, wir nehmen aber den härtesten Fall, der Erstaufruf. Würde man nun zum Beispiel WebP Bilder nehmen, sollen Bilder kleiner werden. Nur wieviel? Als Google 2016 anfing WebP zu pushen aber noch nichts auf der Welt damit umgehen konnte, sprach man von im Mittel 30% kleineren Bildern. Es gab da siggnifikante Qualitätsunterschiede weil die Software (Encoder/Decoder) Kinderkrankheiten en masse hattenund WebP eigentlich immer real erkennbar schlechter aussah als JPEG, aber das ist inzwischen gelöst. Was aber auch passiert ist, ist dass die zum Beispiel die JPEG Encoder/Decoder in den letzten Jahren genauso besser geworden sind. Stand Herbst 22 liegt der mittlere Grössenvorteil von WebP vergleichend zu JPEG bei noch etwa pi mal Daumen 10% Prozent. Wer sich dazu etwas ansehen mag, wird zum Beispiel hier fündig. Gehen wir für ein Vergleichsmodell also mal grob davon aus, dass aus 1064kb Rohbildmaterial etwa 950kb werden. Im Experiment hab ich gerade mal alle Bilder der Seite heruntergeladen, in WebP umgewandelt, auf einen Webserver im Labor geworfen und eine HTML Seite gebaut, die alle Bilder lädt. In meinem kleinen Experiment hab ich die Bilder roh auf insgesamt ca. 750kb gestaucht, mit blossem Auge war das Ergebnis ok, aber das ist jetzt echt keine präzise Wissenschaft. Was ich für einen Testload aber gerne wissen wollte: Wie weit schafft ein Standard Apache mit Transportkompression das weiter zu stauchen, wieviel Daten fliessen wirklich? Die Antwort für meinen Testfall: 126kb, also eine Ersparnis von 14kb. Da kommt ein erstmal paradoxer Effekt ins Spiel, der aber erklärbar ist und funktioniert wie Koffer packen. Wenn man verreisen will, stopf man viel Zeug in einen Koffer, den man dann, wie immer, mit biegen und drücken irgendwie zu bekommt. Grob sowas macht auch Kompression. Wenn ich aber nun den Koffer nochmal kleiner haben will, kann ich den Effekt nicht nochmal gleich wiederholen, ab einer gewissen Menge Verkleinerung kriege ich das nicht mehr viel kleiner. Dasselbe passiert bei Transportkompression. Wenn etwas schon einmal sehr gut gepackt wurde (JPEG, WebP,...), dann wird es wenn man es nochmal versucht (Webserver Deflate, gzip) nicht mehr viel kleiner. Das heisst wenn das Ausgangsmaterial in JPEG technisch etwas schlechter ist, dann hat die Transportkompression dort etwas besseres Spiel, der Unterschied verkleinert sich. Wir haben nun also 14kb Daten mehr, das kann man in Zeit fassen. Eine DSL 1000 Leitung, also ein recht langsamer Fall, kann 125kb Daten pro Sekunde übertragen. 14kb Daten zu übertragen dauert dann 0,11 Sekunden. Bei einer DSL 16000 Leitung wären es am Beispiel 0,007 Sekunden. Das ist damit der Ladezeitgewinn durch neue Bildformate für das Beispiel. Naja naja. Aus sowas leiten wir dann ab: WebP wird inzwischen von allen wichtigen Gegenstellen wie Browsern und Crawlern verstanden und ist etwas effizienter. Ist noch nicht ewig so, ist jetzt aber so. Gilt. Ein Brüller ist das aber echt nicht. Damit ists im technischen Lastenheft keine hohe Priorität, also haben wir uns nicht beeilt. Noch was: Die angesehene Seite hat Potential für Optimierungen. Da sind zum Beispiel son paar Javascript Leichen, vielfach auch durch eigene Einbindungen auf Nutzerseite, die nicht so zügig sind. Könnte man mit dem Händler mal auf den Prüfstand stellen. Da wäre aus meiner Sicht mehr zu holen. Und: Eine gute Sache gibts bei Pagespeed Insights, nämlich die Felddaten. Da wird Google aus den Rückmeldungen vom Chrome Browser (Chrome telefoniert viel nach hause....) ein Querschnitt gebildet. Sieht fürs Muster so aus: Im groben alles grün, alles im Rahmen. Da ist aus meiner Sicht eines Verantwortlichen nur die Time to first Byte über dem erwarteten Wert. In Stichproben ist das gerade nicht zu sehen, aber da ist was. Ich vermute hier einen besonderen Case, weil der Shop sehr viele Daten hat und Datenbankbackups den Shop zur Laufzeit immer kurz blockieren, das ist ein allgemeines MySQL Tech-Thema. In einem grossen Shop dauert auch das Backup dann etwas, wenn dann Besucher da sind gibts Ausreisser und ich schätze die sieht man da. Braucht Forschung. Aber zurück zum Allgemeinen wieder: Solche Daten hat Google für jede etablierte Webseite. Wenn die Seite also bei Nutzern wirklich Probleme hat, dann sieht man das da. Mit diesen Daten arbeitet Google auch fürs Ranking. Alles was darunter kommt ist ein Schnappschuss und manches echt nicht sachdienlich. Kann man sich mal mitnehmen.
Vorsicht: GX 4.7+ zählt Besucher anders als 4.6 und älter. Da sind zum Beispiel neue Mechanismen drin um einzelne Besucher nicht fälschlich doppelt zu zählen oder auch Mechanismen um Bots zu klassifizieren. Den Rest müsste man mal empirisch anzusehen versuchen.
Das hatte ich vergessen, hab ich im Labor nicht reproduziert bekommen. Leer sicherheitshalber einmal deinen Browsercache und versuch es neu. Wenn da noch alte Inhalte drin klemmen, dann siehst du vielleicht immernoch alte Zustände. Wenn das nicht hilft ist ein Ticket richtig. Dann probieren wir das mal in deinem Shop, vielleicht hat der ja ein Spezialszenario. Gib bitte auch an was für einen Browser du nutzt. Was ich nicht kapiere: Wo ist der Beinbruch ein Ticket aufzumachen? Das ist doch ein etablierter Weg persönliche Betreuung anzufordern. Und warum fühlst du dich in die Ecke gestellt? Wer tut da was, was böse oder schlecht ist?
Ich drücke uns die Daumen, dass es schnell wieder Berg auf geht. Leider trauen sich die wenigsten hier zu schreiben, dass es bei ihnen einen deutlichen Rückgang der Bestellungen gibt. Wenn sich es mehr trauen würden, dann würde Gambio sehen, welches Ausmaß es hat.
Ich Trau mich Auch wir haben Rückgänge zu verzeichnen. Ich habe Shopping aktiviert bei Umstellung auf 4800. ich dachte das hängt damit zusammen. Aber es gibt sich wieder langsam.
Hallo Bei uns auch deutlicher Rückgang von Besucher auf Webseite und auch starker Einbruch bei den Bestellungen. Cloudshop sollte ja für nicht Tech-Profis funktionieren.
Es ist Sommer, es ist Kärwa zeit, es ist Kirmes Zeit, es ist Johannisfeuer/Sonnenwende, ... jedes Jahr das gleiche! Die Probleme liegen nicht am Update, ich mach null Werbung, es läuft und ich bekomme meine Bestellungen, auch bei 30c, ich setze momentan 00,00 mühe in mein Shop um Kunden zu bekommen, da Sie von ALLEIN kommen... und das ist schon Traumhaft, sitz da und es läuft wie allein
Ich freue mich riesig für dich. Bis zum 8.6. war es bei mir genau so wie bei dir. Und das über Jahre. Ich musste nie großartig Werbung machen. Wie ich jetzt schon ein paar Mal geschrieben habe, spüre ich es nur im Online-Shop. Ich verkaufe über eine andere Plattform. Da läuft es weiterhin prima. An welchem Datum hast du das Update für die 4.8. bekommen?
Ich glaube, wir müssen noch ein - zwei Wochen abwarten. Die meisten Cloudshops haben vor ein paar Tagen erst ihr Update bekommen. Es gibt sogar noch welche, die es noch nicht haben...
Das freut mich zu hören. Aber ich denke es liegt auch ein Teil mit am Update. Vor dem Update hatten wir zwischen 1000 und 1200 Besucher lt. der Statistik. Nach dem Update nur noch 100. Auch wenn Gambio schreibt das Besucher nicht mehr doppelt gezählt werden. Nur dann müsste es immer noch so zwischen 500 und 600 Besucher sein. Und solange wir den Shop haben gab es bei uns kein Sommerloch.
ich war gestern nur am Handy, da habe ich deine Signatur nicht gesehen. Ich vermute, dass du nicht kürzlich erst eine Update bekommen hast? Denn darum geht es hier (unter anderem): Besucher- und Bestellrückgang nach dem Update.
Hast Du eigentlich einmal die Besucherzahlen in der Shop Statistik mit den Besucher- / Nutzerzahlen aus Google Analytics verglichen?
Besucherzähler optimiert, Sommer und 30°C hin oder her, Bots bestellen ja nix. Nach dem Update haben wir deutlich weniger Besucher und auch die Zahl der Bestellungen ist extrem gesunken.
Klar geht es auch bei uns im Sommer etwas zurück mit den Besuchern. Aber gleich so. 21.06.23 war vor dem Update
Nochmal: Neue Shopversionen ab späten 4.7ern zählen ganz anders als alte Shopversionen. Die erhobenen Zahlen sind im Prinzip kaum vergleichbar.