Responsywna strona internetowa - dlaczego to absolutny priorytet w 2026?

Co to jest strona responsywna i czym różni się od wersji mobilnej

Strona responsywna (RWD, responsive web design) to jedna strona pod jednym adresem. Układa się na nowo w zależności od szerokości ekranu. Na telefonie kolumny ustawiają się jedna pod drugą, menu chowa się pod ikoną, a zdjęcia skalują się do szerokości okna. Na monitorze te same treści rozkładają się w dwóch albo trzech kolumnach. Kod jest jeden, treść jest jedna, zmienia się tylko układ.

Technicznie odpowiadają za to trzy rzeczy. Deklaracja viewport w nagłówku strony mówi przeglądarce, że ma rysować stronę w szerokości ekranu, a nie udawać monitora. Elastyczne szerokości zamiast sztywnych pikseli pozwalają elementom kurczyć się i rozciągać. Punkty przełamania w arkuszu stylów zmieniają układ przy ustalonych szerokościach, na przykład chowają boczną kolumnę poniżej szerokości tabletu.

Alternatywą była kiedyś osobna wersja pod adresem m.domena.pl. Dziś to podejście przestarzałe. Dwie wersje oznaczają dwa zestawy treści do aktualizacji, dwa adresy dla tej samej podstrony i ryzyko, że Google zaindeksuje uboższą z nich. Jeśli Twoja strona nadal ma osobną wersję mobilną, przebudowa na jeden układ responsywny powinna być pierwszym punktem przy planowaniu zmian.

Responsywność to warunek wstępny, nie cel. Strona może poprawnie zmieścić się w ekranie i nadal nie działać dla klienta. Tekst jest za mały, przycisk połączenia jest na dole za galerią, a formularz wymaga powiększania. Dlatego w tym poradniku sprawdzamy stronę tak, jak sprawdza ją klient z telefonem w ręku, a nie tylko tak, jak widzi ją narzędzie.

Ten tekst jest częścią naszego przewodnika po stronach internetowych dla firm z Wielkopolski, w którym zbieramy decyzje do podjęcia przed zleceniem strony. Tu zajmujemy się jedną z nich: co ma działać na telefonie i jak to sprawdzić.

Jak Google czyta Twoją stronę na telefonie

Google indeksuje strony w trybie mobile-first. Robot wchodzi na stronę jako użytkownik telefonu i to, co zobaczy w tej wersji, trafia do indeksu. Jeśli na telefonie chowasz część opisu usług albo tabelę z parametrami, dla Google tej treści może nie być. Zasady opisuje dokumentacja Google w artykule o indeksowaniu mobile-first.

Z tego wynika kilka praktycznych reguł. Treść na telefonie i na komputerze ma być ta sama, może się różnić tylko układ. Nagłówki, opisy zdjęć i dane strukturalne mają być identyczne w obu widokach. Linki wewnętrzne, które na komputerze są w bocznej kolumnie, na telefonie muszą gdzieś istnieć, choćby pod treścią. Pliki obrazów i skryptów nie mogą być zablokowane dla robota.

Częsty błąd przy przebudowach wygląda tak. Firma zamawia nowy układ, a wykonawca „odchudza” wersję mobilną. Usuwa z niej realizacje i opis procesu, bo „na telefonie nikt tego nie czyta”. Po publikacji podstrona traci widoczność na frazy, na które przyciągały właśnie usunięte fragmenty. Treść można zwinąć w rozwijane sekcje, ale ma pozostać w kodzie strony.

Druga reguła dotyczy adresów. Przy jednej stronie responsywnej każda podstrona ma jeden adres, niezależnie od urządzenia. Jeśli przechodzisz z osobnej wersji mobilnej na układ responsywny, stare adresy m.domena.pl potrzebują przekierowań. Jak zaplanować je bez utraty pozycji, opisujemy w poradniku o przeniesieniu strony i przekierowaniach.

