Ostatnio coraz większą wartością staje się wizerunek osób czy instytucji w internecie. Kreowanie wizerunku w sieci to już cała gałąź PRu, z rosnącym zasobem reguł i technik… Ostatnio jednym ze szczególnie popularnych narzędzi stał się mikroblogging. Na blipie, bardzo popularnym polskim mikroblogu, swoje profile ma m.in. ^lechwałęsa, ^premier czy ^tvn24. Śledzą je setki osób, często w czasie rzeczywistym. To pewien rosnący trend i nowe medium przekazywania informacji. Co by się jednak stało gdyby nagle ^lechwałęsa zaczął wklejać lolcaty, a ^tvn24 poinformował o wybuchu bomby atomowej? W UK coś podobnego już wywołało poruszenie, u nas może jeszcze nie, ale za parę lat?

Przyjrzałem się więc bezpieczeństwu blipa i co się okazało? Otóż do niedawna podobne scenariusze były całkiem możliwe.

Przekazałem oczywiście informację i błąd został już poprawiony, a wszystkim ciekawym, o co chodziło z technicznego punktu widzenia polecam lekturę PDFa.

A przecież główny powód nie jest taki skomplikowany:

Jeśli ktoś opiera swój biznes na oferowaniu aplikacji w chmurze, to musi się zatroszczyć, żeby te aplikacje były osiągalne cały czas. DNS jest ważną częścią tej wielkiej otoczki, która pozwala ludziom dotrzeć do gmaila, google docs, itd. W dodatku to jest całkiem czuły punkt. Były już przypadki, kiedy poszczeglne serwisy były nieosiągalne z powodu ataków na DNS (z czego najsłynniejszym był chyba problem z youtubem). Oferując własne serwery DNS, Google zatroszczy się, żeby ich aplikacje były zawsze osiągalne. Oczywiście dla osób, które będą z tych serwerów korzystać.

Myślę więc, że Google nie będzie uprzykrzać ludziom życia reklamami, bo przecież chodzi o to, żeby ludzi zachęcić a nie zniechęcić, prawda?

PS. Poza tym DNS to największa rozproszona baza danych, a Google chyba jest dobre w te klocki?

1. nie wiem czy ktoś już wymyślił dobrą metodę na mierzenie stron, w których treści łądują się dynamicznie i uaktualniają w czasie rzeczywistym
2. no bo na pewno nie gemius
   1. gemius ciągle mierzy stronki swoim skrypcikiem ładującym malutkiego gifa (redot.gif), który jest dobry, ale dla stron statycznych
   2. chociaż na blogu zadają się dostrzegać problem: “w dobie interaktywnych technologii tworzenia stron internetowych takich jak Flash czy Ajax pojęcie odsłony staje się anachroniczne”)
      1. tylko, że ten wpis jest sprzed ponad 2 lat
3. nie wiem też jak w kontekście takich serwisów gemius mierzy średni czas przebywania w serwisie
   1. przecież przez pół godziny mogę sobie rozmawiać i pisać na blipie (na własnym kokpicie), ale do żadnego przeładowania strony nie dojdzie
      1. a w konsekwencji skrypcik gemiusa nie zanotuje żadnej aktywności
      2. statystyki blipa mogą być więc mocno zaniżone
   2. w tym wypadku świetnie wypada pinger
      1. tu za każdym razem jak coś napiszemy to strona się przeładuje, skrypcik gemiusa zostanie załadowany i odonotuje aktywność.
      2. w tym pingerze mają łeb nie od parady – dużo mniej wpisów, i dużo lepsze statystyki
4. żeby było ciekawiej, problemów jest więcej
   1. np. jak zmierzyć popularność serwisu, z którego można korzystać za pośrednictwem aplikacji i komunikatorów?
   2. to już bardziej przypominałoby próbę zmierzenia aktywności na IRCu
      1. mierzenie ilości wejść do “pokoju” to chyba nie jest najlepsza metryka
      2. ale niestety tak to w tej chwili wygląda
5. i niestety jak na razie nie widać szans na poprawę.

ALE

Działania marketingowe to chyba pewna forma reklamy, prawda? Chodzi przecież o to, żeby rożne firmy czy serwisy poprzez swoje profile mogły się komunikować z zainteresowanymi osobami, polecać jakieś artykuły, rzeczy itd. Nie ma się co rozwodzić, gdzieś tam po drodze chodzi o reklamę.

A teraz trzymajcie się. Zaglądamy do regulaminu serwisu Blip.pl:

