✔ Internet Explorer Performance...

[CHaoSlayeR]

Hi zusammen,

ich bin gerade dabei eine kleine business-web-applikation zu bauen und habe nun ein etwas größeres Problem:

Ich habe eine Seite, die sehr groß ist (>75000 Zeilen generierter HTML (J2EE)). Der Nutzer muss auf dieser Seite oft scrollen, da sie auch visuell sehr groß ist. Das eigentliche Problem kommt jetzt erst. Ich habe es nun mit erheblichen Vereinfachungen des HTML-Codes hinbekommen, dass auch der Internet Explorer die Seite selbst sehr flüssig scrollt. Da diese Seite jedoch nur einen Teil der Web-Applikation ausmacht muss diese in einen IFRAME gepackt werden. Aber sobald ich mir dann das Ergebnis ansehe, scrollt der Internet Explorer die Seite im IFRAME nur noch block-weise bei 100% CPU-Auslastung. Im Firefox, Opera, etc. hingegen ist in allen Fällen flüssig scrollbar.

Das schärfste kommt aber noch oben drauf. Jetzt kommt noch mehrfach synchronisiertes Scrolling zwischen diesem und anderen IFRAME's hinzu (+Drag'n'Drop, +Kontext-Menüs, +Tooltips, u.a.)...

Also da bräuchte ich nochmal dringend Hilfe...

Danke schon mal für jede Idee!

Gruß, C]-[aoZ

 

[Gumbo]

Mehr als 75000 Zeilen HTML-Quellcode? Das lässt sich doch sicherlich vereinfachen.

 

[CHaoSlayeR]

Nach Entfernung nicht benötigter whitespaces sind nun noch 57351 Zeilen reines HTML übrig.

Sämtliche stylesheet informationen sind in Selektoren ausgelagert ebenso sämtliche JavaScript-Bereiche. Ebenfalls werden sämtliche Event-Handler-Zuweisungen erst nach dem Laden der Seite über eine Initialisierungs-Funktion den Elementen zugewiesen, sodass kein einziges "onMouseOver", "onMouseOut", "onClick", "onContextMenu", ... mehr im HTML-Code zu finden ist.

Noch weniger geht nicht! Natürlich könnte man sämtliche whitespace-Zeichen entfernen, jedoch kann man dann auch die Fehlersuche im Falle des Falles gleich sein lassen, weil man nicht mehr durchsieht, wann welches Tag-Level geschlossen wird.

Der Grund für so viele Zeilen ist der hohe Anteil an visuellen Elementen. Diese spezielle Seite stellt eine Übersicht dar in der über den Zeitraum eines Monats für ca. 10-25 Ressourcen (Mitarbeiter, Fahrzeuge, ...) deren zeitliche Auslastung in Form von Auftragselementen dargestellt wird. Diese Auftragselemente haben jeweils ein eigenes Tooltip. Das Kontextmenü wird erst bei Anzeige berechnet (damit waren schon einige tausend Zeilen Code gewonnen). Zudem kann man jedes Auftragselement zeitlich verschieben und/oder einer anderen Ressource zuordnen. Dazu kommen noch einige Icons auf innerhalb der Auftragselemente, die den Status des Auftrags signalisieren (neben der Farbe des Elements selbst). Zusätzlich zu diesen Auftragselementen wird im Hintergrund die Verfügbarkeit der Ressource visualisiert. Das bedeutet für einen Mitarbeiter für jeden Tag die reguläre Arbeitszeiten, die absolute nicht-Arbeitszeiten sowie die maximal mögliche Überlastungszeiten zu visualisieren. Dazu kommt spezielle Visualisierung für Wochenende, Feiertage, Krankheit, Urlaub, sonstige Fehlzeiten, usw. Allein diese sich ergebende Hintergrund-Tabelle erstreckt sich (schon ordentlich zusammen-gepackt) auf meiner Test-Seite auf 1431 Zeilen...

Das Hauptproblem der Performance innerhalb eines Frames im Internet Explorer ist scheinbar nicht die Größe des HTML-Codes sondern vielmehr die vielen absolut positionierten Elemente, denke ich. Find ich seltsam, sollte doch gerade die Performance innerhalb von Frames mit dem Internet Explorer 6.x dramatisch gestiegen sein! Wenn man sich aber mal die alternativen Brwoser ansieht, die wesentlich schneller zeichnen, dabei keine Blöcke produzieren, sondern immer ein konsistentes Bild ausgeben und dazu noch bei gleichen Aktionen wesentlich weniger CPU-Last erzeugen...

...also ich weiss nicht. Aber das steht hier auch gar nicht zur Diskussion, denn das Ding soll auch im Internet Explorer flüssig arbeiten...

Gruß, C]-[aoZ

 

[CHaoSlayeR]

OK, Problem ist gelöst:

Schuld war das CSS-Attribut "border-collapse: collapse;" angewendet auf der Tabelle, die zum Layouten der diversen iframes diente. Den größten Performance-Verlust machte jedoch ein frei positioniertes Element mit der Eigenschaft "filter: Alpha(...);" aus.

Gruß, C]-[aoZ

 

[Maik]

OK, Problem ist gelöst

Dann benutze bitte zukünftig auch den Status-Button des Themas und markiere es als erledigt.

 

[Admi]

Sie die Tabellen jetzt auch "seperate"?

Abgesehen davon:
Mit Tabellen layouten? Warum nutzt du keine Div-Container. Tabellen blustern der den Quelltext nur unnötig auf und machen ihn schlecht lesbar. Da du ja anscheinend auch so mit CSS arbeitest, sollte das doch kein Problem darstellen.

 

[CHaoSlayeR]

Ich habe ganz bewußt eine Tabelle benutzt, weil die Ausrichtung mit DIV-Elementen wesentlich fehleranfälliger ist als mit einer Tabelle und noch mehr Rechenaufwand im Browser verursacht.

Den Firefox stört das nicht. Der kennt ja auch die "display"-Werte für Tabellen-Darstellung und zusätzlich kann man dem Firefox auch sagen, dass er ein DIV von oben=20px und links=30px nach unten=50px und rechts=10px aufziehen soll, was der IE schon wieder so gar nicht hinbekommt. Das würde zwar ein paar Zeilen HTML sparen aber umso mehr CSS erzeugen.

Außerdem ist nicht alles immer sinnvoll, was mit CSS geht. Es kommt immer auf den speziellen Einsatz an, finde ich. Und für mich war jetzt ne Tabelle einfach besser...

Gruß, C]-[aoZ