Jak sprawdzić to u siebie bez programisty. Otwórz tę samą podstronę na telefonie i na komputerze i porównaj sekcja po sekcji, czy wszystko jest w obu wersjach. Potem w Search Console użyj sprawdzania adresu URL i testu wersji na żywo. Narzędzie pokazuje zrzut ekranu i kod strony tak, jak pobrał je robot Google dla telefonu. Jeśli brakuje tam sekcji, której na komputerze nie brakuje, masz odpowiedź, zanim zapytasz wykonawcę.

Google nie obiecuje pozycji za sam fakt responsywności. Strona responsywna spełnia warunek wejścia, a o widoczności decydują treść, konkurencja i dalsza praca nad serwisem. Tak samo mówimy klientom przy wdrożeniu: podstawy techniczne przygotowujemy w ramach projektu, a pozycjonowanie jest osobnym zakresem.

Core Web Vitals: trzy liczby, którymi Google mierzy wrażenia ze strony

Core Web Vitals to zestaw trzech wskaźników mierzonych u prawdziwych użytkowników. Google opisuje je i podaje progi w dokumentacji Core Web Vitals w wynikach wyszukiwania. Liczby poniżej pochodzą z tej dokumentacji i mogą się zmieniać, dlatego przed audytem sprawdź aktualną wersję.

• LCP (Largest Contentful Paint) mierzy, po jakim czasie pojawia się największy element w widoku, zwykle zdjęcie w nagłówku albo główny tytuł. Dobry wynik to 2,5 sekundy lub mniej.
• INP (Interaction to Next Paint) mierzy, ile strona potrzebuje czasu, żeby zareagować na dotknięcie, kliknięcie lub wpisanie znaku. Dobry wynik to 200 milisekund lub mniej.
• CLS (Cumulative Layout Shift) mierzy, jak bardzo elementy przeskakują podczas ładowania. Dobry wynik to 0,1 lub mniej.

Z punktu widzenia klienta z telefonem te liczby opisują trzy znajome sytuacje. Strona długo pokazuje biały ekran. Przycisk po dotknięciu nie reaguje, więc klient dotyka drugi raz. Baner cookies albo zdjęcie ładuje się z opóźnieniem i przesuwa tekst w dół, akurat w chwili, gdy palec był nad przyciskiem „Zadzwoń”.

Dane terenowe i dane laboratoryjne

Narzędzie PageSpeed Insights pokazuje dwa rodzaje wyników. Dane terenowe pochodzą z przeglądarek prawdziwych użytkowników z ostatnich tygodni i to one liczą się dla Google. Dane laboratoryjne to pomiar z jednego, symulowanego urządzenia, przydatny do szukania przyczyny. Mała strona lokalnej firmy często nie ma dość ruchu, żeby dane terenowe w ogóle się pojawiły. Wtedy pozostaje pomiar laboratoryjny i własny telefon.

W Google Search Console raport Core Web Vitals rozdziela wyniki na telefon i komputer. Wersja mobilna prawie zawsze wypada gorzej, bo telefon ma słabszy procesor i wolniejsze łącze. Przy ocenie strony patrz na kolumnę mobilną. Dobry wynik na komputerze niczego nie mówi o tym, co widzi klient w samochodzie z jedną kreską zasięgu.

Co psuje się na telefonie najczęściej

Przeglądamy strony klientów przed każdą wyceną przebudowy. Poniższa lista powtarza się niemal w każdej z nich. Nie są to błędy techniczne w ścisłym sensie, tylko decyzje projektowe podjęte przy monitorze, których nikt nie sprawdził z telefonem w ręku.

Większość tych poprawek służy też osobom, które widzą gorzej albo obsługują telefon jedną ręką w rękawicy. Większe pola dotyku, czytelny kontrast i tekst, który da się powiększyć w ustawieniach systemu bez rozsypania układu, to te same decyzje, których wymaga dostępność. Od połowy 2025 roku część usług cyfrowych w Unii podlega wymaganiom dostępności, a czy dotyczą Twojej firmy, zależy od tego, co sprzedajesz i komu. Zakres opisuje dyrektywa dostępna na EUR-Lex, a interpretację zostaw prawnikowi.