Treść zamieszczonych ogłoszeń i informacji w Serwisie nie może być sprzeczna z prawem, normami etycznymi oraz dobrymi obyczajami. W ogłoszeniach nie mogą się znaleźć treści reklamujące inne firmy lub serwisy internetowe. W przypadku naruszenia tego zakazu Gadu-Gadu S.A. może odmówić publikacji ogłoszenia, bądź usunąć takiego Użytkownika. Gadu-Gadu S.A. zastrzega sobie prawo odmowy przyjęcia ogłoszenia, modyfikacji bądź dalszej publikacji bez podania przyczyny.

Co Wy na to? Reklama na blipie zakazana?

PS. Rozumiem, że aktualni administratorzy są OK, do no evil… Ale skąd pewność, że tak będzie cały czas?

JavaScript jest wszędzie

Zacznijmy od tego, że optymalizację czasu wyświetlania się strony powinniśmy zacząć po stronie użytkownika. Jeśli policzymy czas od momentu wpisania adresu i wciśnięcia ENTER aż do wyświetlenia całej strony to wyjdzie nam, że około 80-90% czasu zajmą wszystkie czynności związane z wyświetleniem frontendu, tzn. pobranie dodatkowych obrazków, uruchomienie skryptów, załadowanie dodatkowych ramek itd. Tylko 10-20% to czas w jakim serwer tworzy samą zawartość strony (np. wykonując skrypty PHP). No dobrze, ale co najbardziej wydłuża czas wczytywania się stron WWW? Zdecydowanie JavaScript. W dalszej części spróbujemy jakoś temu zaradzić.

W tej chwili niemal 100% stron WWW używa różnych skryptów: od javascriptowych wodotrysków w interfejsie, po trackery i zewnętrzne reklamy. Najczęściej skrypty JS używane są jako różne wklejki na stronie. Wszystko jest proste: kopiuj-wklej w kod HTML strony. Niestety z punktu widzenia wydajności jest to najczęściej spory błąd.

Dla przeciętnego użytkownika gotowa i załadowana strona to taka, którą już można w całości zobaczyć wraz ze wszystkimi jej składnikami (obrazki, flashe itd). Przeglądarka świetnie sobie radzi żeby zrobić to jak najszybciej: ściąga kilka elementów równolegle i wyświetla je jak tylko do niej dotrą, nawet jeszcze w trakcie ściągania. Inaczej jest jednak ze skryptami. Skrypty ściągane są w całości i zaraz po ściągnięciu uruchamiane. Co więcej, w trakcie działania skryptu przeglądarka nie wykonuje nic innego. Czyli np. nie ściąga pozostałych składników strony tylko cierpliwie czeka aż skrypt zrobi swoje.

Co to oznacza? Oto kilka case studies:

1. Strona korzysta z zewnętrznego skryptu gemiusa umieszczonego w sekcji “head” strony. Gemius ma akurat krótką awarię i skrypt jest niedostępny. Przeglądarka zaczyna wczytywac stronę ale czeka na skrypt. Po kilku sekundach następuje timeout, ale przez ten czas wszystko stoi w miejscu a użytkownik widzi pustą stronę.
2. Nawigacja na stronie oparta jest o panele z zakładkami (tab-based interface). Przełączanie paneli obsługuje skrypt JS, który został umieszczony w kodzie HTML tuż za elementami
   tworzącymi panele. Użytkownik widzi wczytującą się w miarę płynnie stronę, jednak w momencie pokazania się zakładek następuje wyraźne przerwanie wczytywania i przez chwilę nic się nie dzieje.
3. Strona wykorzystuje zewnętrzny widget umieszczony w panelu bocznym. Widget został wstawiony wg. instrukcji od dostawcy: wklej kod <script type=”text/javascript”> document.write(”….”) </script> Użytkownik po wejściu na taką stronę widzi wczytujące się elementy aż do chwili pojawienia się panelu bocznego, następuje dłuższa chwila przerwy, po czym dopiero zaczyna się wyświetlać reszta strony.

Takich sytuacji jest mnóstwo, ale wszystkie mają wspólną przyczynę: jest nią uruchamianie czasochłonnego skryptu w trakcie ładowania strony.

Od czego zacząć?

Po pierwsze przyjrzymy się, które elementy najbardziej spowalniają stronę. Polecam dwa narzędzia: firebug (dodatek do firefoxa) lub IBM Page Detailer (działa zarówno z IE jak i FF). Żeby nabrać trochę wprawy zobaczmy co się dzieje w przypadku naszych case studies:

W przykładzie pierwszym wczytywanie elementów strony wygląda tak:

Widzimy, że drugi element (skrypt statystyk umieszczony w sekcji ) wczytuje się 12 sekund. Przez ten czas przeglądarka czeka i nie wczytuje kolejnych fragmentów strony. Element trzeci ładowany jest dopiero po zakończeniu wczytywania i uruchomieniu skryptu. Efekt: przez 12 s użytkownik widzi pustą stronę.

