Trafiłem niedawno na bardzo ciekawy artykuł na dość popularnym blogu O’Reilly Radar (nawiasem mówiąc – polecam). Artykuł ten traktuje o wpływie szybkości (lub jej braku) ładowania strony na jej efektywność.

Pierwszą ciekawostką jest to, że artykuł prezentuje wyniki podobnych testów wykonanych zarówno przez Google jak i Bing (nową wyszukiwarkę Microsoftu). W obu przypadkach celem oby tych serwisów było dojście do wniosków które pozwolą na maksymalne zoptymalizowanie wyszukiwarek obu firm. Co ciekawe – w obu przypadkach konkuluzje są niemal identyczne.

Zarówno Google jak i Microsoft doszli do dość trywialnego wniosku, że im szybciej strona się ładuje, tym lepiej – a im wolniej, tym mniejsza jej efektywność (liczoną jako np. odnotowanym faktem kliknięcia czy ogólnym, badanym poziomem satysfakcji użytkownika).

Przykładowo wyszukiwarka Bing, testowała jak użytkownicy reagują na szybkość ładowania strony pomiędzy 50ms (jedna/dwudziesta sekundy) a 2000ms (dwie sekundy). Biorąc 50ms jako wartość bazową, stwierdzili np. że czas pomiędzy załadowaniem strony a odnotowanym kliknięciem rośnie (!) – podobnie jak spada prawdopodobieństwo jakiegokolwiek kliknięcia czy próby ponownego wyszukania używając lekko zmienionych słów kluczowych. Gdy strona ładowała się jedną-piątą sekundy (200ms) średnio kliknięcie (lub jakakolwiek akcja) następowała po 500ms (pół sekundy). Gdy strona ładowała się po dwóch sekundach (10 razy wolniej) akcja następowała ponad 3 sekundy później (6x wolniej) – jednocześnie prawdopodobieństwo wykonania jakiejkolwiek akcji spadało do 5%.

Być może pomyślicie “jedna dziesiąta sekundy czy dwie sekundy – co za różnica?”. Otoż okazuje się, że owszem – spora. Strony takie jak Bing czy Google obslugują dziennie setki milionów zapytań – więc polepszenie np. klikalności o 1% to milion kliknięc więcej (!).

Miliony milionami, ale jak ma się to do przeciętnego Polskiego biznesu? Dokładnie tak samo. Pisałem o tym już wcześniej – każda strona www, każdy biznes internetowy powinien być nastawiony na regularne udoskonalanie swojej strony. Nie tylko poprzez np. rozbudowywanie oferty – ale poprzez pomiary usability, łatwości użytkowania, optymalizacji SEO – jak również czysto technicznej szybkości. Z tego prostego powodu, że w długim okresie czasu to się zawsze opłaca, a im większy dany site, tym szybciej tego typu nakłady się zwracają.

Pytanie, co zrobić gdy zmierzymy już szybkość naszej strony i wykupimy najszybszy serwer w okolicy? ;-) Nie wnikając w temat skalowania serwerów IT (to temat na osobną serie artykułów…) ciekawe rozwiązania sugeruje wspomniany artykuł.

Po pierwsze, kontrolować jakie części strony zwracamy w jakiej kolejności – i stosować tzw. progressive rendering – w praktyce wysyłać najpierw te elementy które najszybciej się wyrenderują w przeglądarce, a dopiero póżniej te elementy które zajmą trochę czasu. Idea jest prosta – trzeba użytkownikowi jak najszybciej coś wyświetlić, żeby widział, że strona już faktycznie się ładuje, i żeby jego motywacja do używania strony nie spadała.

Wspomniana metoda zwana “Chunked Transfer Encoding” to dość “techniczne” podejście do sprawy (czytaj: tylko dla zapaleńców ;-) – jednak zwykli userzy mogą dokładnie ten sam efekt osiągnąć stosując np. maksymalną optymalizację kodu HTML (z naciskiem na przejście do lekkiego XHTML), stosowanie AJAX-a do opóżnienia ładowania niektórych elementów itp.

Wszystkim ciekawym analizy tego typu szybkości ladowania strony polecam na koniec dwa roziązania:

* Firefoxowe plugi-iny: FireBug i YSlow

* a dla fanów Mac’a Safari Web Inspector (po uruchomieniu trybu developerskiego)

Czas ładowania się strony jest rzeczywiście kluczowy przy niektórych przedsięwięciach – i przeszukiwarki (Google, Bing) są tego bardzo dobrym przykładem. Ludzie poszukują konkretnej informacji, dostają w wyniku 10 mniej lub bardziej pasujących linków, muszą je “przeskanować” wzrokiem i w ułamku sekundy zadecydować czy klikają w konkretny link, czy w opcje “Pokaż następne 10″. W takim procesie szybkie pokazanie strony www na ekranie użytkownika to absolutny priorytet.

Zachęcam do przeczytania artykułu o zwłoce (latency) na blogu High Scalability – można się dowiedzieć paru ciekawostek, m.in. jak każde dodatkowe 100ms wyświetlania strony wpływa na sprzedaż Amazona.

Natomiast nie należy popadać w jakąś paranoję, zazwyczaj wystarczy drobna optymalizacja, w myśl podwójnego Pareto (4% akcji przynosi 64% efektów). Yahoo przeprowadziło kiedyś analizę czasu ładowania stron w kilku najpopularniejszych serwisach (z nimi samimi włącznie), i okazało się, że najwięcej czasu tracone jest już na maszynie użytkownika. Nie trzeba więc wymieniać serwerów, przepisywać aplikacji, kolokować się do kilku serwerowni naraz (żeby ludzie z Australii też mieli szybko). Najczęściej są to proste, sprytne ruchy w stylu połączenia wszystkich plików CSS w jeden, przesunięcie wszystkich javascript na dół kodu, zamiast dziesiątek oddzielnych obrazków używanie CSS sprites, dodaniu nagłówków Expires i ETag, itp. – przykład konkretnej listy pomysłów można znaleźć np. tutaj: http://developer.yahoo.com/performance/rules.html.

Na koniec muszę trochę popolemizować z Andrzejem, który piszę, że optymalizacja “w długim okresie czasu to się zawsze opłaca”. Kłopot jest w tym, że ten “długi okres czasu” może być za długi. Przy mało dochodowych serwisach (powiedzmy sklep z karmą dla chomików, obrót 30.000pln miesięcznie) szeroka optymalizacja może się nie zwrócić, bo za mało czasu będzie, że pieniadze na nią wydane wróciły w postaci zwiększonego obrotu. Za kilka lat będzie trzeba przecież i tak przebudować sklep, bo zmieni się technologia, oczekiwania klientów, może nawet sam sposób w jaki Internet działa. Jeśli inwestycja w optymalizację nie zwraca się w takim horyzoncie czasowym, może warto wtedy ograniczyć jej zakres, redukując przy tym koszty.