Twoja treść strony internetowej oraz jej nagłówki są przekonujące. Twoje przyciski nawołujące do działania krzyczą, aby je kliknąć. Jednakże czegoś tu brakuje, coś cały czas obniża konwersje. Prawdziwy zabójca konwersji czai się tuż za rogiem, całkowicie nietknięty – czas ładowania strony internetowej. Prędkość witryny często ma większy wpływ na konwersję w kampanii, niż jakikolwiek inny czynnik.
Skrócenie czasu ładowania strony – wpływ na ruch
Kilka lat temu Google doświadczyło dwudziestoprocentowego spadku ruchu tylko i wyłącznie z powodu opóźnienia ładowania o pół sekundy! Myślisz, że to mało? Jeżeli sklep internetowy nie może załadować się w pełni w czasie krótszym, niż 3 sekundy, to może stracić nawet 1/3 dotychczasowego ruchu. W rezultacie najlepsze sklepy internetowe potrafią załadować się w mniej, niż jedną sekundę.
Wpływ prędkości stron www stale pogarsza się na urządzeniach mobilnych, gdzie ograniczona moc obliczeniowa w połączeniu z kiepskim internetem jest normą. Zgodnie z wieloma przeprowadzonymi badaniami, ok. 74% mobilnych użytkowników opuści witrynę, jeżeli nie załaduje się w ciągu 5 sekund. W dzisiejszych czasach używanie telefonów i tabletów do przeglądania internetu szybko wyprzedza popularne laptopy oraz PC-ty. Ponadto dzisiaj konwersja nie ogranicza się tylko do jednej strony.
Wobec tego, jeżeli strony nie będą ładowały się z dostateczną prędkością, będziemy tracić coraz więcej konwersji.
Oczywiście nagłówki oraz treść są bardzo ważne. Fajnie jest mieć piękną i ciekawie zbudowaną stronę internetową. Jednakże, skrócenie czasu ładowania strony jest dziś nawet jeszcze ważniejsze, jeżeli chodzi o konwersje.
Jak znaleźć kompromis między ładną stroną internetową a szybką? Oto, co możesz zrobić:
1. Posprzątaj swój kod źródłowy.
Przejrzysty kod źródłowy witryny nie tylko sprawia, że twórcy stron internetowych są szczęśliwi, ale również powoduje, że strony ładują się znacznie szybciej.
Zmniejszenie rozmiaru plików witryny, zwłaszcza tych głównych, może mieć duży wpływ na skrócenie czasu ładowania strony. Nawet drobne kwestie typu spacje, akapity czy podział wierszy mogą zaszkodzić prędkości całego serwisu.
JavaScript to świetna zabawa, w wielu miejscach jest często niezastąpiony. Pozwala dodawać drobne szczegóły. Jednakże nadużywanie JavaScriptu może znacznie spowolnić czas ładowania strony.
Jeżeli skupisz się na prostocie oraz użyteczności strony internetowej, dojdziesz do wniosku, że te wszystkie dodatkowe atrakcje są zbędne. Niemniej, czasami jest ciężko zrezygnować po prostu z JavaScriptu lub jest to niemożliwe ze względu na wymagane funkcjonalności strony. Wówczas zastosuj się do zalecanych metod przez Google, czyli załaduj JavaScript bezpośrednio w kodzie (o ile skrypt jest krótki), opóźnij jego ładowanie lub rób to asynchronicznie.
Więcej możesz dowiedzieć się z filmu o optymalizacji ścieżek krytycznych podczas renderowania witryn internetowych. Informacje o swoim JavaScript możesz sprawdzić dzięki narzędziu Javascript usage tool.
2. Zmniejsz HTML oraz CSS.
Minifikacja HTML oraz CSS spowoduje „spakowanie” całej treści i dostarczanie jej do przeglądarek internetowych w jak najbardziej uproszczony sposób. Muszę przyznać, że dla wielu z Was zaczną się teraz schody. Jeżeli jesteś pewien swoich umiejętności technicznych, użyj kompresora JavaScript (uwaga, po kompresji nie wszystko może działać tak, jak powinno!). W przeciwnym wypadku sugeruję odwiedzić narzędzie Google PageSpeed Insights, wpisać adres swojej strony internetowej, a następnie wysłać wyniki dla kogoś, kto się na tym po prostu zna.
3. Wykorzystaj kompresję GZIP.
Jest to bezstratna kompresja danych, która powoduje skrócenie czasu ładowania strony www. Jak włączyć kompresję GZIP?
Jeżeli posiadasz serwer Apache, dodaj do swojego pliku .htaccess następujące dyrektywy:
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
Z kolei poniższe przeznaczone są dla serwerów NGINX:
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_vary on;
4. Zminimalizuj ilość przekierowań.
Przekierowania 301 to standardowa praktyka SEO, aby pokazać użytkownikom oraz wyszukiwarkom, że dana strona została na stałe przeniesiona do nowej lokalizacji (inny URL). Jest to świetny sposób na zniwelowanie błędów 404.
Problem zaczyna się wtedy, gdy mamy zbyt wiele przekierowań, które mogą negatywnie wpływać na skrócenie czasu ładowania strony. Więc pytanie brzmi, ile? W typowy dla siebie już sposób odpowiedź Google jest niejasna – zminimalizuj przekierowania do jak najmniejszej ilości, ponieważ powoduje to dodatkowe wycieczki użytkownika oraz robotów po sieci. Używając Screaming Frog możesz szybko zidentyfikować wszystkie obecne przekierowania na swojej witrynie.
5. Zmień lokalizację skryptów.
Wierz lub nie, ale nawet rozmieszczenie skryptów może wpływać pozytywnie lub negatywnie na skrócenie czasu ładowania strony. Przykładowo, jeśli skrypty śledzące są umieszczone w górnej części strony lub między znacznikami head, to przeglądarka będzie musiała sobie poradzić ze skryptami jeszcze zanim zacznie wyświetlać treść użytkownikom. Warto również dodać, że duplikaty skryptów (co jest dość powszechne, gdy wiele osób pracuje na tej samej stronie) będą odrobinę spowalniać witrynę.
Odpowiedzmy sobie na ważne pytanie: czy potrzebujemy dziesięciu kodów śledzących do analizy ruchu na naszej stronie internetowej? Prawdopodobnie nie. Podobnie jak większość rzeczy, o których już wspomniałem. Upraszczanie i minifikowanie pozwoli na znaczne skrócenie czasu ładowania strony.
6. Zmniejsz ilość wtyczek WordPress.
Otwórz swój panel administratora i zobacz, jak wiele wtyczek do wykonania najprostszych rzeczy masz zainstalowanych. Czasami po prostu instalujesz jedną wtyczkę, zapominasz o niej, a ona sobie nadal działa i wpływa negatywnie na skrócenie czasu ładowania strony Twojej strony internetowej.
Problem zaczyna się wtedy, gdy wtyczek jest tak wiele, że zaczynają one ze sobą kolidować, co prowadzi do wydłużenia się czasu ładowania witryny.
Jeżeli chcesz zdiagnozować, które wtyczki są warte zachowania, a które muszą być usunięte, to… jest na to inna wtyczka. 🙂 Plugin Performance Profiler zmierzy wydajność wszystkich wtyczek, które są zainstalowane na Twojej stronie.
7. Zmień swój hosting.
Wiele tanich rozwiązań hostingowych działa na zasadzie współdzielenia miejsca na serwerze z innymi witrynami. Może to ograniczyć możliwości w kwestii skrócenia czasu ładowania strony. Jest to szczególnie ważne w przypadku sklepów internetowych, na których mogą wystąpić nagłe skoki ruchu podczas promocji, co skutecznie może obniżyć ich szybkość ładowania. Mówiąc najprościej – kiepski hosting może zniszczyć całą Twoją kampanię marketingową w internecie.
8. Zoptymalizuj zdjęcia.
Śmierć, podatki oraz użytkownicy, którzy nie optymalizują zdjęć przed dodaniem ich do swojej strony – będą istniały zawsze.
Zmuszanie przeglądarki do tego, aby za każdym razem zmniejszała oryginalne zdjęcie do wielkości miniaturek, pomnożone przez ilość odwiedzin wszystkich podstron oraz wpisów, tworzy mnóstwo niepotrzebnej i dodatkowej pracy. Zwłaszcza na urządzeniach mobilnych z ograniczoną mocą obliczeniową i kiepskim połączeniem internetowym.
Idealnym rozwiązaniem jest zmiana rozmiaru zdjęcia i jego kompresja przed wysłaniem na serwer. Jeżeli stanowi to dla Ciebie zbyt wiele pracy, to przynajmniej wykorzystaj kolejną wtyczkę do WordPressa, np. WP Smush, która pomniejszy rozmiar zdjęć za Ciebie.
Jeżeli chcesz dowiedzieć się więcej na ten temat, odwiedź nasz poprzedni poradnik o optymalizacji zdjęć na stronie internetowej.
9. Dostarcz skrypty i zdjęcia poprzez CDN.
CDN, czyli system dostarczania treści do wielu centrów danych i punktów wymiany ruchu w internecie. W skrócie, jest to system wzywający posiłki z serwerów, które znajdują się najbliżej użytkownika witryny. Oznacza to, że strona będzie starała się korzystać z najbliższych serwerów w celu zmniejszenia czasu i wysiłku potrzebnego do dostarczenia zawartości z serwera do przeglądarki danego użytkownika. Najczęściej używane CDN to CloudFlare oraz MaxCDN. Takie zabiegi mogą drastycznie przyczynić się do skrócenia czasu ładowania strony internetowej.
Skrócenie czasu ładowania strony – podsumowanie
74% użytkowników opuści witrynę, jeżeli nie załaduje się ona w pełni w ciągu 5 sekund. Oznacza to, że wykorzystując wszystkie techniki na skrócenie czasu ładowania strony www, spora część użytkownicy i tak opuści Twoją witrynę i nie przyczyni się do wzrostu konwersji.
Zwiększenie szybkości strony możesz uzyskać dzięki podstawowym zabiegom typu ulepszenie hostingu i usunięcie niepotrzebnych wtyczek. Jeżeli czujesz się na siłach, możesz spróbować bardziej zaawansowanych technik, tzn. minifikacji plików JavaScript i CSS. Nawet zwracając uwagę na proces przesyłania zdjęć do strony www, można przyczynić się do skrócenia czasu ładowania strony.
Wdrożenie wszystkich zmian będzie niestety czasochłonne. Jednakże jest to bez wątpienia najlepszy sposób na poprawę czasu ładowania się witryny oraz konwersji.
Ciekawe porady. Trzeba też powiedzieć, że już te 70-80% to wynik zadawalający 🙂
Eheh, muszę jednak zoptymalizować stronkę 🙂 Dzięki za porady!
Dlaczego po wklejeniu regułki z z punktu 3 strona zamiast się wczytywać wywala mi błąd 500?
Tomku, sprawdź działanie dyrektyw do momentu linijki:
„# Dziala tylko na Apache!”
Jeżeli błąd 500 powodują regułki zawarte poniżej tej linijki, prawdopodobnie Twoja strona nie leży na Apache, a na NGINX. Za chwilę zamieścimy wyraźniejszą adnotację we wpisie, uzupełnimy też go o właściwe komendy dla NGINX.
Problem jest właśnie taki, że zrobiłem to w panelu CMS klienta, a nie mam dostępu do ftp. Nie wiem teraz co mam zrobić, bo nie chciałbym pokazać klientowi, że coś zepsułem 😛 Strona stoi na OVH.
Chodzi o to, aby edytować po prostu plik .htaccess – nieważne jak to zrobisz, to w nim dokonujesz zmian. Jeżeli coś poszło nie tak, to po prostu przywróć poprzednią wersję pliku.
Edytowaliśmy też wpis z wersjami komend dla poszczególnych typów serwera.
Nie jestem w stanie tego zrobić, bo nie mogę się zalogować do CMSu. No nic, będę musiał coś wymyślić.
No niestety, .htaccess to jeden z najbardziej newralgicznych plików każdej strony internetowej. Każdy zbędny znak powoduje natychmiastowy błąd 500. Jakiekolwiek zmiany w nim powinny być poprzedzone utworzeniem kopii zapasowej, aby w razie niepowodzenia móc szybko przywrócić poprzednią wersję pliku.
Tak porady przydatne. Jednak mnie osobiście wynik 70-80% nie zadowala choć osiągnięcie 100% na stronie internetowej często kosztuje sporo nerwów.
Dodatkowo nie zawsze wynik 100% ma sens. Nierzadko zdarza się, że strasznie cierpi na tym UX.
Możliwe, nie neguję tego. Prawdę mówiąc często mnie strasznie irytują komunikaty z narzędzia Googla. Jednak wychodzę z złożenia, że jeśli zależy mi na pozycji Google to chcę osiągnąć najlepszy sugerowany wynik google. Oczywiście trzeba też zważać na funkcjonalność strony, nie może to być takim kosztem. I dlatego to często tak denerwująca sprawa.
A mógłbyś rozwinąć temat szkodliwości dla UX?
To jest bardzo ciekawy temat.
Należy zacząć od tego, że PageSpeed Insights jest testerem bardzo miernym. Tak na dobrą sprawę nie wskazuje on nic konkretnego, istnieją dużo lepsze mierniki – takie jak GTmetrix czy Pingdom Website Speed Test. Podają one zdecydowanie więcej informacji, niż googleowskie narzędzie. Tym bardziej, że sama strona google.pl nie przechodzi pomyślnie swojego własnego testu…
Co do UX, to sprawa jest następująca:
1. Jedno z ostrzeżeń testu googleowskiego ma tytuł „Wykorzystaj pamięć podręczną przeglądarki”. Sęk w tym, że nie da się spełnić tego warunku, jeżeli trzeba korzystać z zewnętrznych skryptów, które siłą rzeczy muszą być doładowywane dynamicznie. Przechowywanie ich na własnym serwerze mija się z celem – po to są one pobierane z zewnątrz, aby taki stan utrzymać. Dzięki temu mamy pewność, że strona korzysta ze skryptów w najnowszej możliwej wersji. Tak więc już tutaj 100/100 nie jest czasem możliwe.
2. Jest jeszcze coś takiego, jak „Wyeliminuj blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie”. Tutaj też pojawia się problem. Ponieważ nawet jeśli mamy tylko jeden plik CSS, to ostrzeżenie to pokaże się i tak i tak. Można się go pozbyć poprzez asynchroniczne załadowanie CSS-a. Tylko że wtedy użytkownicy, zanim załaduje im się strona w sposób pożądany, zobaczą na ułamek sekundy bardzo brzydki widok – czarny tekst na białym tle + kilka bezładnie wiszących obrazków. Taki swoisty „przeskok”. Dopiero po chwili CSS się doładowuje. PageSpeed Insights jest z takiego wyniku zadowolne, jednak nasi klienci przeważnie nie. I mimo tego, że naszym celem jest wynik 100/100, to w większości przypadków klienci proszą nas o to, aby tego „przeskoku” nie było. Co już dyskwalifikuje spełnienie tego warunku googleowskiego testera.
Takich smaczków jest jeszcze nieco więcej.
Tak, w zasadzie wymieniłeś wszystkie te problemy które strasznie mnie samego irytują (i chyba są najgorsze do rozwiązania jeśli się chce zachować jednocześnie funkcjonalność strony). Jednak udaje mi się je obejść. Zaznaczę tylko, że faktycznie nie korzystam z zewnętrznych linków do bibliotek. Jednak ja cały czas mam na myśli serwis pisany przeze mnie od zera. Więc takie rzeczy jak uaktualnienie bibliotek mogę zrobić programowo po stronie serwera. Nie zmienia to faktu, że często jest to naprawdę ale to naprawdę upierdliwe. I jak pisałem ja też uważam, że nie może to odbić się na tym co najważniejsze – wygodzie odbiorcy. Co do narzędzi to też używam tych przez Ciebie wymienionych. Dodatkowo fajne jest też moim zdaniem Web Page Performance Test, też podaje kilka przydatnych informacji.
Otóż to. Tak to już jest – wskaźniki swoje, wygoda użytkowników swoje. Cała sztuka w tym, aby znaleźć złoty środek. 😉
Dokładnie:)
hej, pod wpływem artykułu zacząłem eksperymentować z gzip i deflate. Ten drugi był zaimplementowany jednak po zmianie na gzip strona na wordpress wyraźnie przyspieszyła 😉