W przykładzie drugim mamy skrypt umieszczony gdzieś w połowie sekcji . I podobnie jak poprzednio, przeglądarka parsując kod HTML natrafia na skrypt i zaczyna go wczytywać, przerywając inne czynności.

W przykładzie trzecim mamy 3 widgety, każdy z nich ładuje się 2 sekundy:

Charakterystyczne są tutaj “schodki” pokazujące kolejność ładowania się skryptów: każdy następny element czeka na załadowanie się poprzedniego. Nie ma tu mowy o równoległym wczytywaniu. Cała strona zacznie się wyświetlać dopiero po 6 s. Polecam zapamiętać sobie te “schodki”, bo będą się później pojawiać wszędzie tam, gdzie skrypty powodują blokowanie ładowania się strony.

No tak, ale co teraz?

Przejdźmy wprost do rozwiązania. Najlepiej by było, gdyby zmusić wszystkie skrypty do równoległego wczytywania i uruchamiania się PO załadowaniu całej treści strony. Niestety czasami mamy kilka skryptów które potrzebne są na etapie ładowania treści. Musimy zatem:

1. wydzielić te skrypty, które muszą być uruchomione na etapie wczytywania strony
2. wszystkie pozostałe załadować po wyświetleniu strony
3. ładować skrypty równolegle w tym samym czasie, bez blokowania

W pierwszym punkcie wszystko zależy od strony, ale im mniej skryptów w trakcie ładowania tym lepiej. No i żadnych skryptów z zewnętrznych serwerów. Żadnych.

W punkcie drugim, jeśli na stronie korzystamy z jQuery to najwygodniej skorzystać z $(document).ready() np w taki sposób:

1
2
3
$(document).ready(function() {

    load_all();

});

Jeśli nie chcemy ładować całego jQuery to można skorzystać z gotowych skryptów uruchamianych po załadowaniu struktury DOM. Nie będę wnikał w szczegóły, tylko zainteresowanych odsyłam do bloga Riddle’a, który już to opisał, a w szczególności do tego skryptu.

Pozostało najciekawsze, czyli punkt trzeci. Okazuje się, że jest na to parę sposobów. Tutaj skupimy się na jednym, chyba najciekawszym: dynamicznym ładowaniu skryptów. Spójrzmy na taki kod:

1
2
3
4
5
6
var p=document.getElementsByTagName("HEAD")[0];

var c=document.createElement("script");



c.type="text/javascript";

c.src="http://host/skrypt.js";

p.appendChild(c)

Tworzy on tu dynamicznie element <SCRIPT> i umieszcza go w sekcji <HEAD> strony. Wszystko proste i jasne, ale najciekawsze jest to, że ściągnięcie i uruchomienie skryptu następuje w chwili wykonania linijki p.appendChild(c). Mamy więc idealną kontrolę nad tym kiedy skrypt się ściągnie. Co więcej, dodanie kilku skyptów na raz spowoduje, że będą się ściągać równocześnie. Super! Sposób ten działa zarówno w IE, FF, Operze jak i przeglądarkach opartych na WebKit (Chrome, Safari).

Połączmy teraz wszystkie elementy w jedną całość. Efekt można zobaczyć samemu albo na poniższym obrazku:

I oczywiście cały kod script-loader.js (polecam też zajrzeć w źródło rozwiązania):

Podsumowując: ładujemy wszystkie skrypty dynamicznie po załadowaniu struktury DOM

Rozwiązanie ma następujące efekty:

• nie widać znaczących przestojów w czasie ładowania strony, pomimo użycia skryptów wprowadzających spore opóźnienie (nie liczę tu czasu wczytania pomocniczej biblioteki jQuery)
• skrypty nie blokują wczytywania innych elementów strony. W przykładowym rozwiązaniu do czasu ich uruchomienia cała strona zostanie już wyświetlona
• skrypty ładują się równolegle, bez konieczności czekania na siebie

Ma niestety również pewną wadę: co z sytuacją kiedy różne skrypty są zależne od innych? Tu oczywiście rozwiązań jest wiele, być może kiedyś o tym napiszę.

Zainteresowanych poznaniem innych szczegółów optymalizacji odsyłam również do prezentacji “Even Faster Web Sites” Steve’a Soudersa.

Real World Scenarios

A teraz dwa przykłady znalezione w sieci:

1. Strona główna portalu gazeta.pl

Skrypt umieszczający reklamy wydłuża ładowanie strony o 1.34 s (w tym przypadku).

2. Blog Harnira

Klasyczne schodki: tracimy około 1 s na ładowanie pojedynczych skryptów z bieżącego template’u wordpressa.

quote

Hello World!