16 maja 2019
Aktualizacja: 13 lipca 2020

Jak uzyskać 100 punktów w PageSpeed Insights?

Kategoria: Web
Tagi: dla profesjonalistów,
Autor: Paweł Mansfeld

Jak uzyskać 100 punktów w PageSpeed Insights?

Uzyskanie maksymalnego wyniku 100% w PageSpeed Insights jest mokrym snem web deweloperów oraz SEOwców. Tajemnicą poliszynela jest fakt, że osiągnięcie wyniku 100/100 nie należy do szczególnie trudnych zadań jeżeli tworzymy stronę od podstaw. Wystarczy tak naprawdę przestrzegać bardzo prostych zasad w tworzeniu stron internetowych i unikać wykorzystywania tanich szablonów z zagranicznych marketów.

W tym artykule podpowiem jak zdobyć 100 procent w teście Page Speed Insights zarówno dla urządzeń mobilnych jak i Desktop. Jeżeli interesuje cię jak działa, co mierzy i jaki wpływ mają na pozycje osiągane wyniki w tym narzedziu zapraszam do artykułu: Wpływ wyniku PageSpeed na pozycjonowanie.

Prawie każdą stronę można przerobić tak, że będzie uzyskiwać powyżej 90 punktów na 100 (desktop i mobile). Problem w tym, że dla jednej strony internetowej będzie to kwestia kilku minut, innej kilku godzin a dla jeszcze innej kilka dni pracy. Jeżeli próbujesz sam poprawić wynik lub szukasz usługi polegającej na poprawieniu wyniku PSI musisz wiedzieć kilka ważnych rzeczy:

  • w przypadku typowych stron na których wynik jest ekstremalnie niski wartości w PageSpeed najbardziej zaniżają dodatki z zewnątrz (widget Instagrama, Facebook) i tego typu integracje, które czasem są istotne lub nie wnoszą aż takiej wartości do naszej strony – ich usunięcie to najprostsza metoda na poprawę bardzo niskiego wyniku,
  • 100/100 punktów jest możliwe do uzyskania na stronach tworzonych od podstaw pod to wymaganie – przestaje się używać przeładowanych skryptami szablonów i każdy dodatek w postaci skryptu czy stylu jest osobno optymalizowany dla wyniku PageSpeed Insights,
  • ostatni punkt ma pozytywny wydźwięk, bo zawsze jest coś co można jeszcze poprawić. Jeszcze nigdy się nie zdarzyło, że po optymalizacji, o której możesz przeczytać w tym artykule, wynik nie drgnął w górę.

Za sukces należy już uważać poprawę o kilka punktów.

Ciekawostką jest też fakt, że sposób ewaluacji stron w tym narzędziu jest co jakiś czas uaktualniany. Niegdyś sprawdzał czas odpowiedzi (oczywiście w postaci TTFB) i tego czy deweloperzy trzymają się starych i sprawdzonych technik optymalizacji stron takich jak:

  • minimalizacja kodu HTML, CSS, JS,
  • stosowania zoptymalizowanych grafik,
  • wykorzystywania pamięci podręcznej.

Obecnie sprawdza także wydajność stron, czyli:

  • czas do pełnej interaktywności,
  • procesor bezczynny po raz pierwszy,

a także User Experience

  • widoczność tekstu podczas ładowania się strony internetowej,
  • stabilność wizualna strony internetowej (czy strona nie “skacze” przy ładowaniu),
  • używanie pasywnych detektorów do poprawy działania przewijania.

Niektóre wymogi zostały troszkę zmienione np. kiedyś ustawienie nagłówków Expires na 30 dni dawało pełny wynik, dziś trzeba je ustawić na okres pełnego roku ale do tego jeszcze dojdziemy.

Szczegółowe metryki wydajności

PageSpeed Insights posługuje się czterema metrykami, których wynik w podsumowaniu badania jest przedstawiony za pomocą wykresu paskowego.

