viel laden oder Ajax

[Luzi]

Hallo zusammen

Ich habe folgende Situation:
Eine Ordnerstruktur. Wenn man auf einen übergordneten Knoten klickt, dann werden die Kinderknoten angezeigt.
Bis anhin habe ich mit Ajax gearbeitet. Ich send also bei jedem Klick auf ein Eltern-Node einen Ajax-Request (=> kleine Wartezeit).

Nun habe ich folgende Frage: Ist es besser, wenn ich alle Elemente schon im Vorinein (alles beim Seitenaufruf) lade und auf display:none setze?

Das Ganze hängt natürlich klar mit den Anzahl Elementen zusammen (Wenig Elemente => eher alles auf einmal beim Seitenaufruf; Viele Elemente => eher Ajax).
Die Grösse der Ordnerstruktur hängt vom User ab. Bei mir sind es normalerweise so 500-1000 und das höchste, was noch irgendwie denkbar wäre, wären 2000 Knoten, welche (wenn man alles am Anfang laden würde) geladen werden müssten.

Auf welche Methode würdet Ihr euch entscheiden? Ajax oder alles beim Seitenaufruf?

Vielen Dank für eure Rückmeldungen.

[Tom]

Hello,

Auf welche Methode würdet Ihr euch entscheiden? Ajax oder alles beim Seitenaufruf?

Das ist ein Paradoxon.
Ajax setzt JavaScript voraus.

Alles auf einmal laden ist auch nur dann sinnvoll, wenn man dann auf dem Client innerhalb der Menge navigieren könnte. Das setzt auch JavaScript voraus.

Alles auf einmal laden ohne JavaScriptunterstützung wäre vermutlich Unsinn, es sei denn, man könnte es mittels CSS lösen. Dann kann man aber immer noch nicht auf dem Client in der Menge Navigieren, da ja mit dem Suchbaum irgendetwas gemacht werden soll...

Die beste Lösung wäre mMn immer noch eine serverseitige. Bei jedem Request muss dann nur die entsprechende Haupachse und der daraus ausgewählte Knoten mit seinen Kindelementen übertragen werden.

Die Detailanzeige zu einem Ordnungselement musst Du ja sowieso immer dann holen, wenn es ausgewählt wurde, oder willst Du die auch schon alle mit übertragen? ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[bleicher]

Grüße,

Die beste Lösung wäre mMn immer noch eine serverseitige. Bei jedem Request muss dann nur die entsprechende Haupachse und der daraus ausgewählte Knoten mit seinen Kindelementen übertragen werden.

wieso nciht beides  - bzw server als fallback? das neuladen kann schon seeehr nervig sein, und würde weit merh menschen nerven. ohne JS sind nur ein paar prozent - und wenn man letzendlich will, wird man wohl das neuladen als kleineres übel akzeptieren.
iA ist es unfair - wegen paar prozent ohen JS alle mit dem nervigen serverseitigen zu öden.
MFG
bleicher

[Tom]

Hello,

wieso nciht beides  - bzw server als fallback? das neuladen kann schon seeehr nervig sein,

Klar, wenn man den ganzen Google- und Affiliate-Schrott in seiner Seite drin hat, dann dauert es Minuten, bis die Seite wieder steht. Wenn man nur auf seine eigene begrenzte Datenmenge blickt, von der auch noch viele Elemente cached werden können, dann dauert es heutzutage keine 150ms mehr.

Die Devise sollte also auch hier wieder lauten: weiniger ist mehr.

Große Seiten aufteilen in mehrere Seiten. Struktur ist alles. Man muss selten alles auf einer Seite anzeigen, nur weil die Bildschirme heute mehr Pixel können...

Wenn man sein Design flüssig, aber nicht überflüssig anlegt, dann wird der Betrachter das eventuell gar nicht merken, dass die ganze Seite neu aufgebaut wird, sondern nur in den gänderten Containern die Änderungen bemerken. Die Container, in denen also das Leben spielt, sollten daher relativ fix zueinander montiert werden im Seitengerüst, so dass nicht alles in der Gegend herumspringt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Luzi]

