EDIT Wilken: Beiträge ausgekoppelt aus anderem Thread... Aber selbst wenn das BrowserCaching funktionieren würde - auch bei den Gambio Demo-Shops müssen die beiden dicksten Brocken: gm_dynamic.css.php und gm_javascript.js.php (ca. 1,6 MB) immer wieder neu geladen werden und können nicht aus dem Browsercache verwendet werden - warum eigentlich? (Oder sollte ich besser ein neuen Thread daraus machen?)
Zumindest das CSS wird gecached, zwischenzeitlich auch schon mal aggressiver. Da haben aber zuviele Leute gesagt die Änderungen aus Styleedit ziehen nicht, also wurde das wieder etwas zurück genommen. Für das Javascript kommt das glaube ich hin was du sagst. Du hast aber schon recht, da lauern insgesamt nochmal Baustellen, ich wüsste auch was da noch besser ginge Nachtrag: Du hast übrigens Recht. Wenn man das weiter allgemein ausdiskutieren will, wäre ein neuer Thread dafür klug.
Könntest Du die Beiträge gleich abtrennen, oder soll ich neu starten? Ich habe mir nur mal YSlow angesehen, ob und wie das gecacht wird. Und wenn für den Reload der Seite (Primed Cache) noch mal 1.700 K fällig werden, dann kann da nicht wirklich was gecacht werden: Wenn z. B. ein Expires für 1981 ausgegeben wird, ist das auch schwierig Ciao, Mike
Danke für das Aufspalten des Threads. Warum nicht einfach eine Versionsnummer in die URL mit aufnehmen? Dann kann ich das Expires auf ein Jahr festlegen, aber sobald eine Änderung mit StyleEdit gespeichert wird, muss sich das System eine neue Verion ziehen (kann auch einfach eine neue GUID sein). Fertig. Habe ich an anderer Stelle in ähnlicher Variante schon seit Jahren ohne Probleme verwendet. Ok, ggf. müsste man ein Rewrite machen, damit eine .css / .js und keine .php geladen wird. Ciao, Mike
Ich verlinke dazu mal diesen Bugtracker Eintrag: https://tracker.gambio-server.net/issues/47403 Da hat schon mal jemand dasselbe gedacht Wenn ich mir dafür mal erklären könnte was sich Chrome und Firefox auf meinem Rechner gerade bei Caching Effekten zusammenrechnen... Ich wollte gerade ein paar Modelle hier aufstellen, komme nur gerade auf keinen grünen Zweig, der sich mit der Quantenmechanik erklären liesse...
Das klingt gut! Wenn Ihr das Thema angeht, dann wäre das auch noch ein "Ansatzpunkt" für eine Optimierung: 35 einzelne HTTP Request für zumeist sehr kleine JavaScript Dateien geht sicherlich auch noch besser. Wenn das im Test-Shop alles einzelne Dateien sein können, die auch nicht "minified" sind, dann wäre das für das Debugging schon mal deutlich einfacher. Für den Live-Shop sollte es dann die Möglichkeit geben, das als eine, minified Datei einzubinden. (Und wenn ich dann für eine Seite mal unkomprimiert 2.000 Bytes mitlade, die ich dort nicht benötige, ist das weniger ein Problem.) Ciao, Mike
Ob du minifiziertes Javascript und CSS bekommst, kannst du steuern: Je nachdem ob im Hauptverzeichnis eine .dev-environment Datei beliebigen Inhalts vorhanden ist, bekommst du minifizierte oder debuggbare Inhalte. Ob man die Requests zusammenfassen muss weiss ich nicht, ich denke da erledigt HTTP2 alles nötige.
Oh Mike ist ja auch hier ;-) Wäre super wenn diese Sachen angegangen währen. Das würde echt einiges an Ladezeit bringen und der Seite Beine machen.
Ich fürchte das steht nur inner README im Git und in manchen Quellcodedateien als Kommentar. Muss mal auf die Developerseite glaub ich Find ich auch, wird passieren. Ich weiss nur noch nicht genau wann ich mich gegen andere Nötigkeiten durchsetze