[Q&A] Podstawy optymalizacji technicznej – WordPress i WooCommerce

Optymalizacja techniczna ma wpływ na pozycjonowanie strony, ale często jest odkładana na później. A to błąd, bo poprawnie i szybko działająca strona internetowa, to połowa sukcesu. Chcesz samodzielnie usprawnić działanie swojego serwisu? Sprawdź rozmowę dwóch ekspertek SEO o podstawach optymalizacji technicznej na przykładzie WordPressa – poniższy tekst to transkrypcja jednego z naszych webinarów i ma formę pytań oraz odpowiedzi. Spotkanie prowadziła Milena Majchrzak z SEMSTORM (M), a odpowiedzi udzielała Aneta Rutkowska z LH.pl (A).

 

Szybkość ładowania strony

M: Optymalizacja to jest bardzo skomplikowane i szerokie zagadnienie, które obejmuje bardzo wiele podzagadnień. Dla uproszczenia rozbijmy więc ją na takie podskładowe. Zacznijmy od szybkości ładowania strony, bo to chyba najczęściej jest wspominane, jako taka ważna rzecz. To cegła, kamień węgielny, bez którego nie da się prowadzić optymalizacji. Czy to faktycznie jest tak ważne i dlaczego ta szybkość ma taki wpływ na optymalizację?

 

A: Tak, optymalizacja to bardzo złożony i trudny temat. Często już samo słowo optymalizacja budzi strach. Jak jeszcze dorzucimy do tego optymalizację techniczną, to osoby początkujące bardzo boją się, że sobie nie poradzą. Nie podejmują się więc tego, rezygnują i odkładają na później. Gdy rozwinie się im biznes lub będą mieć środki, by kogoś do tego zatrudnić.

Z takim podejściem bardzo często spotykamy się w LH.pl. Postaram się to dzisiaj przełamać. Powiem o takich podstawowych działaniach optymalizacyjnych, które może wykonać każdy z nas. I rzeczywiście, praca nad prędkością działania strony jest jedną z podstawowych spraw.

Dlaczego? Tak naprawdę wynika to z tego, że Google już od 2010 roku, mniej więcej, mówi nam, że prędkość ładowania strony staje się coraz ważniejsza. Zaczynają coraz wyżej rankować te serwisy, które ładują się szybciej. I to był pierwszy sygnał. Przez kolejne lata to stało się jeszcze ważniejsze i jest weryfikowane na większą skalę.

Te początki dotyczyły pierwszego podejścia do User Experience, czyli jak użytkownik, który wchodzi na stronę, na niej się czuje. Czy treść, której szukał, miał zaserwowaną dosyć szybko, czy nie? Czy te strony ładują się wolno, czy nie? W pierwszych komunikatach z 2010 roku były też takie informacje, by dążyć do optymalizacji ze względu na koszty przesyłu danych, które też nie są zoptymalizowane.

Drugi sygnał ze strony Google przypłynął w 2018 roku. Wówczas internet oszalał pod kątem mobile first. Był to speed update. Wszyscy mówiliśmy o tym, że na urządzeniach mobilnych strony muszą teraz super śmigać, bo jeżeli nie będą, to w ogóle nie będą miały ruchu. Google troszeczkę to przełamał w swoim komunikacie, w którym podkreślał, że prędkość ma znaczenie, ale strony, które są wysoko wypozycjonowane ze względu na treści, nadal będą wysoko, one mocno nie stracą. To było uspokojenie tego całego szaleństwa skupionego na prędkości strony.

Natomiast od 2018 do dzisiaj pojawia się cały czas wiele sygnałów od Google. W tym tak zwana rewolucja, czyli lista czynników do badania pod kątem optymalizacji, określonych jako Core Web Vitals. To nie były nowe czynniki. One istniały, tylko teraz zyskały na znaczeniu. Wśród nich pojawiła się kwestia prędkości ładowania strony, która ma coraz większy wpływ na pozycję w Google. Co więcej, są dowody, że strony ładujące się szybciej, mają większe szanse (ale nie pewność) na pierwszą dziesiątkę. Warto jednak wiedzieć, że pod uwagę brane są też inne czynniki.

 

W ramach Core Web Vitals wyróżnia się 3 wskaźniki: LCP, FID oraz CLS. Wchodzą one w skład sygnałów page experience.

https://developers.google.com/search/blog/2020/05/evaluating-page-experience?hl=pl

 

M: Jest 200 czynników rankingowych i te związane z optymalizacją techniczną, to jest jedynie wycinek całości. Warto postarać się, by te wszystkie 200 zrobić dobrze, a nie skupiać się tylko na jednym czy dwóch. Żeby je zrobić dobrze, trzeba je znać i jednym z nich jest właśnie prędkość ładowania strony.

 

Narzędzia do badania prędkości ładowania strony

 

Czy jest jakieś ogólnodostępne narzędzie do takiego pomiaru prędkości?

 

A: Od tego są testy zewnętrzne, które są bardzo syntetyczne i opierają się na większej próbce niż porównanie dwóch konkurujących stron. Trzy podstawowe narzędzia to:

  • Pingdom Website Speed Test,
  • GTmetrix,
  • PageSpeed Insights.

 

Pingdom Website Speed Test