Ich glaube, ich muss das Projekt etwas genauer beschreiben:

Ich habe einen Online-Vokabeltrainer programmiert. Darin sollen die zu lernenden Vokabeln in Ordner aufgeteilt werden, welche beliebig verschachtelt werden können.

In der "Vokabelübersicht", sollte man dann in diesem Baum navigieren können. Die ganze Seite (die Abfrage der Vokabeln) funktionniert sowieso nur mit Javascript. Daher wird der Besucher ohne Javascript darauf hingewiesen, Javascript zu aktivieren, da sonst die restliche Seite nicht funktioniert.
Wir können also davon ausgehen, dass alle Besucher Javascript haben.

Dann weiter möchte ich wie gesagt, auf das neu Laden bei jedem Klick auf einen Knoten im Baum verzichten.

Das Problem, welches mich dazu veranlagt hat, diesen Thread zu starten ist folgendes:
Ich möchte eine Suche einbauen, welche unmittelbar nach jeder Eingabe eines Buchstabens in das Suchfeld nur die Lektionen anzeigt, in welchen der aktuell eingegebene Suchbegriff enthalten ist.
Wenn ich das Projekt mit Ajax realisieren müsste, wäre die einzige Lösung:
Ich rufe eine Ajax-Seite auf, welche mir anhand des Suchbegriffes die Lektionen ausgibt. Dieser ganze Weg ist ziemlich mühsam.
Wenn ich alle Lektionen "vorausgeladen" hätte, dann müsste ich nur in meinem Dom-Baum nach dem Suchbegriff suchen und könnte diejenigen Elemente disply:list-element setzen und den Rest display:none.

Wäre es, diesen Aspekt miteinbezogen, nicht einfacher, alles vorauszuladen? Oder bringt das trotzdem noch erhebliche Nachteile?

(noch eine kleine Zusatzinfo: Die Ordnerstruktur ist als Liste aufgebaut. Jedes LI hat etwa 250 (bytes) besteht.)

Gruss

[LX]

Dann stellt sich wirklich die Frage, warum Du das jeweilige Dictionary nicht bereits in ein platzsparendes JS-Format (bspw. String mit ";" als Trennzeichen) gebracht hast, sondern als HTML-Konstrukt auslieferst?

Gruß, LX

[Tom]

Hello,

Dann stellt sich wirklich die Frage, warum Du das jeweilige Dictionary nicht bereits in ein platzsparendes JS-Format (bspw. String mit ";" als Trennzeichen) gebracht hast, sondern als HTML-Konstrukt auslieferst?

Das bringt mich nun wieder auf eine Frage:
Wird die *.js-Datei, die man einbindet im HTML, auch auf dem Client cached? Dann wäre es ja wahrhaftig besser, die ganzen Daten in einer JavaScript-Ressource auszuliefern. Der Client würde sich dann nur noch lokal bedienen müssen, was sicherlich kein Problem mehr sein wird in Bezug auf die Ladezeit.

Wie groß darf so eine JS-Ressource werden? Gibt es da verlässliche Aussagen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

Wird die *.js-Datei, die man einbindet im HTML, auch auf dem Client cached?

was lässt dich daran zweifeln? - Ich wüsste nicht, was dagegen spricht.
Natürlich ist es genauso von den Client-Einstellungen und eventuellen Caching-Empfehlungen im HTTP-Header abhängig, aber generell sollte man davon ausgehen, dass eine JS-Ressource auch wie jede andere Ressource vom Client im Cache gelagert wird.

Dann wäre es ja wahrhaftig besser, die ganzen Daten in einer JavaScript-Ressource auszuliefern.

In einer Anwendung, die JS sowieso benötigt - ja, vermutlich. Nur wenn sich der anzuzeigende Datenbestand häufig ändert, bringt das nichts.

Wie groß darf so eine JS-Ressource werden? Gibt es da verlässliche Aussagen?

