W poprzedniej części cyklu bardzo szybko omówiliśmy, jak wygląda pobieranie zasobów wchodzących w skład strony internetowej. W tym odcinku wejdziemy trochę głębiej w tematykę http request i omówimy związane z tym zagadnienia.
Jak już wcześniej wspominałem, Internet – a konkretniej mówiąc strony internetowe – opiera swoje działanie na protokole http. Każdy zasób niezbędny do wyświetlenia strony internetowej jest pobierany z jakiegoś zakątka Internetu wprost na nasze komputery za pomocą tegoż protokołu.
Chrome DevTools
Na potrzeby tego cyklu będę korzystał z Chrome DevTools, standardowo załączanego do przeglądarki internetowej Google Chrome.
Aby powiększyć, kliknij w obraz
Przeglądając dowolną stronę internetową, po naciśnięciu przycisku F12 naszym oczom ukazuje się panel, który służy pomocą w pisaniu stron internetowych. Podczas pierwszego uruchomienia domyślnie włączony jest widok struktury dokumentu HTML, który, jak to zostało wcześniej powiedziane, spina w jedną całość wszystkie niezbędne do wyświetlenia strony informacje.
Nie jest to jednak kurs pisania stron internetowych, dlatego nie będziemy się aż tak skupiać na znaczeniu ciągu znaków widocznych na ekranie. Nas interesuje zakładka Network.
Aby powiększyć, kliknij w obraz
Podstawowe informacje o wydajności strony
Ta zakładka w czytelny sposób za pomocą kolorów wizualizuje nam proces pobierania każdego zasobu wchodzącego w skład strony internetowej. U dołu strony, na pasku stanu, znajdują się podstawowe informacje o wydajności strony, które najbardziej nas interesują. A są to:
• Liczba określająca ilość http request.
• Łączny rozmiar wszystkich zasobów pobieranych na potrzeby wyświetlenia danej strony internetowej.
• Finish, czyli czas, jaki upłynął od żądania strony internetowej do pełnego załadowania strony internetowej.
• DOMContentLoaded – czas, jaki upłynął od żądania wyświetlenia strony internetowej po jej kompletne przetworzenie, bez czekania na zasoby blokujące renderowanie strony typu: arkusze stylów czy skrypty strony.
• Load, czyli czas, jaki upłynął od żądania pobrania strony internetowej do pełnego załadowania wszystkich plików i ich zależności od pamięci podręcznej przeglądarki.
W kontekście wydajnościowym, naszym celem jest utrzymanie wszystkich tych liczb jak najmniejszych.
Trochę więcej szczegółów
Drugim obszarem, jaki możemy obserwować – i tak naprawdę tylko obserwować, bo wpływ na parametry mamy bardzo ograniczony – jest wykres zajętości czasowej, jakiej potrzebują poszczególne etapy http request, aby się w pełni wykonać.
Aby powiększyć, kliknij w obraz
Powyższe etapy dzielą się na:
• Queueing – czas oczekiwania na wolne połączenie TCP (Transmission Control Protocol). Różne przeglądarki pozwalają na pobieranie równocześnie do 8 plików (tworzą 8 połączeń TCP) na serwer. W przypadku Chrome jest to tylko 6 połączeń. Jeżeli pobieramy rozbudowaną stronę, na pewno część zasobów będzie oczekiwała na swój przydział połączenia.
• Stalled – zasób otrzymał swoje własne połączenie TCP. Teraz następuje faza przygotowania tego połączenia, w przypadku kiedy jest możliwość jego ponownego użycia (połączenia do tej samej domeny) lub konfiguracji nowego połączenia.
• DNS lookup – w tej fazie zasób znajdujący się na danym serwerze w przyjaznej formie (np. www.google.com/plik.jpg) zostaje zamieniony na adres IP niezbędny do dalszej komunikacji. Przeglądarka odpytuje serwer DNS, jaki jest numer IP serwera pod nazwą domenową www.google.com i otrzymuje adres IP, na który wysyłane zostanie żądanie przesłania pliku.
• Initial connection – następuje “połączenie” z serwerem. W tej fazie oczekujemy na ustalenie zasad połączenia z serwerem oraz, jeśli korzystamy z HTTPS, inicjujemy SSL handshake – przeglądarka i komputer docelowy, na którym znajdują się zasoby dogadują się jak ustalić pomiędzy nimi bezpiecznie połączenie.
• SSL – w tej fazie czekamy, aż wszystkie ustalenia związane z SSL zostaną zakończone. To tutaj przeglądarka wysyła do serwera klucze autoryzujące, serwer je zwraca i tworzony jest swoisty tunel pomiędzy klientem a serwerem, przez który przesyłane będą dane.
• Request send – przeglądarka wysyła specjalnie skonstruowane żądanie konkretnego pliku do serwera i zaczyna oczekiwać na informację zwrotną.
• Waiting (TTFB) – (ang. Time To First Byte – czas na pierwszy bajt) po wysłaniu żądania trwa oczekiwanie, aż z serwera zostanie przesłana pierwsza porcja pakietów zawierająca informację o pliku. W tym czasie po stronie serwera następuje przeszukanie jego zawartości w poszukiwaniu pliku i przygotowanie go do wysyłki. Jeżeli jest to plik skryptowy, następuje jego przetworzenie przez serwer.
• Content Download – ostatni etap, czyli czas niezbędny do pobrania całego zasobu z serwera.
Podsumowanie
Uff. Jak widać przeglądarka musi się nagimnastykować, aby skompletować wszystkie niezbędne zasoby. W przypadku kiedy strona składa się, dajmy na to, ze 100 elementów, wszystkie te operacje muszą zostać wykonane 100 razy.
W rzeczywistości przeglądarka stara się optymalizować swoją pracę i w ten sposób raz odpytany o adres IP serwer DNS nie jest ponownie zmuszany do przesłania tej informacji, o ile zasoby są dostępne z tego samego serwera. Kiedy połączenie już raz ustali reguły SSL, kolejne połączenia odbywają się na tych samych zasadach. Jednak nie ma sytuacji idealnych. Jeżeli na tym etapie nie zadba się o porządek i odpowiedni podział zasobów pomiędzy serwerami, można stracić wszystkie korzyści, jakie oferują wbudowane w przeglądarkę optymalizacje.
W następnym wpisie cyklu poruszymy temat cachowania zasobów przez przeglądarkę. Na szczęście nie jesteśmy zmuszeni do tego, by za każdym razem, gdy odwiedzamy tę samą stronę internetową, pobierać wszystkie jej zasoby na nowo. Istnieją techniki pozwalające w mądry sposób zorganizować je tak, by nadawały się do ponownego wykorzystania.
