Tudni kell, hogy az adott alkalmazás esetében eléggé sarkalatos kérdés performancia. Magyarul lassú mint a csiga az akácerdőbe'. Ez részben annak köszönhető, hogy meglehetősen összetett és az összes létező technológiát használja, sőt néhány nem létezőt is :) Ennek megfelelően folyamatosan mérve van és a legkisebb további lassulás is eléggé mély ráncokat vés a homlokokra.
Az előzmények ismeretében érthető, hogy nem volt túl örömteli, mikor egy dizájn csiszolgatás után, ahol is kis kinézetbeli igazgatások történtek, bekerült egyszer csak valahonnan 4 másodperc (!) extra renderelési idő. Igaz, hogy a cucc nagyon lassú, de azért 4 másodperc még így is mintegy 70-80%-os lassulást jelentett. Azonnal elkezdődött a vad nyomozás, majd végül kiderült, hogy nem más tekeri meg ennyire a böngészőt, mint egyetlen egy darab dekorációs célból odabiggyesztett 1 pixeles vonal, ami ezzel a kóddal lett kivitelezve:
<table class="tab_top_decor">
<tbody>
<tr>
<td class="tab_top_decor_selected">
</td>
<td>
</td>
</tr>
</tbody>
</table>
Rendben, elismerem, nem a legjobb erre a célra táblázatot használni, de mivel az oldal teljes egészében old-school (és nem túl okos) módon táblázatokkal van formázva, így azt gondoltam, nem oszt nem szoroz, ráadásul akkor még nem tudtam erről a trükkről, ami a 6os explorernek is megmondja, hogy márpedig mekkora az akkora.
Érthető módon majd megölt a kíváncsiság és szanaszét teszteltük az oldalt, míg végül kiderült, hogy az adott tábla csak a TabContainer belsejébe helyezve okozza ezt a durva lassulást. Idő híján nem nyomoztunk tovább, de valószínűleg a TabContainer javascriptjei között van valami ordenáré módon lebaltázva, aminek ezt a 4 másodpercet köszönhettük.
Miután a korábban említett trükköt kiderítettem átírtam DIV-re a dekorációs csíkot és így már minden rendben volt. Na meg természetesen eldöntöttük, hogy ha egy mód van rá megszabadulunk a tebkonténertől, mielőtt még egy időzítet bomba az arcunkba robban.
Nincsenek megjegyzések:
Megjegyzés küldése