Optymalizacja wielkości strony

Ogólna zasada:
Im mniej jest do pobrania tym szybciej.
Im mniej trzeba czekać, tym szybciej.

Naturalnie pobranie 0.6 MB  zajmuje mniej niż pobranie 5 MB.
Tylko od czego to zależy?


Na wielkość strony składają się:

  • obrazki, 
  • skrypty (JavaScript)
  • style (CSS)
  • inne zasoby (np. czcionki, dźwięki, ..)

Redukcja wielkości obrazów

Kompresja bezstratna

Niektóre zasoby możesz zmniejszyć bez zmiany ich wygladu.

 

Redukcja wymiarów

Jeśli obrazki mogą być mniejsze pod względem rozdzielczości to je zmniejsz (zmniejsz wielkość - rozdzielczość - rozmiar).
Widziałem przypadki użycia pełnowymiarowych zdjęć ważących kilka megabajtów (np. z lustrzanki) na stornach.
To znaczy przeglądarka musi pobrać kilka megabajtów by móc pokazać zdjęcie (zamiast kilkuset kilobajtów) - nawet 10x wolniej.
Zdjęcia muszą być albo zmniejszone ręcznie (przed wgraniem), albo CMS musi automatycznie je pomniejszać!

Na marginesie:
Duże zdjęcia to lepsza jakość, ale i dłuższy czas ładowania (więcej trzeba pobrać).
Jeśli przegladasz stronę na małym urządzeniu - z pewnością nie zauważysz różnic między dużym obrazkiem a małym.
W takich sytuacjach istnieje możliwość podania kilku wersji obrazka, w taki sposób by przeglądarka podjęła decyzję który będzie najlepszy (by niepotrzebnie nie pobierać zbyt dużego).
Do tegło służy np. atrybut 'srcset'.

Reklama

Kompresja

Obrazki można przekompresować wybierając niższą jakość (nie przesadzaj z jakością).


Istnieje możliwość redukcji wielkość obrazów, bez zmiany ich jakości.
W tym celu można skorzystać np. z:

  • jpegoptim (pliki jpg),
  • optipng (pliki png),
  • gifsicle (pliki gif istnieją lepsze formaty),
  • svgo (pliki svg)
  • itd.
     

Gdy pliki zostały już zapisane na serwerze prawdopodobnie można uruchomić skrypt który je zmneijszy automatycznie.

Redukcja wielkości skryptów (JS), stylów (CSS)

Ładnie sformatowany skrypt jQuery zajmuje 268 kB (po lewej).
Ten sam kod po minifikacji zajmuje 86.7 kB (po prawej).

Komputer nie potrzebuje, ładnie sformatowanego tekstu w celu jego interpretacji.

Dlatego skrypty poddaje się tak zwanej minifikacji.
Jest to proces polegający na m.in usunięciu wszelkich niepotrzebnych informacji (np. usuwane są spacje, nowe linie, komentarze, ..). Bardziej zaawansowane minifikatory modyfikują kod, tak by zajmował mniej. w powyższym przykładzie:

"function( global, factory )" -> zostało zamienione na "function(a,b)" (minifikatory potrafią zmieniać nazwy zmiennych, tak by zajmowały mniej i wiele więcej).

Kompresja 'w locie' (serwer)

By zredukować ilość przesyłanych danych, można kompresować każdy przesyłany plik.
Serwer spakuje plik, a przeglądarka użytkownika rozpakuje.

Wystarczy włączyć kompresję gzip na serwerze!
W przypadku serwera NGNIX* jest to kwestia dodania jednej linijki przez administratora.

*NGNIX nazwa własna jednego z najpopularniejszych serwerów WWW.
W przypadku Apache (inny bardzo popularny serwer WWW)  prawdopodobnie jest podobnie.

 

Stanowi to nieduże dodatkowe obciążenie serwera, w zamian za duże korzyści!

Reklama

Redukcja ilości plików

