[html/css] Trage roostermatrix

[siepeltjuh]

Voor mijn werk heb ik een C# script in elkaar gezet dat html bestanden uitspuugd. Ik ben geen C# kenner, maar dit kreeg ik nog wel voor elkaar

Het HTML bestand is erg clean, geen javascript of andere meuk, alleen wat css.
Nu is het zo dat als ik het html bestand lokaal open hij goed functioneerd, maar zodra ik hem online heb staan werkt hij erg traag. Dit is te merken aan de response van de browser (elke ie versie) en aan de hover effecten. (kan maar niet ontdekken waarom dat opeens is)
Van ditzelfde overzicht heb ik nog veel grotere overzichten, die performen nog slechter.

De oorzaak ligt denk ik vooral aan het idioot hoge aantal tabel cellen. Aangezien ruimtes per kwartier wel of niet beschikbaar kunnen zijn bestaan er dus 4 cellen per uur, 14 uur per dag, 7 dagen en 50 ruimtes levert dan dus al 20.000cellen op. Ik heb al gekeken om de hover functie te schrappen, weinig effect, het scrollen bij grotere lijsten is nog steeds te traag.
Het html bestand vervangen door een voorgerenderde png is ook een optie, maar dat is eigenlijk een oplossing die ik pas als laatste zou willen proberen.

http://www.leosiepel.nl/tnet/index.html

Ik ben vooral benieuwd op welke punten het html bestand nog kan worden geoptimaliseerd, zelf heb ik al heel veel dingen verbeterd. File size is al met 50% afgenomen.
Het gaat dus om optimalisatie en indien iemand een idee heeft om het helemaal om te gooien en op een andere manier de kolommen / blokken op te bouwen wordt ook zeer gewaardeerd, natuurlijk indien het ook daadwerkelijk een verbetering oplevert.

[Bosmonster]

In alle browsers is het hartstikke snel, behalve IE. Die heeft blijkbaar nogal moeite met zoiets simpels als een tr:hover.

[ Voor 40% gewijzigd door Bosmonster op 03-03-2010 16:44 ]

[Twan V]

Ik denk dat als je werkt met divs inplaats van een grote tabel, de snelheid al een stuk toeneemt.

_{ps. er zit een typo in je link: ww ipv www}

Bosmonster schreef op woensdag 03 maart 2010 @ 16:43:
In alle browsers is het hartstikke snel, behalve IE. Die heeft blijkbaar nogal moeite met zoiets simpels als een tr:hover.

Als ik in IE8 de 'kapotte-website-knop' (hier intern jargon voor Compabiliteitsweergave) aanklik, werkt hij wel lekker swift.

De laadtijd is nog wel een verbeterpuntje, op dat vlak blijft mijn opmerking m.b.t. divs staan.

[ Voor 60% gewijzigd door Twan V op 03-03-2010 16:48 . Reden: Reactie op Bosmonster toegevoegd ]

[crisp]

Probeer eens een table-layout:fixed

[Bosmonster]

crisp schreef op woensdag 03 maart 2010 @ 16:47:
Probeer eens een table-layout:fixed

Heeft helaas geen effect (heb het voorbeeld even overgenomen lokaal, aangezien ik wel geinteresseerd ben in dit soort extreme performance-problemen in een specifieke browser).

[Bosmonster]

Twan V schreef op woensdag 03 maart 2010 @ 16:45:

Als ik in IE8 de 'kapotte-website-knop' (hier intern jargon voor Compabiliteitsweergave) aanklik, werkt hij wel lekker swift.

De laadtijd is nog wel een verbeterpuntje, op dat vlak blijft mijn opmerking m.b.t. divs staan.

IE7 compatibility mode verandert hier niks aan de performance.

En waarom zou je van zoiets in godesnaam divs willen maken Het is een tabel.

[HuHu]

Misschien heb je hier wat aan: http://msdn.microsoft.com...spx#Use_Fixed-Size_Tables

• Set the table-layout CSS attribute to fixed on the table.
• Explicitly define col objects for each column.
• Set the WIDTH attribute on each col.

Verder bestaat de class .th niet in je CSS, maar gebruik je die wel op alle th elementen. Die zou ik dan ook maar weghalen.

[ Voor 25% gewijzigd door HuHu op 03-03-2010 16:54 ]

[MBV]

Hier ook 10x zo snel in compatibility view. En nog leuker: ook met Coral IETab werkt het best aardig, die kennelijk standaard in compatibility view staat ofzo. Laadtijd is hier prima, met of zonder kapotte-website-knop.

[siepeltjuh]

Dank alleen voor de reacties.

De voorbeeld pagina is misschien niet zo`n heel goed voorbeeld, het was meer bedoeld om aan te geven wat voor soort overzicht ik precies bedoel en de techniek die ik gebruikt heb.

Ik heb de HTML pagina aangepast naar 40 ruimtes, dan is het performance probleem weer wat groter dan met de initiele 25. Sommige lisjten zijn wel 60 tot 80 ruimtes groot.

Compatibility view heeft weinig tot geen effect.
Andere browsers werken wel, maar vinden het ook al ietsje minder leuk. Opzich ook niet zo gek met een html file van 250KB.

DIV`s gebruiken lijkt me niet echt zinvol, veel schiet ik niet op en het is bijzonder ingewikkeld om na te maken met div`s. Probeer maar eens 1 enkele rij om te zetten nar DÌV`s.

Naar de fixed table ga ik kijken.

[André]

De table-layout:fixed zal denk ik een hoop schelen. En wellicht dat je de :hover beter kunt vervangen met een javascript die de background van een rij aanpast (in IE dan).

[siepeltjuh]

de table-layout fixed krijg ik maar niet voor elkaar. zeker in combinatie met de <col width="123">
Tot nu toe heb ik alleen maar de layout omzeep kunnen helpen. Ook vindt ik het col gebeuren een beetje zondigen (niet semantisch) en erg vreemd gedrag.

Het probleem in IE lijkt een browser instelling te zijn:
Lokaal niets aan de hand
Extern traag
Externe site toegevoegd aan lokale intranet zone en huppa werkt vlot. Ik kan nog niet vinden welke instelling het precies is.

In ik altijd maar verkondigen dat ik zo tevreden ben met IE. Los daarvan ben ik nog steeds zeer benieuwd naar optimalisatie in zijn geheel van deze pagina.

Miniscuul verbeterde versie.

[ Voor 35% gewijzigd door siepeltjuh op 03-03-2010 23:48 ]

[Kiphaas7]

Intranet sites en lokale bestanden worden standaard weergegeven in de compatibiliteits modus van IE8, dus dat is wel degelijk te verklaren.

(Aangezien al eerder aangegeven was dat de compatibiliteits modus van IE8 duidelijk sneller is)

[Puch-Maxi]

Oftfopic:
Grappig, op het Hanze heeft men zojuist een dergelijk systeem ingevoerd.
Het ziet er goed uit moet ik zeggen en het werkt heel wat beter dan het oude systeem (mailen)

edit:
Verhip, sterker nog dit is het systeem van Hanze

[ Voor 36% gewijzigd door Puch-Maxi op 04-03-2010 01:46 ]

[Bosmonster]

Even een IE7-compat-mode meta-tag bovenin je pagina dus.

Wel bizar dat IE8 zo traag is. Ik ben al wel wat rare IE8 bugs tegengekomen, maar dit is wel heel extreem.