Wyższa prędkość działania to wyższa konwersja. Gdy strona odpowiada szybciej, użytkownicy są mniej skorzy do jej opuszczenia. W dodatku tempo odpowiedzi wpływa na pozycjonowanie - Google premiuje szybkie strony.
W dobie błyskawicznego dostępu do sieci, prędkość coraz mniej zależy od parametrów łącza, a coraz więcej od techniki serwowania treści. Poznaj metody skrócenia czasu oczekiwania użytkowników do minimum.
Jakie znaczenie ma subiektywne odczucie szybkości działania aplikacji?
Wg Nielsena Norman'a, autora " Usability Engineering", pierwsza granica dla percepcji upływu czasu na polecenia użytkownika to:
- 100ms - wszystkie reakcje zwrotne front-end'u mieszczące się w tej granicy są postrzegane jako płynne i dają wrażenie bezpośredniej kontroli nad aplikacją.
- Czas wykonywania akcji w przedziale między 0.2s, a 1s zauważamy jako opóźnienie. Jeśli jest to czas reakcji graficznych elementów sterujących aplikacją tj. przycisków, wysuwanych listy itd., to użytkownik odczuje upływ czasu tak jakby to on "wykonywał pracę".
- Po upływie 1s oczekiwania użytkownik traci poczucie płynności dostępu do informacji. Zaczyna zerkać na pasek postępu, pojawia się dyskomfort i wrażenie braku bezpośredniej kontroli.
- 10s to maksymalny limit utrzymania uwagi na wyświetlanym komunikacie dzielącego odbiorcę od żądanej treści. Po upływie takiego czasu użytkownik zazwyczaj chce wykonać następną akcję, odświeża lub zamyka okno. Dla takich przypadków, aby "nie stracić usera", warto wyświetlić informację zwrotną o postępie wykonywanej akcji w formie paska postępu lub animowanej pętli.
Studia Nielsena nad usability dotyczą aplikacji w ogóle, jak również stron internetowych i aplikacji mobilnych. W przypadku przechodzenia pomiędzy stronami, można pozornie uznać, że część zadań związanych z użytecznością leży po stronie przeglądarki i jest zależna od parametrów łącza, jednak walka o uwagę odbiorcy obowiązuje stale na każdej platformie. Podczas przeglądania treści online dystraktorów jest nawet więcej, niż w regularnych aplikacjach. Czas oczekiwania użytkownika powinien być możliwie najkrótszy.
Anatomia opóźnienia
Czas oczekiwania użytkownika na wyświetlenie strony zależy głównie od liczby i rozmiaru plików (lub porcji danych) potrzebnych do ściągnięcia przez przeglądarkę. Każdemu pobieranemu plikowi odpowiada jedno połączenie HTTP. Pobieranie danych to jednak nie jedyny etap.
Ponieważ przeglądarki ograniczają maksymalną liczbę połączeń nawiązanych z jedną domeną, proces ściągania plików odbywa się zarazem szeregowo, jak i równolegle. Obrazuje to zjawisko poniższa wizualizacja połączeń, jakie wykonuje przeglądarka podczas otwierania strony www.smart.biz.pl/techblog/co-potrafi-qr-kod. (Wykonana dzięki www.webpagetest.org)
Co można zaobserwować:
- Czas potrzebny na rozwiązanie adresów przy użyciu serwerów nazw (DNS) zostaje strawiony tylko raz na domenę - jedynie pierwsze żądanie dla domeny www.smart.biz.pl zawiera etap ciemno-turkusowy.
- Czas nawiązywania połączenia (kolor pomarańczowy) zostaje zminimalizowany w sytuacji pobierania plików tego samego typu z tej samej domeny.
- Sumaryczny czas, który upływa przed rozpoczęciem pobierania (kolor zielony) może być dłuższy niż czas pobierania danych (niebieski).
- Pewne grupy elementów są pobierane wg kolejności, zależnej od struktury HTML strony. Wszystkie elementy “czekają” na załadowanie bazowego dokumentu HTML. Kolejność elementów w układzie kolumn ma znaczenie.
- Przeglądarka pobiera jednocześnie z jednej domeny jedynie ograniczoną liczbę elementów.
- Im więcej niepowtarzalnych domen, tym więcej czasu upływa na rozwiązywanie ich nazw. Proces ten jest jednak równoległy.
Zasady zachowania szybkiej odpowiedzi.
Strona w przeglądarce ładuje się tym szybciej, im mniej wywołuje połączeń HTTP z tego samego źródła, im mniej danych potrzebuje do ściągnięcia oraz im mniej jest miejsc w kodzie blokujących płynne renderowania dokumentu.
1. Linkuj JavaScript i CSS jako zewnętrzne pliki.
Linkuj arkusze stylów i skrypty z odrębnych plików używając elementu <link>, dzięki czemu pliki trafią do cache przeglądarki. Nie używaj elementu @import. Wykorzystuj te same pliki,a zostaną one odczytane z cache przeglądarki, gdy Twój gość przejdzie do każdej kolejnej podstrony. Jednocześnie zadbaj, by plików zewnętrznych nie było zbyt wiele - każdy plik to dodatkowe zapytanie HTTP.
2. Stosuj <link> zamiast @import.
Przeglądarki IE ładują pliki wskazane dyrektywą @import, tak jakby były importowane elementem <link> przed zamknięciem </body> (co w większości przypadków nie jest pożądane). W dodatku łączenie @import i <link> łamie stosowanie równoległych zapytań HTTP przez przeglądarkę.
3. Umieszczaj style CSS w nagłówku.
Jeśli strona posiada zdefiniowane wszystkie style w sekcji <head>, to przeglądarka szybciej renderuje resztę strony. W przeciwnym razie przeglądarka będzie musiała wykonać przynajmniej jeden dodatkowy przebieg wyrysowania zawartości w oknie.
4. Stosuj kompresje gzip.
Skuteczność kompresji zależna jest od danych - jest tym większa im wyższa jest powtarzalność znaków w kompresowanym zbiorze danych (zob. Kodowanie Huffmana). Upakowane formaty, takie jak JPG i większość multimediów, zazwyczaj kompresują się w bardzo niewielkim stopniu. Dla tekstowych plików HTML, CSS, JavaScript współczynnik kompresji może wynosić ponad 60%. Automatyczną kompresję ustawiaj na poziomie serwera lub aplikacji webowej.
5. Bundling - łącz pliki źródłowe tego samego typu.
Łącz pliki stylów w jeden arkusz CSS, pliki JavaScript w jeden skrypt, dzięki czemu zmniejszasz liczbę żądań HTTP.
6. Minifikuj (Minification).
Czy minifikacja jest już w słowniku języka polskiego? Występuje w szybkich stronach. Jej ślady widać w mocno upakowanym kodzie. Minifikacja odchudza pliki źródłowe przez usuwanie białych znaków i komentarzy. Traktuj nią wszystkie, poprzednio połączone, pliki tekstowe wysyłane do przeglądarki: CSS, JavaScript i kod HTML.
- Narzędzia do minifikowania plików online: jsmini.com, Css-compressor
- Plugin edytora sublime tex: Sublime-Minifier
- Plugin edytora notepad++: JSmin
- Programy linii poleceń: Yuicompressor, Jsmin.
7. Kompiluj JavaScript.
Bardziej zaawansowaną metodą zmniejszania objętości kodu jest kompilacja JavaScript za pomocą Google Closure compiler, który kompiluje wskazany kod wraz z zależnościami w nowy zoptymalizowany skrypt pozbawiony nieużywanych bloków kodu.
Skrypty można kompilować bezpośrednio w aplikacji online lub wykorzystując API.
Jest to bardziej zaawansowany sposób na minifikację skryptów. Jeżeli Twoja strona korzysta z zewnętrznych bibliotek JavaScript, ale nie wykorzystuje większości ich funkcji, to Closure Compiler uszczupli wielkość skryptów do minimum, obcinając nieużywane obszary importów i pozostawiając przeglądarce do ściągnięcia tylko faktycznie potrzebny kod.
8. Umieszczaj JavaScript zaraz przed </body>.
Jeśli tylko strona nie potrzebuje danego skryptu do wyświetlenia treści, to umieść go na końcu strony zaraz przed elementem </body>. Odbiorca zobaczy treść, zanim przeglądarka załaduje skrypty.
9. Interpretuj i ewaluuj leniwie.
Unikaj parsowania i wykonywania skryptów, jeśli tylko nie jest to konieczne. Wykonanie skryptów może wyraźnie obniżyć poczucie szybkiego działania, szczególnie w przeglądarkach urządzeń mobilnych.
Stosuj kod JavaScript, którego jak największa część jest wykonywana dopiero w momencie żądania użytkownika, lecz niekoniecznie zaraz po załadowaniu strony. Ładuj dodatkowe biblioteki dopiero wtedy, gdy są potrzebne lub linkuj jako tekst i ewaluuj przy pierwszej próbie użycia.
10. HTML5 i CSS3.
Budowa stron na bazie HTML5 i CSS3 pozwala uzyskać efekty znacznie mniejszym nakładem linijek kodu, niż to ma miejsce w przypadku CSS2/HTML4. Pierwszym z brzegu przykładem może być player video - nie ma tutaj już potrzeby używania odrębnego, ciężkiego komponentu Flash. Zaokrąglanie rogów w HTML5/CSS3 to kilka linijek kodu, zamiast zagnieżdzania div'ów i ładowania dodatkowego zestawu grafik. HTML5 i CSS3 to odrębny, bardzo ciekawy temat - po więcej przykładów odsyłam do HTML5 Rocks.
11. Użyj różnych domen dla statycznych zasobów strony.
Przeglądarki posiadają limit maksymalnej liczby połączeń Http z pojedynczym hostem - dla starszych limit wynosił 2, dla nowszych najczęściej wynosi 6.
Dlatego podczas ładowania strony, gdzie wszystkie pliki (style, skrypty i grafika) linkowane są z jednego serwera, przeglądarka będzie pobierać jednocześnie nie więcej niż np. 6 (Chrome) elementów. Każdy plik ponad limit będzie musiał czekać na swoją kolej.
By przeglądarka ładowała możliwie wiele zasobów równolegle, linkuj część plików z dodatkowych domen. Liczba różnych domen źródłowych nie powinna być jednak zbyt duża, ponieważ kosztowne jest samo rozwiązanie nazwy każdego hosta. W zależności od użytego przez użytkownika DNS, każde rozwiązanie wcześniej nie odwiedzanego przez przeglądarkę adresu, to zazwyczaj czas rzędu 30 - 150 milisekund.
| Przeglądarka | liczba połączeń per host | ogólna liczba połączeń |
|---|---|---|
| Chrome 24 - 26 | 6 | 9 |
| Firefox 19 | 6 | 14 |
| Firefox 20 | 6 | 15 |
| Firefox 21 | 6 | 9 |
| IE 8, 9 | 6 | 35 |
| IE 10 | 8 | 16 |
| Opera 12.11 | 6 | 16 |
| Android 2.3 | 8 | 10 |
| Android 4 | 6 | 13 |
| IEMobile 9 | 6 | 60 |
| Opera Mobile 12 | 8 | 32 |
| Chrome Mobile 18 | 6 | 8 |
12. Linkuj pliki statyczne z domen bez ciasteczek.
Czyli pliki ładuj z domen, które nie mają spowalniających komuniakację mechanizmów sesji. Wybierz statyczny, publicznie dostępny folder.
13. Linkuj popularne pliki z publicznych Content Delivery Network (CDN).
Ładowanie popularnych plików strony z zewnętrznych serwerów zwiększa szansę na to, by ten element nie został w rzeczywistości ściągnięty przez przeglądarkę. Linkując z CDN pieczesz kilka pieczeni na raz:
- serwery CDN są/bywają zoptyamalizowane geograficznie
- pliki zazwyczaj są już zminifikowane i skompresowane
- wyższe prawdopodobieństwo, że nazwa adresu CDN jest już rozwiązany przez lokalny DNS
- im popularniejszy DNS, tym wyższe prawdopodobieństwo, że plik jest już w cache przeglądarki
Co linkować? Przede wszystkim JavaScript - często spotykanym zasobem linkowanym z CDN jest biblioteka jQuery, listę znajdziesz na Googlowym CDN. Ciekawym pomysłem jest ładowanie z CDN całych zrębów szablonów front-endowych. Np. Twitter Bootstrap utrzymuje bootstrapcdn.com, ale osobiście wolałbym poczekać, aż zdecyduje się go serwować Google lub inny większy gracz.
14. Określaj wymiary i nie skaluj obrazów.
Ustawiaj atrybuty width i height dla każdego znacznika <img> zgodny z rzeczywistymi rozmiarami grafiki.
15. Stosuj sprite'y
Czyli łącz pliki graficzne w jeden plik. Ta technika daje dobre rezultaty, gdy używasz wielu niewielkich plików. Pamiętaj, że pozioma orientacja grafiki zwykle waży mniej od pionowej. Ograniczaj paletę barw - np. dzieląc obrazy na 2 pliki: 16 kolorowy dla ikon w serwisie oraz drugi dla 24bitowej palety barw niewielkich zdjęć. A oto przykład sprit'e użytego w tym artykule:
Tutorial Css sprites.
16. Optymalizuj grafikę.
Stosuj najwęższą możliwą paletę barw dla PNG. Jeśli nie jest konieczna unikaj przezroczystości. Kompresuj JPG. Stosuj image-maps.
- Clever PNG Optimization Techniques
- Smush.it™ - optymalizator online
- PNGGauntlet - program Win/Mac/Linux do optymalizacji grafiki
17. Optymalizuj back-end, stosuj prekalkulację odpowiedzi.
Optymalizacja warstwy usługowej to odrębne zagadnienie. Generalnie korzystaj tam, gdzie pozwala na to domena biznesowa, z doświadczeń świata noSQL:
- denormalizacja - projektuj model danych, tak by móc wykonywać na nich proste i szybkie w wykonaniu zapytania nawet kosztem powtarzalności, rozmiaru i aktualności
- wydajność vs. dokładność - jak wyżej, jeśli tylko pozwalają na to wymagania na Twoją aplikację, wymieniaj dokładność wyników na szybkość w ich obliczaniu
- rezygnuj z JOIN'ów w zapytaniach, a jeśli się ich pozbędziesz, rozważ bazy typu klucz wartość (BigTable, HBase) lub dokumentowe MongoDB.
- nie obliczaj wyników na żądanie użytkowników, lecz w trakcie dodawania rekordów lub odpalaj jako zadania w tle
- używaj pamięci podręcznej (cache) po stronie dostępu do bazy danych (Memchached, Ehcache).
18. Ustawiaj nagłówek Expiry w odpowiedziach HTTP
Dobrze skonfigurowane nagłówki Expires header pozostawią zasoby strony w cache przeglądarki. Nagłówek można ustawić dla każdego typu odpowiedzi na poziomie serwera. Dla serwerów współdzielonych, konfiguracja zaszyta jest w pliku .htaccess. Jeśli masz pełną kontrolę nad serwerem, to czas życia zasobów w cache przeglądarek ustawisz w plikach konfiguracyjnych serwera HTTP, np httpd.conf Apache. Zawsze jednak można sterować zawartością nagłówków w odpowiedziach HTTP z poziomu aplikacji PHP/Java/innej, odpowiednio modyfikując komunikat przed wysłaniem.
19. Inline images - małe obrazy koduj do postaci data URI.
Kolejna metoda na zmniejszenie liczby wywołań HTTP: zamiast ładować odrębne pliki grafik, zapisz je w zakodowanej do base 64 postaci w arkuszach stylów.
Jest to sposób na załadowanie grafiki wektorowej/rastrowej lub fontu bez dodatkowego pliku. Jak to często w podobnych sztuczkach bywa, ukryty jest haczyk, i jak tradycja nakazuje haczyk związany jest z Internet Explorerem - IE obsługuje od wersji 8 i dla IE wielkość zakodowanego URI nie może przekraczać 32kb. Stosuj dla niewielkich grafik. Zakodowany obrazek zazwyczj cięższy o ok 25% i pozostanie większy nawet jeśli odpowiedzi są kompresowane. edytor online
20. Nie przesadzaj z przekierowaniami 301.
Przekierowania 301 to optymalny sposób na zachowanie SEO starych linków z sieci prowadzących do nieistniejących zasobów w utrzymywanym serwisie. Jednak zbyt duża liczba przekierowań 301 połączona w łańcuch spowolni działanie przeglądarki.
21. Wykorzystuj wbudowane funkcje CMS lub serwera HTTP.
Wykorzystuj wtyczki systemów zarządzania treścią Twojej strony. Jeśli wybrałeś popularnego Wordpress'a lub Joomla! wiele z w.w. praktyk zrealizujesz za pomocą pluginów. Konfiguruj cache strony na poziomie aplikacji (CMS) - strony pozbawione formularzy lub personifikowanej treści serwer może generować jedynie raz na określony czas, dzięki czemu będzie szybciej odpowiadał na większą liczbę zapytań użytkowników.
- Joomla
- Wordpress
Czym zmierzyć wydajność strony.
Audyt wydajność strony można przeprowadzić za pomocą rozszerzeń przeglądarek Firebug (YSlow) oraz Chrome Developer Tools.
Podobną funkcjonalność oferują analizatory wydajności online (webpagetest.org, loads.in) dodając możliwość testowania z różnych lokalizacji geograficznych oraz współdzielenia i porównywania wyników.