21 stycznia 2020

Optymalizacja Fontów (czcionek) dla strony WWW

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

Optymalizacja Fontów (czcionek) dla strony WWW

W tym artykule poruszymy kilka elementów, które wpływają na wydajność strony internetowej i są bezpośrednio związane z internetowymi fontami (lub niepoprawnie: czcionkami).

Aby zdać sobie sprawę z tego jak web-font jest istotny w optymalizacji wydajnościowej strony internetowej, należy zwrócić uwagę na kilka istotnych faktów:

  1. Fonty są zasobami statycznymi,
  2. Mogą być dostarczane w wielu wariantach grubości, które zawierają wiele zestawów znaków – wykorzystujemy zazwyczaj kilka z nich,
  3. Kroje pisma mogą być dołączane do strony na wiele sposobów.
  4. Font blokuje i wpływa na czas renderowania strony – istnieje wiele technik optymalizacyjnych, które mogą ten czas skrócić.
  5. Font ma znaczny wpływ na design i czytelność strony internetowej.

No to w takim razie idźmy po kolei…

Dodawanie fontów do strony internetowej

Zanim przejdziemy do optymalizacji, musimy zrozumieć jak strona ładuje font i sprawdzić jakie techniki można wykorzystać w celu dołączenia niestandardowych fontów do strony internetowej.

Font jako zasób strony internetowej

Web-font to zbiór wektorowych glifów liter i symboli. Za pomocą matematycznych wyrażeń każda litera jest od początku narysowana. Dzięki temu zmieniając wielkość jakiegoś napisu, ma on zawsze ostre i wyraźne krawędzie – z dokładnie tą samą sytuacją mamy do czynienia kiedy posługujemy się grafiką zapisaną w formacie wektorowym. Rozmiar pliku danego fontu zależy od złożoności ścieżek, liczby wszystkich liter i symboli dostępnych w ramach kroju który on reprezentuje.

Formaty fontów obsługiwane przez przeglądarki

Aby dołączyć font, który będzie obsługiwany we wszystkich aktualnie wykorzystywanych przeglądarkach, należy dysponować aż czterema różnymi formatami. Producenci przeglądarek jak zwykle „umówili się” aby skomplikować web designerom życie? Nie, jak zwykle jest to kwestia rozwoju i opracowywania coraz to efektywniejszych metod kompresji.

Podobnie jak przy optymalizacji zdjęć, mamy sytuację, że nowe formaty czcionek działają tylko w nowych przeglądarkach a stare dołączamy po to aby strona dobrze się prezentowała także w starszych systemach.

  • format EOT jest obsługiwany przez przeglądarki Internet Explorer,
  • format WOFF jest obsługiwany wielu nowych przeglądarkach,
  • format WOFF 2.0 to najnowszy format, którego pliki zajmują najmniej miejsca ale jest wspierany tylko przez nowe przeglądarki.
  • format TTF obsługują starsze przeglądarki Androida (poniżej wersji 4.4),
  • jest jeszcze format SVG ale jest on aktualnie wypierany i niekompatybilny z IE i Firefox.

Dokładną tabelę kompatybilności można sprawdzić poniżej. Tak wygląda wsparcie dla WOFF:

Wsparcie formatu WOFF, źródło: Caniuse

Format WOFF to skompresowane kroje TrueType/OpenType, które zawierają informację o źródle fontu.

WOFF2 to zaś udoskonalenie formatu WOFF, który cechuje się lepsza efektywnością kompresji:

Wsparcie formatu WOFF2.0, źródło: Caniuse

Jak widać, tak jak w przypadku zdjęć przeglądarka Microsoftu ma własny świat:

Wsparcie formatu EOT, źródło: Caniuse

Ciekawą cechą formatu EOT jest to, że font może być użyteczny tylko dla strony w konkretnej domenie – jest to coś w rodzaju zabezpieczenia antypirackiego. Teraz widać dlaczego IE tak kurczowo trzyma się tego formatu.

Co z tego wszystkiego wynika? To oznacza, że musimy udostępnić przeglądarkom kilka plików na raz i każda przeglądarka będzie korzystała z tego pliku, z którym jest kompatybilna.

Dołączanie fontów w CSS

