Hallo Jürgen,
Wichtiger wäre mMn, die Seiten so zu cachen, dass Sie nicht bei jeden Aufruf, sondern nur bei jeder Datenänderung neu montiert werden müssen, es sei denn, zwischen zwei Änderungen liegen nur wenige Aufrufe.
Als Idee gespeichert.
Klar könnte ich nur den CSV String per Ajax holen und das auf dem Client vorhandene Rumpf-HTML per JS wieder aufblasen. Reduziert den traffic weiter.
Beim Programmieren der nächsten Liste greife ich die Idee wieder auf: Never touch a running system
Edit: Oder habe ich deine Idee falsch verstanden und du meinst Seiten, die gleichartig an mehrere User geschickt werden und auf dem Server gecacht werden sollen?
Damit hatte ich vor Jahren experimentiert. Der Programmieraufwand war hoch, denn bei Datenänderung mussten mehrere Caches gelöscht werden und bei zusätzlichen Programmen ging die Übersicht verloren. Da gibt jemand einen neuen Termin ein, will den auf der Startseite, auf dem Mitglieds-, Orts-, Typenkalender sehen ... Bei 200 Orten sind 600 Orts-Cashes zu verwalten, wenn jeder Ort + 20 km je drei Seiten hat. ...
Nach Mitternacht werden die Termine des vergangenen Tages gelöscht, alle Listen müssen bei Anforderung neu erstellt werden. Unübersichtlich.
Kompromiss war, im DB-Datensatz ein HTML-Snippet für die Kurzform, eines für die Langform des Termins abzulegen und die Listen aus dieses Snippets aufzubauen. Hat in der Durchlaufzeit des Servers, die unten rechts immer angezeigt wird, prozentual kaum was gebracht und beim traffic gar nichts.