To bardzo proste narzędzie, w którym wpisuje się adres swojej strony i wybiera się, skąd ma być wykonywany test. I tu jest ogólna zasada robienia testów prędkości strony. Zawsze wybierajcie serwer najbliższy Wam albo Waszym klientom, jeżeli gdzieś sprzedajecie albo serwujecie jakieś usługi za granicą. Dla usług z Polski będzie to serwer z Frankfurtu.

 

GTmetrix

Bardziej syntetyczne narzędzie, można wybrać sobie wykonywanie testu z bardzo wielu miejsc. Haczyk: jeżeli wejdziesz na stronę, nie mając tam konta (a założenie go trwa chwilę), to pierwszy wykonany test będzie z Vancouver, z Kanady. Nie ma sensu testować stamtąd strony, chyba że macie tam klientów. Warto założyć konto i testować z Londynu, bo to jest najbliższy Polsce serwer do testów.

 

PageSpeed Insights

Najbardziej popularne, narzędzie od Google, podpowiada, co można zoptymalizować na stronie.

 

M: Również SEMSTORM ma narzędzia, które między innymi wspomagają badanie szybkości strony. Sekcja „Audyty” to nie jest tylko szybkość. To jest cała masa innych rzeczy, które można poprawić – związanych z optymalizacją techniczną, z kwestiami bezpieczeństwa. Jeżeli narzędzia pokazują, że coś nie gra, to warto zajrzeć nieco głębiej.

 

Audyty w SEMSTORM pokazują, którymi elementami strony warto się zainteresować, by poprawić optymalizację techniczną.

 

 

Nie lepiej zbadać to za pomocą Search Console?

 

A: Nie polecam – tak samo jak nie polecam raportu, który generuje się w Google Analytics. W Google Analytics jest to próbka bodajże 2% wszystkich odwiedzin, więc jest bardzo mała. Mam wiedzę na temat tego raportu sprzed kilku miesięcy (rozmowa odbyła się 28 października 2021 roku), kiedy jeszcze mówiło się o tym, że ta metryka jest wciąż przez Google testowana i udoskonalana. Lepiej więc poczekać, aż zostanie dopracowana i wtedy z niej korzystać.

 

M: W SEMSTORM korzystamy z Lighthouse, bo zależało nam na czymś więcej, niż tylko prędkość ładowania strony, a to narzędzie daje też perspektywę klienta i pokazuje nie tylko, czy strona ładuje się szybko, ale czy jest też szybko interaktywna.

 

W skład audytu SEMSTORM wchodzą m.in. dane z Lighthouse.

 