Zanim strona znajdzie się na twoim komputerze.
Twój komputer musi porozmawiać z serwerem.

Komunikacja z przeglądarki z serwerem przypomina pisanie SMS.

Przypomina to trochę SMSowanie.

Ty: Cześć, możesz rozmawiać?

(wysłałeś zapytanie, czekasz na odpowiedź)

Serwer: Tak

(Serwer otrzymał SMS, odpisuje)

Ty: Prześlij mi A

(wysłałeś prośbę, czekasz na odpowiedź)

Serwer: B

(Serwer otrzymał zapytanie, odpisuje na twoją prośbę)

 

Łatwo się domyśleć, że dużo szybciej było by gdybyś zapytał od razu o A oraz B, C, ..

Pojedyńcze zapytania to standard HTTP 1.0.
Komunikacja, każda prośba o plik wymaga wcześniejszego przywitania (handshake).

Gdy zapytasz się raz, czy możecie rozmawiać, a później będziesz prosił o kolejne dane po otrzymaniu odpowiedzi to standard HTTP 1.1. Różni się tym od HTTP 1.0, że pytamy się "Masz 5 minut?" - jeśli tak, to możemy pytać o kolejne pliki, bez potrzeby każdorazowego pytania czy serwer ma czas.

 

 

By uniknąć zbędnego gadania. Czasem pliki zależne do strony (np. skrypty, style) pakuje się w jedną teczkę (bundle).
Dzięki czemu zamiast prosić o A, B, C osobno, od razy przesłać wszystko na raz - jedna paczka ze skryptami A, B, C.

HTTP/2

Inne rozwiązania:

SPYDY - technologia od Google, która miała zrewolucjonizować komunikację, jednak wykryto w niej podatności (niebezpieczeństwo) i nie należy z niej skorzystać.

Na horyzoncie mamy HTTP 2.0, niektóre duże serwisy już korzystają, ale jeszcze trzeba poczekać.

Zobacz porównanie HTTP 1.1 vs HTTP 2.0

https://http2.golang.org/gophertiles

Na polskich hostingach dostępna jest opcja HTTP 2.

Jeśli posiadasz własny serwer np. z NGNIX, to kwestia dodania tylko jednego słowa do konfiguracji "http2" i przeładowanie serwera.
Jednak  musisz mieć: Nginx > 1.9.5, OpenSSL >= 1.0.2g (zapewni wsparcie również dla HTTP/2 dla użytkowników Chrome).

Na moim serwerze niestety HTTP/2 jest wyłączone, ale bardzo by się przydało.
Związane jest to z tym, że muszę przeprowadzić aktualizację serwera (a na to aktualnie nie mam czasu).
Sama aktualizacja zajmuje nie wiele, ale zawsze trzeba uwzględnić czas, na rozwiązanie ewentualnych problemów.

 

Istnieje wiele rozwiązań, przy towrzeniu serwisów, osobiście zazywczaj urzywam WebPacka.

Reklama

Zbyt wiele skryptów

Współcześnie często ładuje się dużo niepotrzebnych skryptów 'na wszelki wypadek'.
Wszystko wynika z ciągłego rozwoju - ewolucji przeglądarek.

Tak kiedyś wyglądała przegladarka, z pewnością nie działał by na niej YouTube.


Największe zmiany były widoczne w czasie tzw. 'wojny przeglądarkowej'. W tym czasie powstało unikalnych funkcjonalności dla danej przeglądarki. Zaś ta sama strona różnie wyglądała na różnych przeglądarkach (w wyniku błędów/różnic w implementacji).

 


Ewolucja, to nowe możliwośći, jednak nie można zapominać o 'starszych'.

 

Załużmy, że piszęc skrypt, programista użył funkcji X (dostępnej w nowej przeglądarce), jeśli stronę odwiedzi klient używając starszej przeglądarki - nie będzie ona posiadała funkcji X.
W takiej sytuacji strona nie bedzie działać prawidłowo!

