Korzystałem z Internetu przez jeden dzień przy budżecie 50 MB
Opublikowany: 2022-03-10Ten artykuł jest częścią serii, w której staram się korzystać z sieci pod różnymi ograniczeniami, reprezentując daną grupę demograficzną użytkownika. Mam nadzieję podnieść rangę trudności, z jakimi borykają się prawdziwi ludzie, których można uniknąć, jeśli projektujemy i rozwijamy się w sposób zgodny z ich potrzebami.
Ostatnim razem nawigowałem po sieci przez jeden dzień za pomocą Internet Explorera 8. Tym razem przeglądałem sieć przez jeden dzień z budżetem 50 MB.
Dlaczego 50 MB?
Wielu z nas ma to szczęście, że korzysta z planów mobilnych, które pozwalają na przesyłanie kilku gigabajtów danych miesięcznie. W przeciwnym razie zazwyczaj jesteśmy w stanie połączyć się z domowymi lub publicznymi sieciami Wi-Fi, które są na szybkich łączach szerokopasmowych i mają praktycznie nieograniczoną ilość danych.
Są jednak części świata, w których dane mobilne są zaporowo drogie i gdzie infrastruktura szerokopasmowa jest niewielka lub nie ma jej wcale.
Ludzie często kupują pakiety danych o wielkości zaledwie kilkudziesięciu megabajtów na raz, co sprawia, że gigabajt jest stosunkowo dużą, a przez to kosztowną ilością danych do kupienia.
— Dan Howdle, analityk telekomunikacji konsumenckiej w Cable.co.uk
Jak drogo mówimy?
Koszt danych mobilnych
Badanie przeprowadzone w 2018 r. przez cable.co.uk wykazało, że Zimbabwe było najdroższym krajem na świecie dla danych mobilnych, gdzie 1 GB kosztował średnio 75,20 USD, wahając się od 12,50 USD do 138,46 USD. Ogromna rozpiętość cen wynika z tego, że mniejsze ilości danych są bardzo drogie, a tym samym stają się proporcjonalnie tańsze, im większy plan transmisji danych się zobowiążesz. Możesz przeczytać metodologię badania, aby uzyskać więcej informacji.
Zimbabwe bynajmniej nie jest jednorazowe. Gwinea Równikowa, Święta Helena i Falklandy są następne w kolejce, z 1 GB danych kosztujących odpowiednio 65,83 USD, 55,47 USD i 47,39 USD. Kraje te mają na ogół kombinację słabej infrastruktury technicznej i niskiej adaptacji, co oznacza, że dostarczanie danych jest zarówno kosztowne, jak i nie ma ekonomii skali, aby obniżyć koszty.
Dane są drogie również w niektórych częściach Europy. Gigabajt danych w Grecji oznacza zwrot 32,71 USD; w Szwajcarii, 20,22 USD. Dla porównania, ta sama ilość danych kosztuje 6,66 USD w Wielkiej Brytanii lub 12,37 USD w USA. Na drugim końcu skali Indie są najtańszym miejscem na świecie dla danych, przy średnim koszcie 0,26 USD. Kirgistan, Kazachstan i Ukraina odpowiednio 0,27, 0,49 i 0,51 USD za GB.
Szybkość sieci komórkowych również znacznie się różni w zależności od kraju. Być może zaskakujące jest to, że użytkownicy w co najmniej 30 krajach na całym świecie, w tym w Australii i Francji, doświadczają szybszych prędkości w sieci komórkowej niż Wi-Fi. Korea Południowa ma najszybszą prędkość pobierania mobilnego, wynoszącą średnio 52,4 Mb/s, ale Irak ma najwolniejszą, pobierając średnio 1,6 Mb/s i przesyłając 0,7 Mb/s. Stany Zjednoczone zajmują 40. miejsce na świecie pod względem prędkości pobierania mobilnego (około 34 Mb/s) i są zagrożone dalszym spadkiem w tyle, gdy świat zmierza w kierunku 5G.
Jeśli chodzi o typ połączenia z siecią komórkową, 84,7% połączeń użytkowników w Wielkiej Brytanii to 4G, w porównaniu do 93% w USA i 97,5% w Korei Południowej. Dla porównania, mniej niż 50% w Uzbekistanie i mniej niż 60% w Algierii, Ekwadorze, Nepalu i Iraku.
Koszt danych szerokopasmowych
Tymczasem badanie kosztów Internetu szerokopasmowego w 2018 r. pokazuje, że połączenie szerokopasmowe w Nigrze kosztuje 263 USD „za megabit miesięcznie”. Ta metryka jest trochę trudna do zrozumienia, więc oto przykład: jeśli średni koszt pakietów szerokopasmowych w kraju wynosi 22 USD, a średnia prędkość pobierania oferowana przez pakiety wynosi 10 Mb/s, wtedy koszt „za megabit miesięcznie” byłby być 2,20 USD.
To interesująca metryka, która potwierdza, że prędkość łącza szerokopasmowego jest równie ważnym czynnikiem, jak limit danych. Koszt 263 USD sugeruje połączenie niezwykle wolnego i niezwykle drogiego łącza szerokopasmowego. Dla porównania, wskaźnik wynosi 1,19 USD w Wielkiej Brytanii i 1,26 USD w USA.
Być może łatwiej jest zrozumieć średni koszt pakietu szerokopasmowego. Należy zauważyć, że badanie to szukało najtańszych pakietów szerokopasmowych w ofercie, ignorując czy te pakiety miały limit danych, czy nie, więc dostarcza użytecznej liczby, a nie kosztu danych per se.
Jeśli chodzi o sam koszt pakietu, Mauretania ma najdroższy dostęp szerokopasmowy na świecie, średnio 768,16 USD (zakres od 307,26 do 1 368,72 USD). Ten ogromny koszt obejmuje budowę fizycznych linii do nieruchomości, ponieważ niewiele już istnieje w Mauretanii. Z prędkością 0,7 Mb/s Mauretania posiada również jedną z najwolniejszych sieci szerokopasmowych na świecie.
Tajwan ma najszybsze łącze szerokopasmowe na świecie, ze średnią prędkością 85 Mb/s. Najwolniejszy jest Jemen – 0,38 Mb/s. Jednak nawet kraje z dobrze rozwiniętą infrastrukturą szerokopasmową mają tak zwane „not-spots”. Wielka Brytania zajmuje 34. miejsce na 207 krajów pod względem szybkości łącza szerokopasmowego, ale w lipcu 2019 r. w Wielkiej Brytanii nadal istniała szkoła bez łącza szerokopasmowego.
Średni koszt pakietu szerokopasmowego w Wielkiej Brytanii wynosi 39,58 USD, aw USA 67,69 USD. Najtańszą średnią na świecie jest Ukraina, wynosząca zaledwie 5 USD, chociaż najtańszą transakcję szerokopasmową ze wszystkich uzyskano w Kirgistanie (1,27 USD — w porównaniu ze średnią krajową 108,22 USD).
Zimbabwe było najbardziej kosztownym krajem dla mobilnej transmisji danych, a statystyki nie są dużo lepsze w przypadku szerokopasmowego Internetu, ze średnim kosztem 128,71 USD i kosztem „za megabit miesięcznie” wynoszącym 6,89 USD.
Koszt bezwzględny a koszt w warunkach rzeczywistych
Wszystkie przedstawione do tej pory koszty są kosztami bezwzględnymi w USD, opartymi na kursach wymiany w momencie badania. Koszty te nie zostały uwzględnione w kosztach utrzymania, co oznacza, że w wielu krajach koszt jest w rzeczywistości znacznie wyższy.
Ograniczę dziś przeglądanie do 50 MB, co w Zimbabwe kosztowałoby około 3,67 USD w taryfie komórkowej transmisji danych. To może nie wydawać się dużo, ale nauczyciele w Zimbabwe strajkowali w tym roku, ponieważ ich pensje spadły do zaledwie 2,50 dolara dziennie.
Dla porównania, 3,67 dolara to około połowa minimalnej płacy 7,25 dolara w USA. Jako mieszkaniec Zimbabwe musiałbym pracować około półtora dnia, aby zarobić pieniądze na zakup tych 50 MB danych, w porównaniu do zaledwie pół godziny w USA. Nie jest łatwo porównywać koszty życia w różnych krajach, ale biorąc pod uwagę same zarobki, koszt 50 MB danych w Zimbabwe w wysokości 3,67 USD to 52 USD dla Amerykanina za płacę minimalną.
Przygotowanie eksperymentu
Uruchomiłem Chrome i otworzyłem narzędzia deweloperskie, w których zdławiłem sieć do wolnego połączenia 3G. Chciałem zasymulować powolne połączenie, jakiego doświadczają użytkownicy w Uzbekistanie, aby zobaczyć, jakie doświadczenia dadzą mi strony internetowe. Ograniczyłem również procesor, aby symulować przebywanie na niższym urządzeniu końcowym.
Zainstalowałem ModHeader i ustawiłem nagłówek „Save-Data”, aby informować strony internetowe, że chcę zminimalizować zużycie danych. Jest to również nagłówek ustawiony przez Chrome na Androida w „trybie uproszczonym”, który omówię bardziej szczegółowo później.
Pobrałem TripMode; aplikacja dla komputerów Mac, która zapewnia kontrolę nad tym, które aplikacje na komputerze Mac mogą uzyskiwać dostęp do Internetu. Dostęp do Internetu każdej innej aplikacji jest automatycznie blokowany.
Jak daleko przewiduję, że mój budżet 50 MB zabierze mnie? Przy średniej wadze strony internetowej wynoszącej prawie 1,7 MB, sugeruje to, że w moim budżecie mam około 29 stron, choć prawdopodobnie o kilka więcej, jeśli mogę pozostać na tych samych stronach i wykorzystać pamięć podręczną przeglądarki.
W trakcie eksperymentu będę sugerować wskazówki dotyczące wydajności, aby przyspieszyć pierwsze malowanie treści i postrzegany czas ładowania strony. Niektóre z tych wskazówek mogą nie wpływać na ilość danych przesyłanych bezpośrednio , ale zazwyczaj wiążą się z odroczeniem pobierania mniej ważnych zasobów, co w przypadku wolnych połączeń może oznaczać, że zasoby nigdy nie są pobierane, a dane są zapisywane.
Eksperyment
Bez zbędnych ceregieli załadowałem google.com, używając 402 KB mojego budżetu i wydając 0,03 USD (około 1% mojego budżetu Zimbabwe).
W sumie nie jest to zły rozmiar strony, ale zastanawiałem się, skąd pochodzą te 24 żądania sieciowe i czy strona może być lżejsza.
Strona główna Google — DOM
Patrząc na znaczniki strony, nie ma zewnętrznych arkuszy stylów — cały CSS jest wbudowany.
Wskazówka dotycząca wydajności nr 1: Wbudowany krytyczny CSS
Jest to dobre dla wydajności, ponieważ oszczędza przeglądarce konieczności wykonywania dodatkowego żądania sieciowego w celu pobrania zewnętrznego arkusza stylów, dzięki czemu style można przeanalizować i zastosować natychmiast przy pierwszym malowaniu treści. Należy tu dokonać kompromisu, ponieważ zewnętrzne arkusze stylów mogą być buforowane, ale wbudowane nie (chyba że nauczysz się sprytnie posługiwać się JavaScript).
Ogólna rada jest taka, aby twoje krytyczne style (wszystko ponad krawędzią) były inline, a reszta twojej stylizacji była zewnętrzna i ładowana asynchronicznie. Asynchroniczne ładowanie CSS można osiągnąć w jednym niezwykle sprytnym wierszu HTML:
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
Narzędzia deweloperskie pokazują upiększoną wersję DOM. Jeśli chcesz zobaczyć, co zostało faktycznie pobrane do przeglądarki, przejdź do karty Źródła i znajdź dokument.
Możesz zobaczyć, że jest tutaj DUŻO wbudowanego JavaScriptu. Warto zauważyć, że został on raczej oszpecony niż tylko pomniejszony.
Porada dotycząca wydajności nr 2: Zminimalizuj i zdegraduj swoje zasoby
Minifikacja usuwa niepotrzebne spacje i znaki, ale uglifikacja w rzeczywistości „zmienia” kod, aby był krótszy. Znakiem ostrzegawczym jest to, że kod zawiera krótkie, wygenerowane maszynowo nazwy zmiennych, a nie nietknięty kod źródłowy. To dobrze, ponieważ oznacza, że skrypt jest mniejszy i szybszy do pobrania.
Mimo to skrypty wbudowane wyglądają na około 120 KB zasobu strony 210 KB (około połowa rozmiaru skompresowanego gzipem 60 KB). Ponadto istnieje pięć zewnętrznych plików JavaScript o wielkości 291 KB z pobranych 402 KB:
Oznacza to, że JavaScript stanowi około 80 procent całkowitej wagi strony.
To nie jest bezużyteczny JavaScript; Google musi je mieć, aby wyświetlać sugestie podczas pisania. Ale podejrzewam, że wiele z nich to kod śledzenia i konfiguracja reklam.
Dla porównania wyłączyłem JavaScript i przeładowałem stronę:
Wersja wyszukiwarki Google z wyłączoną obsługą JS ma tylko 102 KB, w przeciwieństwie do 402 KB. Chociaż Google nie może zapewnić autosugestii w tych warunkach, witryna nadal działa, a ja właśnie ograniczyłem zużycie danych do jednej czwartej tego, co było. Gdybym naprawdę musiał ograniczyć wykorzystanie danych w dłuższej perspektywie, jedną z pierwszych rzeczy, które zrobiłbym, jest wyłączenie JavaScript. Nie jest tak źle, jak się wydaje.
Porada dotycząca wydajności nr 3: mniej znaczy więcej
Tworzenie inline, uglifowanie i minifikowanie zasobów jest dobre i dobre, ale najlepsza wydajność wynika z nieprzesyłania zasobów w pierwszej kolejności.
- Czy przed dodaniem jakichkolwiek nowych funkcji masz ustalony budżet wydajności?
- Czy przed dodaniem kodu JavaScript do witryny można korzystać z funkcji za pomocą zwykłego kodu HTML? (Na przykład walidacja formularzy HTML5).
- Zanim wciągniesz dużą bibliotekę JavaScript lub CSS do swojej aplikacji, użyj czegoś takiego jak bundlephobia.com, aby zmierzyć, jak duża jest. Czy wygoda jest warta wagi? Czy możesz osiągnąć to samo, używając kodu waniliowego przy znacznie mniejszym rozmiarze danych?
Analiza informacji o zasobach
Jest tu dużo do rozpakowania, więc bierzmy się do roboty. Mam tylko 50 MB do zabawy, więc zamierzam wydoić każdy kawałek tej strony. Zapoznaj się z krótkim samouczkiem Chrome Devtools.
Przeniesiono 402 KB, ale 1,1 MB zasobów: co to właściwie oznacza?
Oznacza to, że faktycznie pobrano 402 KB treści, ale w postaci skompresowanej (przy użyciu algorytmu kompresji, takiego jak gzip lub brotli). Przeglądarka musiała wtedy wykonać trochę pracy, aby rozpakować ją w coś znaczącego. Całkowity rozmiar rozpakowanych danych to 1,1 MB.
To rozpakowanie nie jest bezpłatne — dekompresowanie zasobów wymaga kilku milisekund. Ale to znikome obciążenie w porównaniu do wysyłania 1,1 MB przez przewód.
Porada dotycząca wydajności nr 4: Kompresuj zasoby tekstowe
Zasadniczo zawsze kompresuj zasoby, używając czegoś takiego jak gzip. Ale nie używaj kompresji w swoich obrazach i innych plikach binarnych — powinieneś zoptymalizować je wcześniej u źródła. Kompresja może faktycznie sprawić, że staną się większe.
I, jeśli możesz, unikaj kompresji plików, które mają 1500 bajtów lub mniej. Najmniejszy rozmiar pakietu TCP to 1500 bajtów, więc kompresując do, powiedzmy, 800 bajtów, niczego nie oszczędzasz, ponieważ nadal jest przesyłany w tym samym pakiecie bajtowym. Ponownie, koszt jest znikomy, ale marnuje trochę czasu procesora na kompresję na serwerze i czas procesora na dekompresję na kliencie.
Wróćmy teraz do karty Sieć w Chrome: zagłębimy się w te priorytety. Zwróć uwagę, że zasoby mają priorytet od „Najwyższy” do „Najniższy” — są to najlepsze przypuszczenia przeglądarki dotyczące tego, które zasoby są ważniejsze do pobrania. Im wyższy priorytet, tym szybciej przeglądarka spróbuje pobrać zasób.
Porada dotycząca wydajności nr 5: Daj przeglądarce wskazówki dotyczące zasobów
Przeglądarka odgadnie, jakie są zasoby o najwyższym priorytecie, ale możesz podać wskazówkę dotyczącą zasobów, używając tagu <link rel="preload">
, instruując przeglądarkę, aby jak najszybciej pobrała zasób. Dobrym pomysłem jest wstępne wczytanie czcionek, logo i wszystkiego, co pojawia się w części strony widocznej na ekranie.
Porozmawiajmy o buforowaniu. Przytrzymam ALT i kliknę prawym przyciskiem myszy, aby zmienić nagłówki kolumn, aby odblokować bardziej soczyste informacje. Zamierzamy sprawdzić Cache-Control.
Cache-Control określa, czy zasób może być buforowany, jak długo może być buforowany i jakie zasady powinny być przestrzegane w przypadku ponownej walidacji. Ustawienie odpowiednich wartości pamięci podręcznej ma kluczowe znaczenie dla obniżenia kosztów danych przy powtórnych wizytach.
Porada dotycząca wydajności nr 6: Ustaw nagłówki kontroli pamięci podręcznej na wszystkich zasobach, które można przechowywać w pamięci podręcznej
Zauważ, że wartość cache-control zaczyna się od dyrektywy public
lub private
, po której następuje wartość wygaśnięcia (np. max-age=31536000
). Co oznacza dyrektywa i dlaczego dziwnie określona wartość max-age
?
Wartość 31536000
to liczba sekund w ciągu roku i jest teoretyczną maksymalną wartością dozwoloną przez specyfikację kontroli pamięci podręcznej. Często zdarza się, że ta wartość jest stosowana do wszystkich zasobów statycznych i faktycznie oznacza „ten zasób się nie zmieni”. W praktyce żadna przeglądarka nie będzie buforować przez cały rok, ale będzie buforować zasób tak długo, jak ma to sens.
Aby wyjaśnić dyrektywę public/private, musimy wyjaśnić dwie główne pamięci podręczne, które istnieją poza serwerem. Po pierwsze, istnieje tradycyjna pamięć podręczna przeglądarki, w której zasób jest przechowywany na komputerze użytkownika („klient”). A potem jest pamięć podręczna CDN, która znajduje się między klientem a serwerem; zasoby są buforowane na poziomie CDN, aby uniemożliwić CDN ciągłe żądanie zasobu z serwera pochodzenia.
Dyrektywa Cache-Control
public
umożliwia buforowanie zasobu zarówno po stronie klienta, jak i CDN. Wartość private
oznacza, że tylko klient może ją buforować; CDN nie powinien. Ta ostatnia wartość jest zwykle używana w przypadku stron lub zasobów, które istnieją za uwierzytelnianiem, gdzie można je buforować na kliencie, ale nie chcielibyśmy ujawniać prywatnych informacji, buforując je w CDN i dostarczając innym użytkownikom.
Jedną z rzeczy, która zwróciła moją uwagę, było to, że logo Google ma kontrolę pamięci podręcznej „prywatne”. Inne obrazy na stronie mają publiczną pamięć podręczną i nie wiem, dlaczego logo miałoby być traktowane inaczej. Jeśli macie jakieś pomysły, dajcie znać w komentarzach!
Odświeżyłem stronę i większość zasobów była obsługiwana z pamięci podręcznej, poza samą stroną, która jak już widzieliście jest private, max-age=0
, co oznacza, że nie może być zbuforowana. Jest to normalne w przypadku dynamicznych stron internetowych, gdzie ważne jest, aby użytkownik zawsze otrzymywał najnowszą stronę podczas odświeżania.
W tym momencie przypadkowo kliknąłem adres URL „Wyjaśnienia” w narzędziach do tworzenia oprogramowania, który zaprowadził mnie do odniesienia do analizy sieci, co kosztowało mnie około 5 MB mojego budżetu. Ups.
Dokumenty programistyczne Google
4,2 MB tej nowej strony o wielkości 5 MB zajęło obrazy; konkretnie SVG. Najważniejszy z nich miał 186 KB, co nie jest szczególnie duże — było ich tak wiele i wszystkie zostały pobrane jednocześnie.
Załadowanie strony o wielkości 5 MB stanowiło 10% mojego dzisiejszego budżetu. Do tej pory wykorzystałem 5,5 MB, wliczając w to przeładowanie strony głównej Google bez JavaScriptu, i wydałem 0,40 USD. Nawet nie chciałem otwierać tej strony.
Co byłoby lepsze wrażenia użytkownika tutaj?
Porada dotycząca wydajności nr 7: leniwe ładowanie obrazów
Normalnie, gdybym przypadkowo kliknął link, nacisnąłbym przycisk Wstecz w mojej przeglądarce. Pobranie tych obrazów nie przyniosłoby mi żadnych korzyści — co za strata 4,2 MB!
Poza filmami, w których na ogół wiesz, w co się pakujesz, obrazy są zdecydowanie największym winowajcą wykorzystania danych w sieci. Badanie 500 najlepszych witryn na świecie wykazało, że obrazy zajmują do 53% średniej wagi strony. „Oznacza to, że mają duży wpływ na czas ładowania strony, a następnie ogólną wydajność”.
Zamiast pobierać wszystkie obrazy podczas ładowania strony, dobrą praktyką jest leniwe ładowanie obrazów, aby tylko użytkownicy, którzy są zaangażowani w stronę, ponosili koszty ich pobrania. Użytkownicy, którzy zdecydują się nie przewijać poniżej zakładki, nie tracą więc niepotrzebnej przepustowości na pobieranie obrazów, których nigdy nie zobaczą.
Istnieje świetny przewodnik css-tricks.com dotyczący wdrażania leniwego ładowania obrazów, który zapewnia dobrą równowagę między tymi z dobrymi połączeniami, tymi ze słabymi połączeniami i tymi z wyłączonym JavaScript.
Gdyby na tej stronie zaimplementowano leniwe ładowanie zgodnie z powyższym przewodnikiem, każdy z 38 plików SVG byłby domyślnie reprezentowany przez obraz zastępczy o wielkości 1 KB i ładowany do widoku tylko podczas przewijania.
Porada dotycząca wydajności nr 8: Użyj odpowiedniego formatu dla swoich obrazów
Myślałem, że Google przegapił sztuczkę, nie używając WebP, który jest formatem obrazu, który jest o 26% mniejszy w porównaniu do PNG (bez utraty jakości) i o 25-34% mniejszy w porównaniu do plików JPEG (i porównywalnej jakości). Pomyślałem, że spróbuję przekonwertować SVG do WebP.
Konwersja do WebP obniżyła jeden z SVG ze 186 KB do zaledwie 65 KB, ale w rzeczywistości, patrząc na obrazy obok siebie, WebP wyszedł ziarnisty:
Następnie spróbowałem przekonwertować jeden z plików PNG do WebP, który powinien być bezstratny i powinien być mniejszy. Jednak dane wyjściowe WebP były *cięższe* (127 KB, z 109 KB)!
To mnie zaskoczyło. WebP niekoniecznie jest srebrną kulą, o której myślimy, a nawet Google zaniedbało jej użycie na tej stronie.
Więc moja rada brzmi: tam, gdzie to możliwe, eksperymentuj z różnymi formatami obrazu na podstawie obrazu. Format, który zapewnia najlepszą jakość przy najmniejszym rozmiarze, może nie być tym, którego oczekujesz.
Wróćmy teraz do DOM. Natknąłem się na to:
Zwróć uwagę na słowo kluczowe async
w skrypcie Google Analytics?
Pomimo tego, że jest to jedna z pierwszych rzeczy w nagłówku dokumentu, nadano temu niski priorytet, ponieważ wyraźnie zrezygnowaliśmy z bycia żądaniem blokującym za pomocą słowa kluczowego async
.
Żądanie blokujące to takie, które zatrzymuje renderowanie strony. Wywołanie <script>
domyślnie blokuje, zatrzymując parsowanie kodu HTML do momentu pobrania, skompilowania i wykonania skryptu. Dlatego tradycyjnie umieszczamy wywołania <script>
na końcu dokumentu.
Porada dotycząca wydajności nr 9: Unikaj pisania blokujących wywołań skryptów
Dodając atrybut async
do naszego tagu <script>
, informujemy przeglądarkę, aby nie przerywała renderowania strony, ale pobierała skrypt w tle. Jeśli kod HTML jest nadal analizowany do czasu pobrania skryptu, analizowanie jest wstrzymywane na czas wykonywania skryptu, a następnie wznawiane. Jest to znacznie lepsze niż blokowanie renderowania po napotkaniu <script>
.
Istnieje również atrybut defer
, który jest nieco inny. <script defer>
nakazuje przeglądarce renderowanie strony, podczas gdy skrypt ładuje się w tle, i nawet jeśli kod HTML jest nadal analizowany do czasu pobrania skryptu, skrypt musi poczekać, aż strona zostanie wyrenderowana, zanim będzie można ją wykonać . Dzięki temu skrypt jest całkowicie nieblokujący. Przeczytaj „Efektywnie ładuj JavaScript z odroczeniem i async”, aby uzyskać więcej informacji.
Tak czy inaczej, wystarczy wnikliwe Google. Czas wypróbować inną witrynę. Wciąż zostało mi prawie 45 MB z mojego budżetu!
Amazonka
Strona główna Amazona załadowana o łącznej wadze około 6 MB. Jednym z nich był obraz o wielkości 587 KB, którego nawet nie mogłem znaleźć na stronie. To był plik PNG, prawdopodobnie z wyraźnym tekstem, ale na tle fotograficznym — klasyczna kombinacja, która jest straszna dla wydajności.
W rzeczywistości na mojej karcie sieci było kilka kilkusetkilobajtowych obrazów, których nie mogłem zobaczyć na stronie. Podejrzewam błędną konfigurację gdzieś na Amazon, ale te niewidoczne obrazy razem przeżuły co najmniej 1 MB moich danych.
A co z wizerunkiem bohatera? To główny obraz na stronie, który ma tylko 94 KB przeniesionych — ale można go zmniejszyć o około 15%, gdyby został przycięty bezpośrednio wokół tekstu i piłkarzy. Moglibyśmy wtedy zastosować ten sam kolor tła w CSS, co na obrazku. Dodatkową zaletą jest możliwość zmiany rozmiaru do mniejszych ekranów przy jednoczesnym zachowaniu czytelności tekstu.
Powiedziałem to już raz i powiem to jeszcze raz: optymalizacja i leniwe ładowanie obrazów to największa korzyść, jaką możesz wnieść do wagi strony w witrynie .
Optymalizacja obrazów zapewniła jak dotąd najistotniejszą redukcję danych. Możesz sprawić, że JavaScript jest lepszym rozwiązaniem dla ogólnej wydajności, ale nie redukcji danych. Optymalizacja lub usuwanie obrazów to najbezpieczniejszy sposób na zapewnienie znacznie lżejszego środowiska i jest to podstawowa optymalizacja, na której opiera się Oszczędzanie danych.
— Tim Kadlec, Rozumienie stron Chrome Lite
Aby być uczciwym wobec Amazon, jeśli zmienię rozmiar przeglądarki do rozmiaru mobilnego i odświeżę stronę, witryna jest zoptymalizowana pod kątem urządzeń mobilnych, a całkowita waga strony wynosi tylko 2,1 MB.
Ale to prowadzi mnie do następnego punktu…
Porada dotycząca wydajności nr 10: nie rób założeń dotyczących połączeń danych
Trudno jest wykryć, czy ktoś na komputerze stacjonarnym korzysta z połączenia szerokopasmowego, czy łączy się przez klucz sprzętowy lub telefon komórkowy z ograniczeniem danych. Wiele osób pracuje w ten sposób w pociągu lub mieszka w obszarze, w którym infrastruktura szerokopasmowa jest słaba, ale sygnał sieci komórkowej jest silny. W przypadku Amazona istnieje możliwość zaoszczędzenia dużych ilości danych na stronie na komputery i nie powinniśmy popadać w samozadowolenie tylko dlatego, że rozmiar ekranu sugeruje, że nie korzystam z urządzenia mobilnego.
Tak, powinniśmy spodziewać się większego wczytywania strony, jeśli nasz widoczny obszar jest „rozmiarem komputera stacjonarnego”, ponieważ obrazy będą większe i lepiej zoptymalizowane pod kątem ekranu niż bardziej ziarniste obrazy mobilne. Ale strona nie powinna być o rząd wielkości większa.
Ponadto wraz z żądaniem wysyłałem nagłówek Save-Data
. Ten nagłówek wyraźnie wskazuje na preferencje dotyczące ograniczonego wykorzystania danych i mam nadzieję, że w przyszłości więcej stron internetowych zacznie to zauważać.
Początkowe obciążenie „pulpitu” mogło wynosić 6 MB, ale po chwili siedzenia i oglądania wspięło się do 8,6 MB, gdy do akcji wkroczyły zasoby o niższym priorytecie i śledzenie zdarzeń. Ta strona zawiera prawie 1,7 MB zminimalizowanego kodu JavaScript. Nawet nie chcę na to patrzeć .
Wskazówka dotycząca wydajności nr 11: używaj pracowników internetowych do obsługi JavaScript
Co byłoby gorsze — 1,7 MB JavaScript czy 1,7 MB obrazów? Odpowiedzią jest JavaScript: te dwa atuty nie są równoważne, jeśli chodzi o wydajność.
Obraz JPEG musi zostać zdekodowany, zrasteryzowany i pomalowany na ekranie. Paczka JavaScript musi zostać pobrana, a następnie przeanalizowana, skompilowana, wykonana — i jest wiele innych kroków, które silnik musi wykonać. Pamiętaj, że te koszty nie są do końca równoważne.
— Addy Osmani, Koszt JavaScript w 2018 roku
Jeśli musisz wysłać tak dużo kodu JavaScript, spróbuj umieścić go w robocie sieciowym. Dzięki temu większość kodu JavaScript z dala od głównego wątku, który jest teraz zwolniony do przemalowania interfejsu użytkownika, pomagając Twojej stronie internetowej pozostać responsywną na urządzeniach o niskim poborze mocy.
Mam teraz około 15,5 MB w moim budżecie i wydałem 1,14 USD z mojego budżetu Zimbabwe na dane. Musiałbym pracować przez pół dnia jako nauczyciel, żeby zarobić pieniądze, żeby zajść tak daleko.
Słyszałem dobre rzeczy o wydajności Pinteresta, więc postanowiłem go przetestować.
Być może nie jest to najuczciwszy z testów; Zostałem przeniesiony na stronę logowania, na której asynchroniczny proces wykrył, że jestem zalogowany na Facebooku i zalogował mnie automatycznie. Strona ładowała się stosunkowo szybko, ale żądania wkradły się, ponieważ coraz więcej treści było wstępnie ładowanych.
Zauważyłem jednak, że przy kolejnych załadowaniach strony pracownik serwisu odsłonił większość treści — oszczędzając około połowy wagi strony:
Witryna Pinterest to progresywna aplikacja internetowa; zainstalował pracownika usługi do ręcznego obsługi buforowania CSS i JS. Mogłem teraz wyłączyć Wi-Fi i nadal korzystać z witryny (choć niezbyt przydatne):
Porada dotycząca wydajności nr 12: Użyj pracowników serwisu, aby zapewnić wsparcie w trybie offline
Czy nie byłoby wspaniale, gdybym musiał tylko raz załadować witrynę przez sieć, a teraz uzyskać wszystkie potrzebne informacje, nawet jeśli jestem offline?
Świetnym przykładem może być strona internetowa, która pokazuje prognozę pogody na dany tydzień. Powinienem pobrać tę stronę tylko raz. Jeśli wyłączę komórkową transmisję danych, a następnie wrócę do strony w pewnym momencie, powinna ona być w stanie wyświetlić mi ostatnią znaną treść. Jeśli ponownie połączę się z Internetem i załaduję stronę, otrzymam bardziej aktualną prognozę, ale statyczne zasoby, takie jak CSS i obrazy, nadal powinny być obsługiwane lokalnie od pracownika serwisu.
Jest to możliwe dzięki skonfigurowaniu Service Workera z dobrą strategią buforowania, tak aby buforowane strony mogły być ponownie dostępne w trybie offline. Witryna z dokumentacją lodash jest dobrym przykładem pracownika serwisu na wolności:
Treści, które rzadko się aktualizują i mogą być używane dość regularnie, są idealnym kandydatem do leczenia przez pracowników usług. Dynamiczne witryny z ciągle zmieniającymi się kanałami wiadomości nie są tak dobrze przystosowane do korzystania z trybu offline, ale nadal mogą na tym skorzystać.
Pracownicy usług mogą naprawdę uratować sytuację, gdy masz napięty budżet danych. Nie jestem przekonany, że korzystanie z Pinteresta było najbardziej optymalne pod względem wykorzystania danych — kolejne strony miały około 0,5 MB, nawet na stronach z niewielką liczbą obrazów — ale pozwalał, aby JavaScript obsługiwał żądania stron za Ciebie i utrzymywał te same elementy nawigacyjne na miejscu może być bardzo wydajny. BBC zarządza rozmiarem transferu wynoszącym zaledwie 3,1 KB dla powrotnych wizyt do artykułów, które można renderować za pomocą aplikacji jednostronicowej.
Do tej pory sam Pinterest przeżuł 14 MB, co oznacza, że straciłem około 30 MB mojego budżetu, czyli 2,20 USD (prawie dzienne wynagrodzenie) mojego budżetu Zimbabwe.
Lepiej uważam na ostatnie 20 MB… ale gdzie w tym zabawa?
Gamespot
Wybrałem ten, ponieważ w przeszłości wydawał się zauważalnie powolny na moim telefonie komórkowym i chciałem dowiedzieć się, dlaczego. Rzeczywiście, wczytanie strony głównej zużywa 8,5 MB danych.
6,5 MB z tego sprowadzało się do automatycznie odtwarzanego wideo w połowie strony, które – żeby być uczciwym – nie wydawało się pobierać, dopóki nie zacząłem przewijać. Niemniej jednak…
Widziałem tylko połowę wideo w moim oknie widzenia — prawa strona została przycięta. Trwało też 30 sekund i założę się, że większość ludzi nie usiądzie i nie będzie oglądać całości. Ten pojedynczy zasób zwiększył ponad trzykrotnie rozmiar strony.
Porada dotycząca wydajności nr 13: Nie ładuj wideo z wyprzedzeniem
Z reguły nie ładuj jej wstępnie, chyba że głównym sposobem komunikacji w Twojej witrynie jest wideo.
Jeśli korzystasz z YouTube lub Netflix, rozsądnie jest założyć, że ktoś odwiedzający Twoją stronę będzie chciał, aby film automatycznie ładował się i odtwarzał. Oczekuje się, że film przegryzie pewne dane, ale jest to uczciwa wymiana treści. Ale jeśli prowadzisz witrynę, której głównym nośnikiem jest tekst i obraz — a akurat oferujesz dodatkowe treści wideo — nie ładuj wideo.
Pomyśl o artykułach z wiadomościami z osadzonymi filmami. Wielu użytkowników chce tylko przejrzeć nagłówek artykułu, zanim przejdzie do następnej rzeczy. Inni przeczytają artykuł, ale zignorują wszelkie osadzania. A inni będą pilnie klikać i oglądać każdy osadzony film. Nie powinniśmy ograniczać przepustowości każdego użytkownika, zakładając , że będzie chciał oglądać te filmy.
Powtarzając: użytkownicy nie lubią autoodtwarzania wideo. Jako programiści robimy to tylko dlatego, że każą nam nasi menedżerowie, a każą nam to robić tylko dlatego, że robią to wszystkie najfajniejsze aplikacje, a najfajniejsze aplikacje robią to tylko dlatego, że reklamy wideo generują 20 do 50 razy większe przychody niż tradycyjne reklamy. Przeglądarka Google Chrome zaczęła blokować autoodtwarzanie wideo w niektórych witrynach na podstawie osobistych preferencji, więc nawet jeśli opracujesz swoją witrynę pod kątem automatycznego odtwarzania wideo, nie ma gwarancji, że użytkownicy będą tak zadowoleni.
Jeśli zgodzimy się, że dobrym pomysłem jest udostępnienie filmu wideo (kliknij, aby odtworzyć), możemy pójść o krok dalej i sprawić, by kliknął, aby załadować. Oznacza to wyśmiewanie obrazu zastępczego wideo z przyciskiem odtwarzania nad nim i pobieranie wideo tylko po kliknięciu przycisku odtwarzania. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.
Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.
What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.
The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.
Otóż to. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.
Performance Tip #14: Optimize For First Page Load
What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.
Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.
With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.
Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.
Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.
The Decline Of Proxy Browsers
I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.
Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.
It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:
It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.
Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.
Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.
Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.
I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.
Tryb uproszczony udostępnia Google adres URL HTTPS, dlatego ma sens, że ten tryb nie jest dostępny w trybie incognito. Jednak inne informacje, takie jak pliki cookie, dane logowania i spersonalizowana zawartość strony, nie są udostępniane Google — według ghacks.net — i „nigdy nie przerywają bezpiecznych połączeń między Chrome a witryną”. Można się zastanawiać, dlaczego pozornie żadna z tych usług oszczędzania danych nie jest dozwolona w systemie iOS (i nie ma żadnych wiadomości, czy tryb Lite będzie kiedykolwiek dostępny w systemie iOS).
Serwery proxy oszczędzające dane wymagają dużego zaufania; Twoja aktywność przeglądania, pliki cookie i inne poufne informacje są powierzane jednemu serwerowi, często w innym kraju. Wiele serwerów proxy po prostu nie będzie już działać, ponieważ wiele witryn przeszło na HTTPS, co oznacza, że inicjatywy takie jak tryb Turbo stały się w dużej mierze „bezużyteczną funkcją”. HTTPS zapobiega tego rodzaju zachowaniom typu „man-in-the-middle”, co jest dobrą rzeczą, chociaż oznacza upadek niektórych z tych usług proxy i sprawił, że witryny są mniej dostępne dla osób ze słabymi połączeniami.
Nie mogłem znaleźć żadnego narzędzia do oszczędzania danych kompatybilnego z OSX lub iOS, z wyjątkiem Bandwidth Hero for Firefox (co wymaga skonfigurowania własnej usługi kompresji danych — znacznie przekraczającej możliwości techniczne większości użytkowników!) i skyZIP Proxy (którego ostatnia aktualizacja w 2017 i pełen literówek, po prostu nie mogłem się zmusić do zaufania).
Wniosek
Zmniejszenie śladu danych Twojej witryny idzie w parze z poprawą wydajności frontendu. Jest to najbardziej niezawodna rzecz, jaką możesz zrobić, aby przyspieszyć działanie witryny.
Oprócz kosztów danych istnieje wiele dobrych powodów, aby skupić się na wydajności, jak opisano w poście na blogu GOV.UK na ten temat:
- 53% użytkowników opuści witrynę mobilną, jeśli jej wczytanie zajmie więcej niż 3 sekundy.
- Ludzie muszą skoncentrować się o 50% bardziej, gdy próbują wykonać proste zadanie na stronie internetowej przy użyciu wolnego połączenia.
- Wydajniejsze strony internetowe wydłużają czas pracy baterii urządzenia użytkownika i zazwyczaj wymagają mniej energii na serwerze. Wydajna witryna jest dobra dla środowiska.
Nie jesteśmy w stanie zmienić globalnego kosztu nierówności danych. Ale mamy moc, aby zmniejszyć jego wpływ, poprawiając wrażenia dla wszystkich w tym procesie.