A: Dlatego Google wprowadził Core Web Vitals. By zwrócić uwagę na doświadczenie użytkownika. Jak długo musi czekać, aż strona się załaduje? Jak szybko uzyskuje ona pełną interaktywność? Jak długo musi czekać, aż strona będzie stabilna (wyświetlą się wszystkie banery, pop-up'y, ciasteczka itp.). Google kładzie na to nacisk i zwraca uwagę, a te informacje w GTmetrix są bardzo fajnie pokazane.

 

Przykładowy wynik strony w narzędzi GTmetrix

Strona z prezentacji Anety Rutkowskiej, na której pokazany jest wynik testu z https://gtmetrix.com/

 

Jeżeli strona chodzi na https, to do testu trzeba wrzucić adres z https. Wykres pokazuje, jak szybko załadowały się poszczególne punkty ładowania strony:

  • TTFB (Time To First Byte), 
  • LCP  – czyli jeden z czynników Core Web Vitals,
  • onload time – czyli ten czas załadowania strony, który kiedyś w GTmetrix był jako ogólny czas ładowania strony plus kilka innych informacji,

na podstawie których możemy predykować. To jest pierwszy punkt, który pokazuje, gdzie szukać przyczyny problemu z szybkim ładowaniem strony i jak go rozwiązać. 

 

Działanie strony internetowej a jej prędkość ładowania

A: Najpierw przeanalizujmy te wszystkie punkciki, które pojawiają się na wynikach z GTmetrix. Żeby to zrozumieć, trzeba zrozumieć, jak działa strona internetowa.

 

Schemat działania strony internetowej z prezentacji Anety Rutkowskiej

Strona z prezentacji Anety Rutkowskiej

 

  1. User →
  2. Zapytanie (wywołuje zapytanie; wykonuje pierwszą akcję) →
  3. Zapytanie kierowane jest do serwera DNS, który „wskazuje” serwer właściwy dla zapytania →
  4. Serwer (hosting), na którym hostowana jest strona internetowa z odpowiedzią; tu jest WordPress, wtyczki, motyw, dodatkowe skrypty dograne, obrazki, zdjęcia →
  5. Zapytanie jest przetworzone (serwer musi zareagować, uruchamiają się skrypty PHP, pobudzenie bazy danych, baza danych odpowiada i to wszystko dzieje się na hostingu) →
  6. Przekazanie treści przez skrypt.

 

Co wpływa na czas operacji na poziomie hostingu (punkty: 4-6)?

A: Problem prędkości działania strony czy zbyt długiego ładowania strony bez analizy hostingu (czy nie jest blokerem) nie może być rozwiązany. Informacja z hostingu pozwala iść dalej.

Z procesorami hostingowymi, jest tak samo, jak z procesorami w komputerach. Im nowszy procesor, im bardziej wydajny, im ma więcej rdzeni i więcej mocy w ogóle, tym szybciej przetwarza zapytania. Pierwsza sprawa to jest prędkość dysków. Im szybsze dyski, tym operacje zapisu i odczytu danych wykonują się po prostu szybciej. To są dwie techniczne rzeczy, które mają wpływ na czas wykonania tego pierwszego zapytania do serwera, które w ogóle idzie. Druga sprawa to jest reakcja serwera DNS i ogół tych wszystkich działań zależy od hostingu. Są jednak też czynniki, które nie zależą od hostingu.

 

Co wpływa na czas operacji poza hostingiem?

A: Jest to:

  • sposób, w jaki została napisana aplikacja,
  • liczba wtyczek (3 czy 33),
  • motyw (prosty, bez page buildera, czy wielki kombajn, który wykonuje wiele różnorodnych operacji),
  • optymalizacja strony,
  • cache – to także ma wpływ na parametr TTFB, czyli Time To First Byte.

TTFB to parametr, który pokazuje, jak szybko serwer przetwarza zapytanie, czyli reaguje. Natomiast sprowadzenie TTFB do samego hostingu czy hostingodawcy nie jest do końca słuszne. Wpływają na to też kwestie optymalizacji strony, choć jakość serwera udostępnionego przez hostingodawcę i konfiguracje zastosowane na tym serwerze, mają ogromne znaczenie.

 

M: LH ma usługi dedykowane pod WordPress. Skąd ta miłość?

 

A: Hostingujemy obecnie ponad 30 000 WordPressów na serwerach i nie ma dnia, żeby BOK nie otrzymał jakichś zapytań właśnie o WordPress. Większość stron hostowanych to WordPress. Globalnie WordPress ma 40% udział w rynku stron internetowych, a gdy się spojrzy na strony wyłącznie postawione na CMS (system do zarządzania stroną internetową), to ten udział jest 60%, więc jest to gigant, jeżeli chodzi o popularność CMS, więc nie można go ignorować.

 

M: W raportach technologii, które mamy w systemie w SEMSTORM, wszystkich WordPress, które widoczne są w polskim Google na przynajmniej jedno słowo kluczowe – jest 5 milionów. Ciekawostka: na WordPress stoi Uniwersytet Warszawski.

Porozmawiajmy jednak o wnętrznościach strony, bo nie tylko hosting ma znaczenie, ale też to, jak została napisana aplikacja. Zacznijmy od czegoś, co jest mi bardzo bliskie, bo zaczynałam, jako front-end developer – wygląd. Czy wygląd, skórka jest istotna? Czy mogę ściągnąć pierwszą lepszą darmową i odpalić na tym moją pierwszą stronę firmową?

 

A: Zanim przejdę do odpowiedzi, jeszcze słowo o TTFB. Możecie sprawdzić GTmetrix swoje strony i zobaczyć, jak długi jest ten TTFB. Jeżeli jest on do 300 – 400 milisekund to jest on ok i nie ma czym się martwić, bo to jest bardzo fajny czas na przetworzenie pierwszego zapytania. Jeżeli jest powyżej lub sięga nawet 1 sekundy, to zwróćcie uwagę na to, gdzie macie hosting i jakie macie rzeczy na tym hostingu skonfigurowane. Tu trzeba sprawdzić, czy nie jest włączona stara wersja PHP na WordPress. Czy hosting nie jest wolny (firma nie rozwija architektury serwerowej, nie dba o jakość sprzętu). Sposobem na przetestowanie tego jest zmigrowanie do innego hostingu i sprawdzenie TTFB. Jeżeli znacząco spadnie to znak, że to hosting był problemem.

 

Wygląd strony internetowej, a prędkość jej ładowania

A: Kwestia strony. W WordPress mamy dostęp do tysięcy bezpłatnych motywów i wtyczek oraz płatnych rozwiązań. I gdy sobie tego nawybieramy za dużo, to może być problem. Po przeanalizowaniu w LH ponad 30 000 WordPress okazało się, że klienci mają średnio po 11 wtyczek, a rekordzista ma 93 i ta strona jeszcze działa.

Trzeba sobie uświadomić, że im więcej dodatków do tego WordPress zainstalujecie, im więcej kodu dorzucicie lub im więcej dodatków słabej jakości (bo to, w jaki sposób jest wtyczka napisana, również może się bardzo od siebie różnić), tym ten czas załadowania strony po prostu będzie większy.

Im więcej skryptów będzie ładowało się w tym pierwszym załadowaniu, tym ten czas będzie się wydłużał. Im bardziej skomplikowany motyw sobie zainstalujemy, tym ten czas się będzie wydłużał. I jak już o tym rozmawiamy, to nasuwa mi się jeszcze kolejna sprawa, czyli page builder, czyli te wtyczki, które mają pomóc i szczególnie dla osób początkujących są bardzo kuszące, bo ładnie wyglądają wizualnie.

 

Jak page builder wpływa na prędkość ładowania strony

 

Czemu skoro prędkość jest taka ważna, duża część osób decyduje się na page buildery typu elementor, wp – bakery?

 

M: Może ich popularność bierze się z prostoty. Wezmę page builder, wszystko wyklikam i z głowy.

 

A: Trzeba na początek rozdzielić strony budowane na kreatorach jak na przykład wix od page builderów instalowanych jako wtyczka. Zajmiemy się tymi drugimi. Myślę, że ich popularność wzięła się z tego, że WordPress miał kiedyś bardzo nieładny, nieprzyjemny edytor wizualny.

Klasyczny edytor wizualny wyglądał trochę jak word i page buildery pojawiły się jako rozwiązanie wszystkich problemów osób, które nie znały HTML i CSS i nie potrafiły sobie na froncie takimi prostymi zmianami cokolwiek ustawić. Na przykład marginesy albo tabelki, które w klasycznym edytorze to było po prostu przekleństwo. I to było rozwiązanie dla osób, które chciały mieć szybki efekt, móc sobie wszystko poklikać taką metodą przeciągnij i upuść.

I ogólnie sama idea page builderów była słuszna, bo WordPress dążył i cały czas dąży do tego, by być jak najbardziej przyjaznym dla początkujących i by ten próg wejścia do WordPress był coraz niższy. I to jest wszystko super.

Natomiast problem z page builderami dotyczy głównie tego, jak one są pisane. One zawierają bardzo dużo kodu. Generują dużo większe obciążenie dla samego serwera niż zwykła strona, która jest oparta o edytor, który jest w WordPress wbudowany.

W 2018 WordPress wprowadził nowy edytor wizualny – Gutenberg. To edytor blokowy, który jest odpowiedzią na page buildery. Jest formą page buildera, bo umożliwia budowanie treści, tworzenie nawet całych stron, landingów, podstron, a także tworzenia contentu na blogu za pomocą bloków. Czyli wybieramy sobie blok galeria, wybieramy blok tabelka, blok kolumna i wypełniamy treściami. Super przyjemnie się to wszystko robi. Gdy się porówna Gutenberga, tego, który razem z instalacją nowego WordPress jest wrzucany z elementorem, to się nagle okazuje, że tam jest dwa razy więcej żądań.

Jeżeli w czasie załadowania strony znaczenie ma to, co idzie na sam początek, czyli to pierwsze załadowanie, ten pierwszy element – to im ten pierwszy element jest mniejszy, im zgrabniejszy, lepiej napisany, tym to załadowanie jest szybsze.

Ale jeżeli porównamy sobie page buildery ze zwykłym Gutenbergiem, to się nagle okazuje, że to drzewo dom, czyli drzewo elementów struktury strony jest dwa razy większe, bo jest więcej elementów, chociażby HTML. Jest dwa razy więcej plików HTML (elementor), jest dwa razy więcej żądań, ten ładunek tych plików do załadowania jest też dwa razy większy, dalej jest więcej zapytań do bazy danych. A im więcej zapytań do bazy danych, tym ten czas załadowania jest dłuższy. I to niestety jest problem page builderów.

One są super rozbudowane, mają dużo elementów graficznych do dostosowania, dają bardzo dużo możliwości, ale idzie za tym kiepskiej jakości kod, albo kod dużo bardziej udziwniony. Czysty kod Gutenberga jest lżejszy i ładniejszy dla oka niż kod elementora. Page buildery są sporą przeszkodą do dobrej optymalizacji strony.

 

Czy to jest przeszkoda nie do przeskoczenia?

 

M: Co byś radziła, czy przebudować tego page buildera, czy jakieś inne rozwiązanie?

 

A: Można zoptymalizować stronę na page builderze, ale to już wymaga trochę więcej wiedzy. Trzeba trochę głębiej wejść w kod. Zoptymalizować sobie samemu ten kod. Wtedy to nie jest takie proste dla osoby początkującej.

Jeżeli zastosujemy sobie page builder tylko na stronie głównej, bo tak nam jest łatwiej po prostu wyklikać sobie stronę główną, ale podstrony zachowamy już natywnie, wpisy blogowe będą już pisane w WordPress, a nie w page builderze – to strona już będzie lżejsza.

Header, footer to może podrzuci nam motyw. Może będzie miał taką możliwość, żeby ustawić sobie taki nagłówek i taką stopkę, jaką chcemy.

Problem polega na tym, kiedy sobie w tym page builderze wyklikamy absolutnie wszystko i za każdym wywołaniem jakiejkolwiek podstrony te wszystkie skrypty i pliki page builderowe będą się ładowały i tym bardzo dużym ładunkiem, będą ten czas ładowania opóźniały.

 

Dodatkowe wtyczki – jak wpływają na obciążenie strony

 

A co z nakładkami na Gutenberga, np. Kadence?

 

A: Nakładki na Gutenberga nic mi nie mówią. Może uda się doprecyzować to pytanie. Do Gutenberga jest bardzo dużo wtyczek w tym momencie, które rozszerzają nieco jego możliwości. I tu też trzeba działać bardzo ostrożnie, a nie że zainstalujemy sobie wszystkie wtyczki, które nam tego Gutenberga rozszerzają.

Jeżeli potrzebujemy sobie ustawić jakąś konkretną treść, jakiś timeline, bo chcemy pokazać, jak rozwijała się nasza firma, to można poszukać wtyczki, która pozwala na wprowadzenie takiego bloku. Zainstalować tę wtyczkę, wprowadzić ten jeden blok. Nie instalować 5 wtyczek, które to dadzą, tylko skupić się na jednej. To jest takie rozwiązanie dla osoby początkującej, która sama sobie tego timeline po prostu nie napisze, bo nie jest na tyle techniczna, żeby to zrobić. Wszystko z umiarem. Być może o to właśnie chodziło w temacie rozszerzeń Gutenberga.

 

Motywy WordPressowe – a prędkość ładowania strony

 

Czy motywy mają wpływ?

 

A: Tak, jak najbardziej. Motywy mają wpływ. Bardzo wiele motywów, szczególnie tych płatnych, które pobieramy sobie z płatnych bibliotek (nigdy nie pobierajcie z Allegro, ani chomika, ani innych niezaufanych miejsc) np. Teamforrest, albo inny płatny katalog, ma często domyślnie wbudowanego elementora.

One są super, piękne. Potem je instalujemy, okazuje się, że mają elementora i kółko się zamyka. Nie mogę się wypowiedzieć na temat konkretnego motywu, ale ogólnie mogę powiedzieć, że motywy mają znaczenie. Jeżeli motyw ma elementor wbudowany, to mamy problem (wyzwanie), o którym była mowa wcześniej. Jeżeli motyw jest prosty i realizuje naszą potrzebę, no to super. Na pewno będzie lżejszy niż motyw, który ma bardzo wiele ustawień.

 

M: Aleksander dopisał w komentarzu, że istnieją jeszcze inne page buildery, takie jak: Oxygen, Bricks, Zion, napisane w VUE.js. Niech to będzie jako podpowiedź, że nie tylko na elementorze świat stoi.

Zostawię na razie ten temat i zadam Ci takie przewrotne pytanie. Rozmawiamy o wtyczkach, o motywach, o wyglądach, o page builderach, o hostingach – może to wszystko sobie odpuścić i sięgnąć po starego, dobrego WordPress? Bo dzisiaj mamy szybkie komputery, łącza, więc naturalnie pozwalamy sobie na więcej. Na strony, które są cięższe, które się ładują dłużej, więc może powinniśmy wrócić na przykład do 2010 roku, wziąć starą wersję WordPress i zainstalować ją, bo ona powinna być lepiej zoptymalizowana pod tamten słaby internet i niezbyt dobre komputery. Może to jest rozwiązanie?

 

A: Wtedy popularne były rozwiązania typu wix, jakieś kreatory stron. Nawet niektóre firmy hostingowe udostępniały takie kreatory stron na swoich hostingach i to były takie rozwiązania do wyklikania sobie strony wizytówki. Natomiast jak spopularyzowała się kwestia marketingu internetowego, dbania o SEO, o optymalizację treści, no to te kreatory stron po prostu nie miały racji bytu, bo tego nie da się dobrze zoptymalizować.

Nie mamy dostępu do kodu. Nie mamy nawet możliwości, by ustawić title i description na swojej stronie. Nie mamy możliwości zainstalować dodatku, typu wrzucić skrypt Google Analytics, więc to nie jest rozwiązanie, które jest alternatywą dla WordPress, choć jest popularne.

Wix nie jest rozwiązaniem problemów i nie jest rozwiązaniem przyszłościowym, jeżeli patrzymy na swoją stronę jak na biznes, który będzie rósł. Jest rozwiązaniem dla kogoś, kto ma biznes lokalny i potrzebuje mieć wizytówkę gdzieś wiszącą w internecie, nie ma czasu w ogóle na budowanie strony i swojego klienta odsyła na tę wizytówkę, by sprawdzić cennik lub numer telefonu. Ale nie chce jej promować, nie chce jej jakoś mocno wybijać. To nie jest alternatywa.

 

M: Tak, ale ja widzę, że jest miejsce na takie page buildery, jest masa ludzi, którzy chcą podrzucić taką właśnie stronę wizytówkę. Wyświetlę jeszcze jeden komentarz, bo to jest też coś, o czym chciałabym wam powiedzieć.

 

Względy bezpieczeństwa strony w optymalizacji technicznej

 

No, ale co z bezpieczeństwem? Motywy z 2010 roku to zaproszenie dla hakerów.

 

M: Tak, masz rację. To jest case, z którym się spotkałam. To jest pytanie, które zostało mi zadane (które ja zadałam Anecie). I chciałabym powiedzieć, że w życiu tego nie róbcie. Bezpieczeństwo tego, co było w 2010 roku, tych starych rzeczy, jest na niskim poziomie. One nie dostają już poprawek bezpieczeństwa. A kwestie bezpieczeństwa to też są kwestie optymalizacji technicznej. Musimy mieć pewność, że nasze wtyczki nie mają podatności, że ktoś do naszego WordPress ot tak sobie nie wejdzie. Dlatego tak w kwestii optymalizacji technicznej warto zawsze sprawdzić, czy macie aktualizowanego Waszego WordPressa. To też jest coś bardzo ważnego, co powoduje, że wasza strona jest bezpieczna.

 

A: Tak, absolutnie. I w ogóle, mówiąc o aktualizacji, warto porozmawiać o statystykach. Blisko połowa (globalnie) WordPress to są najnowsze wersje WordPress, czyli 5.8. Jeżeli jest 5.7 – to nie ma tragedii. Ale wszystkie poniżej 5.0 (5.0 wprowadził Gutenberga) to są już bardzo stare, które proszą się o problemy.

Od dawna nieaktualizowany WordPress to jest zaproszenie do wejścia dla szkodliwych botów, które nam wstrzykną kody, albo zdominują kokpit i wyrzucą jako administratora, stworzą nowych użytkowników i będą wykorzystywać WordPressa, jako takie miejsce, w którym będzie wyświetlał się spam, albo będzie przekierowywało na jakieś strony pornograficzne, bo to się niestety bardzo często dzieje.

I to jest przekleństwo WordPressowe. Przez to, że mamy taką mnogość dodatków, mnogość motywów, taką dowolność w ogóle w zarządzaniu WordPressem oraz przez to, że mamy funkcję wyłączenia automatycznych aktualizacji. To powoduje, że niektórzy użytkownicy przestają dbać o swoje WordPressy. Wychodzą z założenia, jak strona powstała dwa lata temu i działa, to nie będę ruszać, bo przestanie działać, bo wybuchnie.

Ale trzeba to aktualizować. Najlepiej mieć zawsze włączone automatyczne aktualizacje, bo to są najczęściej aktualizacje bezpieczeństwa, czyli te, które łatają podatności na bieżąco wykryte we wtyczkach, w motywach i w samym corze WordPress. Podatność w corze WordPress też już się zdarzyła, bodajże w 2017 roku.

Aktualizowanie z tzw. ręki motywów, wtyczek raz na jakiś czas, wchodzenie do WordPress i sprawdzanie, czy nie ma najnowszych aktualizacji, wykonanie tych aktualizacji, czy zrobienie sobie kopii roboczej WordPressa – to są wszystko rzeczy, które będą zapobiegały sytuacjom niebezpiecznym.

 

Aktualizacja wersji PHP

M: I z tym wiąże się wersja PHP. Jeżeli mamy starego, niezaktualizowanego WordPressa, no to na hostingu też musimy mieć włączoną starą wersję PHP, bo inaczej ten WordPress na tym hostingu działać nie będzie.

Najnowszą wersją PHP jest 8.0. Jest to w pełni kompatybilna wersja z najnowszym WordPressem. Jeżeli ktoś ma najnowszego WordPress, a starszą wersję PHP, to spróbujcie włączyć nowszą. Jeżeli nie zadziała, bo na przykład motyw nie ma zrobionej jeszcze kompatybilności z wersją 8.0, to niech to będzie przynajmniej ta wersja 7.4 (poprzednia) i na tej już motyw powinien działać.

Jeśli nie działa, to jest sygnał, że twórcy motywu go nie rozwijają. Być może warto sobie ten motyw zmienić albo przebudować swoją stronę w oparciu o rozwiązania, które są po prostu zaktualizowane.

 

M: Ja jeszcze powiem, że aktualizacja PHP to również poprawa szybkości i wydajności.  

 

Optymalizacja strony za pomocą wtyczek do WordPress

M: Przejdźmy już do samego WordPress. Jakie wtyczki do optymalizacji możesz polecić?

 

A: Żadnych. :) Da się zrobić szereg rzeczy bez wtyczek. Jeżeli więc ktoś potrafi zrobić bez wtyczek, to polecam podążanie tą drogą. Na przykład przez plik .htaccess i dyrektywy do tego pliku, ale to jest takie zadanie z gwiazdką.

