Szybkość strony dla początkujących: co naprawdę poprawia czas ładowania

Co naprawdę oznacza „szybkość strony”

Kiedy ludzie mówią „moja strona jest wolna”, zwykle mają na myśli jedno z dwóch:

• Strona długo nic nie pokazuje, albo
• Wygląda na gotową, ale nadal jest nieczuła (przyciski opóźniają, obrazy ładowane są późno, układ skacze).

„Czas ładowania” to nie jedna cyferka na stoperze. Strona ładuje się etapami: przeglądarka żąda plików (HTML, obrazy, fonty, skrypty), pobiera je, a potem zamienia je w użyteczną stronę. Możesz to porównać do otwierania sklepu: odblokowanie drzwi, zapalenie świateł, rozłożenie towaru, i wreszcie gotowość do obsługi klientów.

Dlaczego prędkość ma znaczenie (nie tylko „bo ładnie”)

Szybkość wpływa na:

• Użytkowników: wolne strony stresują na urządzeniach mobilnych i przy słabym połączeniu. Ludzie szybciej opuszczają stronę i mniej jej ufają.
• SEO: Google wykorzystuje sygnały związane z prędkością (w tym Core Web Vitals) jako część doświadczenia strony. Szybsza strona nie zapewni automatycznie miejsca #1, ale wolna może Cię hamować.
• Konwersje: każda dodatkowa sekunda to większa tarcia—mniej rejestracji, mniej zakupów, mniej wysłanych formularzy.

Ustal oczekiwania: większość zysków pochodzi z kilku obszarów

Nie potrzebujesz 50 mikrooptymalizacji. Dla większości stron początkujących największe poprawy pochodzą z krótkiej listy: obrazy, za dużo JavaScript/CSS, skrypty stron trzecich, oraz czas odpowiedzi serwera/hosting.

Co ten poradnik omówi (a czego nie)

Ten poradnik skupia się na praktycznych, niskiego ryzyka krokach, które poprawiają rzeczywisty czas ładowania strony, szczególnie na urządzeniach mobilnych. Nie będziemy zanurzać się głęboko w zaawansowane tematy jak przebudowa architektury aplikacji, tworzenie niestandardowych warstw cache, czy budżetowanie wydajności dla dużych zespołów inżynieryjnych. Celem jest pomóc Ci wprowadzić zmiany, które możesz skończyć — i zweryfikować — bez łamania strony.

Kluczowe metryki szybkości (bez żargonu)

Gdy ktoś mówi „moja strona jest wolna”, zwykle chodzi o jedno z trzech: główna treść pojawia się późno, strona jest nieczuła przy interakcji lub układ ciągle skacze. Core Web Vitals dobrze mapują te skargi.

Trzy Core Web Vitals

LCP (Largest Contentful Paint): ile trwa pojawienie się największego „głównego” elementu (często obraz hero lub blok nagłówka). Jeśli LCP jest wysokie, użytkownik patrzy na prawie pustą stronę.

INP (Interaction to Next Paint): jak szybko strona reaguje po interakcji użytkownika (tap, klik, pisanie). Jeśli INP jest wysoki, strona wydaje się „lepka”—przyciski reagują z opóźnieniem, menu otwierają się późno.

CLS (Cumulative Layout Shift): jak bardzo strona przeskakuje podczas ładowania. Jeśli tekst się przesuwa i przez to klikniesz zły przycisk, to jest CLS.

TTFB: czas do pierwszego bajtu

TTFB (Time to First Byte) to ile trwa zanim serwer (i wszystko pośrednie) zacznie wysyłać cokolwiek. Wolny TTFB opóźnia wszystko: obrazy nie mogą zacząć się pobierać, fonty nie mogą się załadować, i zwykle pogarsza się LCP. Problemy z TTFB często wskazują na hosting, ciężką pracę po stronie serwera lub brak cache.

Testy laboratoryjne vs. dane z realnych użytkowników

Testy laboratoryjne (np. Lighthouse) symulują ładowanie strony w określonych warunkach. Są świetne do debugowania i porównań przed/po.

Dane z realnych użytkowników (zwane też „field data”, jak CrUX w PageSpeed Insights) pokazują, co odwiedzający naprawdę doświadczają na różnych urządzeniach i sieciach. To właśnie one są najważniejsze dla pytania: „Czy dla prawdziwych ludzi strona jest szybka?”.