AFAIK gibt es da in der Theorie keine Beschränkungen. In der Praxis mag es sein, dass der eine oder andere Browser bei einer gewissen Größe überproportional viel Zeit braucht, oder vielleicht auch ganz aufgibt. Aber einige 100kB sind erfahrungsgemäß noch unproblematisch (von der Ladezeit der JS-Ressource selbst abgesehen); ich habe schon Webseiten erlebt, die über 1MB Javascript eingebunden hatten.

Ciao,
 Martin

[Luzi]

Vielen Dank für eure konstruktiven Antworten!

Jedoch müsst ihr mir kurz auf die Sprünge helfen: Was ist ein JS-Resource-File? Ist das eine *.js-Datei, welche einen Array mit der Ordnerstruktur gespeichert enthält und bei jeder Seite eingebunden wird (also eigentlich eine Offline-Kopie der benötigten Datenbank-teile)? Oder ist das eine andere Art von File (nicht *.js)?

Wie kann ich dann dem Browser sagen, dass er die Seite aus dem Cache aufrufen soll / im Cache ablegen soll? Ist das diese Sache mit dem Manifest von HTML5 (damit kenne ich mich schon aus, aber ist das wirklich diese Sache?).

Muss der Browser auch nach einer kleinen Änderung das ganze File neu laden?

Wie sage ich dem Browser, wann er ein File neu laden soll?

Danke und Gruss

[Der Martin]

Hallo,

Was ist ein JS-Resource-File?

ein Wort-Ungetüm bzw. in diesem Zusammenhang ein Widerspruch.
Auf deinem Server liegen Dateien. Die Übertragung über HTTP kennt aber keine Dateien. Alles, was über HTTP angefordert und übertragen wird, nennt man Ressource. Das kann der Inhalt einer Datei sein, die auf dem Server liegt, es kann aber ebensogut das dynamisch erzeugte Ergebnis einer Datenbankabfrage sein. Für den Client ist es nicht erkennbar, ob die Daten, die er bekommt, aus einer Datei stammen oder ob Oma Wilhelmine sie von Hand eintippt.
Deshalb sollte man den Begriff "Datei" im HTTP-Kontext vermeiden; es handelt sich um Ressourcen.

Wie kann ich dann dem Browser sagen, dass er die Seite aus dem Cache aufrufen soll / im Cache ablegen soll?

Das entscheidet er weitgehend selbständig. Dabei berücksichtigt er einerseits seine eigene Konfiguration, die dieses Verhalten in gewissen Grenzen beeinflusst, andererseits Empfehlungen, die der Server im HTTP-Header mitsendet. Normalerweise braucht man da nichts zu tun, wenn man nicht ganz spezielle und exotische Wünsche hat.

Muss der Browser auch nach einer kleinen Änderung das ganze File neu laden?

Die ganze Ressource, ja.

Wie sage ich dem Browser, wann er ein File neu laden soll?

Indem du es neu anforderst? Dann wird der Browser schon selbst entscheiden, ob er tatsächlich erneut vom Server anfordert, oder doch die Kopie nimmt, die er noch im Cache hat (siehe oben).

Ciao,
 Martin

[Tom]

Hello,

Wie kann ich dann dem Browser sagen, dass er die Seite aus dem Cache aufrufen soll / im Cache ablegen soll?

Das entscheidet er weitgehend selbständig. Dabei berücksichtigt er einerseits seine eigene Konfiguration, die dieses Verhalten in gewissen Grenzen beeinflusst, andererseits Empfehlungen, die der Server im HTTP-Header mitsendet. Normalerweise braucht man da nichts zu tun, wenn man nicht ganz spezielle und exotische Wünsche hat.

Man sollte den Browser darum bitten, was er beim nächsten Request auf diese Ressource mitsenden sollte. Anderenfalls tut er es nämlich oft nicht.

Nam sollte also die Header mitsenden:

header ("Last-Modified: $last_modified");

wobei sich $last_modiefied z.B. ergibt aus:

