Die Erlebniswelten Bearbeitung wird bei uns ab dem ca. 10. Block sehr langsam.
Dabei werden nur ein einfaches Grid, Text und Bildelemente verwendet.
Im Frontend lädt die erstellte Erlebniswelt dagegen ohne Probleme.
Woran kann das liegen?
Ergänzung:
Werden die Blöcke Stück für Stück gelöscht, sieht man, wie die Speicherzeit sinkt und die Ladezeit wieder schneller wird. Es werden keine Fehlermeldungen angezeigt.
Verwendete SW-Version: 6.4.20.
Das Verhalten kann aber auch in anderen SW-Versionen beobachtet werden.
Wie können wir die Lade- und Speicherzeit verbessern?
Kann schon sein das der Editor da an seine Grenze kommt, der komplette Editor ist generell etwas suboptimal gelöst. Über was für eine Speicher- bzw. Ladezeit sprechen wir hier, 10 Sekunden, 3 Minuten?
Aber wenn du sagst das es keine Fehlermeldung angezeigt werden und es im Frontend ohne Probleme läuft gibt es da wahrscheinlich nicht viel Verbesserungspotential.
Danke für’s schnelle Feedback.
Ladezeit bzw. Speicherzeit ca. 10-15 Sekunden, dann beim runterscrollen wieder Ladezeit von einigen Sekunden.
Diese Ladezeiten summieren sich natürlich, wenn nach einer Blockänderungen gespeichert wird und dann noch auf eine Sprachvariante der Erlebniswelt gewechselt wird…
Haben andere User ähnliche Erfahrungen? Wir können doch nicht die einigen sein die mit etwas komplexeren Erlebniswelten arbeiten …
Gibt es evtl. Einstellungsmöglichkeiten (PHP-Werte etc.) die die Ladezeit beschleunigen können?
Vielleicht hilft diese Änderung mit dem neusten Update auf 6.5.1 ja weiter: platform/2023-03-07-improve-performance-cms-block-config.md at trunk · shopware/platform · GitHub
Mittlerweile mit aktuelleren Systemwerten (PHP8, MYSQL 8, Shopware 6.5.7).
Leider ist die Bearbeitung der Erlebniswelten immer noch ein Geduldsspiel.
Es scheint ja nach meinen letzten Erkenntnissen nicht am Webserver zu liegen, sondern daran, dass im Shopware-Backend alles per Javascript zusammengebaut wird.
Hat jemand einen Tipp um das zu beschleunigen?
Im Browser (FF) sehe ich leider keine Möglichkeit mehr Systemressourcen für Javascript-Prozesse zur Verfügung zu stellen…
Dazu muss aber erst einmal analysiert werden, wo die Ursache liegt. Kann ja schlicht und einfach am Browser liegen.
Das Problem erstreckt sich leider über unterschiedliche Rechner und Konfigurationen (FF/Chrome etc.).
Sind wir wirklich die Einzigen mit extrem langlamer Erlebniswelten-Bearbeitung im Backend?
Denke nicht, bei uns ist das auch der Fall.
Ergibt sich bei uns aber durch die Komplexizität der Erlebniswelt.
Diverse „kurze“ Unterseiten gehen halt innerhalb ein 1-2 Sekunden. Bei anderen Kategorieseiten wo wir mit vielen Bildern, Blöcken und Erklärungen arbeiten kann es schonmal 5-10+ Sekunden dauern.
Richtig. Wo simples HTML mit ein bisschen AJAX eine schlanke Umsetzung ermöglicht hätten, muss nun alles per Javascript „dynamisch“ auf dem Client zusammengebastelt werden. Und da Browser in aller Regel dafür gar nicht gebaut sind, stösst die Nummer irgendwann an Grenzen.
Alles ein riesiger Overload von (im Einzelfall größtenteils gar nicht genutzten) Funktionen und „Frameworks“, oftmals noch potenziert, wenn man wie bei Dir viele Blöcke verwendet. Nennt sich moderne Programmierung. So funktionieren SW6 und viele andere Anwendungen. Liegt daran, dass Programmierer nicht mehr programmieren, sondern Frameworks zusammenklicken. Ist in etwa so, als wenn Du mit einem riesigen, vollständig ausgestatteten Werkzeugwagen anrückst, um einen Nagel in die Wand zu schlagen.
Hilft Dir jetzt nicht weiter, ist aber „die Zukunft“.
Danke. Leider habe ich mir schon so etwas gedacht.
Gibt es evtl. die Möglichkeit dem Browser mehr Ressourcen für die Javascript-Berechnungen zu geben?
Der Client-Rechner hätte ja genug „Power“
Dazu müsste man wissen, wo genau es hakt und viele andere Dinge spielen da mit rein. Pauschal kann man da aus der Ferne keinen Tipp geben.
Da stellt sich aber auch die Frage, ob der Server, PHP Einstellungen und MySQL Einstellungen für SW6 optimiert wurden. Da gibt es unzählige Schrauben die man drehen muss bis alles läuft. Aber wie schon erwähnt, man muss das genauer analysieren.
Hab ich schon vermutet.
Allerdings für unsere Zwecke zzt. OK und haben gegengesteurt indem wir den Aufbau etwas vereinfacht haben. Weniger Blöcke mehr eigenes HTML. Kann ich eh besser mit um 