Każdy z tych problemów da się naprawić bez przebudowy całej strony, jeśli strona ma sensowną konstrukcję. Jeśli problemów jest osiem na dziesięć podstron, poprawki kosztują więcej pracy niż nowy układ. Jak podjąć tę decyzję, opisujemy niżej w sekcji o poprawianiu i przebudowie.

Co ma działać na telefonie w Twojej branży

Klient z telefonem ma zwykle inne zadanie niż klient przy biurku. Dlatego zanim ocenisz własną stronę, ustal, co ta osoba chce zrobić w pierwszej minucie. Poniżej typowe sytuacje z firm, z którymi pracujemy.

Firma usługowa: instalacje, serwis, naprawy

Klient szuka z telefonu, bo coś się zepsuło albo stoi przed domem, który chce wyremontować. Chce zadzwonić albo wysłać zdjęcie miejsca montażu. Przycisk połączenia ma być widoczny bez przewijania, a formularz ma przyjmować zdjęcie prosto z aparatu. Lista miejscowości, które obsługujesz, ma być tekstem, nie grafiką, bo klient sprawdza, czy do niego dojeżdżacie. Godziny pracy i informacja o dyżurze serwisowym powinny być na pierwszym ekranie.

Produkcja i B2B

Tu klient z telefonu to często inżynier albo osoba z zakupów, która dostała link w mailu. Chce szybko ocenić, czy robicie to, czego potrzebuje, i zapisać kontakt do rozmowy przy komputerze. Tabele parametrów, karty w PDF i zapytanie z załącznikiem muszą działać na telefonie, choć samo zapytanie zostanie wysłane później. Przy stronach producentów oddzielamy procesy, materiały i zastosowania, żeby na małym ekranie dało się przejść do jednej usługi bez przeglądania całej oferty. Przykład strony dla firmy z przemysłu zobaczysz w realizacji Nomatec. Więcej o tym typie strony piszemy w poradniku o stronie internetowej dla firmy produkcyjnej i na stronie usługi strony dla firm produkcyjnych.

Handel i sklep

Klient porównuje ceny w sklepie stacjonarnym konkurencji albo na kanapie wieczorem. Filtry kategorii mają działać dotykiem, a zdjęcie produktu ma dać się powiększyć. Koszyk i płatność nie mogą wymagać przepisywania danych z karty przy złym świetle. Jeśli dopiero planujesz sprzedaż online, w poradniku sklep internetowy, jak zacząć opisujemy, od czego zależy wybór platformy.

Gastronomia

Tu klient prawie zawsze szuka z telefonu, bo chce zjeść za chwilę. Potrzebuje menu jako tekstu, nie zdjęcia karty, godzin otwarcia na dziś, numeru telefonu i mapy. Rezerwacja albo zamówienie w trzech dotknięciach. Co jeszcze sprawdzić, opisujemy w poradniku o stronie internetowej dla restauracji.

Budowlanka i wykończenia

Klient ogląda realizacje, często pokazując je komuś drugiemu na ekranie telefonu. Galeria ma otwierać zdjęcia w pełnym ekranie, z przesuwaniem palcem, i ładować się szybko także w terenie. Opis zakresu przy każdej realizacji ma być krótki, a przycisk „Zapytaj o podobny projekt” pod zdjęciem. Szczegóły zbieramy w poradniku o stronie www dla firmy budowlanej.

Deweloper

Kupujący ogląda inwestycję na telefonie w drodze z oględzin innej. Plan osiedla z wyborem domu wygląda dobrze na monitorze, a na telefonie bywa nieczytelny. Dlatego przy stronach deweloperów obok interaktywnego planu projektujemy tekstową listę ofert, żeby plan nie był jedyną drogą do karty domu. Na stronie VPM Development zapytanie wychodzi z karty konkretnej oferty, więc biuro sprzedaży wie, o który dom chodzi. Zakres takich stron opisujemy na stronie usługi strony dla deweloperów.

Jak sprawdzić, czy Twoja strona jest responsywna

Zacznij od własnego telefonu, nie od narzędzia. Narzędzie powie, że strona „jest mobilna”, bo układ mieści się w ekranie. Nie powie, że klient nie znajdzie numeru telefonu. Przejdź całą ścieżkę w roli klienta i zapisz, gdzie się zatrzymałeś.