Dlaczego nie polecam wtyczek? Każda wtyczka to jest dodatkowy kod. Każdy dodatkowy kod jest dodatkowym obciążeniem w przypadku ładowania strony, ale też dodatkowym niebezpieczeństwem, na które się narażamy. Trzeba je aktualizować, rozwijać, dbać i sprawdzać, czy wszystko jest w porządku. Też dlatego, że wtyczki usypiają naszą czujność. Jest takie przekonanie, że skoro muszę zająć się optymalizacją strony, to zainstaluję pięć wtyczek z artykułu top 5 wtyczek do optymalizacji i właściwie już nic nie muszę robić. To w ogóle nie jest rozwiązanie.

Po pierwsze wtyczki instalowane przez osoby początkujące bardzo często instalowane są w takiej formie out of the box. Instalujemy, włączamy i zostawiamy. Nic w środku nie konfigurujemy, bo przecież nie wiemy, jak mamy to skonfigurować. Natomiast wtyczki pozostawione na podstawowych, domyślnych konfiguracjach nie zrealizują naszych potrzeb.

 

M: WordPress nie jest moim CMS, więc pokopałam sobie trochę i okazuje się, że z wtyczkami do systemów cashujących były w 2021 roku dwa ogromne problemy z bezpieczeństwem. Te dwie wtyczki, które miały problemy wpłynęły na bezpieczeństwo ośmiu milionów WordPress. To dodatkowy argument, że nie możemy zainstalować i zostawić. Bezpieczeństwo przede wszystkim.

 