Dołączenie własnego fontu polega na wykorzystaniu instrukcji font-face. Deklarujemy nazwę fontu oraz zamieszczamy ścieżkę prowadzącą do pliku przechowującego wszystkie glify.

 @font-face {
  font-family: Montserrat;
  src: url(montserrat.woff);
} 

Jeżeli korzystamy z Google Fonts dodajemy taką linijkę zazwyczaj przed właściwymi stylami CSS:

<link href="https://fonts.googleapis.com/css?family=Montserrat&display=swap" rel="stylesheet"> 

Jeżeli sprawdzimy jaki kod kryje się w pliku to okazuje się że tam użyto dokładnie tej samej metody:

@font-face {
   font-family: 'Montserrat';
   font-style: normal;
   font-weight: 400;
   src: local('Montserrat Regular'), local('Montserrat-Regular'), url(https://fonts.gstatic.com/s/montserrat/v14/JTUSjIg1_i6t8kCHKm459Wdhyzbi.woff2) format('woff2');
 }

O tym co oznaczają poszczególne instrukcje będzie w dalszej części artykułu.

Zestawy znaków dla różnych języków

W przypadku kiedy na stronie będą potrzebne polskie znaki diakrytyczne (lub strona będzie obsługiwała wiele innych języków) należy zadbać oto aby dobrać taki font, który zawiera glify potrzebne w danym jezyku.

W Google Fonts możemy wybrać w zakładce personalizowania (lub jak kto woli customizacji) potrzebne dla nas języki:

Wybór zestawu znaków do obsługi języków w Google Fonts

To powoduje, że do zasobu CSS zawierający deklarację czcionki dodawany jest parametr subset=latin-ext:

<link href="https://fonts.googleapis.com/css?family=Roboto&display=swap&subset=latin-ext" rel="stylesheet">

Tutaj mała uwaga: w przypadku kiedy w naszym szablonie widać linki do Google Fonts odnoszące się także do innych subsetów (cyrylica, greka, wietnamski), można je spokojnie usunąć a dzięki temu zaoszczędzimy parę linii w CSS. Teraz pora na nieco bardziej wyszukane techniki optymalizacji.

Optymalizacja fontów internetowych

Jak wiadomo, wydajność strony internetowej wpływa zarówno na UX jak i pozycje w wyszukiwarce. Stosowanie dobrych praktyk pozwoli osiągnąć cele biznesowe lub zminimalizować koszty promocji strony internetowej i zmaksymalizować zyski już pozyskanego ruchu na naszej stronie.

Tak jak w przypadku zdjęć, filmów i dźwięku, fonty też można poddawać skutecznej optymalizacji zarówno pod kątem prędkości wczytywania jak i prędkości renderowania.

Ilość fontów i ograniczenie projektu

Najbardziej oczywistą optymalizacją jest ograniczenie ilości stosowanych fontów na stronie internetowej. Dwa fonty powinny spokojnie wystarczyć na każdej stronie niezależnie od jej charakteru czy tematyki (nie licząc tych specjalnych do piktogramów). Zazwyczaj stosuje się inny font dla nagłówków (i innych dużych napisów lub brandingu) a inny font dla paragrafów. Jeżeli jakaś strona wykorzystuje więcej fontów, wystarczy dodać linijkę CSS, która zmieni font na taki, który jest już wykorzystywany także w innym miejscu.

Kompresja GZIP

Wymienione formaty EOT i TTF nie są domyślnie kompresowane. Do pliku .htaccess należy dodać następujące instrukcje (o ile jeszcze ich tam nie ma):

<ifmodule mod_deflate.c>
<ifmodule mod_mime.c> #Checks if your server supports Addtype
Addtype font/opentype .otf
Addtype font/eot .eot
Addtype font/truetype .ttf
</ifmodule>
AddOutputFilterByType DEFLATE font/opentype font/truetype font/eot
</ifmodule>

Czytaj więcej w artykule: kompresja GZIP i DEFLATE

Formaty woff i woff2 są już kompresowane, nie trzeba ich już kompresować.

Nagłówki Expires / Cache-Control

Tak jak każdy zasób statyczny, raz pobrany font może być przechowywany na urządzeniu. Dzięki temu unikamy ponownego pobierania fontu z serwera przy przeładowaniu strony bądź poruszaniu się po innych podstronach tego samego serwisu. Aby osiągnąć taki efekt można użyć np. nagłówków Expires. Niektóre serwery mogą nie obsługiwać fontów, dlatego aby były one rozpoznawane należy dodać typ tak jak w przykładzie powyżej (nie trzeba powtarzać raz dodanych instrukcji):

AddType application/vnd.ms-fontobject .eot
AddType font/ttf .ttf
AddType font/otf .otf
AddType font/woff .woff
AddType font/woff2 .woff2
AddType image/svg+xml .svg

ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
ExpiresByType font/ttf "access plus 1 year"
ExpiresByType font/otf "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year" 

Czytaj więcej w artykule: pamięć podręczna i nagłówki Expires

Odchudzanie fontów

W przypadku kiedy korzystamy z narzędzia Google Fonts, jesteśmy kuszeni przez kreator odnośnika aby dodawać kolejne style i warianty grubości linii.

Dostosowywanie fontu Google Fonts

Na szczęście, w Google Fonts mamy wyraźne ostrzeżenie, że font będzie się ładował bardzo długo, jeżeli dodamy wiele jego wariantów grubości. Podczas kiedy inni obcinają pojedyncze znaki i martwią się kompresją o kilka kilobajtów, w wielu szablonach Fonty są dodawane tak jakby „na zapas”. Nie dość że występują we wszystkich możliwych wariantach, to jeszcze dodawane są zestawy znaków dla wietnamskiego, greki i cyrylicy…

Serwowanie fontów

Fonty można serwować bezpośrednio z serwerów Google. To pozwoli współdzielić fonty pomiędzy różnymi podstronami. W przypadku Font-Awesome, oficjalny CDN od czasu do czasu spowalnia odpowiedź, wtedy możemy wykorzystać własny hosting. Ponieważ większość z nas dysponuje – powiedzmy to sobie wprost – zazwyczaj słabymi hostingami, do serwowania fontów możemy użyć sieci CDN czyli Content Delivery Network.

Dzięki umieszczeniu fontu w CDN radykalnie skracamy czas jego pobierania co ma odzwierciedlenie także w wydajności strony, bo jak pamiętamy font blokuje renderowanie i dopóki nie zostanie pobrany strona będzie miała na moment niewidoczne albo lekko zniekształcone litery.

Wielokrotne testy wskazały, że ładując font o wadze 60KB z CDN czas oczekiwania (opóźnienie pobierania) wynosi ok. 110ms na ten sam plik z własnego serwera trzeba poczekać ok. 200ms. Niestety fonty podlegają polityce CORS i musimy skonfigurować CDN aby wysłał nagłówek: Header set Access-Control-Allow-Origin „*”. O tym zrobię wkrótce osobny wpis.

Odchudzanie kodu CSS fontów ikonowych

Kiedy wykorzystujemy kilka symboli z Font Awesome, Material Design Icons lub innych tego typu wynalazków, dobrze jest wyciąć nieużywane klasy z plików CSS odpowiedzialnych za dodawanie kodów unicode.

Każdy font ikonowy, w którym używamy klas typu „fa fa-times” jest dostarczany ze specjalnym plikiem CSS, który pozwala na użycie semantycznych nazw ikon. Na początku jest deklaracja @font-face a potem niekończąca się lista wszystkich możliwych do zastosowania ikon. Wygląda to mniej więcej tak:

.fa-glass:before {
content: "\f000";
}
.fa-music:before {
content: "\f001";
}
.fa-search:before {
content: "\f002";
}

Takie pliki potrafią ważyć ok. 40KB. Koniecznym krokiem optymalizacji strony, która używa tego typu fontów jest wycięcie tych klas, których nie używamy. Możemy sobie przeszukać stronę pod kątem wykorzystywanych ikon a potem zostawić tylko te, które są nam potrzebne. Wycinanie klas z pliku CSS nie jest fascynującym zajęciem ale pozwoli uzyskać bardzo dobry wynik w PageSpeed Insights. Jeżeli strona wykorzystuje wiele ikon, pomocne może okazać się wykorzystanie audytu Coverage, który opisałem w artykule jak usunąć nieużywany kod CSS.

Alternatywnym rozwiązaniem i dużo bardziej wydajnym jest użycie ikony w formacie SVG i dołączenie jej do strony metodą inline. Font-Awesome w wersji SVG można pobrać tutaj: https://github.com/encharm/Font-Awesome-SVG-PNG W sieci można znaleźć także inne popularne zestawy ikon w wersji SVG i PNG.

Dołączanie plików za pomocą tagu <img> mija się z celem, bo generuje dodatkowe zapytanie HTTP/HTTPS. Najlepiej użyć metody in-line.

Zamiast klasycznego umieszczenia ikony:

<i class="fa fa-chevron-right"></i>

mamy coś takiego:

<svg width="1792" height="1792" viewBox="0 0 1792 1792" xmlns="http://www.w3.org/2000/svg"><path d="M1363 877l-742 742q-19 19-45 19t-45-19l-166-166q-19-19-19-45t19-45l531-531-531-531q-19-19-19-45t19-45l166-166q19-19 45-19t45 19l742 742q19 19 19 45t-19 45z" fill="#fff"/></svg>

Technika wymaga nie małego wysiłku i co prawda kod jest mniej czytelny ale zaoszczędzenie ok. 150KB jest nie do przecenienia w kontekście wydajności stron internetowych i wyniku PageSpeed Insights.

Font-display czyli widoczności tekstu podczas ładowania strony

Nowa wersja PageSpeed Insights uczy deweloperów, że dobrą praktyką jest zastosowanie specjalnej instrukcji font-display.

Wsparcie tej właściwości CSS w przeglądarkach można sprawdzić w poniższej tabeli:

źródło: Caniuse

Właściwość font-display może przyjmować 4 wartości:

auto – domyślne zachowanie przeglądarki

block – blokuje font (najczęściej na 3 sekundy) i nieskończony okres, po którym może być on podmieniony. W praktyce działa to tak, że przeglądarka najpierw namaluje tak jakby niewidoczne litery (jeśli czcionka nie jest jeszcze załadowana) i poprawi jej wygląd po jej załadowaniu. W tym celu silnik renderujący tworzy tymczasową czcionkę z właściwościami podobnymi do wybranej czcionki (wielkość, odstępy, linia). Tej wartości należy używać tylko wtedy, gdy wymagane jest renderowanie tekstu w określonym kroju pisma, aby strona była przydatna. Symbole, rzadkie pismo, istotne elementy interfejsu.

swap – nie blokuje fontu ale też ma nieskończony okres po którym może być podmieniony. Przeglądarka generuje tekst w dostępnym foncie o podobnych parametrach a po pobraniu wszystkie litery są natychmiast zastępowane na właściwe kształty. Podobnie jak wyżej, wartość ta powinna być używana wtedy kiedy renderowanie tekstu w określonej czcionce jest istotne dla danej strony (także pod kątem wizerunkowym) ale w tym przypadku renderowanie w dowolnie innej czcionce powinno zapewniać prawidłowy i czytelny komunikat. Zastosowania – nagłówki w górnej części strony, logo, slogany reklamowe. To między innymi ta wartość przyczyni się do poprawy wyniku w PageSpeed Insights. To taki odpowiednik lazy-load dla czcionek internetowych.

fallback – blokuje font na krótki moment (100 milisekund) i daje krótkie okno czasowe (najczęściej 3 sekundy) na dokonanie podmiany fontu, o której mowa w powyższych punktach. W praktyce oznacza to, że w przypadku wolnego pasma lub wolnego procesora font zostanie zastąpiony podobnym odpowiednikiem a w przypadku szybkich urządzeń zostanie wyświetlona prawidłowa czcionka. Fallback sprawdzi się w przypadku tekstu zasadniczego strony internetowej (artykułu, blogu ale też opisu produktu w sklepie internetowym) gdzie konkretny krój nie odgrywa aż tak istotnej roli. To taki jeden duży kompromis pomiędzy user experience, wydajnością a wyglądem tekstu.

optional – też blokuje font na krótki moment ale nie daje przeglądarce czasu na podmianę kroju. Tę właściwość wykorzystujemy gdzie konkretny font ma drugorzędne a nawet trzeciorzędne znaczenie i priorytetem jest dla nas user experience na wszystkich urządzeniach kosztem zgodności prezentacji tekstu z zamiarem web designera.

Najczęściej korzystam z właściwości swap, bo nie chcę ani poświęcać tego jak wygląda tekst ani prędkości wczytywania strony internetowej. Zmiana fontu na inny po krótkim czasie nie jest moim zdaniem aż takim problemem by rezygnować z dokładnie tego fontu, który został przewidziany w projekcie – tym bardziej że ma to miejsce tylko przy odwiedzinach pierwszej podstrony witryny.

Zakres Unicode

Czasem można się jeszcze spotkać z takimi wyrażeniami:

unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF; 

Właściwość unicode range mówi przeglądarce dla jakiego zestawu znaków ma być zastosowany konkretny font. To bardzo niedoceniana właściwość, ponieważ w przypadku kiedy okaże się, że na stornie nie ma żadnego znaku z danego zakresu, font nie będzie pobierany i tym samym przyspieszymy działanie strony.

Preload – wcześniejsze pobieranie fontu

Ostatnią techniką może być jeszcze preload.

 <link rel="preload" href="fonts/MaterialIcons-Regular.woff2" as="font"> 

Dodanie takiego linku tak jak w przypadku innych zasobów powoduje pobieranie się fontu jeszcze zanim przeglądarka natrafi na odpowiednią instrukcję font-face. Dzięki temu wykorzystujemy współbieżność szybkich łącz internetowych. Niestety przeglądarka ładuje plik z fontem nie wiedząc czy będzie jej on potrzebny. W ten sposób można optymalizować fonty, co do których wiemy, że będą wykorzystywane w treści bieżącej strony a tym bardziej wtedy kiedy są one widoczne w górnej części strony czyli w tzw. obszerze above the fold.

Podsumowanie

Jak widać optymalizacja fontu to szerokie zagadnienie. Taka sama sytuacja ma miejsce przy dołączaniu zdjęć i multimediów. Istotne jest co załączamy, jaką metodą i jakich technik optymalizacji użyjemy aby pogodzić zarówno user experience, wydajność i wspaniałą prezentację.

Źródła:

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization

https://www.w3schools.com/cssref/css3_pr_font-face_rule.asp

https://developers.google.com/web/updates/2016/02/font-display

https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range

https://caniuse.com/

Oceń artykuł na temat: Optymalizacja Fontów (czcionek) dla strony WWW
Średnia : 4.8 , Maksymalnie : 5 , Głosów : 5


 

Odpowiedz lub skomentuj

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




Komentarze

Kasia Kowalska

26 stycznia 2020

Omg, rób mi stronę, proszę :) A tak na serio, żebym tylko potrafiła tą całą wiedzę, którą umieściłeś w tym artykule odpowiednio wykorzystać u siebie na stronie. Powoli poprawiałam sobie statystyki na Google PageSpeed Insights, doszłam na komórkach nawet do 45, co w moim przypadku było ogromnym sukcesem. Odkąd przeszłam na płatny motyw, cały czas mam problem z fontami i średnio mi idzie rozwiązanie tego problemu. Może powoli jakoś dam radę przetworzyć te informacje na bardziej zrozumiałe dla mnie i w końcu coś z tego wyjdzie. W każdym razie, dzięki za wpis — niesamowita kopalnia wiedzy.

