Przyspieszenie strony

Strona, która ładuje się pięć sekund, traci połowę odwiedzających, zanim cokolwiek zobaczą — a Google od dawna bierze szybkość pod uwagę przy układaniu wyników. Mierzę, co konkretnie spowalnia Twoją stronę, wycinam to i pokazuję liczby przed i po. Bez przepisywania serwisu od zera. Zielona Góra i cała Polska, zdalnie.

Po czym poznasz, że strona jest za wolna

Search Console pokazuje „Słabe adresy URL”

W raporcie Core Web Vitals Google wprost mówi, które podstrony ocenia źle i dlaczego. To najbardziej wiarygodne źródło, bo opiera się na danych prawdziwych użytkowników, a nie na jednorazowym teście.

Na telefonie treść skacze

Zaczynasz czytać, a tekst przeskakuje w dół, bo doładował się baner. Klikasz nie w to, co chciałeś. Google mierzy to osobno i jest to jeden z trzech wskaźników, które bierze pod uwagę.

Ludzie wchodzą i od razu wychodzą

W statystykach widać wejścia, ale prawie nikt nie przechodzi dalej niż pierwsza podstrona. Przy wolnej stronie to najczęściej nie wina treści — po prostu nie zdążyli jej zobaczyć.

Panel administracyjny muli

Jeśli Tobie zapisanie wpisu zajmuje kilkanaście sekund, odwiedzający ma podobnie. Wolny panel prawie zawsze oznacza przeciążoną bazę albo wtyczkę, która coś robi przy każdym kliknięciu.

Strona ma kilkadziesiąt wtyczek

Każda dokłada swoje skrypty i style do każdej podstrony, także tam, gdzie nie jest używana. Formularz kontaktowy ładuje się wszędzie, choć formularz jest na jednej podstronie.

Zdjęcia ważą po kilka megabajtów

Plik prosto z aparatu wyświetlany w okienku 600 pikseli. Najczęstsza przyczyna wolnej strony i zarazem najłatwiejsza do usunięcia.

Skąd się to bierze

Page builder

Divi, Elementor, WPBakery — wtyczki do wizualnego składania podstron. Wygodne w obsłudze, ale każdą podstronę obudowują własnym kodem, który musi się wczytać, zanim cokolwiek się pokaże.

Motyw z sześćdziesięcioma wersjami demo

Kupiony pod jedno demo, a ładuje zaplecze przygotowane pod wszystkie sześćdziesiąt.

Wtyczka na każdą drobnostkę

Osobna na przyciski, osobna na tabelki, osobna na ikonki. Każda ciągnie za sobą własną bibliotekę, nawet na podstronach, gdzie nic z niej nie ma.

Najtańszy hosting

Współdzielony serwer, na którym stoi kilkaset stron. Tu żadna optymalizacja nie pomoże, dopóki nie zmienisz serwera — i powiem Ci to od razu, zanim weźmiemy się za resztę.

Co robię

1. Mierzę przed

Core Web Vitals z Search Console, czas do pierwszej treści, waga strony, lista tego, co się wczytuje. To punkt odniesienia — bez niego „szybciej” jest kwestią wrażenia.

2. Biorę się za obrazy

Konwersja do WebP, dopasowanie rozmiarów do miejsc, w których naprawdę się wyświetlają, leniwe ładowanie tego, co poniżej ekranu. Na stronach ze zdjęciami to zwykle największy pojedynczy zysk.

3. Ustawiam cache i kompresję

Cache stron, kompresja, nagłówki przeglądarki, CDN jeśli ma sens przy Twoim ruchu. Konfiguruję pod konkretną stronę, a nie z domyślnych ustawień wtyczki — źle ustawiony cache potrafi popsuć koszyk albo formularz.

4. Wycinam to, co nie pracuje

Nieużywane wtyczki. Skrypty ładowane wszędzie, a potrzebne na jednej podstronie. Fonty w pięciu grubościach, z których używasz dwóch. Mapy, czaty i piksele przestawione tak, żeby nie blokowały pierwszego wyświetlenia.

5. Mierzę po

Te same wskaźniki co na starcie, zestawione obok siebie. Do tego lista, co zostało zrobione i czego świadomie nie ruszałem — razem z powodem.

6. Zostawiam instrukcję

Krótko i po ludzku: jak dodawać zdjęcia, żeby nie zepsuć tego, co zrobiłem, i czego nie instalować.

Wyjście z Divi albo Elementora

Jeśli strona stoi na page builderze, optymalizacja ma sufit. Da się zejść z czasu ładowania o jedną trzecią, ale nie zejdzie się do poziomu strony bez buildera, bo ten kod po prostu musi się wczytać. Mówimy tu o Divi, Elementorze czy WPBakery — czyli wtyczkach doklejonych do WordPressa, a nie o platformach typu Wix, z których nie da się „wyjść”, bo tam strona nie należy do Ciebie.

Wyjście z buildera to nie przełączenie przełącznika, tylko zakodowanie strony od nowa — każdą podstronę trzeba przełożyć na bloki WordPressa. Treść zostaje, wygląd zostaje, znika warstwa pośrednia, która spowalnia.

To osobna praca i osobna wycena. Taniej niż nowa strona, bo projektu graficznego nie trzeba robić od zera — ale to dalej budowa, a nie poprawka: 1 000 zł przy zwykłej stronie, 1 500 zł przy rozbudowanej, od 2 500 zł przy sklepie.