Czy będą porady, jak zoptymalizować WordPress? Na razie jest sama teoria. Proszę o jakieś must have, typu 10 rad optymalizacji technicznej dla początkujących.

 

A: Nie wiem, czy będzie 10, ale chciałabym coś powiedzieć dla osób początkujących.

 

Szybkie porady dotyczące optymalizacji technicznej dla początkujących

 

  1. Przede wszystkim, zaczynając od początku: hosting. Szybki i wydajny hosting, który rozwija swoją infrastrukturę – może bardzo mocno pomóc.
  2. Kolejna sprawa: wersja PHP. Jeżeli nie wiecie, jaką macie wersję PHP – na blogu LH.pl znajdziecie artykuł, o tym jak sprawdzić jaką wersję PHP ma nasz WordPress i możecie sprawdzić, jaką wersję obecnie macie włączoną. Jeżeli są to wersje starsze niż 7.4, to należałoby się z nimi pożegnać. Jednocześnie trzeba sprawdzić, czy strona jest kompatybilna z tą nową wersją PHP. Sprawdzić, czy motyw współpracuje z tą nową wersją PHP.
  3. Wtyczki i motywy. Jeżeli budując stronę, testowaliście różnorodne rozwiązania (więc instalowaliście różnorodne wtyczki), żeby zobaczyć, jak to wszystko działa i wygląda (co jest ok), to po zakończeniu prac trzeba wyrzucić te wtyczki, których nie potrzebujecie. Te motywy, które się nie spodobały, też trzeba usunąć. Oczyść swojego WordPress ze zbędnych dodatków, bo to naprawdę robi robotę.
  4. Wyłączenie i wyrzucenie wtyczek, które robią dokładnie to samo. Po takim uprzątnięciu strona potrafi przyspieszyć nawet dwukrotnie.
  5. Wyrzucenie wtyczek funkcyjnych. To wtyczki, które tłumaczą stronę, zmieniają linki z http na https. One już zrobiły robotę i nie są potrzebne. Można je wyrzucić.
  6. Obrazki. To jest temat rzeka. Bardzo często obrazki są spowalniaczem. PageSpeed Insights potrafi wylistować największe obrazki, więc wiadomo, co należy poprawić. Ale nie róbcie tego za pomocą wtyczki. Wejdźcie na WordPress, znajdźcie te obrazki, skorzystajcie z bezpłatnych narzędzi graficznych do kompresji obrazków (Optimizilla, Bulk Resize Photos, Fast Stone Image Viewer, Robin Image Optizmizer – wtyczka) i ponownie wgrajcie na WordPress już zmniejszone. Nie wrzucamy zbyt dużych obrazków, bo nie trzeba, a to spowalnia stronę. Obrazki w jpg, a nie w png, bo to też bardzo dużo zmienia.
  7. Aktualizacja, czyli aktualny WordPress. Każda nowa wersja WordPress, motywu, wtyczek czy PHP ma na celu zwiększenie wydajności i bezpieczeństwa.
  8. Przechodzenie na rozwiązania bezwtyczkowe. Przy zmianie http na https nie instalujcie najpopularniejszej wtyczki, która dynamicznie zmienia url i musi zostać w WordPress, bo jest ciągle w pracy, tylko weźcie wtyczkę, która robi robotę raz i można ją wyrzucić. Można tę zmianę zrobić też w bazie danych i nie potrzeba do tego żadnego dodatku.
  9. Rozwijać się, uczyć się. Wiedzieć, jak najwięcej o WordPress, by jak najwięcej wtyczek móc zastąpić sobie kodem, czy chociażby dyrektywą w .htacess, która może załatwić wszystko: przekierowania, cashowanie, zmianę na https.