„Dostatecznie dobre” cele dla początkujących

• LCP: celuj w ≤ 2.5s (do 4.0s wymaga pracy)
• INP: celuj w ≤ 200ms (do 500ms wymaga pracy)
• CLS: celuj w ≤ 0.10 (powyżej 0.25 to problem)
• TTFB: celuj w ≤ 0.8s (powyżej 1.8s często odczuwalnie wolno)

Jak zmierzyć swoją stronę zanim cokolwiek zmienisz

Jeśli zaczniesz „optymalizować” bez bazy, łatwo zmarnować czas — albo przypadkowo spowolnić stronę. Poświęć 20 minut na pomiary najpierw, wtedy będziesz wiedzieć, które zmiany pomogły.

Uruchom PageSpeed Insights (szybkie sprawdzenie rzeczywistości)

Użyj PageSpeed Insights dla szybkiego snapshotu. Narzędzie raportuje dane z realnych użytkowników (gdy są dostępne) i dane laboratoryjne (symulowany test). Zwróć uwagę na:

• Wyniki mobilne vs desktop (zwykle mobilne są problematyczne)
• Listę „Opportunities” (dobre pomysły, nie sztywna lista zadań)
• Czy test ma dane z realnych użytkowników dla Twojego URL

Do głębszych testów laboratoryjnych uruchom Lighthouse w Chrome:

1. Otwórz DevTools → Lighthouse
2. Wybierz Mobile i Performance
3. Uruchom 2–3 razy i zachowaj wynik środkowy (wyniki się różnią)

Użyj WebPageTest, aby zobaczyć „waterfall”

Gdy potrzebujesz zobaczyć co opóźnia stronę, WebPageTest jest jednym z najczytelniejszych narzędzi. Widok waterfall pokazuje każdy plik ładowany po kolei — HTML, obrazy, fonty, skrypty i tagi zewnętrzne — oraz miejsca, gdzie przeglądarka czeka.

Zacznij od jednej kluczowej strony (strona główna lub ważna strona docelowa) i testuj:

• First View (zimny cache) i Repeat View (z cache)
• Profil urządzenia mobilnego, jeśli to możliwe

Zapisz warunki testu (żeby wyniki miały sens)

Zanotuj dla każdego testu:

• Urządzenie (laptop, telefon średniej klasy itp.)
• Sieć (Wi‑Fi, 4G, ustawienia throttlingu)
• Lokalizacja (region testu w WebPageTest)
• Dokładny URL (wraz z parametrami)

Zrób prostą listę kontrolną przed/po

Utwórz mały log (prosta tabela/spreadsheet): data, użyte narzędzie, URL, wyniki i co zmieniłeś. Zmieniaj jedną lub dwie rzeczy naraz, potem testuj pod tymi samymi warunkami.

Jeśli iterujesz nad aplikacją (nie tylko statyczną stroną), warto mieć bezpieczny sposób na wdrażanie i wycofywanie eksperymentów wydajności. Platformy takie jak Koder.ai (które mogą generować i hostować aplikacje React/Go z workflow czatu) są tu przydatne, bo możesz robić snapshoty, testować zmiany i szybko cofać jeśli poprawka „prędkości” przypadkowo psuje UX.

Najczęstsze powody, dla których strony ładują się wolno

Wolne strony rzadko są spowodowane jedną tajemniczą rzeczą. To zwykle kilka powszechnych problemów „wagowych i opóźniających”, które się nakładają — szczególnie na urządzeniach mobilnych.

1) Obrazy większe niż potrzeba

Obrazy często stanowią największy ciężar strony. Pojedynczy obraz hero zapisany w złym rozmiarze (albo w starszym formacie) może dodać megabajty i sekundy.

Częste przyczyny:

• Wgrywanie zdjęcia szerokiego na 4000px, chociaż serwis wyświetla je w 1200px
• Używanie PNG do zdjęć zamiast nowoczesnych formatów jak WebP/AVIF
• Serwowanie tego samego dużego obrazu zarówno desktopowi jak i mobilowi

2) Za dużo JavaScript (i za dużo dodatków)

JavaScript może opóźniać moment, kiedy strona staje się użyteczna. Nawet jeśli strona „się pojawia”, może być powolna, podczas gdy skrypty się ładują, parsują i wykonują.

