09.34, 20 marzec, 2009
|
 |
||
|
Naturalny progress bar.
Spinnery, indicatory, śmigacze, kręciołki. Wszystkie mają jeden cel: wydłużyć czas oczekiwania na rezultat działania aplikacji. Widzisz je klikając zdjęcie z lightboxem, gdy ładuje Ci się ajaxowy formularz. I to jest jak najbardziej w porządku - użytkownik widzi i wie, że aplikacja działa i należy czekać. Bez tego nie wiedzielibyśmy, czy klik się udał, czy może nie trafiliśmy w przycisk
Co jednak z całą stroną? Czasem trzeba odczekać swoje, żeby główna strona się pokazała. Całkiem fajnym pomysłem jest dodanie takiego kręciołka, który zniknie po całkowitym załadowaniu się strony. Jednak w tym rozwiązaniu jest kilka braków. Przede wszystkim to, że najprawdopodobniej kręciołek nie zniknie dopóki **CAŁA** strona się nie załaduje… a to oznacza zakończenie ładowania zarówno reklam jak i np. Google Analytics. Czyli de facto na stronę będzie trzeba jeszcze dłużej czekać. Dlatego warto zaprojektować stronę w taki sposób, aby wykorzystać naturalną właściwość protokołu http: wysyłanie zawartości strony w partiach, gdy jest to możliwe. Często jednak łatwo poddać się pokusie i idąc na łatwiznę zablokować sobie ten dar od losu na przykład nieumiejętnie załączając pliki javascript lub css. Gdy zrobisz to dobrze - cała strona będzie działała jak jeden wielki progress bar: w pierwszej chwili załaduje się logo sajtu, po 0.2 sekundach menu, po kolejnych chura tagów i zaraz po niej zawartość w głównej szpalcie itd. aż do stopki. Tyle, że zanim użytkownik będzie chciał scrollować do stopki i przekonać się, czy już się załadowała, już będzie miał dostępne informacje bardziej interesujące. www.dobrzemieszkaj.pl zorganizowaliśmy w ten sposób. Zachęcam do sprawdzenia. Oczywiście istnieje ryzyko, że po wyrenderowaniu głównego menu ktoś kliknie w dział, który go interesuje. Wtedy pewnie nie zdążą sie załadować żadne “analyticsy”, jednak wtedy warto zadać sobie pytanie: czy wolę mieć wejścia niezarejestrowane, czy oddać je konkurencji? Jeśli interesują Cię bardziej szczegóły techniczne - postaram się niedługo je zamieścić. Grzegorz Pawlik |
|||
|
Ciekawy temat, ciekawy artykuł (szczegóły techniczne mile widziane!) Głównie chodzi o ładownie i wykonywanie skryptów na samym końcu, a cssów - na początku i tylko zewnętrznych. Dzięki ładowaniu cssów na początku - przeglądarka możliwie szybko ma informacje o wyglądzie strony. Nie każdy wie, że po natrafieniu na nową deklarację styli (np inline) często cała zawartość musi zostać wyrenderowana (czasem można zwrócić na to uwagę, kiedy widzisz stronę, a po chwili znika i pojawia się znów podczas ładowania). Tu oczywiście jest też pole do popisu dla twórców przeglądarek, żeby robić to możliwie oszczędnie - ale dobrze wiemy, że na tych czasem trudno liczyć Co do skrytpów - przeglądarka nie czeka na ich załadowanie, zanim zacznie dostawać zawartość właściwą. Poza tym wykonanie skryptów też opóźnia powstawanie strony, gdyż znów przeglądarka czeka na ich zakończenie (w końcu możesz JScriptem zmienić klasy elementów oraz style). Dlatego, zamiast np takiego bloku: podpiąć funkcję wykonaj_operacje_na_elemencie do zdarzenia onload elementu body. W naszej biblioteczce Tomku, albo gdzieś na moim biurku jest książka Wydajne serwisy internetowe. Polecam lekturę do tramwaju ps. co do tych bez JSa - to wydaje mi się, że problem jest niezależny od opisanego celu osiągnięcia efektu progress bar-u. Choć nie wiem na 100% - możliwe, że to zależeć będzie od konkretnego problemu. Ja raczej pomyślałem o jakimś ładowaniu elementów za pomocą JS dokładnie w takiej kolejności jak sobie tego życzymy i dynamicznym dodawaniu ich do DOMa. Ale już widzę, że to rozwiązanie miało by zbyt wiele wad, żeby je stosować w praktyce - choćby optymalizacja pod seo żeby daleko nie szukać… Zostaw komentarz
|
|||