To takie moje porady dla początkujących, mam nadzieję, że przydatne.

 

M: To ja jeszcze dodam parę porad od siebie. Zwracajcie uwagę na duplicate content, który macie u siebie (np. kategorie na blogu, gdzie macie wpisy). Tagi mogą to robić. Przez to Google indeksuje wiele stron o tej samej treści, a nie powinno tak być i to powinno zostać usunięte. Dzięki temu strona może nie jest szybsza, ale jest lepiej zoptymalizowana pod wyszukiwarki.

Czasem mamy fikuśne animacje albo walidacje formularzy – to obsługują skrypty. Sprawdzajcie we wtyczce, czy te skrypty jsowe (bo tak one się nazywają) są w wersji produkcyjnej czy deweloperskiej. Wersja produkcyjna jest zminimalizowana, jest znacznie mniejsza. Wersja deweloperska jest rozdmuchana, żeby tam wszystko było super dobrze widać. To są też kilobajty kodu, który możecie zaoszczędzić w dość prosty sposób.

Zwracajcie uwagę, czy nie wyindeksowujecie sobie czasem strony, bo to się też czasem zdarza.

Bezpieczeństwo. Starajcie się nie używać jakichś wtyczek, nie tylko WordPress, ale także innych, które mają problem z bezpieczeństwem. Automatyczny audyt powinien to wykazać.