Skrypty stron trzecich często są winowajcami: widgety czatu, popupy, heatmapy, narzędzia A/B, tagi reklamowe i embedy społecznościowe. Każdy z nich może dodać kolejne żądania sieciowe i opóźniać krytyczne prace przeglądarki.

3) Wolny hosting lub ciężka praca serwera

Czasami przeglądarka czeka na Twój serwer zanim cokolwiek zacznie pobierać. To często odczuwalne jako wolna początkowa odpowiedź (TTFB). Przyczyny to słaby hosting, zapchane bazy danych, nieoptymalne motywy/wtyczki lub strony generowane dynamicznie przy każdej wizycie.

4) Brak cache + zbyt wiele żądań

Jeśli Twoja strona zmusza każdą wizytę do zaczynania od zera, odwiedzający wracający będą karani. Bez cache'a serwer buduje strony na nowo, a przeglądarka ponownie pobiera pliki, które rzadko się zmieniają.

Poza tym wiele małych plików (fonty, skrypty, style, trackery) tworzy „narzut żądań”. Nawet jeśli każdy plik jest mały, sumaryczny czas oczekiwania się kumuluje.

Dobra wiadomość: te przyczyny da się naprawić — i zwykle największe zyski osiągniesz, zajmując się nimi w tej kolejności.

Obrazy: najszybszy i najbardziej pewny sposób na zysk

Jeśli masz zrobić tylko jedną poprawkę wydajności — zajmij się obrazami. W wielu stronach początkujących obrazy odpowiadają za największą część pobranej „wagi” strony — szczególnie na urządzeniach mobilnych. Dobrą wiadomością jest to, że poprawki obrazów są zazwyczaj bezpieczne, szybkie i nie wymagają zmiany projektu.

1) Zmniejsz obrazy do rozmiaru wyświetlanego

Częsty błąd to wgrywanie ogromnego zdjęcia (np. 4000px szerokości) i wyświetlanie go w 800px. Przeglądarka i tak musi pobrać duży plik.

Eksportuj obrazy zbliżone do maksymalnego rozmiaru, w którym będą faktycznie wyświetlane. Jeśli obszar treści bloga ma 800px szerokości, nie wgrywaj 3000–4000px „na zapas”.

2) Używaj nowoczesnych formatów (WebP/AVIF) gdy to możliwe

JPEG i PNG nadal działają, ale nowoczesne formaty często dostarczają tę samą jakość wizualną przy dużo mniejszym rozmiarze pliku.

• WebP ma szerokie wsparcie i jest dobrym domyślnym wyborem.
• AVIF może być jeszcze mniejszy, ale kodowanie trwa dłużej, a wsparcie jest bardziej zróżnicowane.

Jeśli Twój CMS lub wtyczka do obrazów potrafi automatycznie serwować WebP/AVIF z fallbackami, to idealne rozwiązanie.

3) Kompresuj obrazy i usuń niepotrzebne metadane

To właśnie kompresja daje większość natychmiastowych zysków. „Wizualnie identyczny” obraz często można zmniejszyć o 30–70%.

Usuń też metadane, których nie potrzebujesz (informacje o aparacie, lokalizacji). Nie zmienia to wyglądu, ale dodaje bajty.

Praktyczna zasada: kompresuj aż zaczynasz widzieć spadek jakości, potem cofnij o krok.

4) Używaj responsywnych obrazów (srcset) dla mobile vs desktop

Użytkownicy mobilni nie powinni pobierać obrazów w rozmiarach desktopowych. Responsywne obrazy pozwalają przeglądarce wybrać odpowiedni rozmiar na podstawie szerokości ekranu.

Jeśli Twój system generuje kilka rozmiarów obrazów automatycznie, upewnij się, że motyw je poprawnie wykorzystuje. W HTML strony powinno pojawić się coś w stylu srcset (wiele wersji) zamiast jednego olbrzymiego pliku.

Szybka lista kontrolna

Zanim przejdziesz do bardziej zaawansowanych działań (jak minifikacja kodu), sprawdź najważniejsze obrazy:

• Czy mają rozmiar dopasowany do miejsca, w którym się pojawiają?
• Czy serwowane są jako WebP/AVIF, gdy to możliwe?
• Czy są sensownie skompresowane?
• Czy urządzenia mobilne otrzymują mniejsze wersje?