1. Wejdź na stronę z wyników Google, nie z zakładki, bo klient trafia na podstronę usługi, a nie na stronę główną.
2. Sprawdź, czy bez powiększania czytasz nagłówek i pierwszy akapit.
3. Przewiń całą podstronę i zapisz, czy coś wystaje poza ekran w poziomie.
4. Otwórz menu i dojdź do trzech różnych podstron, a potem wróć na początek.
5. Dotknij numeru telefonu. Ma uruchomić połączenie, nie skopiować tekst.
6. Wypełnij formularz do końca, z załącznikiem, i sprawdź, co dostajesz na skrzynkę.
7. Obróć telefon poziomo i powtórz dwa poprzednie kroki.
8. Powtórz test na drugim systemie: jeśli masz Androida, poproś kogoś z iPhonem.
9. Wyłącz Wi-Fi i wejdź na stronę przez sieć komórkową, najlepiej poza miastem.

Narzędzia, które uzupełniają test ręczny

PageSpeed Insights od Google pokazuje wyniki Core Web Vitals osobno dla telefonu i komputera. Podaje też listę przyczyn: za duże obrazy, blokujące skrypty, brak wymiarów obrazów. Chrome DevTools (klawisz F12, ikona telefonu) pozwala przełączać szerokości ekranu i symulować wolne łącze bez wychodzenia z biura. Google Search Console w raporcie Core Web Vitals pokazuje, które adresy mają problem u prawdziwych użytkowników. Żadne z tych narzędzi nie zastąpi kroku piątego i szóstego z listy wyżej.

Jeśli strona ma analitykę, sprawdź jeszcze jedną rzecz. W GA4 porównaj udział telefonów w odwiedzinach z udziałem telefonów w wysłanych formularzach. Jeśli telefony dają większość ruchu, a prawie żadnego zapytania, to sygnał, że ścieżka na małym ekranie gdzieś się urywa. Konkretnych proporcji nie zakładaj z góry, porównuj własne dane z własnymi.

Co zapisać po teście

Z testu ma wyjść lista, którą można przekazać wykonawcy. Dla każdego problemu zapisz adres podstrony, model telefonu, co próbowałeś zrobić i co się stało. Zrzut ekranu zastępuje pół strony opisu. Taka lista pozwala wycenić poprawki bez zgadywania, a przy przebudowie staje się częścią wymagań wobec nowej strony.

Formularz i kontakt na małym ekranie

Zapytanie z telefonu wysyła osoba, która nie ma pod ręką klawiatury ani dokumentów. Formularz ma to uwzględniać. Najczęstsze powody porzucenia, które widzimy w zgłoszeniach klientów, to za dużo pól, nieczytelny komunikat o błędzie i zabezpieczenie, które każe wybierać obrazki z sygnalizacją świetlną.

Co zmieniamy przy projektowaniu formularza dla telefonu:

• Pola mają właściwy typ: numer telefonu otwiera klawiaturę numeryczną, adres e-mail klawiaturę ze znakiem małpy.
• Autouzupełnianie jest włączone, żeby telefon sam podstawił dane z pamięci.
• Załącznik można dodać z aparatu, bez szukania pliku w folderach.
• Błąd wyświetla się przy polu, nie na górze strony, i mówi, co poprawić.
• Zabezpieczenie przed spamem działa w tle. Stosujemy Cloudflare Turnstile, który nie wymaga klikania obrazków.
• Po wysłaniu klient widzi potwierdzenie i informację, kiedy się odezwiecie.

Liczba pól to osobna decyzja. Na telefonie każde pole kosztuje więcej uwagi niż na komputerze. Dla firmy usługowej wystarczają zwykle telefon, kod pocztowy i opis z możliwością dodania zdjęcia. Dla producenta sensowne są pola o etapie projektu i rodzaju materiału. Bez nich handlowiec oddzwania z pytaniami, które mogły być w formularzu. Jak dobrać pola do rodzaju zapytań, rozpisujemy w poradniku o formularzu kontaktowym, który przynosi zapytania.