Metryki w PageSpeed Insights
  1. Pierwsze wyrenderowanie treści (FCP ang. First Contentful Paint) – mierzy jak długo zajmuje przeglądarce wygenerowanie pierwszego kawałka DOM po kliknięciu w link do badanej strony lub po wpisaniu jej w pasek adresu. Zalecany wynik to 1.5 sekundy.
  2. Opóźnienie od pierwszej interakcji (FID ang. First Inpud Delay) – ponieważ to jak szybko pojawi się strona w wyszukiwarce to tylko część historii, ta metryka sprawdza jak długo po załadowaniu tych pierwszych obiektów DOM użytkownik musi czekać na możliwość interakcji (np. kliknięcie w linki lub wykorzystanie dołączonych do strony skryptów reagujących na inne zdarzenia).
  3. Największe wyrenderowanie treści (LCP ang. Largest Contentful Paint) – sprawdza ile czasu zajmuje pojawienie się największego elementu DOM u góry strony (jest to np. slajd, grafika, slogan itd…).
  4. Skumulowane przesunięcie układu (CLS ang. Cumulative Layout Shift) – pewnie nie raz kliknąłeś na reklamowy banner tylko dlatego, że pojawił się później niż reszta strony. Ta metryka wykrywa takie sytuacje i sumuje rozmiar przesunięcia – jak można się domyślić – im jest ono mniejsze, tym lepiej.

Jak poprawić wynik w PageSpeed Insights?

Poprawa wyniku jest możliwa za pomocą realnego przyspieszania wczytywania i renderowania stron interntowych w przeglądarkach. Poniżej kilka technik optymalizacyjnych, które umożliwiają polepszyć parametry FCP, FID, LCP i CLS i tym samym zwiększyć wynik w PageSpeed Insights.

Wyświetlaj obrazy w formatach nowej generacji

PageSpeed Insights często podpowiada aby stosować formaty graficzne nowej generacji. Mowa oczywiście o otwartym standardzie grafiki internetowej jakim jest WebP, o którym pisałem już jakiś czas temu w artykule o optymalizacji zdjęć na stronach internetowych. Jako, że podmiana wszystkich grafik z PNG i JPG (lub JPEG) na WebP spodoba się użytkownikom Chrome, Opery i Firefoxa to użytkownicy nieco gorszych przeglądarek takich jak Internet Explorer i Safari będą troszkę zawiedzeni – dlaczego? – ponieważ nie zobaczą zdjęć. Przeglądarki te nie wspierają formatu WebP.

Jest metoda aby pogodzić potrzeby obu grup użytkowników – należy użyć podejścia progressive enhancement i zdjęcia zamieszczać zarówno w starym jak i nowym formacie. Chociaż PageSpeed tego nie wymaga, warto się pochylić nad nieco mniej zaawansowanymi użytkownikami Internetu i zamieścić alternatywne formaty starszej generacji w następujący sposób:

<picture> 
	<source type="image/webp" srcset="obrazek.webp"> 
	<img src="obrazek.png" alt="opis obrazka"> 
 </picture>

Nowe formaty należy zastosować także dla atrybutów poster w klipach video oraz dla tła i dynamicznie wykorzystywanych atrybutów typu data-src w efektach parallax itp.

Jeżeli interesuje Cię ten wątek, czytaj więcej o WebP i innych formatach graficznych nowej generacji. Poprawa w tej sferze może poprawić metryki FCP, FID, LCP.

Odłóż ładowanie obrazów poza ekranem

W przypadku obrazów, należy też stosować technikę optymalizacyjną o nazwie lazy-load. Polega to na tym, że grafiki które są położone niżej niż ok. 1600 pikseli mają być ładowane z opóźnieniem, np po jakimś czasie od pełnego wczytania się strony lub po przewinięciu widoku w dół.

Zoptymalizowana ścieżka krytyczna

O tym jak działa w praktyce lazy load, jak go zaprogramować (także według najnowszej metody z wykorzystaniem atrybutu loading) napisałem w artykule: Lazy load czyli opóźnione ładowanie zdjęć. Uwaga: lazy-load może poprawiać FCP, FID, LCP ale wdrożony niepoprawnie może to robić kosztem CLS. Aby temu zapobiec, przy dodawaniu zdjęć należy posługiwać się atrybutami width oraz height, które “zarezerwują” miejsce na zdjęcie zapobiegając “skakanie” strony.

Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej 

Raz pobrany plik z serwera może być wielokrotnie użyty przez przeglądarkę do generowania wyglądu kolejnych podstron witryny. Pamięć podręczna plików statycznych oraz nagłówki sterujące buforowaniem zasobów w kolejnych warstwach infrastruktury to jedna z najbardziej pierwotnych i krytycznych technik optymalizacji witryn internetowych. Czytaj więcej jak ustawić nagłówki Expires i Cache-Control oraz jakie są między nimi różnice.