Jeżeli macie taką możliwość to starajcie się minimalizować i łączyć w jeden wszystkie style CSS, które macie u siebie odpowiedzialne za wygląd. Zwłaszcza jeżeli nie budujecie na implementorze, tylko korzystacie z własnej skórki. Są na to metody. Takie działanie zmniejsza liczbę żądań do serwera.

 

A co z WooCommerce?

 

A: To jest wtyczka, która rozszerza WordPress o sklep, więc wszystkie te rzeczy, o których powiedziałam, czyli dotyczące PHP, aktualizacji, obrazków, czy zachowania higieny kodu, czyli stosowania takich domyślnych, natywnych WordPressowych rozwiązań, a nie wchodzenie w te ciężkie, chociażby Page Buildery, dotyczą też Woo Commerce. Te wcześniejsze rady są więc uniwersalne.

 

Jak zrobić https?

 

A: Możecie to zrobić taką wtyczką: better search place, która pozwala na zmianę urli z http na https, wykonanie tego, zapisanie i usunięcie wtyczki. To jest funkcyjna rzecz tylko na chwilę.

 

M: Możecie też to zrobić za pomocą .htaccess. W internecie jest wiele tutoriali, jak to można zrobić, więc wtedy nie potrzeba w ogóle żadnej wtyczki.

 

Pamiętajmy, by nie instalować tych wtyczek jak leci na stronie produkcyjnej, bo nawet po usunięciu potrafią narobić bardzo złe rzeczy w bazie. Potrafi zostać masa tabel i danych, które będziemy musieli ręcznie usunąć, a to wszystko powoduje, że całość po prostu puchnie.

 