Kontakt poza formularzem też wymaga sprawdzenia. Numer telefonu ma być linkiem uruchamiającym połączenie. Adres e-mail linkiem otwierającym pocztę. Adres firmy linkiem do nawigacji. Jeśli obsługujecie zgłoszenia przez komunikator, przycisk do niego ma otwierać aplikację z gotową wiadomością. Każde z tych połączeń testujemy na etapie wdrożenia, bo to one zamieniają odwiedziny na rozmowę.

Zdjęcia, czcionki i skrypty: skąd bierze się ciężar strony

Strona responsywna może być wolna. Układ dopasuje się do ekranu, ale telefon pobierze te same pliki co monitor, jeśli nikt tego nie zaplanował. Trzy źródła ciężaru powtarzają się w każdym audycie.

Zdjęcia

Zdjęcie z aparatu wrzucone wprost do strony waży kilka megabajtów i ma szerokość kilku tysięcy pikseli. Telefon wyświetla je w szerokości ekranu, ale pobrać musi całość. Pomaga zestaw wersji tego samego zdjęcia w kilku szerokościach, z którego przeglądarka wybiera pasującą, oraz format WebP zamiast JPG. Zdjęcia poniżej pierwszego ekranu ładują się dopiero wtedy, gdy klient do nich przewinie. Każde zdjęcie ma mieć zapisane wymiary w kodzie, żeby strona zarezerwowała miejsce, zanim plik się pobierze. Bez tego tekst przeskakuje, a wskaźnik CLS rośnie.

Czcionki

Każdy krój pisma to osobny plik do pobrania, a każda odmiana, na przykład pogrubienie, to kolejny. Projekt z czterema krojami w sześciu odmianach opóźnia pokazanie tekstu na wolnym łączu. Zwykle wystarczają dwa kroje w dwóch odmianach. Tekst ma być widoczny od razu w czcionce zastępczej, a właściwy krój podmienia się po pobraniu.

Skrypty zewnętrzne

Czat, mapa, osadzony film, wtyczka z opiniami, piksel reklamowy, baner zgody. Każdy z tych elementów to kod z innego serwera, który telefon musi pobrać i uruchomić. Osobno żaden nie jest problemem, razem potrafią podwoić czas ładowania. Przed wdrożeniem robimy listę skryptów i dla każdego pytamy, czy ma być na każdej podstronie i czy może ładować się po pokazaniu treści. Tagi analityczne i reklamowe spinamy w Google Tag Managerze z trybem zgody, żeby ładowały się raz i zgodnie z decyzją użytkownika.

Filmy i osadzenia

Film z YouTube osadzony wprost na stronie dociąga odtwarzacz i jego skrypty, zanim ktokolwiek nacisnął „odtwórz”. Na stronie głównej z trzema filmami to jeden z najcięższych elementów. Zamiast tego pokazujemy kadr z filmu jako zwykłe zdjęcie z przyciskiem, a odtwarzacz ładuje się dopiero po dotknięciu. To samo dotyczy osadzonych postów z mediów społecznościowych i map. Gdy osadzenie jest konieczne, trafia poniżej pierwszego ekranu i ładuje się leniwie, tak jak zdjęcia.

Jeśli zarządzasz stroną samodzielnie, ciężar rośnie z czasem. Każda nowa wtyczka, każde zdjęcie wgrane bez kompresji, każde dodatkowe osadzenie. Dlatego przy przekazaniu strony ustalamy rozmiar zdjęć, które zespół wgrywa, i listę elementów, których nie dodaje się bez konsultacji.

Szablon, WordPress czy własny kod: co to zmienia na telefonie

Każda z tych dróg może dać stronę responsywną. Różnią się tym, kto decyduje o układzie na telefonie i co dzieje się z nim po roku. Decyzję między WordPressem a własnym kodem omawiamy szerzej w poradniku WordPress czy własny kod. Tu patrzymy tylko na wersję mobilną.