Kompresja zasobów tekstowych (włącz kompresję tekstu)

Znaczne przyspieszenie pobierania się witryn internetowych jest możliwe dzięki bezstratnej kompresji danych. Kompresja zasobów tekstowych jest dostępna dzięki algorytmowi deflate – temu samemu, który odpowiada za kompresję grafik PNG. Kompresję GZIP lub deflate stosujemy najczęściej dla zasobów HTML, CSS, JS oraz XML. Zmniejsza ona rozmiar sumaryczny całej strony internetowej przyczyniając się do szybszego wczytywania podstrony odwiedzanej na samym początku sesji. Czytaj o tym jak włączyć GZIP / deflate na standardowym serwerze WWW.

Minifikacja CSS, JavaScript

Dużo mniej efektywna ale niosąca wielowymiarowe korzyści jest minimalizacja kodu CSS i JS. Jest to usunięcie nadmiarowych znaków w kodzie, który nie wpłynie na finalny efekt interpretacji przez silnik przeglądarki. Spacje i tabulatory i znaki nowej linii w kodzie interpretowanym są potrzebne podczas pracy z kodem a w JS można zmienić nazwy zmiennych na unikalne i jednoliterowe zamienniki. Jest wiele narzędzi które automatyzują tego typu prace i o nich napisałem osobny artykuł. Czytaj jak poradzić sobie z tym punktem w minimalizacji kodu CSS i JavaScript.

Usuń nieużywany kod CSS

Nowa wersja PageSpeed Insights wymaga nie tylko minimalizacji ale także usunięcia nieużywanych instrukcji CSS. Skąd się biorą taki instrukcje? Obecnie strony są budowane z wykorzystaniem front-endowych frameworków czyli takich szkieletów jak Bootstrap a nawet gotowych szablonów stron WWW które oczywiście mają swoje zalety ale zawierają wiele elementów interfejsu których nie wykorzystujemy. Należy te elementy z arkusza stylu usunąć. Jest to jeden z trudniejszych punktów do zrealizowania bez odpowiednich narzędzi i motywacji ale jest możliwy z odrobiną motywacji i znajomości CSS. Czytaj więcej o tym jak usunąć nieużywany kod CSS. Usuwanie nadmiarowego kodu CSS znacznie poprawia FCP i FID na urządzeniach mobilnych.

Usuń nieużywany JavaScript

To samo co wyżej ale odnosi się do plików ze skryptami JavaScript. Wiele skryptów jest potrzebnych tylko na jednej stronie. Niepotrzebne ładowanie raz użytych skryptów znacznie spowalnia stronę obniżając realną prędkość i wyniki w analizie podstawowych wskaźników interntowych.

Dobrym przykładem są tutaj skrypty ReCaptcha, skrypty do obsługi formularzy czy obsługa pokazu slajdów ze strony głównej. Mimo, że z tych mechanizmów korzystamy tylko na wybranych podstronach np. “kontakt” – w wielu systemach CMS pliki te są ładowane także do strony głównej czy bloga. Za pomocą prostej funkcji if, można spowodować aby kod był ładowany tylko tam gdzie jest to potrzebne.

Kolejnym skutecznym sposobem na usunięcie nieużywanego kodu JavaScript jest pozbycie się zależności od bibliotek i gotowych wtyczek. Przykładem może być całkowite usunięcie jQuery zastępując wykorzystywane metody na natywny kod Vanilla JS. Sprawdź przykłady jak przerobić popularne metody jQuery na czysty JavaScript. Drugim przykładem może być zastosowanie najnowszych bibliotek które tą zależnością nie są ograniczone. Dokonując aktualizacji Bootstrapa 4 i 4.5 na Bootstrap 5 pozbywamy się zależności od jQuery zachowując w miarę dobrą kompatybilność kodu.

Wyeliminuj zasoby blokujące renderowanie

Ilość oraz rozmiar zasobów zewnętrznych ma ogromny wpływ na uzyskiwany wynik PSI ale nie należy bać się każdej linijki CSS i JavaScript. Dołączenie do zoptymalizowanej strony skompresowanego kodu CSS frameworku Bootstrap oraz jego skryptu JS (wraz z Popper i jQuery Slim) nadal pozwala osiągnąć 100 (zarówno przy urządzeniach mobilnych jak i w Desktopie).

