Wydajność stron
i aplikacji internetowych

Maciej Brencz, Wikia Inc.
AKAI, 27 marca 2012

Plan prezentacji

• dlaczego wydajność jest ważna?
• backend vs frontend
• najlepsze praktyki
• monitoring
• studium przypadku
• narzędzia.

Dlaczego wydajność jest ważna?

• kto chce czekać 10 sekund na załadowanie podstrony sklepu internetowego?
• YAHOO! dodało 400 ms opóźnienia do czasu ładowania stron » spadek odsłon o 5-9%
• Mozilla poprawiła czas ładowania strony "reklamowej" Firefoxa o 2,2 sekundy » wzrost pobrań o 15,4% (60 milionów w skali roku)
• Netflix po zaimplementowaniu tylko jednej z reguł (kompresja GZIP) zmniejszyło ruch na wyjściu z serwerów o 50%
• dbanie o wydajność powinno być stale obecne w projekcie.

80-90% of the end-user response time is spent on the frontend. Start there. The Performance Golden Rule

Wąskie gardła

• nadal pamiętajmy o wydajności po stronie serwera (optymalizacja zapytań SQL, cache'owanie)
• protokół HTTP oparty o TCP/IP » kosztowne nawiązanie połączenia + ew. SSL » Keep-Alive, HTTP pipelining
• przeglądarki ograniczają liczbę równoległych pobrań z jednej domeny » domain sharding
• użycie różnych domen » zapytania DNS
• przeglądarka musi pobrać i zinterpretować wiele plików: HTML, JavaScript, CSS, obrazki, flash, ...

The fastest HTTP request is the one not made.

Najlepsze praktyki

• zmniejszenie ilości pobieranych danych
• ograniczenie liczby zapytań » redukcja przekierowań HTTP, błędów HTTP 404 (brakujące pliki), łączenie plików CSS oraz JS
• minifikacja plików CSS oraz JS
• optymalizacja obrazków
• kompresja GZIP przesyłanych danych
• wykorzystanie cache'a przeglądarki (pliki statyczne, zapytania AJAX) » nagłówki HTTP, obsługa ciasteczek, CDN.

Optymalizacja plików CSS i JavaScript

• minifikacja: usunięcie białych znaków, komentarzy + zaawansowana "obróbka" kodu JS
• kompresja przesyłanego kodu: użycie algorytmu GZIP
• jQuery 1.7.2 - 247 kB kodu, 92 kB po minifikacji, 33 kB po minifikacji i kompresji (ponad 7x mniej)
• narzędzia: cssmin, Google Closure Compiler, uglifyjs.

Optymalizacja obrazków (cz. 1)

• wybór formatu: GIF, PNG czy JPEG + wybór kompresji
• usunięcie bloków EXIF z plików JPEG (prawa autorskie)
• ikonki serwowane z jednego pliku - tzw. sprite.
  

  .icon {
  	background-image: url(/images/sprite.png);
  }
  .icon.ok {
  	background-position: -1096px -80px;
  }

Optymalizacja obrazków (cz. 2)

• serwowanie obrazków we właściwych rozmiarach (unikajmy skalowania w HTMLu)
• małe obrazki (1-2 kB) umieszczone "bezpośrednio" w pliku CSS - enkodowanie base64
  

  #foo {
  	background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAlCAYA
  }

• wykorzystanie cache'a przeglądarki (pliki statyczne)
• narzędzia: pngcrush, smush.it, pngquant.

Nagłówki HTTP, a wydajność