Strony firmowe budujemy na WordPressie albo we własnym kodzie PHP, zależnie od zakresu i od tego, co firma ma aktualizować samodzielnie. Gotowy szablon ma sens, gdy strona jest tymczasowa albo zakres jest mały. Wtedy uprzedzamy, że układ mobilny będzie taki, jaki przewidział autor szablonu, a nasze poprawki będą ograniczone.

Przy przebudowie starszej strony na WordPressie sprawdzamy jeszcze jedno. Motywy sprzed kilku lat mają wersję mobilną dodaną później, jako nakładkę, i to ona najczęściej się rozjeżdża przy aktualizacjach. Jeśli po każdej aktualizacji wtyczek coś na telefonie przestaje działać, układ mobilny jest doklejony, a nie zaprojektowany.

Poprawić obecną stronę czy zbudować nową

To pytanie słyszymy przy większości zapytań o responsywność. Odpowiedź zależy od trzech rzeczy: konstrukcji strony, liczby problemów i tego, co jeszcze ma się zmienić.

Poprawki wystarczają, gdy strona ma jeden układ responsywny, a problemy dotyczą konkretnych elementów. Za mała czcionka, tabela, formularz, zbyt ciężkie zdjęcia. Takie rzeczy poprawiamy w istniejącym kodzie, bez zmiany struktury i adresów. Zakres ustalamy po przejrzeniu strony, w ramach uzgodnionych poprawek.

Przebudowa jest sensowniejsza w trzech sytuacjach. Strona ma osobną wersję mobilną. Układ opiera się na starym szablonie z doklejoną wersją mobilną. Poza responsywnością zmienia się oferta, struktura podstron albo identyfikacja. Poprawianie strony, której treść za chwilę będzie nieaktualna, to praca wykonana dwa razy. Kiedy przebudowa ma sens, rozpisujemy w poradniku o redesignie strony www.

Koszt obu wariantów zależy od zakresu i wyceniamy go indywidualnie po obejrzeniu strony. Od czego zależy wycena, opisujemy w artykule o tym, ile kosztuje strona internetowa. Przy poprawkach decyduje liczba elementów do zmiany. Przy przebudowie liczba i typy podstron oraz to, co ma powstać poza układem.

Pytania, które zadajemy przed decyzją

• Czy strona ma jeden adres dla każdej podstrony, czy osobną wersję m.domena.pl.
• Ile podstron ma problem na telefonie i czy to te same elementy na każdej.
• Czy po aktualizacjach systemu układ mobilny psuł się w przeszłości.
• Czy w ciągu roku zmieni się oferta, logo albo struktura strony.
• Czy obecna strona przynosi zapytania z Google, które trzeba zachować przy zmianie adresów.
• Kto będzie dodawał treści po zmianach i w jakim panelu.

Przykład z naszego biurka

Firma serwisowa z powiatu nowotomyskiego zgłosiła się z prośbą o „poprawienie strony na telefonie”. Strona była z 2016 roku, na WordPressie, z osobną wersją mobilną dodaną wtyczką. Na telefonie menu nie otwierało podstron usług, formularz nie przyjmował zdjęć, a numer telefonu był obrazkiem. Jednocześnie firma zmieniła nazwę i miała nowe logo, a połowa usług na stronie już nie istniała.

Poprawki w starym kodzie naprawiłyby menu i formularz, ale nie zmieniłyby treści, logo ani wtyczki mobilnej, która psuła się po każdej aktualizacji. Zaproponowaliśmy przebudowę: ten sam system, nowy motyw projektowany od telefonu, osiem podstron zamiast dwudziestu, formularz ze zdjęciem i przekierowania ze starych adresów. Firma dostarczyła opis usług i zdjęcia ekipy, my resztę. Stare adresy podstron, które przynosiły wejścia z Google, przekierowaliśmy na nowe. Zapytania z telefonu zaczęły przychodzić ze zdjęciem miejsca montażu, czego wcześniej nie dało się wysłać.

Jak projektujemy strony responsywne w ADREAMS

Pracujemy w czterech etapach, opisanych na stronie usługi tworzenie stron internetowych. Wersja mobilna pojawia się w każdym z nich, a nie dopiero przy testach.