Jeśli konsekwentnie zastosujesz te cztery zasady, szybkość i czas ładowania strony zwykle poprawią się niemal od razu — często wystarczy, by pchnąć Core Web Vitals w dobrą stronę.

Lazy loading i priorytety dla tego, co widać na pierwszy rzut oka

Lazy loading oznacza opóźnianie pobierania niektórych obrazów (czasem iframe) do momentu, gdy są blisko pojawienia się na ekranie. To może skrócić początkowy czas ładowania, bo przeglądarka nie pobiera wszystkiego naraz — szczególnie przydatne na długich stronach z wieloma obrazami poniżej pierwszego ekranu.

Kiedy lazy loading pomaga

Lazy loading jest najbardziej użyteczny dla:

• Siatek produktów, postów na blogu i stron docelowych z dużą ilością treści poniżej pierwszego ekranu
• Osadzonych wideo/map, które nie są od razu potrzebne
• Użytkowników mobilnych na wolniejszych łączach

Użyty rozsądnie, zmniejsza „pracę na start” i sprawia, że strona wydaje się szybsza.

Nie lazy-loaduj hero (chroń LCP)

Największy obraz nad pierwszym ekranem to często hero. Jeśli go lazy-loadujesz, przeglądarka może za długo czekać z jego żądaniem, co szkodzi LCP.

Zasada: nigdy nie lazy-loaduj głównego obrazu hero ani niczego krytycznego w pierwszym ekranie (obraz nagłówka, podstawowe zdjęcie produktu, górny baner).

Zapobiegaj przesunięciom układu ustawiając szerokość/wysokość

Lazy loading może powodować „skoki” gdy obrazy się pojawiają. Aby zapobiec CLS, zawsze rezerwuj miejsce:

• Ustaw width i height na obrazach, lub
• Użyj CSS z ustalonym współczynnikiem proporcji

Dzięki temu układ strony pozostanie stabilny podczas ładowania obrazów.

Preloaduj to, co naprawdę ważne

Jeśli obraz lub font nad pierwszym ekranem jest kluczowy dla pierwszego wrażenia, rozważ jego preload, aby przeglądarka pobrała go wcześnie. Używaj tego oszczędnie — preloadowanie zbyt wielu zasobów może zaszkodzić, konkurując o pasmo.

Jeśli chcesz podejścia checklistowego, połącz to z krokiem pomiarowym w /blog/how-to-measure-site-speed-before-you-change-anything.

Podstawy cache: spraw, by powtórne wizyty były znacznie szybsze

Cache to sposób przeglądarki na powiedzenie: „Już to pobrałem — mogę użyć lokalnej kopii?”. Zamiast za każdym razem pobierać ten sam logotyp, plik CSS czy bundle JS, przeglądarka przez pewien czas trzyma kopię lokalnie. To znacząco przyspiesza powtórne wizyty i zmniejsza użycie danych — zwłaszcza na urządzeniach mobilnych.

Cache przeglądarki, prosto

Gdy Twoja strona wysyła plik (np. styles.css lub app.js), może też wysłać instrukcję, jak długo plik można używać ponownie. Jeśli przeglądarka może trzymać go przez np. 30 dni, to przy kolejnym odwiedzeniu te pliki ładują się natychmiast z urządzenia zamiast serwera.

To nie przyspieszy magicznie pierwszej wizyty, ale może znacząco przyspieszyć:

• Drugą stronę, którą ktoś kliknie
• Powtórne wizyty w ciągu dni/tygodni
• Użytkowników z przerywanym połączeniem

Ustaw nagłówki cache dla „statycznych” plików

Pliki statyczne to rzeczy, które nie zmieniają się co minutę: obrazy, CSS, JavaScript, fonty. To idealni kandydaci do dłuższego cache'u.

Co chcesz osiągnąć (konceptualnie):

• CSS/JS/obrazy: cache na dłuższy czas (tygodnie/miesiące)
• Strony HTML: cache ostrożnie (częściej krócej), bo treść może się zmieniać

Twój hosting, CMS lub framework może oferować prosty przełącznik „static asset caching”. Jeśli pracujesz z developerem, poproś o ustawienie odpowiednich nagłówków Cache-Control dla zasobów.

