Identyfikowanie zasobów wczytywanych z sieci

Panel Network (Sieć) w Narzędziach deweloperskich w przeglądarce pomaga określić, które zasoby są wczytywane i kiedy. Każdy wiersz w panelu Sieć odpowiada konkretnemu adresowi URL wczytanemu przez Twoją aplikację internetową.

Panel sieci w Chrome DevTools.

Sprawdzaj, co wczytujesz

Aby wypracować właściwe strategie buforowania aplikacji internetowej, musisz wiedzieć, co dokładnie wczytujesz. Podczas tworzenia niezawodnej aplikacji internetowej sieć może podlegać działaniom mrocznym. Musisz zrozumieć luki w zabezpieczeniach sieci, aby sobie z nimi radzić w aplikacji.

Może Ci się wydawać, że już wiesz, jak wczytuje się Twoja aplikacja internetowa. Może to być prawda, jeśli używasz niewielkiego rozproszenia w postaci statycznego kodu HTML, JavaScript, CSS i plików graficznych. Jednak gdy tylko zaczniesz mieszać zasoby firm zewnętrznych hostowanych w sieciach dostarczania treści i używać dynamicznych żądań interfejsu API oraz odpowiedzi generowanych przez serwer, obraz szybko staje się bardziej mroczny.

Strategia buforowania, która ma sens w przypadku kilku małych plików CSS, prawdopodobnie nie sprawdzi się na przykład w przypadku setek dużych obrazów.

Wiedz, kiedy się wczytuje

Kolejnym elementem ogólnego obrazu wczytywania jest to, kiedy wszystko jest wczytywane.

Niektóre żądania wysyłane do sieci, np. żądanie nawigacji w początkowym kodzie HTML, są wysyłane bezwarunkowo, gdy tylko użytkownik wejdzie na dany adres URL. Kod HTML może zawierać zakodowane na stałe odniesienia do krytycznych plików CSS lub JavaScript, które również muszą się wczytać, aby wyświetlić interaktywną stronę. Wszystkie te żądania znajdują się w krytycznej ścieżce wczytywania. Musisz je agresywnie zapisywać w pamięci podręcznej, aby działały szybko.

Inne zasoby, takie jak żądania do interfejsu API lub zasoby leniwie ładujące, mogą zacząć się ładować dopiero po zakończeniu wstępnego wczytywania. Jeśli żądania te następują tylko po określonej sekwencji interakcji użytkownika, w ramach kilku wizyt na tej samej stronie może zostać wysłany żądanie zupełnie innego zbioru zasobów. Mniej agresywna strategia buforowania jest często odpowiednia w przypadku treści, które zostały uznane za znajdujące się poza krytyczną ścieżką wczytywania.

Kolumny Nazwa i Typ pomagają określić,

Kolumny Nazwa i Typ zapewniają zrozumiały obraz tego, co jest wczytywane. Odpowiedź na pytanie „co się wczytuje?” w tym przykładzie to łącznie 4 adresy URL, z których każdy reprezentuje unikalny typ treści.

Panel sieci w Chrome DevTools pokazujący 4 wczytywane pliki.

Nazwa odpowiada adresowi URL, którego zażądała Twoja przeglądarka – widoczna będzie jednak tylko ostatnia część ścieżki adresu URL. Jeśli np. załaduje się strona https://example.com/main.css, w kolumnie Nazwa pojawi się tylko wartość main.css.

Kilka ostatnich znaków ścieżki adresu URL, następujących po kropce (np. „css”), to tzw. rozszerzenie adresu URL. Rozszerzenie adresu URL informuje ogólnie o typie zasobu, którego dotyczy żądanie, i odwzorowuje bezpośrednio na informacje wyświetlane w kolumnie Typ. Na przykład v2.html jest dokumentem, a main.css jest arkuszem stylów.

Kolumna Kaskada pomaga określić,

Przyjrzyj się kolumnie Wodospad, zaczynając od góry i schodząc w dół. Długość każdego słupka odzwierciedla łączny czas wczytywania poszczególnych zasobów. Jak mogę odróżnić żądanie wysłane w ramach krytycznej ścieżki wczytywania, a żądanie uruchamiane dynamicznie po zakończeniu wstępnego wczytywania strony?

Pierwsze żądanie w kaskadzie będzie zawsze dotyczyło dokumentu HTML, np. v2.html. Kolejne żądania będą przesyłane po tym początkowym żądaniu nawigacyjnym (jak wodospad!) w zależności od tego, do jakich obrazów, skryptów i stylów odwołuje się dokument HTML.

Widok kaskadowy Narzędzi deweloperskich w Chrome.

Kaskada pokazuje, że gdy tylko zakończy się wczytywanie obiektu v2.html, rozpoczną się żądania dotyczące zasobów, do których się odwołuje (nazywanych zasobami podrzędnymi). Przeglądarka może wysyłać żądania dotyczące wielu zasobów podrzędnych jednocześnie. Reprezentują to nakładające się słupki w kolumnie Kaskada dla main.css i logo.svg. Jak widać na zrzucie ekranu, strona main.js zaczyna ładować się jako ostatnia i kończy się po zakończeniu ładowania dla pozostałych 3 adresów URL.