Paweł Mansfeld

27 stycznia 2020

Dziękuję za komentarz. Cieszę się, że artykuł inspiruje do udoskonalania strony. Gratuluję uzyskanych wyników - 45/100 to dość dobry wynik biorąc pod uwagę, że mamy do czynienia z gotowym szablonem. Choć publikowane treści są najważniejsze, bardzo dobrze, że zwracasz uwagę na techniczną wydajność strony, bo jest to ostatnio jeden z najlepszych trików na wyprzedzenie konkurencji w wyszukiwarce. Stale będę publikował tego typu porady dlatego zaglądaj do mnie co jakiś czas :) Jeżeli coś jest niejasne pisz śmiało w komentarzach, po to one są. Oczywiście, zawsze jestem otwarty na współpracę.

Kasia Kowalska

27 stycznia 2020

Mała poprawka, te 45 to było przed zmianą motywu :( Teraz jest bidnie, aż piszczy. Mam jednak pytanie troszkę inne. Czy ten pomiar na Googlu jest miarodajny? Dlaczego np. na innych stronach, jak np. GT Metrix wyniki są już zupełnie inne? Pytam, bo statystyki na tym drugim "urządzeniu" mam korzystniejsze.

Paweł Mansfeld

28 stycznia 2020

Skoro Google wypuściło takie narzędzie to można je uważać za "miarodajne", bo niby poco inny sposób obliczania jakości strony miałby być zaimplementowany w narzędziu PageSpeed a inny w algorytmie wyszukiwarki. Częstym nieporozumieniem jest to, że PageSpeed Insights jest uważany za narzędzie do badania szybkości pobierania się strony - to błąd, spowodowany tradycyjną nazwą tego narzędzia (w końcu Speed to szybkość). PageSpeed Insights po aktualizacji z 2018 roku bada zarówno prędkość pobierania się strony z serwera jak i realną wydajność

"Wydajność" w Informatyce to efektywność przetwarzania danych, strona "szybka" szybko pobierze się z serwera. Strona wydajna pojawi się szybko w przeglądarce działającej zarówno na mocnym jak i na słabszym urządzeniu. Strona niewydajna może zostać szybko pobrana z serwera na wszystkich urządzeniach ale tylko na mocnym sprzęcie zostanie szybko wyświetlona zaś na starszych komputerach i smartfonach będzie "zamulać" przeglądarkę i pojawi się z opóźnieniem.

Kiedyś GTMetrix w polu PageSpeed dawał dokładnie ten sam wynik co PSI. Po aktualizacji, ten pierwszy test GT Metrix zachował "stare zasady" a PageSpeed działa całkiem inaczej. Kiedyś oba narzędzia badały szybkość odpowiedzi serwera i dobre praktyki web developerskie (czyli czy skrypty są połączone i czy jest ich dużo) wynik był obliczany za pomocą prostej analizy kodu i dzięki prostym regułom. Do tego analizowane były zwracane nagłówki przez poszczególne zasoby - takie narzędzie każdy sobie może napisać w PHP i sam miałem taki tester na własnej stronie (nazywał się WebLab).

Obecnie jednak, PSI faktycznie odwiedza stronę i specjalny mechanizm symuluje działanie przeglądarki (narzędzie Lighthouse), dzięki temu jest w stanie określić jak strona będzie szybka i responsywna na interakcję w praktyce a nie tylko "na papierze". To stąd przykładowo może przeanalizować efekt blokowania się fontów, zużycie CPU i jak szybko góra strony pojawi się w przeglądarce. PSI "czepia" się również animacji bo wykonuje kod JavaScript i CSS. Nie mógłby tego dokonać analizując sam kod strony.

Można stworzyć stronę która strasznie zamula przeglądarkę a do tego uzyska 100% w GT Metrix bo narzędzie to bada proste zasady tworzenia stron. PageSpeed nie pozwoli na to, bo symuluje cały proces i uwzględnia różne wyniki dla urządzeń mobilnych i Desktop. Pierwszy wynik w GT Metrix bazuje na starym algorytmie PageSpeed a drugie bazuje na narzędziu od Yahoo!. W PageSpeed pierwszy wynik dotyczy problemów które potęgują się na urządzeniach mobilnych a drugi jest bardzo podobny do starego testu PageSpeed. Ten drugi wynik jest zazwyczaj wyższy, bo tam wymagania są mniej restrykcyjne. Wielu deweloperów krytykuje i umniejsza istotność testu PSI z czysto ludzkiego oporu do zmiany własnych przyzwyczajeń i sposobów pracy - stąd często można się natknąć na różne artykuły mające na celu zdewaluować jego istotność lub zaleca się korzystać ze wspomnianego GT Metrix, Pingdom czy innych (powiedzmy to sobie wprost) już nieaktualnych narzędzi do badania wydajności stron.

 

Wykryto brak połączenia z Internetem.