Ten punkt jest połączony z poprzednim, ale ważny jest także sposób umieszczania zarówno stylów jak i skryptów JavaScript. Czytaj o tym kiedy dokonywać kombinacji, czyli scalania skryptów w jeden plik, a kiedy wklejać je w ciało strony: Kombinacja plików CSS / JS vs. wklejanie kodu w ciało strony. Najlepszą jednak stosunkowo trudną do wykonania praktyką jest wydzielenie krytycznego CSS (potrzebnego do poprawnego wyświetlania się pierwszego ekranu strony), wklejeniu go do nagłówka kodu HTML a pozostałe instrukcje dołączyć w postaci plików opóźniając ich załadowanie. Czytaj więcej o tym jak optymalizować krytyczną ścieżkę renderowania i jak wyeliminować zasoby blokujące renderowanie.

Zapewnij widoczność tekstu podczas ładowania czcionek internetowych

To jeden z punktów, który dotyka nie tyle szybkości wczytywania co User Experience witryny. Jeżeli korzystasz w niej z niestandardowych fontów możesz pozwolić na wyświetlenie się tekstu za pomocą standardowej “czcionki” dzięki nowym właściwościom w CSS:

Wystarczy dodać do elementów, w których używamy niestandardowych fontów właściwości font-display z wartością swap:

@font-face{
font-family:Lato;
font-style:normal;
font-weight:400;
font-display:swap;
src:local('Lato Regular');
}

Właściwość ta spowoduje, że jeśli font nie jest załadowany, każdy element, który próbuje jej użyć musi wyrenderować się przy użyciu fontu rezerwowego (poprostu kolejnego w liście font-family). Jeśli font zostanie pomyślnie szybko załadowany, jest używany standardowo. W efekcie może się zdarzyć, że przy niskiej jakości połączeniu użytkownik będzie korzystał z fontu rezerwowego np. domyślnego fontu przeglądarki lub font się zauważalnie podmieni krótko po pełnym wczytaniu witryny.

Czytaj więcej o innych technikach optymalizowania fontów, które przyspieszają wczytywanie się stron i poprawiają wynik w PageSpeed Insights takich jak preload, unicode range czy usuwanie niepotrzebnych wariantów: Optymalizacja fontów na stronach internetowych. Optymalziacja fontów powinna być przeprowadzona starannie aby nie pogorszyć CLS.

Skróć czas reakcji / odpowiedzi serwera (TTFB)

Uwaga “Reduce initial server response time” dotyczy czasu reakcji serwera TTFB (ang. Time To First Byte) to opóźnienie, które jest liczone od wysłania żądania HTTP do serwera WWW do momentu odebrania przez nas pierwszego bajtu odpowiedzi. Im mniejszy czas TTFB tym lepiej – określa on jednocześnie jakość hostingu oraz jakość wdrożenia witryny, sklepu czy aplikacji internetowej. W bardzo dużym stopniu wpływa na ostateczny wynik PSI.

Na długość czasu TTFB składa się ogrom czynników ale najważniejsze z nich to:

  • poziom skomplikowania CMSa i złożoności obliczeniowej generowania widoków w back-endzie,
  • jego dodatków (modułów, pluginów, rozszerzeń i ich ilości),
  • faktycznych parametrów i optymalizacji serwera,
  • fizyczna odległość klienta od serwera WWW,
  • obciążenie serwera ruchem (obciążenie łącza i CPU),
  • usługi zewnętrzne po stronie back-endu.

Czas TTFB można radykalnie skrócić za pomocą skorzystania z technik pamięci podręcznej w warstwie aplikacji, ulepszeniu opcji serwera lub migracji do innej firmy hostingowej. Czytaj w jaki sposób testować i jak skrócić czas TTFB witryny w różnych CMSach w osobnym artykule.

Unikaj zbyt dużego DOM

Co to jest element DOM? Element DOM lub obiekt DOM to nic innego jak dowolny element na danej podstronie witryny. Może to być obrazek, link, div, przycisk, formularz. Niektóre elementy DOM mogą być zagnieżdżane tzn. mogą być elementami podrzędnymi (dziecko) w stosunku do swoich elementów nadrzędnych (rodziców).