Cel i zakres

Ustalamy, co klient ma zrobić na stronie i z jakiego urządzenia zwykle to robi. Dla serwisu instalacyjnego to telefon i zdjęcie, dla producenta zapytanie przy komputerze po pierwszym kontakcie z telefonu. Z tej odpowiedzi wynika, co pokazujemy na pierwszym ekranie w wersji mobilnej. Przeglądamy obecną stronę na telefonie i spisujemy, co się w niej urywa. Lista materiałów, które przygotowujesz po swojej stronie, jest w poradniku co przygotować do strony internetowej.

Treści i projekt

Projektujemy widoki telefonu i komputera równolegle, zaczynając od telefonu. Tam jest mniej miejsca i trudniej ukryć bałagan. Układ, który działa na wąskim ekranie, na szerokim zwykle tylko zyskuje. Przy projekcie ustalamy, które treści będziesz aktualizować samodzielnie, bo to wpływa na to, jak budujemy elementy. Pole na zdjęcie realizacji musi przyjąć pionowe i poziome ujęcie bez psucia układu. Zatwierdzasz oba widoki, zanim zaczniemy budować.

Wdrożenie i sprawdzenie

Budujemy stronę i przechodzimy listę z sekcji o testach na prawdziwych telefonach, z obu systemów. Sprawdzamy formularze z załącznikami, linki do połączeń i nawigacji oraz wersje językowe, jeśli są. Mierzymy Core Web Vitals w pomiarze laboratoryjnym. Dostajesz adres roboczy, żeby obejrzeć stronę na własnym telefonie przed publikacją. Uwagi z tego etapu zbieramy w jednej liście.

Publikacja i przekazanie

Po publikacji konfigurujemy pomiar w uzgodnionym zakresie, zwykle GA4 i Search Console, żeby dało się śledzić zapytania z podziałem na urządzenia. Przekazujemy instrukcję obsługi ustalonych elementów, w tym zasady wgrywania zdjęć, bo to najczęstsza przyczyna późniejszego spowolnienia. Opiekę po publikacji ustalamy osobno.

Pytania do każdego wykonawcy

Jeśli porównujesz oferty, te pytania pokażą, czy wersja mobilna jest w nich zaplanowana, czy tylko obiecana.

• Czy projekt obejmuje osobne widoki dla telefonu i komputera do akceptacji przed wdrożeniem.
• Na jakich urządzeniach i w jakich przeglądarkach strona będzie testowana przed publikacją.
• Co stanie się z układem mobilnym po aktualizacji systemu albo szablonu.
• Jakie rozmiary zdjęć będzie mógł wgrywać zespół i czy strona sama je przeskaluje.
• Czy formularz przyjmie załącznik z aparatu i jakie zabezpieczenie przed spamem zostanie użyte.
• Czy wykonawca sprawdzi Core Web Vitals dla telefonu przed przekazaniem i pokaże wynik.

Co dzieje się z responsywnością po publikacji

Strona responsywna w dniu publikacji nie jest responsywna na zawsze. Pięć rzeczy psuje ją najczęściej w pierwszym roku.

Treści dodawane przez zespół. Zdjęcie w pełnej rozdzielczości, tabela wklejona z Excela z dwunastoma kolumnami, akapit skopiowany z Worda z własnym formatowaniem. Każdy z tych elementów potrafi rozciągnąć stronę poza ekran. Dlatego instrukcja przy przekazaniu opisuje, jak dodawać treści, a nie tylko gdzie kliknąć.

Aktualizacje systemu i wtyczek. Na WordPressie po każdej większej aktualizacji wchodzimy na trzy typowe podstrony z telefonu. Zajmuje to kilka minut i wyłapuje większość problemów, zanim zauważy je klient.

Nowe elementy od innych dostawców. Czat od firmy obsługującej zgłoszenia, wtyczka z opiniami, kod od agencji reklamowej. Każdy z nich dokładamy przez Google Tag Managera i sprawdzamy, co robi z czasem ładowania na telefonie.