• zapytania POST nigdy nie są cache'owane
• nagłówki odpowiedzi pozwalają określić czas cache'owania statycznej treści przez przeglądarkę
• Expires: Fri, 20 Apr 2012 10:27:47 GMT
• Cache-Control: public, max-age=31536000 (cache'uj na jeden rok, wprowadzony w HTTP 1.1)
• nagłówek Last-Modified dla treści dynamicznej
• If-Modified-Since wysyłane przez przeglądarkę » nowa treść lub odpowiedź 304 Not Modified
• jak inwalidować stare wersje plików przy długim czasie cache'owania?

Domeny bez ciasteczek

• ciasteczka "zatruwają" wszystkie zapytania wysyłane na domenę, w której są ustawione » dodawane są również do zapytań o pliki statyczne
• inne domeny do serwowania plików statycznych
  (wikia.com vs images.wikia.nocookie.net)
• zapytania nie zawierają niepotrzebnych ciasteczek
• konieczny cache buster w URLach.

Content Delivery Network (CDN)

• "proxy" serwujące treść statyczną (JS, CSS, obrazki, flash)
• serwery rozsiane po całym świecie widoczne pod wspólną domeną » różne adresy IP w różnych miejscach świata
• pliki serwowane z najbliższych użytkownikowi serwerów » krótszy czas odpowiedzi
• zapytania nie zawierają niepotrzebnych ciasteczek
• Yahoo! po wprowadzeniu CDN zanotowało 20% skrócenie czasu ładowania strony
  
  
• darmowy CDN na Google AppEngine (np. CirruxCache)
• src.sencha.io - darmowy CDN dla obrazków z funkcją ich optymalizacji i skalowania.

Ładowanie plików CSS i JavaScript, a wydajność

• CSS: tagi <link> jak najwcześniej (sekcja <head>) » wczesne aplikowanie CSS'a
  
  
• JavaScript: tagi <script> na samym dole dokumentu (przed </body>) » ściąganie JS'a blokuje renderowanie strony
• wczytywanie bez blokowania: atrybut async wprowadzony w HTML5 » JS wykonuje się natychmiast po pobraniu
• nie zachowuje kolejności wykonywania asynchronicznych skryptów
• różne zachowanie w różnych przeglądarkach (test).

Kod 3rdparty: Facebook, Twitter, Google Analytics, ...

var script = document.createElement("script"),
	firstScript = document.getElementsByTagName('script')[0];
script.type = "text/javascript";
script.async = true; // asynchronicznie, bez wzajemnego blokowania
script.src = "http://foo.net/script.js";
firstScript.parentNode.insertBefore(sNew, firstScript);

• skrypty "zewnętrzne" wczytywane asynchronicznie (bez blokowania, wykonują się natychmiast po pobraniu)
• SPOF - single point of failure » ryzyko zablokowania wczytywania strony w przypadku problemów z zewnętrznym serwerem » rozwiązaniem wczytywanie asynchroniczne.

Dalsze kroki (cz. 1)

• optymalizacja HTMLa » zmniejszenie liczby elementów DOM (szybsze renderowanie, szukanie elementów)
• optymalizacja kodu JS » profiling, analiza kodu uruchamianego na onDOMready
• optymalizacja kodu CSS » optymalizacja selektorów, wykorzystanie dziedziczenia, unikanie expression
• poprawne cache'owanie zapytań AJAXowych
• lazyloading » ładowanie plików tylko, gdy potrzebne
• użycie localStorage jako cache'a » aplikacje mobilne
• prerendering w Chrome 13+ (<link rel="prerender" href="cart-buy.php">).

Dalsze kroki (cz. 2)

• preloading obrazków » poprawa postrzeganej przez użytkownika wydajności
• wykorzystanie możliwości CSS3, HTML5 » gradienty, zaokrąglone rogi, @font-face zamiast obrazków, canvas, webworkers, ...
• ograniczenie użycia ciasteczek » krótsze nazwy, rozważenie użycia localStorage
• równoległe ściąganie obrazków z kilku domen (images1.foo.net, images2.foo.net, ...) - optymalnie cztery domeny
• pobieranie tylko zmieniającego się fragmentu strony (wraz z użyciem W3C History API).

Studium przypadku - www.put.poznan.pl

• PageSpeed index: 78 / YSlow: ocena B (index 87)
• 51 zapytań HTTP - 389,3 kB (z pustym cachem)
• pliki JS ładowane na górze strony (blokowanie renderowania)
• brak minifikacji plików JS i CSS
• strona ściąga 47 plików statycznych (45,5 kB) z domeny strony » użycie CDN lub domeny nocookie?
• skalowanie niezoptymalizowanych obrazków w HTMLu (łącznie 125 kB do zaoszczędzenia)
• małe obrazki powinny korzystać ze sprite'a
• kilka fragmentów zakomentowanych w HTMLu, puste elementy.

Monitorowanie rezultatów

• regularne, automatyczne pobieranie danych z Google PageSpeed API » część danych widoczna w Google Webmaster Tools
• RUM, czyli Real User Monitoring
• Google Analytics monitoruje czas ładowania strony dla 10% odsłon (SiteSpeed)
• W3C Navigation Timing - window.performance.timing
• boomerang.js - zbiera dane o czasie załadowania strony przez końcowych użytkowników, wysyła zebrane dane na serwer
• problem ze zmierzeniem jak lepsza wydajność przekłada się na ruch na stronie » zyski firmy / klienta.

Skrzynka narzędziowa

• Google PageSpeed - analiza wydajności stron wraz z sugestiami (wtyczka do Fx / Chrome + API)
• YSlow - analiza wydajności stron wraz z sugestiami + integracja z smush.it
• DOM monster - analiza złożoności HTMLa, JavaScriptu (skryptozakładka)
• phantom.js - przeglądarka z silnikiem WebKit z interfejsem w linii komend oraz API w JS
• webpagetest.org - zdalne mierzenie wydajności
  z wybranej lokacji oraz przeglądarki.

Lektura uzupełniająca

• Steve Souders, High Performance Web Sites, O'Reilly Media 2007
• Steve Souders, Even Faster Web Sites, O'Reilly Media 2009
• stevesouders.com
• 35 Best Practices for Speeding Up Your Web Site (YAHOO)
• Let's make the web faster (Google)
• Planet Performance (aggregator blogów)

Performance is a feature, it must be continuously monitored and tested.