Test ten może być oblewany przez wyjątkowo rozbudowane podstrony np. strony główne w sklepie internetowym, portale z reklamami lub długie tzw. strony One-Page. PageSpeed Insights zgłasza ten problem wtedy, kiedy tych elementów jest zbyt dużo lub są zbyt głęboko pozagnieżdżane, według dokumentacji:

  • więcej niż 1500 elementów,
  • o głębokości większej niż 32 poziomy,
  • zawierające więcej niż 60 elementów potomnych.

Dla przykładu karuzela z najnowszymi produktami nie powinna zawierać więcej niż 60 ostatnich produktów. Pomiędzy znacznikiem <body> a najbardziej zagnieżdżonym elementem nie powinno być więcej niż 32 znaczników otwierających. W sekcji komentarzy napisałem odpowiedź jak można radzić sobie z tym problemem.

Nie używa pasywnych detektorów do poprawy działania przewijania

Detektory zdarzeń dotyku i przewijania wykorzystujemy po stronie JavaScriptu do tworzenia płynniejszego przewijania strony, tworzenia niestandardowej nawigacji (np. przewijania w bok) oraz do zmiany domyślnego zachowania się niektórych elementów np. linków, które zamiast odsyłać do strony płynnie przewijają widok do elementów położonych na innej wysokości.

Stosowanie takich instrukcji jak:

document.addEventListener("touchstart", handleStart, false);

Wadą takich rozwiązań jest to, że funkcje te mogą blokować lub opóźniać interakcję. Na szczęście w nowych przeglaarkach rozwiązano ten problem i wprowadzono argument który pozwala przekształcić je na pasywny detektor. Wystarczy w funkcji addEventListener ustawić flagę passive na wartość true:

document.addEventListener('touchstart', onTouchStart, {passive: true});

Unikaj document.write()

document.write() to instrukcja JavaScript pozwalająca dodać treść lub kod JavaScript do strony. Niestety, sztucznie opóźnia ładowanie się strony ponieważ zmusza do ponownego parsowania kodu a niektóre przeglądarki (w tym Chrome) mogą zablokować wykonanie się tego skryptu.

Zamiast przestarzałego document.write() można użyć asynchronicznego ładowania zasobów za pomocą instrukcji async:

<script src="skrypt.js" async></script>

Automatyzacja prac deweloperskich

Część z tych prac można zautomatyzować stosując wtyczki i moduły do konkretnych systemów CMS. Istnieje oficjalny moduł PageSpeed autorstwa Google, który pozwala wykonać automatyczną minifikację, ustawienie nagłówków i scalenie plików JS i CSS na poziomie serwera. Czytaj więcej o module PageSpeed w specjalnym artykule, który zawiera test i instrukcję instalacji.

Co utrudnia uzyskanie pełnego wyniku PageSpeed Insights?

  • Korzystanie z gotowych szablonów, które zostały stworzone na bazie innych gotowych szablonów, które zostały dostosowane do potrzeb za pomocą wtyczek, które w nieoptymalny sposób ładują nadmiarowy kod JS/CSS.
  • Korzystanie z wtyczek przeznaczonych dla potrzeb amatorów chcących tworzyć strony za pomocą kreatorów wizualnych. Dla WordPress są to Elementor, Elementor Pro, Divi, Wp Bakery, Uncode. Dla Joomla są to Helix, Pagebuilder.
  • Stosowanie wielu web-fontów w dodatku z paroma wersjami grubości i niewykorzystywanymi zestawami znaków (np. wietnamski, cyrylica, alfabet grecki).
  • Stosowanie fontów ikonowych, podczas kiedy wykorzystujemy kilka znaczków, które spokojnie mogłyby być zastąpione wersjami inline SVG,
  • skrypty z zewnątrz i wtyczki dodające swój kod do szablonu (Pixel Facebooka, Feed z Instagrama, dodatkowe skrypty do analizy i śledzenia, z których i tak nie korzystasz) LiveChat, Recaptcha, HotJar,
  • Nieprawidłowe dołączanie filmów YouTube za pomocą iframe,
  • słaby (najczęściej krajowy) hosting typu “LiteSpeed”,
  • błędny dobór rozwiązań optymalizacyjnych np. komplikowanie infrastruktury dodatkowymi węzłami w postaci Cloudflare, pamięci na zewnętrznym serwerze (memchached lub Redis), i innych tego typu “wynalazków”, które nie są przeznaczone dla prostych stron internetowych.