$last_modified = @gmdate('D, d M Y H:i:s',@filemtime(JSPATH.$filename)).' GMT';

Und dann sollte der Server oder dessen Resource Handler darauf achten, dass er die Hinweise des Client auch beachtet

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']))

(da gibt es noch mehr Möglichkeiten, wie das Element heißen kann, die sind mir aber im Moment entfallen...)

und anstelle der Ressource auch nur einen entsprechenden HTTP-Status zurücksendet, z.B.:

header("HTTP/1.0 304 Not Modified");
    header("Cache-Control: max-age=86400, must-revalidate");

Dann weiß der Client, dass er seinen Cache benutzen darf.

Voraussetzung dafür ist natürlich immer, dass der Client vernünftige Einstellungen bezüglich der Cache-Nutzung hat. Wenn die auf "nur einmal im Jahr neu laden" steht, dann klappts nicht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Luzi]

Ich könnte mir folgende Variante vorstellen:

Ich speichere die Wörter per localstorage von HTML5 auf dem Client-PC und auch auf dem Web-Server.
Immer, wenn keine Client-*.sqlite-Datei gefunden wird, wird die Online-Version der Datei auf den Computer kopiert. Das muss ich ja so mache, da man sonst nicht von überall auf die identischen Daten zugriff hat (und das ist ein Feature meines Online-Vokabelntrainers).

Als weiteres Feature möchte ich einen Offline-Modus (Zugriff auf die Webseite und die Datenbank auch ohne Internet sofern man vorher schon einmal die Seite mit Internetzugriff besucht hat) einbauen.  Das wäre ja dann auch getan mit dem lokalen Speichern der *.sqlite-Dateien, da der Browser ja immer zuerst die lokale *.sqlite-Datei öffnen will und nur, wenn diese nicht vorhanden ist auf den Web-Abgleich zurückgreift.

Ist das eine gute Lösung? und umsetzbar?

Muss ich eine solche Lösung nur mit Javascript programmieren (kein PHP)? Ich habe ja im Offline-Modus keine Serververbindung und somit kein PHP. ist das richtig?

Muss ich also die ganze Datenbankschnittstelle (welche ich zur Zeit mit php und mysql geregelt habe) auf (nur) Javscript und SQLite umstellen?

Vielen Dank und Gruss

[bleicher]

Grüße,

Wie kann ich dann dem Browser sagen, dass er die Seite aus dem Cache aufrufen soll / im Cache ablegen soll? Ist das diese Sache mit dem Manifest von HTML5 (damit kenne ich mich schon aus, aber ist das wirklich diese Sache?).

das schreit nach localStoarge/SQLite lösung - das wäre perfekter einsatz für den lokalen speicher, vor allem, weil die vokabeln sich eher sleten ändern ;)

Muss der Browser auch nach einer kleinen Änderung das ganze File neu laden?

speichere den zeitpunkt der änderung für jedeneintrag auf dem server und den letzten local - dann musst du nur die neu dazugekommenen übertragen.

Wie sage ich dem Browser, wann er ein File neu laden soll?

wenn du es bevorzugst- auf deutsch.
MFG
bleicher

[LX]

Hi, Tom!

Wird die *.js-Datei, die man einbindet im HTML, auch auf dem Client cached? (...)

Solange die URL nicht geändert wird, ja. Allerdings wird der Cache wieder aufgeräumt, sobald dessen maximale Größe erreicht ist. Dagegen hilft in modernen Browsern ein Cache-Manifest (siehe HTML5 Offline Apps), welches dazu führt, dass man die entsprechenden Daten dauerhaft verwenden kann.

Wie groß darf so eine JS-Ressource werden? Gibt es da verlässliche Aussagen?

Verschiedene Browser (gerade im mobilen Bereich) haben eine Speicherbegrenzung für JS. Beim iPhone liegt diese bspw. aktuell bei 10MB, danach wird das Script gestoppt. Das ist aber auch schon die kleinste Grenze, die mir bekannt ist.

Gruß, LX