Używaj wersjonowanych nazw plików, żeby aktualizacje nie utknęły

Powszechny problem: „Jeśli będziemy cache'ować pliki miesiącami, jak użytkownicy dostaną nowy design jutro?” Rozwiązanie to wersjonowane nazwy plików.

Zamiast ciągle używać app.js, proces budowania może wyprodukować coś w stylu:

• app.3f2a1c.js
• styles.a81b09.css

Gdy zawartość się zmieni, nazwa pliku się zmienia, więc przeglądarka potraktuje go jak nowy plik i pobierze od razu — jednocześnie bezpiecznie cache'ując starsze wersje.

Uwaga na service workery (zaawansowane)

Service workery mogą pchnąć cache jeszcze dalej, pozwalając Twojej stronie kontrolować, co i kiedy jest przechowywane, a czasem umożliwiając działanie offline. Mogą jednak powodować trudne do zrozumienia problemy ze „starymi treściami”, jeśli są źle zarządzane. Dla początkujących traktuj service workery jako opcję zaawansowaną — świetne, gdy masz jasne cele i kogoś doświadczonego do utrzymania ich.

CDN: kiedy pomaga (a kiedy nie)

CDN (Content Delivery Network) to grupa serwerów rozproszonych po różnych regionach, które mogą dostarczać pliki Twojej strony z miejsca bliższego odwiedzającemu. Zamiast każdemu żądaniu podróżować do jednego serwera, wiele żądań obsługuje serwer „na brzegu” bliżej użytkownika.

Co CDN faktycznie robi

CDN najlepiej przyspiesza zasoby statyczne — rzeczy, które nie zmieniają się przy każdym żądaniu — jak obrazy, CSS, pliki JavaScript, fonty i wideo. Te pliki można skopiować na serwery CDN i ponownie wykorzystywać dla wielu odwiedzających.

Kto zyskuje najwięcej: strony z odwiedzającymi w różnych miastach/krajach, serwisy media-heavy oraz firmy prowadzące kampanie płatne kierujące ruch z różnych lokalizacji.

Jak CDN zmniejsza opóźnienia dla globalnych odwiedzających

Odległość dodaje opóźnienia. Jeśli Twój serwer jest w jednym kraju, a odwiedzający na innym kontynencie, każde żądanie trwa dłużej. CDN zmniejsza to opóźnienie, serwując cache'owane pliki z edge servera bliżej odwiedzającego, co zwykle poprawia czas ładowania strony i może pomóc Core Web Vitals — szczególnie na mobilnych połączeniach.

Zasoby statyczne vs dynamiczne strony

• Zasoby statyczne: świetne do CDN. Cache'uj je agresywnie.
• Strony dynamiczne (koszyk, obszar konta): często nie da się ich bezpiecznie cache'ować, albo tylko częściowo. Niektóre CDN oferują „dynamic acceleration”, ale to bardziej zaawansowane i nie zawsze opłacalne.

Powszechne pułapki

Błędne nagłówki cache mogą uniemożliwić cache'owanie w ogóle (albo cache'ować zbyt krótko). Przeciwna do tego jest sytuacja „stale cache'owanej zawartości”: aktualizujesz plik, ale odwiedzający nadal dostają starą wersję. Aby tego uniknąć, używaj wersjonowanych nazw plików (np. app.1234.js) i poznaj funkcję purge w Twoim CDN.

CDN nie zastąpi naprawy ciężkich obrazów, nadmiaru skryptów czy wolnego hostingu — ale może być silnym mnożnikiem korzyści, gdy podstawy są już ustawione.

Przytnij CSS i JavaScript bez psucia strony

CSS i JavaScript to często „niewidoczny ciężar”, który spowalnia stronę. W przeciwieństwie do obrazów, problemu nie zawsze widać, ale przeglądarka wciąż musi pobrać, przetworzyć i wykonać te pliki, zanim strona będzie gotowa.

Minifikacja CSS i JavaScript (co zmienia, a czego nie)

Minifikacja usuwa zbędne spacje, komentarze i formatowanie. Zwykle pliki są mniejsze i szybciej się ściągają.

Co to zmienia: rozmiar pliku.

Czego to nie zmienia: ile pracy przeglądarka musi wykonać, aby sparsować i uruchomić kod. Jeśli Twoje skrypty wykonują dużo pracy przy ładowaniu, minifikacja tego nie naprawi — traktuj minifikację jako szybki, punktowy zysk.