Podsumowanie

Zdobycie 100 punktów w PageSpeed Insights daje pewność, że od strony deweloperskiej poczyniono wszystkie wysiłki aby strona działała szybko i była wygodna dla użytkowników. PSI to jeden z głównych wyznaczników jakości stron internetowych i źródło satysfakcji dla perfekcjonistów.

Zielony wynik w Page Speed Insights z pewnością zostanie doceniony przez klientów, dla których korzystanie ze strony będzie wygodne oraz przez algorytm wyszukiwarki, które chętniej będą powracać do strony celem indeksowania a to może przyczynić się do lepszych pozycji w wyszukiwarce.

Źródła

https://developers.google.com/web/tools/lighthouse/audits/webp?utm_source=lighthouse&utm_medium=unknown

https://web.dev/vitals/

Oceń artykuł na temat: Jak uzyskać 100 punktów w PageSpeed Insights?
Średnia : 4.7 , Maksymalnie : 5 , Głosów : 25


 

Odpowiedz lub skomentuj

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *




Komentarze

Adam

14 października 2019

Witam, dzięki za porządny artykuł. Chciałem przy okazji zapytać o co chodzi z elementami DOM - bo mi taka sugestia wyskakuje. To jest struktura zagłębienia konkretnych znaczników? Zmieniłem jeden span na div i przestało mi na jednej podstronie wyskakiwać.

Paweł Mansfeld

15 października 2019

Witam serdecznie, dziękuję za bardzo dobre pytanie. Nie wiem czemu pominąłem ten temat, tworzyłem ten wpis na bazie jakiejś strony klienta i tam tego problemu musiało nie być - zaktualizuję ten artykuł o to zagadnienie. Element drzewa DOM, to w dużym uproszczeniu każdy element jaki jest na stronie. Może to być link, zdjęcie, DIV, dowolny obiekt w HTML. Jeżeli PageSpeed zgłasza ten problem to znaczy, że takich elementów jest po prostu zbyt dużo (około 1500 elementów nadrzędnych), lub są zbyt głęboko pozagnieżdżane (więcej niż 32 poziomy).

Dla przykładu, problem taki występuje często w sklepach internetowych na stronach głównych, gdzie mamy np. listę kategorii, z wieloma pod i pod-pod kategoriami jeżeli mamy skomplikowane megamenu, slajder z producentami i na dole jeszcze karuzela z najnowszymi produktami to w pewnym momencie zaczyna być tego zbyt dużo. Analizatorowi PageSpeed to przeszkadza bo generowanie takiej strony jest kosztowne dla przeglądarki. Strona taka może składać się z samego tekstu, ważyć około 100KB, używać CDNa, czas TTFB serwera może dążyć do zera a mimo to strona taka może się wczytywać wolno i może "zamulać" przeglądarkę, bo wszystkie te elementy (karuzele, harmonijki, zakładki) muszą zostać "narysowane".

Mamy zazwyczaj trzy wyjścia (w kolejności od najłatwiejszego do wdrożenia):

  • zmniejszyć liczbę tego typu widgetów i rozbudowanych elementów,
  • przebudować kod aby elementy nie były tak pozagnieżdzane (często można spotkać nadmiarowe divy lub spany, które niczego nie zmieniają w wyglądzie/działaniu),
  • zastosować technikę infinite-scroll tak, aby elementy na dole np. jakieś karuzele i dodatkowe listy produktów zostały dodane asynchronicznie do strony po przewinięciu.
Mam nadzieję, że pomogłem.

centus

24 grudnia 2019

Hej, noobowe pytania:
1) a które fonty są niestandardowe?
2) w jakim pliku dodawać font-display:swap;

Paweł Mansfeld

24 grudnia 2019

Dobre pytania,
1: wszystkie, które importujemy - nie należy zapominać o fontach ikonowych (typu Font Awesome, Material Icons), bo często to one obniżają wynik w PSI.
2: Dodajemy dokładnie tam gdzie mamy definicję fontu czyli po instrukcji font / font-family. Wystarczy zobaczyć jak to jest rozwiązane w Google Fonts:

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: local('Roboto'), local('Roboto-Regular'), url(https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu4mxK.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

 

Wykryto brak połączenia z Internetem.