Preload/Init

[makki]

Zwei Themen die ich nochmal sep. "auftischen" will:

1) Mit dem aufkommen von immer mehr Bildchen, die einfach meistens gross und damit langsam sind, frage ich einfach mal ganz doof: wäre es möglich einen Mechanismus zu haben, alle initial (Startseite) nicht sichtbaren (Unterseiten,dynamsich geänderte) Images verzögert nach den essentials zu laden?
Sie sollen natürlich ASAP in den Cache, aber erst, wenn die erstmal sichtbare Seite (inkl. transforms/knx) fertig ist.
Ich fühle: da gibts was mit jQuery xhr, Events, evtl. einer Queue oder so

2) Selbes Thema: diagrams: das backend bekommt man nicht schneller, das ist eine gefühlte Woche lang ausgetunded worden aber auch hier besteht das Problem das diese den eigentlich rattenscharf schnellen Aufbau der Visu verzögern, wenn man auf 10 Unterseiten halt mal 100 davon hat (in anderen Visus ginge das garnicht, aber wir können ja.. also passiert es auch..)

Der ein oder andere Crack hat vielleicht eine Idee wie man da rangeht, das zu optimieren; die Bilder und diagrams sollen natürlich trotzdem alsbald möglich (vor)geladen werden, aber eben nach den KNX-Werten (transforms), weil das geht eigentlich recht zackig, auch bei 500, wenn man das Backend nicht mit 100 diagrams oder die 3G-Verbindung mit 50 Grafiken lahmlegt..

Makki

[chriss1980]

1) Mit dem aufkommen von immer mehr Bildchen, die einfach meistens gross und damit langsam sind, frage ich einfach mal ganz doof: wäre es möglich einen Mechanismus zu haben, alle initial (Startseite) nicht sichtbaren (Unterseiten,dynamsich geänderte) Images verzögert nach den essentials zu laden?
Sie sollen natürlich ASAP in den Cache, aber erst, wenn die erstmal sichtbare Seite (inkl. transforms/knx) fertig ist.
Ich fühle: da gibts was mit jQuery xhr, Events, evtl. einer Queue oder so

jQuery lazy load plugin? Die Anleitung sieht erstmal ziemlich einfach aus, ich habe aber keine Ahnung, ob man es hinbekommt die angezeigte Seite zuerst zu laden...

edit: achso, der gleiche Ansatz sollte doch auch für Diagramme funktionieren. Erst (kleine) Dummy-Daten verwenden und dann nach Aufbau der Seite und allem anderen JS-Geraffel die echten Daten nachladen?

[Chris M.]

Was auf jeden Fall dabei wichtig ist: die Größe des finalen Bildes / Diagramms /... sollte zum Zeitpunkt des Aufbaus der Visu-Seite (= DOM) bereits bekannt sein.
So braucht man nachher keinen Reflow mehr, sondern nur noch einen Repaint, was schneller und für den Anwender hübscher ist.

[makki]

Was auf jeden Fall dabei wichtig ist: die Größe des finalen Bildes / Diagramms /... sollte zum Zeitpunkt des Aufbaus der Visu-Seite (= DOM) bereits bekannt sein.

Das wäre zwar schön aber kaum möglich (das Tablet wurde gedreht, resize, ..)
Das ist aber IMHO nicht das Problem, der Client hat ja bei weitem genug Dampf unter der Haube; was ich daran erstmal unschön finde/lösen will ist die Zeit bis die erste Seite kommt.

Was mir bei der Fragestellung aber kam:
Für den Fall mehrere identischer Diagramme, könnte es natürlich Sinn machen, das im Backend zu cachen -> untersuche ich mal.
Obs da 40ms jetzt rausreissen wage ich aber zu bezweifeln, das wäre eher eine Optimierung in Stufe 2 (aber macht evtl. auch Sinn! weil ich habe dasselbe Diagram 10x drin.. ist nun die Frage ob das Backend das besser cachen sollte [mit mehreren Clients machts Sinn] oder das Diagram-Plugin.. optimalerweise wohl beides, Stufe 3..)

Makki

[2ndsky]

Das ist aber IMHO nicht das Problem, der Client hat ja bei weitem genug Dampf unter der Haube;

Je nach dem, wie das Design aufgebaut ist kann das schon sehr störend sein. Wenn die angezeigten Widgets keine feste Größe haben, verschiebt sich das komplette Layout wenn zuerst ein 0x0 Pixel großes Bild geladen wird, das anschließend durch ein 32x32 Pixel Bild ersetzt wird. Nur mal so als Denkanstoß... keine Ahnung ob das bei der CV ein Problem darstellen würde.

[makki]

keine Ahnung ob das bei der CV ein Problem darstellen würde.

Aktuell geht das 95% schon
Aber ist natürlich einer von vielen Punkten..

Makki