[LX]

Ich gebe Tom Recht: wenn Dein Konzept so gestaltet ist, dass entweder AJAX vorausgesetzt wird, oder innerhalb der Seite gewaltige Datenmengen übertragen werden, ist es fehlerhaft.

Der Server sollte dem Client nur jene Daten ausliefern, die dieser am Stück sehen soll, unabhängig davon, ob er sie mit einem Seiten-Rahmen ausliefert (ohne Javascript) oder, falls vorhanden, eben über AJAX/HTML oder aber JSON bzw. JSONp nur die eigentlichen Inhalte.

Gruß, LX

[bleicher]

Grüße,
"große datemengen" ist eine ansichtssache - was wäre besser - einmalig 500kb zu übertragen, oder 10 anfragen a 80kb zu prodzuieren?
1000 datensätze wird wohl kaum mehr als 1MB produzieren - und wenn man das um localStorage erweitert, wäre das sogar trafficschonend. dialUp-maßnahmen sind shcon siet jahren nicht mehr aktuell, selbst für mobile internetnutzer kaum noch.
MFG
bleicher

[Tom]

Hello,

"große datemengen" ist eine ansichtssache - was wäre besser - einmalig 500kb zu übertragen, oder 10 anfragen a 80kb zu prodzuieren?

Das kann man erst beantworten, wenn man weiß, wie die Hierarchie der Seite aufgebaut ist und wieviele Roundturns zu einer Zielfindung gehören. Wenn man nicht sicherstellen kann, dass die Datenmenge am Client für mehrere Roundturns weiternutzbar ist, dann ist "alles laden" auf _j-e-d-e-n_ Fall falsch.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[bleicher]

Grüße,

Das kann man erst beantworten, wenn man weiß, wie die Hierarchie der Seite aufgebaut ist und wieviele Roundturns zu einer Zielfindung gehören. Wenn man nicht sicherstellen kann, dass die Datenmenge am Client für mehrere Roundturns weiternutzbar ist, dann ist "alles laden" auf _j-e-d-e-n_ Fall falsch.

jein - wenn sich nur ein teil der daten ändert, köntne man immer noch über kleinere updates dabei bleiben - irgendein sinn müssen ja die superschnellen JS-benchmarkbrowser haben, nicht? ich meine nicht, dass es als einzige, aber vllt als hauptweg mit fallback genutzt werden kann. wenn man html5 nicht anfängt z nutzen, wird es nie "ankommen".
MFG
bleicher

[Der Martin]

Hallo,

"große datemengen" ist eine ansichtssache - was wäre besser - einmalig 500kb zu übertragen, oder 10 anfragen a 80kb zu prodzuieren?

vermutlich die 500kB am Stück. Denn jeder HTTP-Request bedeutet protokollbedingt etwas Overhead (kann locker 1k pro Request sein), vor allem aber eine gewisse Totzeit, die locker eine halbe bis eine Sekunde betragen kann.

dialUp-maßnahmen sind shcon siet jahren nicht mehr aktuell, selbst für mobile internetnutzer kaum noch.

Was willst du damit sagen?

Ciao,
 Martin

[LX]

Hallo, bleicher!

Da möchte ich widersprechen (besonders, weil ich selbst mobile Seiten unter genau diesen Gesichtspunkten baue). Gerade im mobilen Umfeld ist in manchen Gegenden kaum Edge vorhanden, geschweige den GPRS. Da machen schon 10kb einen spürbaren Unterschied. Allerdings muss man hier auch abwägen, denn die zusätzlichen Header für AJAX/JSON-Requests verbrauchen ebenfalls Bandbreite.

Wobei natürlich nichts dagegen spricht, einmal geladene Daten lokal zu cachen, soweit möglich bzw. sinnvoll.

Gruß, LX

[hotti]

hi,

Auf welche Methode würdet Ihr euch entscheiden? Ajax oder alles beim Seitenaufruf?

Last-Modified. Damit nimmt der UA die Seiten in den Cache.

Hotti