Sklep jest wyraźnie droższy — od 2 500 zł; tyle wyniosło ostatnie takie zlecenie. Tu nie wystarczy wyeksportować produkty, pozmieniać i zaimportować z powrotem — trzeba przenieść zamówienia, konta klientów, warianty i całą konfigurację płatności oraz wysyłki, a potem przejść ścieżkę zakupową od produktu do potwierdzenia zamówienia, żeby mieć pewność, że nic nie wypadło po drodze.

Czasem odradzam: przy stronie, która i tak nadaje się do wymiany, taniej wychodzi zbudowanie nowej — i wtedy tak mówię, zamiast brać pieniądze za przekładanie czegoś, co za rok wyleci.

Ile to kosztuje

To trzy różne zakresy i trzy różne wyceny. Kwoty są orientacyjne — ostateczną podaję po obejrzeniu strony.

Builder czy kreator — to to samo

Jedni mówią „builder”, inni „kreator”, jeszcze inni „page builder” — chodzi o to samo: wtyczkę doklejoną do WordPressa, w której składa się podstrony z gotowych klocków. Najpopularniejsze to Divi, Elementor i WPBakery. Jeśli osoba, która robiła Ci stronę, używała któregoś z tych słów, to jest dokładnie ta sytuacja.

Czym innym jest Wix, Squarespace czy WordPress.com. To nie wtyczka, tylko cała platforma — strona nie należy do Ciebie i nie da się jej stamtąd „odchudzić” ani przenieść jeden do jednego. Jedyną drogą jest zbudowanie strony od nowa na WordPressie, z przepisaniem treści. To też robię, ale wtedy rozmawiamy o nowej stronie, nie o optymalizacji.

Zamawiasz u mnie stronę albo sklep? Opiekę przez pierwszy rok masz 30% taniej.

A co z hostingiem

Jeśli po pomiarze okaże się, że wąskim gardłem jest serwer, powiem to wprost — i nie wezmę za to ani złotówki. Porządne firmy hostingowe przenoszą stronę za darmo, LH.pl robi to w ramach usługi. Podpowiem, gdzie przejść i na jaki pakiet, a przeniesieniem zajmie się nowy hosting. Nie ma powodu, żebyś płacił mi za coś, co dostajesz w cenie.

Czego nie obiecuję

Nie obiecuję setki w PageSpeed Insights. Ten wynik da się podbić sztuczkami, które ładnie wyglądają w teście i nic nie dają prawdziwemu odwiedzającemu, a czasem wręcz psują wygodę korzystania. Obiecuję konkretne liczby w Core Web Vitals i w czasie ładowania, zmierzone przed i po, na Twojej stronie.

Jak zaczynamy

1. Podajesz adres strony

Nic więcej nie potrzebuję do pierwszego pomiaru. Robię go z zewnątrz, bez dostępów.

2. Mówię, co da się wycisnąć

Dostajesz listę: co spowalnia stronę, ile z tego da się odzyskać i w jakiej cenie. Jeśli uznam, że zysk nie jest wart wydatku, też to powiem.

3. Pracuję etapami

Najpierw rzeczy bezpieczne i najbardziej opłacalne. Ryzykowniejsze zmiany robię na kopii i wdrażam dopiero po sprawdzeniu.

4. Raport przed i po

Te same wskaźniki zestawione obok siebie, plus krótkie podsumowanie, co dalej warto zrobić samemu.

Zaczynamy?

Pierwszy pomiar i odpowiedź, czy to się opłaca, są bezpłatne — potrzebuję tylko adresu strony.

Najczęściej zadawane pytania (FAQ)

Zależy od punktu wyjścia. Przy stronie ze zdjęciami prosto z aparatu i kilkudziesięcioma wtyczkami zejście o połowę czasu ładowania jest normą. Przy stronie już nieźle zoptymalizowanej zysk bywa niewielki — i wtedy powiem Ci przed rozpoczęciem, że nie warto.

Tak. Optymalizacja nie zmienia wyglądu ani treści — zmienia to, jak strona się wczytuje. Wyjątkiem jest wyjście z page buildera, które wyceniam i uzgadniam osobno.

Nie zawsze, ale czasem to jedyne, co realnie pomoże. Jeśli po pomiarze okaże się, że wąskim gardłem jest serwer, powiem to od razu. Samo przeniesienie strony na szybszy hosting to 200 zł, przy sklepie 600 zł.

Nie obiecuję setki i uważam, że gonienie za tym wynikiem to strata pieniędzy. Liczy się to, co Google zbiera od prawdziwych użytkowników w raporcie Core Web Vitals, i na tym się skupiam.

Da się, tylko z sufitem. Obrazy, cache i wycięcie zbędnych wtyczek zwykle dają zauważalną poprawę. Do poziomu strony bez buildera nie zejdziemy, bo jego kod musi się wczytać — i to jest moment, w którym rozmawiamy o wyjściu z buildera.

Ryzykowniejsze zmiany robię na kopii i wdrażam dopiero po sprawdzeniu. Najczęstszym źródłem problemów jest cache przy sklepach i formularzach — dlatego konfiguruję go ręcznie pod konkretną stronę, a nie z domyślnych ustawień wtyczki.