Web Performance Optimization czyli szybsze strony WWW

WorkGate Poznań 2014, Concordia Design

Transcript

1. Web Performance Optimization czyli szybsze strony WWW WorkGate Poznań 2014, Concordia Design
2. Plan • dlaczego warto optymalizować strony WWW • historia, protokół HTTP • co optymalizować: backend vs frontend • złote reguły optymalizacji • monitoring + narzędzia • infrastruktura w Wikii.
3. Dlaczego warto optymalizować? • 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).
5. Backend • cachowanie - memcache, Redis, ... • optymalizacja zapytań i struktury bazy danych • przetwarzanie offline ◦ czy wszystkie operacje muszą odbywać się w trakcie obsługi żądania od użytkownika? ◦ message queue, crontab • mikroserwisy, SOA.
6. The Last Mile macbre@droplet-ams:~$ traceroute -T wikipedia.org traceroute to wikipedia.org (91.198.174.192), 30 hops max, 60 byte packets 1 95.85.28.254 (95.85.28.254) 0.338 ms 0.304 ms 0.360 ms 2 95.85.0.237 (95.85.0.237) 0.251 ms 7.433 ms 95.85.0.233 (95.85.0.233) 0.239 ms 3 95.85.0.249 (95.85.0.249) 31.483 ms 31.485 ms 0.265 ms 4 text-lb.esams.wikimedia.org (91.198.174.192) 1.195 ms rtt min/avg/max/mdev = 0.756/1.114/1.536/0.178 ms macbre@debian:~$ traceroute -T wikipedia.org traceroute to wikipedia.org (91.198.174.192), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.148 ms 1.342 ms * ... 6 * rt1-przybyszewskiego-vlan503.core.icpnet.pl (62.21.99.162) 7.884 ms 11.777 ms 7 rev-193.111.37.117.atman.pl (193.111.37.117) 15.757 ms 16.677 ms 15.618 ms 8 text-lb.esams.wikimedia.org (91.198.174.192) 47.485 ms 46.750 ms 47.568 ms macbre@debian:~$ ping wikipedia.org -c 50 rtt min/avg/max/mdev = 40.988/42.507/49.930/1.641 ms
7. Od serwera do klienta • Mbit/s a czas ładowania stron https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/ Mbit/s a czas wczytywania strony RTT a czas wczytywania strony RTT = Round Trip Time
8. Krótka historia HTTP • HTTP 1.1 ustandaryzowany w roku 1999 • oparty o protokół TCP/IP ◦ TCP z roku 1989 ◦ kosztowne połączenie (SYN, SYN/ACK, ACK) + negocjacja przy połączeniach HTTPS (5+ pakietów) ◦ odbiór każdego pakietu musi zostać potwierdzony.
9. Optymalizacja HTTP • każde połączenie i zapytanie do serwera kosztowne (RTT - round trip time) • każde zapytanie HTTP: ◦ nagłówki zapytania ◦ nagłówki odpowiedzi ◦ treść odpowiedzi • GET vs POST.
10. The fastest HTTP request is the one not made. ”
11. Optymalizacja HTTP Redukcja liczby zapytań i rozmiaru odpowiedzi: • połączenia: Keep-Alive • odpowiedzi: ◦ gzip / optymalizacja obrazków ◦ minifikacja ◦ ciasteczka vs local storage • zapytania: ◦ łączenie plików CSS/JS, obrazków, przekierowania
12. Cache przeglądarki • Max-Age: <na ile sekund cacheować> ◦ kolejne zapytania realizowane przez cache ◦ pliki statyczne (CSS, JS, obrazki) ◦ inwalidacja przez zmianę adresu URL: http://foo.net/v123/static/js/main.js
13. Cache przeglądarki • Last-Modified: <data> ◦ przeglądarka wysyła zapytanie z If-Modified-Since ◦ serwer odpowiada: Not-Modified lub pełna odpowiedź ◦ cache’owanie dynamicznej treści • ETag / If-None-Match • inwalidacja cache’a bywa problematyczna.
14. Backend vs frontend http://www.webpagetest.org/result/141111_B3_Z4X/1/details/
15. 80-90% of the end-user response time is spent on the frontend. Start there. ”
16. Google A.D. 1998
17. FPS A.D. 2012 https://developer.mozilla.org/en-US/demos/detail/bananabread
18. Frontend Przeglądarka jako “system operacyjny”dla serwisów WWW: • dane: local storage, Indexed DB • grafika: WebGL, animacje CSS • dostęp do lokalizacji użytkownika, mikrofonu, kamery, ...
19. Frontend 1. zmniejszenie liczby zapytań do serwera 2. optymalizacja grafiki 3. optymalizacja plików statycznych (CSS/JS) 4. optymalizacja kodu JS 5. optymalizacja kodu CSS.
20. Frontend 1. zmniejszenie liczby zapytań do serwera a. cache przeglądarki b. lazy-loading c. łączenie plików w jedno zapytanie.
21. Frontend 2. optymalizacja grafiki a. wybór formatu - JPEG czy PNG? i. progresywny JPEG b. usunięcie metadanych z plików (mozjpeg) c. prawidłowe skalowanie grafiki d. CDN / cookie-less domain e. WebP od Google’a (nawet do 50% mniejsze pliki) f. sprite’y… http://blarg.co.uk/blog/comparison-of-jpeg-lossless-compression-tools
22. Sprite: grafika lub webfont
23. Frontend 3. optymalizacja plików statycznych (CSS/JS) a. łączenie plików + GZIP - mniej zapytań, mniejsza odpowiedź b. minifikacja - usunięcie białych znaków, “kompresja” zmiennych w skryptach JS, modyfikacja styli (uglifyjs, csso) c. CDN / cookie-less domain d. zewnętrzne biblioteki + SPOF.
24. Frontend 3. optymalizacja plików statycznych (CSS/JS) d. “modułowe”, aktualne biblioteki - jQuery jQuery v1.11.1 - 94 kB (32 kB gzip) jQuery v2.1.1 - 82 kB (29 kB gzip) jQuery v2.1.1-ajax,css - 55 kB (19 kB gzip). http://projects.jga.me/jquery-builder/
25. Frontend 4. optymalizacja kodu JS a. <script> blokuje renderowanie strony i. ładowanie skryptów na dole strony lub async b. operacje na DOM są “ciężkie” c. cache’owanie selektorów jQuery d. podpinanie zdarzeń (events bubbling) e. cache’owanie z użyciem local storage.
26. Frontend 5. optymalizacja kodu CSS a. kontrola kodu generowanego przez SASS / LESS b. optymalizacja selektorów (“czytane” od prawej) c. animacje w CSS3 (transition) d. enkodowanie obrazków w base64 e. usuwanie niepotrzebnych prefixów: -webkit-, -moz- f. wykorzystanie dziedziczenia: ul vs ul li.
27. Monitoring • po stronie serwera HTTP, bazy danych, … • po stronie klienta (RUM) • testy syntetyczne • monitoring regresji - grunt-phantomas.
28. Narzędzia • curl, Firebug, Chrome Developer Tools • YSlow, Google PageSpeed, WebPagetest • konsola: ◦ grunt-yslow ◦ phantomjs (phantomas + http://yellowlab.tools/) ◦ analyze-css ◦ uglifyjs ◦ csso ◦ mozjpeg, pngout, pngoptim
29. Infrastruktura w Wikii serwis WWW w duuuużej skali
30. • 36 TB danych wysłanych do klientów ◦ 436 MB na sekundę ◦ 86% to obrazki ◦ 3% to HTML • 2.5 mld zapytań HTTP do naszego CDNa ◦ 29 000 na sekundę • 110 mln zapytań do naszych Apache’y (~4,5%) ◦ 1270 na sekundę ◦ 39 maszyn (po 256 GB RAM, 32x 3.30GHz) Dzień z życia Wikii
31. master - 4x slave 6 klastrów + shared do 5k/query na sek sharding - 12 maszyn ~40 maszyn x 32 rdzenie Główne data center Zapasowe data center read-only
32. Co dalej? • eksperymentowanie + monitoring • linki: ◦ http://stevesouders.com/ ◦ http://www.perfplanet.com/ ◦ http://calendar.perfplanet.com/ #webperf