Usuń nieużywany CSS i wysyłaj tylko to, co potrzebne na danej stronie

Wiele stron ładuje „jedną uniwersalną” arkusz styli zawierającą reguły dla stron, komponentów i funkcji, których aktualna strona nie używa. Ten dodatkowy CSS nadal się pobiera i może spowolnić renderowanie.

Praktyczne podejście:

• Jeśli używasz page buildera lub dużego motywu, poszukaj opcji typu „load assets per page” lub „only load used CSS”.
• Jeśli masz developera, poproś o "critical CSS" (małe style potrzebne do pierwszego ekranu) i opóźnione ładowanie reszty.

Cel jest prosty: strona główna nie powinna nosić ciężaru całej witryny.

Odkładaj lub używaj async dla niekrytycznego JavaScriptu

Niektóre skrypty blokują moment, kiedy strona staje się interaktywna, bo przeglądarka musi je wykonać.

• defer jest zwykle najlepsze dla własnych skryptów, które mogą poczekać aż HTML zostanie sparsowany.
• async lepiej dla niezależnych skryptów (często zewnętrznych), które nie zależą od innych plików.

Jeśli nie jesteś pewien, zacznij od odkładania wszystkiego, co nie jest potrzebne dla pierwszego ekranu (menu, animacje, suwaki, dodatkowe trackery).

Ogranicz ciężkie biblioteki i duże frameworki tam, gdzie to możliwe

Duże biblioteki mogą dodać setki KB (lub więcej). Zanim dodasz kolejną wtyczkę lub framework, zapytaj:

• Czy funkcję można zrobić prostszym kodem?
• Czy można usunąć bibliotekę używaną tylko na jednej stronie?

Mniej skryptów to zwykle mniej niespodzianek — szczególnie dla wydajności mobilnej, gdzie czas CPU jest równie ważny co rozmiar pobieranych plików.

Skrypty stron trzecich: małe widgety, duże spowolnienia

Skrypty stron trzecich to wszystko, co Twoja strona ładuje z serwerów innej firmy. Są popularne, bo szybko dodają funkcje — ale mogą też być jednym z największych i najmniej przewidywalnych powodów spowolnienia ładowania strony.

Typowi winowajcy (i dlaczego przeszkadzają)

Najczęściej spowalniają:

• Analityka i trackery (Google Analytics, piksele, menedżery tagów)
• Widgety czatu (live chat, chatboty)
• Reklamy i retargeting (sieci reklamowe, header bidding)
• Embedy (YouTube, wpisy społecznościowe, mapy, widgety opinii)

Te skrypty często pobierają dodatkowe pliki, wykonują dużo JavaScriptu i czasem blokują przeglądarkę przed ukończeniem ładowania strony.

Jak wykryć „długie zadania” i skrypty blokujące

Otwórz Chrome DevTools → Performance, nagraj ładowanie strony i szukaj:

• Long tasks (duże bloki na głównym wątku). To zwykle oznacza, że JavaScript blokuje interaktywność.
• Skryptów uruchamianych wcześnie (zanim można przewinąć lub kliknąć), które opóźniają renderowanie.

Możesz też uruchomić Lighthouse (Chrome DevTools → Lighthouse) i sprawdzić rekomendacje związane z „Reduce JavaScript execution time” i „Eliminate render-blocking resources”.

Spraw, by skrypty zewnętrzne były mniej szkodliwe

Kilka przyjaznych początkującym pomysłów:

• Ładuj po interakcji, jeśli to możliwe: nie inicjalizuj czatu, recenzji ani embedów wideo dopóki użytkownik nie kliknie, nie przewinie lub nie otworzy panelu.
• Opóźnij nieistotne tagi: jeśli skrypt nie jest potrzebny do pierwszego widoku, nie uruchamiaj go w krytycznym momencie ładowania.

Zastąp ciężkie embedy lekkimi podglądami

Zamiast ładować pełne osadzenie YouTube/Facebook/Map na starcie, pokaż prosty podgląd (miniaturka + przycisk play). Prawdziwe osadzenie załaduj dopiero po kliknięciu.

To utrzymuje stronę szybką dla wszystkich — szczególnie na urządzeniach mobilnych — bez usuwania funkcji.