By rozwiązać ten problem, programiści wymyślili coś co nazwali "polyfill".

In web development, a polyfill is code that implements a feature on web browsers that do not support the feature.

https://en.wikipedia.org/wiki/Polyfill_(programming)

Jest to po prostu 'program' - skrypt, który udaje (implementuje) brakującą funkcję które dana przegladarka nie wspiera.

W efekcie w praktyce ładuje się dużo niepotrzebnego kodu - 'na wszelki wypadek'.

Dlaczego mamy karać za dobre postepowanie?

Jeśli ktoś ma nową przeglądarkę (dobrze), to dlaczego ma za to dłużej czekać, by załadowały się wszystkie 'polyfile'?
Dlatego najlepiej je załadować 'opcjonalnie'! (tylko gdy trzeba)

Reklama

 

Blokujące skrypty

Uwaga, gdy przegladarka napotka w kodzie HTML, skrypt.
Musi go pobrać i przeczytać.
Na ten czas wstrzymywane jest generowanie strony!

By uniknąć takiej sytuacji można:

  • wczytać skrypt asychronicznie (atrybut async)
  • wczytać skrypty na końcu strony (w tym czasie użytkownik zobaczy całą stronę, zanim zostaną wczytane skrypty)).
  • można dodać skrypt dynamicznie po wczytaniu strony

Pierwszy czy kolejny raz?

Gdy wchodzisz na stronę po raz pierwszy.

Przeglądarka musi pobrac treść strony (html) oraz zależne pliki np. style (jak ma wyglądać strona - pliki CSS) oraz skrypty (JS).
Gdy wchodzisz na stronę kolejny raz, to przeglądarka już 'zna te pliki' (zapisała je wcześniej w pamięci podręcznej) - przez co nie musi ich ponownie pobierać.

Zatem za pierwszym razme strona ładuje się wolniej niż przy kolejnych odwiedzinach.

Jeśli skrypty, style 'upchniemy' w treść strony, to użytkownik szybciej zobaczy stronę przy pierwszym wyświetleniu.
Jednak przy każdym kolejnym wyswietleniu /podstronie będzie musiał je pobierać wraz z treścią strony, choć gdyby były zapisane osobno to przegladarka by je już miała.
Zatem kolejne wyświetlenia (np. podstrony), mogły by być szybsze.

Z wielu badań wynika, zę ludzie są bardziej skłonni dłużej poczekać za pierwszym razem, jednak potem wymagają 'natychmiastowej reakcji' (przynajmniej od aplikacji webowych :))

 

Dla przykładu google, w treści strony umieszcza skrypty, style tak by strona ładowała się możliwie szybko za pierwszym razem, a w między czasie (w wczytaniu, 'dociąga resztę' - by porawić doświadczenia użytkownika).

 

Przerysowanie - repaint

...

 

Sprawdź szybkość swojej strony i rekomendacje jej poprawy


 

Usługa Google umożliwiająca sprawdzenie szybkosci strony.
Aplikacja sugeruje również: 'co można poprawić'.

Wejdź na:

https://developers.google.com/speed/pagespeed/insights/ i sprawdź szybkość swojej strony.
Zobaczysz również rekomendacje - co możesz przyśpieszyć.

 

Reklama

Podobał Ci się ten artykuł?

Jeśli tak, to zarejestruj się aby otrzymywać powiadomienia o nowych artykułach poszerzających perspektywę. A mając szerszą perspektywę, możesz podjmować lepsze decyzje! (a to Twój czas, pieniądze, zdrowie, ..)


Dobre? - polub i poleć innym
Polub StartHerePL: Zdrowie
Polub StartHerePL: Biznes
Polub StartHerePL: InfoTechnologia

Newsletter?

Najpierw jakoś potem jakość. Prawie wszystkie artykuły cały czas aktualizuję :) Możesz spotkać: literówki, niedokończone zdania itp. Wszelkie uwagi są mile widziane! michal @ starthere.pl