O Developer Tools, które są dostępne w przeglądarce Chrome (w innych przeglądarkach także możemy je znaleźć) można przeczytać w pierwszej części naszego artykułu o narzędziach w Chrome dla Deweloperów. Znajdują się w nim podstawy, opis menu, funkcje i ich zastosowanie. W tej części skupiamy się na możliwości przyśpieszenia naszej strony przy pomocy tychże narzędzi. Poznajcie drugą część tajemnic klawisza F12.
Z artykułu dowiesz się:
- Co jeszcze możesz zrobić dzięki narzędziom dla programistów?
- Na czym polega kompresja tekstu?
- Jak zmienić rozmiar zdjęcia?
- Tajemnice klawisza F12 – krótkie podsumowanie.
Najpierw audyt
W poprzedniej części poradnika dla deweloperów znajdziesz informacje dotyczące audytu strony. Jest on niezbędny do dalszych działań, bowiem dzięki niemu będziemy wiedzieć, co może doprowadzać do spadków wydajności. Na jego podstawie możemy dużo łatwiej podjąć działania naprawcze. W samym samouczku od Google dotyczącym naprawy strony dostajemy dobrą radę, która brzmi: „Eksperymentuj”. To bardzo cenna wskazówka, bo faktycznie czasami niewielkie zmiany, które wydają się kosmetycznymi usprawnieniami, mogą mieć duży wpływ na szybkość ładowania się strony.
Skoro już mowa o audycie, to pamiętaj, że poza audytem „technicznym”, dostępnym pod F12 możesz także korzystać z bezpłatnego narzędzia do audytowania semantycznego stron. Dzięki niemu uzyskasz dodatkowe wskazówki, dotyczące Twojej strony www, w warstwie „marketingowej”.
Włączenie kompresji tekstu
Kompresja tekstu może być jednym z dobrych sposobów na poprawienie wydajności strony. Polega ona na zmniejszeniu rozmiaru pliku tekstowego przed wysłaniem go przez sieć. Jest to coś w rodzaju sposobu spakowania folderu przed wysłaniem go pocztą e‑mail, aby zmniejszyć jego rozmiar. Zanim jednak włączymy kompresję, musimy sprawdzić, czy zasoby tekstowe są kompresowalne. Jak to zrobić?
Po wykonaniu raportu należy kliknąć w zakładkę „Network” (Sieć), a następnie po lewej stronie pod wierszem z napisem „Filter” musimy zaznaczyć okienko „Use Large Request Rows”. W ten sposób w kolumnie „Size” pojawią się dwie wartości liczbowe. Pierwsza wartość to rozmiar nieskompresowanego zasobu, a druga rozmiar zasobu pobieranego podczas ładowania WWW. Jeśli dwie wartości są takie same, zasób nie jest kompresowany, gdy jest wysyłany przez sieć.
Inny sposób sprawdzenia tego elementu to klikniecie w dowolny plik z listy (kolumna „Name”), a następnie kliknięcie w zakładkę „Headers”. Otrzymamy wtedy informację o danym pliku, w której ważna jest dla nas następująca linijka: content‑encoding:. Jeśli takowej nie posiadamy, to znaczy, że nasz plik nie jest kompresowalny, a jeśli po dwukropku znajduje się informacja gzip, deflate lub br, to znaczy, że możemy nasz plik poddać kompresji.
Aby skompresować tekst, musimy dodać następujący kod do pliku zarządzającego przesyłem danych na serwerze. Na naszych serwerach kompresja podatnych typów plików jest włączona domyślnie. Jeśli korzystasz z serwera, na którym nie jest to domyślne ustawienie, powinien pomóc wpis w .htaccess Twojej strony. Odpowiednia sekcja może wyglądać tak:
<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
</IfModule>Kolejne wpisy odnoszą się do różnego rodzaju zasobów, jak czcionki, czysty tekst, kod html, pliki css itp. W ten sposób łatwo dodasz odpowiednie dyrektywy.
Po zmianach możemy zweryfikować, czy faktycznie pliki zostały pomniejszone. Wystarczy załadować ponownie stronę i sprawdzić, czy interesujące nas pliki mają mniejsze wartości. Dla pewności dobrze jest też kliknąć w wybrany plik *.js i upewnić się, czy w zakładce „Headers” przy content‑encoding: pojawiła się opcja informująca o kompresji.
Dla pewności możemy ponownie przeprowadzić audyt, wykonując następujące czynności:
- Kliknij kartę Audyty.
- Kliknij opcję Wykonaj audyt.
- Pozostaw ustawienia takie same, jak poprzednio.
- Kliknij Uruchom audyt.
Zmiana rozmiaru zdjęć
Często w raportach pojawia się informacja, że nasze zdjęcia są zbyt duże, przez co długo się ładują i spowalniają stronę. Jeśli użytkownik ogląda zdjęcia na ekranie urządzenia mobilnego o szerokości 500 pikseli, nie ma sensu wysyłanie obrazu o szerokości 1 500 pikseli. Idealnie byłoby wysłać obraz o szerokości najwyżej 500 pikseli. To oczywiście przykład dla aplikacji.
Poniżej dwa sposoby zarządzania obrazami w przypadku aplikacji.
- Zmiana rozmiaru zdjęć podczas procesu kompilacji.
- Utworzenie wielu rozmiarów każdego obrazu podczas procesu kompilacji, a następnie użycie ich w kodzie „srcset”. W czasie wykonywania przeglądarka dba o wybór najlepszego rozmiaru dla urządzenia, na którym działa. Zobacz obrazy o względnej wielkości. Więcej o tej metodzie można przeczytać na stronie Google dla developerów.
W przypadku stron wygląda to trochę inaczej. Raport pokazuje nam, które obrazy powinniśmy w szczególności poddać kompresji. OK, tutaj najlepszym rozwiązaniem wydaje się skorzystanie z podpowiedzi, jaką daje nam Google w raporcie. Według wskazówki najlepiej przekonwertować zdjęcia na nowe formaty, takie jak JPEG 2000, JPEG XR, WebP. Dlatego dobrze jest zapoznać się z zasadami dotyczącymi optymalizacji grafik.
Eliminowanie zasobów blokujących renderowanie
Critical Rendering Path ma kluczowe znaczenie dla wydajności naszych stron – naszym celem jest nadanie różnych priorytetów wyświetlanej treści zależnie od tego, jakie działania na stronie chce podejmować użytkownik. Szybkie wyświetlanie stron internetowych wymaga od przeglądarki wielu zabiegów. Większość tej pracy jest ukryta przed programistami witryn internetowych – piszemy kod, a ładnie wyglądająca strona pojawia się na ekranie. Ale jak dokładnie przebiega w przeglądarce proces pozwalający przejść od znaczników HTML i CSS oraz kodu JavaScript do zrenderowanych pikseli na ekranie?
Podstawą optymalizacji wydajności jest zrozumienie zdarzeń występujących na etapach od wczytania znaczników HTML i CSS oraz kodu JavaScript, przez ich przetwarzanie, po przekształcenie na zrenderowane piksele. Właśnie z tych etapów składa się Critical Rendering Path. Jeśli jakieś elementy blokują renderowanie, może to spowolnić naszą stronę.
Czym są zasoby blokujące renderowanie? To zewnętrzny plik JavaScript lub CSS, który przeglądarka musi pobrać, przeanalizować i wykonać, zanim będzie mogła wyświetlić stronę. Celem jest uruchomienie tylko podstawowego kodu CSS i JavaScript, który jest wymagany do prawidłowego wyświetlania strony. Warto znaleźć kod i zobaczyć, czy tak naprawdę jest on nam potrzebny. W raporcie, w jego odpowiedniej części – „Eliminate render-blocking resources”, znajdziemy, które pliki mogą być problematyczne.
Następnie wciskamy Command + Shift + P (Mac) lub Control + Shift + P (Windows, Linux, Chrome OS), aby otworzyć menu poleceń i wybrać opcję „Show Coverage”, czyli pokaż pokrycie. Stanowi ona przegląd, ile kodu w plikach jest wykonywane podczas wczytywania strony. Linia kodu została wykonana, jeśli ma zielony pasek. Czerwony pasek oznacza, że kod nie został wykonany i zdecydowanie nie jest potrzebny przy ładowaniu strony. Krótko mówiąc, podczas pracy z własnym kodem karta „Coverage” może pomóc w analizie kodu wiersz po wierszu i dostarczać tylko kod potrzebny do załadowania strony.
Możemy także po naciśnięciu Command + Shift + P (Mac) lub Control + Shift + P (Windows, Linux, Chrome OS) wybrać opcję „Request blocking”, która daje nam możliwość zablokowania danego kodu i sprawdzenia, czy strona bez niego się załaduje i będzie interaktywna. Wybierając „Add pattern”, możemy wpisać, który katalog lub plik ma nie być ładowany. Po odświeżeniu strony zobaczymy, które z naszych zasobów zostały zablokowane – będą miały one kolor czerwony.
Odpowiednie środowisko pracy
Warto podczas analizy i pracy skorzystać z zakładki „Performance”, gdzie możemy symulować rodzaj połączenia sieciowego, a także szybkość pracy procesora. Przydaje się to przede wszystkim do analizy ładowania stron na urządzeniach mobilnych, które przecież mają więcej ograniczeń sprzętowych niż komputery. Przeładowanie strony pozwala na wizualizację wszystkich kroków, jakie muszą się odbyć do załadowania strony.
Otrzymujemy w tym miejscu linię czasu, ślad pokazujący aktywność chronologicznie, od lewej do prawej. Wykresy FPS, CPU i NET u góry pokazują ilość klatek na sekundę, aktywność procesora i aktywność sieci. Jest to wskazówka, że możemy przyspieszyć ładowanie strony, wykonując mniej pracy, na przykład przez JavaScript. Tutaj krok po kroku możemy analizować kolejne działania i wyszukać te, które trwają najdłużej.
Narzędzia dla programistów Chrome – podsumowanie
O klawiszu F12 i narzędziach dla developerów można napisać dziesiątki, jak nie setki stron poradników. Dlatego powyższy artykuł oraz jego pierwszą część warto traktować jako wstęp do poznania tych narzędzi. Skupia się on na jednej z wielu ich możliwości, czyli analizie ładowania strony oraz na jej przyśpieszeniu. Jeśli interesują Was inne możliwości narzędzi dla developerów, to warto przejrzeć dokumentację udostępnioną przez Google.
Fajny artykuł, często korzystam z narzędzi dla developerów w chrome, ale nie znałem niektórych „sztuczek”