Szybkość początkowego ładowania witryny lub aplikacji to pierwsze wrażenie, jakie odbierają użytkownicy. W tym przewodniku wymienimy sprawdzone techniki pozwalające zaoszczędzić cenne sekundy podczas początkowego ładowania strony.
Spis treści:
Początkowy czas ładowania
Czas, jaki upływa od wprowadzenia przez użytkownika lub klienta nazwy domeny Twojej witryny do wyświetlenia treści, to kilka najważniejszych sekund, których potrzebujesz, aby zrobić dobre pierwsze wrażenie.
Amazon odkrył, że każde 100 milisekund opóźnienia kosztuje ich 1% sprzedaży.
A jednak wielu twórców stron internetowych traktuje to jako refleksję. Dodawanych jest coraz więcej bibliotek dla coraz większej liczby funkcji i stopniowo z czasem zaczynają one uzyskiwać mniej konwersji. Co gorsza, te straty w konwersji są trudne do wykrycia, ponieważ porzucają wolno ładującą się stronę, zanim zdąży ona wysłać jakiekolwiek dane.
Niektóre z nich to techniki, które można zaimplementować na froncie, a inne na zapleczu. Niezależnie od tego aplikacje internetowe muszą ładować się szybko.
Dodaj właściwe pomiary
Pierwszą rzeczą, którą musisz zrobić, to dodać pomiary. Istnieje wiele etapów procesu załadunku i nie będziesz wiedział, gdzie jest wąskie gardło bez pomiaru odpowiednich segmentów.
Oto najważniejsze kamienie milowe procesu ładowania:
Pomiary | Diagram utworzony w dniu Terrastruktura
Oznacza to, że powinieneś śledzić metryki dla każdego segmentu tego diagramu.
Przyjrzyjmy się, jak możesz to zrobić.
Żądanie przeglądarki do odpowiedzi obsłużone:
Zmierz to na swoim serwerze. Chcesz uzyskać moment, w którym interfejs API otrzymuje żądanie, kiedy obsługuje odpowiedź. W zależności od tego, czy wykonywane są połączenia zewnętrzne, na przykład do baz danych, może to być bardzo krótkie lub znaczące wąskie gardło.
Odpowiedź udzielona na otrzymaną odpowiedź:
Jest to trudniejsze do zmierzenia, ale jednym ze sposobów na to jest dodanie sygnatury czasowej, gdy twoja odpowiedź opuszcza serwer i zmierzenie tego z bieżącym czasem po stronie użytkownika w pierwszej możliwej chwili (znacznik skryptu w nagłówku kodu HTML strona).
Otrzymano odpowiedź na pierwszą zadowalającą farbę:
Pierwsze malowanie treści odnosi się do renderowania pierwszego elementu w DOM. Może to być coś tak prostego, jak jakiś tekst, tło lub ładujący się spinner. Można to zmierzyć, uruchamiając Lighthouse w narzędziach deweloperskich Chrome.
Pierwsza pełna treści farba do największej treściwej farby:
Największe malowanie zawartości odnosi się do renderowania największego elementu w widocznym obszarze przeglądarki użytkownika. Zazwyczaj sygnalizuje to koniec części „renderowania” wczytywania strony, a użytkownik widzi wypełniony ekran. Jest to również mierzone przez uruchomienie Lighthouse.
Największa treściwa farba do czasu interaktywnego:
Wreszcie, czas przejścia do trybu interaktywnego odnosi się do tego, kiedy użytkownik może wykonywać czynności, takie jak przewijanie, klikanie i pisanie. Może to być szczególnie frustrujące, jeśli ten czas trwania jest długi, ponieważ zobaczą przed sobą wyrenderowany ekran, ale nie będą mogli nic zrobić, chociaż spodziewają się, że będą w stanie to zrobić! To kolejna miara, którą Lighthouse pomaga nam mierzyć.
Zmniejsz kod
Teraz, gdy masz już pomiary, możesz przystąpić do optymalizacji. Optymalizacje wymagają kompromisów, a pomiary pokażą, które z nich są tego warte.
Najszybciej ładuje się pusta strona, ale do aplikacji można dodać dużo kodu, zanim ktokolwiek zauważy różnicę w szybkości ładowania między nią a pustą stroną. Często zdarza się, że przyrosty są tak małe, że nie dostrzegasz różnicy między kompilacjami, aż pewnego dnia po prostu zaczyna wydawać się powolna. Zdajesz sobie sprawę, że Twoja aplikacja jest rozdęta i właśnie w tym momencie zmniejszenie kodu będzie miało znaczenie.
Zmniejszając kod, uzyskujesz dwie ulepszenia szybkości:
- Twoja aplikacja jest szybciej przesyłana przez sieć.
- Przeglądarka użytkownika kończy analizowanie kodu szybciej.
Pierwsze przyspieszenie jest niewielkie; ponieważ żądania są kompresowane przez sieć, jeśli usuniesz 1 MB kodu źródłowego, może to oznaczać tylko 10 KB oszczędności na przepustowości. Jednak przyspieszenie wynikające z mniejszej analizy jest znaczące. Twoi użytkownicy prawdopodobnie korzystają z Twojej aplikacji w całym spektrum przeglądarek i komputerów, z których wielu nie ma mocy obliczeniowej, która mogłaby przeanalizować kod tak szybko, jak robi to samodzielnie.
Mogą też działać na urządzeniach mobilnych z jeszcze mniejszą mocą obliczeniową. Różnica może dotyczyć wielkości sekund.
Im mniej masz kodu, tym szybciej przeglądarka może zakończyć analizowanie i uruchomić aplikację. Nawet jeśli chcesz pokazać ekran ładowania, który kontroluje Javascript, poprzedziło to parsowanie tego kodu.
Ale nie chcesz wycinać funkcji ani usuwać kodu. Na szczęście istnieje kilka standardowych praktyk pozwalających na zmniejszenie kodu bez konieczności robienia tego.
- Przeprowadź swój kod przez minifikatory. Minifiery wykonują optymalizacje, takie jak skracanie długich nazw do krótkich (signUpDarkModeButton staje się ss), usuwanie białych znaków i inne, aby Twój kod był jak najbardziej zwarty bez utraty czegokolwiek.
- Importuj części. Biblioteki są często przepełnione rzeczami, których nie potrzebujesz, ale są spakowane razem pod jednym pakietem. Być może potrzebujesz tylko określonej funkcji biblioteki narzędziowej, więc zamiast importować całą bibliotekę, możesz zaimportować tylko potrzebny kod.
- Kod martwy, który wstrząsa drzewem. Czasami pozostawiasz kod do celów debugowania lub nie wyczyściłeś dokładnie przestarzałej funkcji i chociaż jest ona w kodzie źródłowym, nigdy nie jest uruchamiana. W łańcuchu narzędzi JavaScript znajdują się narzędzia, takie jak Webpack, które mogą wykrywać martwy kod lub nieużywane zależności i automatycznie usuwać je z kompilacji produkcyjnej.
Podziel kod na fragmenty
Po zmniejszeniu jak największej ilości kodu z całej aplikacji możesz pomyśleć o dalszym wyciśnięciu tego pomysłu i zmniejszeniu kodu potrzebnego do początkowego ładowania.
Załóżmy, że 20% Twojego kodu obsługuje niektóre funkcje Twojej aplikacji, do których użytkownicy mogą uzyskać dostęp dopiero po kilku kliknięciach. Analiza tego kodu przed wyświetleniem ekranu ładowania byłaby stratą czasu. Podział kodu na części może znacznie skrócić czas interakcji.
Zamiast mieć przeplatający się wykres zależności importu dla wszystkich plików JavaScript, zidentyfikuj obszary, które można łatwo wyciąć. Na przykład może komponent ładuje jakieś ciężkie biblioteki. Możesz wyodrębnić ten komponent do osobnego pliku, a następnie zaimportować tylko wtedy, gdy użytkownik jest gotowy do interakcji z tym komponentem.
Istnieje kilka bibliotek umożliwiających odroczenie ładowania, w zależności od używanego frameworka. Nie ma potrzeby przesadzać z tym i rozdzielać każdy komponent, ponieważ wtedy użytkownik ma szybkie początkowe ładowanie i musi czekać na każdą kolejną interakcję. Znajdź największe fragmenty, które możesz podzielić, i podziel tam swój kod źródłowy.
Renderowanie po stronie serwera
Biorąc pod uwagę, że przeglądarki muszą wykonywać tak intensywne analizowanie i kompilowanie, a użytkownicy korzystają z Chromebooków i urządzeń mobilnych, jedną z powszechnych technik skracania czasu ładowania jest przeniesienie części tego obciążenia na serwery. Oznacza to, że zamiast dawać pustą stronę, a następnie używać Javascript do wypełnienia całej treści, jak robi to obecnie większość aplikacji jednostronicowych, możesz uruchomić silnik JavaScript na swoim serwerze (zwykle Node.js) i wypełnić jak najwięcej danych i treści.
Twoje serwery będą znacznie szybsze i przewidywalne niż przeglądarki użytkowników. Nieuchronnie nadal będą musieli przeanalizować kod JavaScript, aby aplikacja była interaktywna. Mimo to renderowanie po stronie serwera może wypełnić znaczną część początkowej zawartości, tak że gdy użytkownik otrzyma stronę, będzie ona już wyświetlać co najmniej ekran ładowania lub pasek postępu.
A jeśli dane są potrzebne do wstępnego widoku, klient nie musi składać osobnego żądania, aby je uzyskać; będzie już uwodniony w aplikacji, z której klient będzie mógł korzystać.
Kompresuj zasoby
Zasoby ożywiają stronę, a strona nie wydaje się w pełni załadowana, dopóki te zasoby nie zakończą renderowania. Może to być Twoje tło, ikony interfejsu użytkownika, zdjęcie profilowe użytkownika, a nawet ikona ładowania. Często zasoby mogą również zmieniać układ, więc jeśli użytkownik zacznie z czymś wchodzić w interakcję, strona może nadal przeskakiwać podczas ładowania zasobów. Czasami te zasoby są największą zawartością.
Ale zasoby są również jedną z najcięższych części aplikacji. Obraz może mieć kilka megabajtów, a ładowanie wielu ikon może z łatwością przekroczyć maksymalny limit jednoczesnych żądań sieciowych przeglądarki, powodując oszałamiającą kolejkę ładowania.
Prawie nigdy nie chcesz pobierać obrazu z Internetu, a następnie odwoływać się do niego w swojej aplikacji. Obrazy powinny być przeskalowane do możliwie najmniejszych rozmiarów, w jakich będą wyświetlane. Jeśli masz profil użytkownika wyświetlany w małym elemencie o wymiarach 50 na 50 pikseli, bez zmiany rozmiaru, aplikacja zajmie trochę czasu, aby pobrać pełny obraz, który wygląda ostro jak tapeta na pulpicie, a następnie zmniejszy go do małego rozmiaru.
Po drugie, obrazy można kompresować w zależności od ich formatu. Obecnie preferowanym formatem jest webm, ale dziedzina kompresji w sieci jest stale ulepszana, a na horyzoncie pojawia się wiele nowych formatów. Ze względu na zmieniający się charakter formatów niektóre przeglądarki mogą nie obsługiwać nowszych! Na szczęście technologia przeglądarek pozwala przeglądarce użytkownika na ładowanie dowolnego obsługiwanego formatu.
Więc skompresuj do najnowszego i najlepszego formatu, ale zachowaj też mniej nowoczesną wersję i użyj elementów obrazu i wideo, które obsługują formaty wsteczne.
Wniosek
Oto pięć najskuteczniejszych technik zapewniających użytkownikom niezwykle szybkie pierwsze ładowanie aplikacji. Poprawią one współczynniki konwersji, zadowolenie użytkowników, a nawet rankingi wyszukiwania, ponieważ SEO nagradza szybkie czasy ładowania. Na Terrastrukturastosujemy te i inne techniki, aby użytkownicy mogli tworzyć i wyświetlać diagramy, które widzisz w tym artykule, tak szybko, jak to możliwe.