Zmiany po stronie Google. Progi Core Web Vitals i sposób pomiaru zmieniały się w ostatnich latach, a wskaźnik INP zastąpił wcześniejszy FID. Aktualny stan opisuje dokumentacja, do której linkujemy w sekcji o Core Web Vitals. Raport w Search Console pokazuje takie zmiany w pierwszej kolejności, dlatego raz na kwartał ktoś powinien do niego zajrzeć.

Nowe urządzenia. Składane telefony, tablety z rysikiem, bardzo szerokie monitory i okna przeglądarki ustawione obok siebie na jednym ekranie. Układ, który zakładał dwie konkretne szerokości, na takim sprzęcie pokazuje pustą przestrzeń albo ściśnięte kolumny. Dlatego projektujemy układy płynne, a nie dopasowane do listy modeli. Raz w roku ktoś z zespołu powinien obejrzeć stronę na sprzęcie, którego wcześniej nie było w firmie.

Pomiar po wdrożeniu nie sprowadza się do wyników narzędzi. W GA4 porównuj zapytania z telefonów i komputerów w czasie. Jeśli po dodaniu nowej sekcji albo wtyczki udział telefonów w zapytaniach spada, to pierwszy sygnał, że coś na małym ekranie przestało działać. W ramach opieki po publikacji możemy przejmować ten przegląd, a zakres ustalamy osobno.

Słownik pojęć, które usłyszysz od wykonawcy

• RWD (responsive web design). Sposób budowy strony, w którym jeden kod układa się na nowo zależnie od szerokości ekranu.
• Mobile-first. Projektowanie od wersji na telefon, a potem rozszerzanie układu na większe ekrany. Także sposób indeksowania Google, w którym liczy się wersja mobilna.
• Viewport. Obszar, w którym przeglądarka rysuje stronę. Deklaracja viewport mówi telefonowi, żeby nie udawał monitora.
• Breakpoint (punkt przełamania). Szerokość ekranu, przy której układ się zmienia, na przykład z trzech kolumn na jedną.
• Core Web Vitals. Trzy wskaźniki Google mierzone u prawdziwych użytkowników: LCP, INP oraz CLS.
• LCP. Czas do pokazania największego elementu w widoku.
• INP. Czas reakcji strony na dotknięcie lub kliknięcie.
• CLS. Miara przeskakiwania elementów podczas ładowania.
• Lazy loading. Doładowywanie zdjęć i filmów dopiero wtedy, gdy użytkownik do nich przewija.
• Srcset. Zapis w kodzie, który podaje przeglądarce kilka wersji zdjęcia w różnych szerokościach do wyboru.
• Pole dotyku. Obszar, w który trzeba trafić palcem, żeby uruchomić przycisk lub link. Większy niż sam napis.
• Hamburger. Ikona z trzech kresek, pod którą chowa się menu na małym ekranie.
• Dane terenowe. Pomiary z przeglądarek prawdziwych użytkowników, zbierane przez Google i pokazywane w PageSpeed Insights oraz w Search Console.

TL;DR

• Strona responsywna to jeden kod i jeden adres, który układa się na nowo pod szerokość ekranu. Osobna wersja m.domena.pl to przeżytek.
• Google indeksuje wersję mobilną, więc treść na telefonie ma być ta sama co na komputerze, choćby zwinięta.
• Core Web Vitals (LCP, INP, CLS) mierzą ładowanie, reakcję i przeskakiwanie. Patrz na wyniki dla telefonu.
• Test zacznij od własnego telefonu i pełnej ścieżki do zapytania. Narzędzia dokładaj potem.
• Najczęściej psują się tekst, tabele, menu, formularz i ciężkie zdjęcia. Każde z nich ma znaną naprawę.
• Formularz na telefonie potrzebuje właściwych typów pól, załącznika z aparatu i zabezpieczenia bez obrazków.
• Poprawki wystarczą przy pojedynczych problemach, przebudowa przy osobnej wersji mobilnej albo zmianie oferty.
• Po publikacji responsywność psują nowe zdjęcia, aktualizacje i cudze skrypty. Sprawdzaj stronę na telefonie po każdej zmianie.

FAQ