A: Dokładnie. A potem trzeba w bazie ręcznie wszystko usuwać i początkująca osoba może mieć z tym problem, bo baza danych przy pierwszym spotkaniu jest przerażająca. To jest jednak duży problem.

 

Co z wtyczkami z czatu FB? Czy mocno wpływają one na szybkość?

 

M: Jest takie przekonanie w branży SEO, że jak ktoś ma zainstalowanego Google Analyticsa, to w Core Web Vitals nie wymaksuje, albo w page speedach nie wymaksuje. Poniekąd jest to prawda, bo każdy kod mierzący, każda wtyczka, którą dodajecie, to są dodatkowe odwołania do serwera, dlatego bardzo ważne jest to, żeby wszystko robić asynchronicznie. Dla osób mocno technicznych są jeszcze takie opcje jak defer, które także pozwalają trochę podziałać, albo są preloady wszelkiego rodzaju, które możecie wykorzystać.

 

A: Skrypty facebookowe, które się ładują, Google Analytics, Google Tag Manager, który musi nam się odpalić na stronie – jest problemem. Można też opóźnić ich ładowanie i to też jest jakieś rozwiązanie. To dla osób, które są nieco bardziej zaawansowane. Jeżeli mówimy o zewnętrznych skryptach, to często są to w ogóle zewnętrzne biblioteki mediów, albo zewnętrzne fonty, które się ładują. To też da się rozwiązać. Na przykład font można serwować lokalnie, żeby nie odwoływać się do żadnej biblioteki mediów, żeby nie być uzależnionym od tego serwera, do którego się odwołujemy.

Ogólnie chcę powiedzieć, kończąc temat, że trzeba zawsze zbadać stronę, żeby wiedzieć, co ją spowalnia i co utrudnia jej pracę. Prawym „zbadaj”, „przejdź do network”, odświeżyć stronę, zobaczyć, co się ładuje po kolei, żeby w ogóle coś podpowiedzieć. Jeżeli ktoś chce, bym przeanalizowała jego stronę to na: aneta.rutkowska@lh.pl można śmiało pisać. Postaram się podpowiedzieć, co można zmienić.

Jeżeli hosting nie będzie u nas a to TTFB będzie wysokie, to na pewno będę kierowała w dobre ręce naszych opiekunów migracji, żebyście chociaż przetestowali, bo przez 14 dni nasz hosting można testować bezpłatnie. Sprawdzicie czy hosting wam rozwiązuje ten problem z TTFB.

 

Czy oprócz Yoast do SEO coś innego jeszcze jest?

 

A: Yoast jest rozwiązaniem w porządku, nie mam do niego większych zastrzeżeń. Ma silną konkurencję w postaci all in one SEO pack, ale mam taką jedną zasadę, że jak coś się nazywa „all in one”, to ja już tego nie instaluję. Najczęściej to oznacza po prostu bardzo dużo funkcji, których ja pewnie nie będę potrzebowała, więc Yoast jest mniejszym złem. Fajnie na contencie pokazuje, w którą stronę iść, jeżeli chodzi o SEO. Jest użyteczna dla osób początkujących.

 

M: Nie traktujcie tego, co mówi wtyczka, jako prawdę objawioną. Optymalizacja każdego tekstu czy strony rządzi się swoimi prawami. Na każde słowo kluczowe mogą być inne parametry i Yoast tego nie uwzględnia. Te same sugestie poda do opisu stron kategorii o śrubkach, jak i do opisu stron kategorii na iPhonie. A to dwa zupełnie inne teksty powinniśmy wypluć. Natomiast on systematyzuje pewne rzeczy i pod tym względem jest fajny. Zwraca uwagę, czy tekst jest czytelny dla człowieka. To mi się super podoba.

 

Webp jest też fajnym formatem do obrazków.

 

A: Webp to też jest super format obrazków, ale on nie jest obsługiwany przez wszystkie przeglądarki. Dlatego też trzeba pamiętać o tych użytkownikach, którzy wchodzą na stronę z Safari i im trzeba zafundować jpg. Dlatego jpg jest bardziej uniwersalne niż webp. Jest taka wtyczka webp conwerter i na blogu LH jest artykuł o tym, jak podejść do konwersji. Zachęcam, żeby sobie tam zajrzeć, bo tam pokazujemy wszystkie blaski i cienie tego rozwiązania.

 

M: Pojawił się jeszcze jeden komentarz, do którego chciałabym się odnieść:

 

 Łączenie plików css i js w jeden w dobie HTTP/2 i HTTP/3 mija się z celem, a może powodować wysypywanie się strony.

 

M: Łączenie plików JS w jeden jest bardzo ryzykowne, ale łączenie plików CSS, jeżeli zachowamy kolejność, zupełnie nie wpłynie na to, czy strona się wysypie, czy nie. Jeżeli nie mamy elementora, bo ja to podkreśliłam. Page buildery rządzą się trochę swoimi prawami. Łączenie plików CSS naprawdę nie powinno rozsypać strony, tam trzeba już sporo nawalić, ale z JS całkowicie się zgadzam. Tam czasem może dochodzić, zwłaszcza, jak zrobimy to nieumiejętnie, do konfliktów i dlatego nie poleciłam tego początkującym.

 

Chcesz wiedzieć więcej o hostingu i optymalizacji technicznej stron WordPress? Przeczytaj powiązane tematycznie artykuły:

 

Dodatkowo cały zapis webinaru znajdziesz na naszym koncie w serwisie YouTube:

 

 

Przeczytaj także

Komentarze