Porównanie WordPress 5.5 vs 5.4 pod kątem szybkości to gorący temat dla całej naszej ekipy. Uważam, że świadczenie takiej usługi, jak hosting WordPress o wysokiej wydajności, zobowiązuje do tego rodzaju analiz. Tylko pomyśl: Magda Paciorek, Marek Łaska, Tomek Urbański i ja prawie się pokłóciliśmy, interpretując wyniki. Testy wcale nie dawały od razu oczywistych wniosków. Co więcej – każda uzyskana cyfra wprowadzała coraz więcej zamieszania…
Porównanie WordPress 5.5 vs 5.4 – szybkość
Szybkość ładowania stron www jest bardzo, bardzo ważna i bez wątpienia staje się coraz bardziej istotna w osiąganiu sukcesów w Sieci. Zaledwie kilka dni temu pojawiła się wersja WP 5.5. Magda Paciorek popełniła obszerny wpis, tłumacząc, jak ostatnia aktualizacja WordPress wzbogaciła funkcjonalnie WordPress’a. To znakomity artykuł, bardzo polecam go Twojej uwadze.
Ja z kolei podjąłem wyzwanie sprawdzenia, jak zmiany w WordPress będą rzutować na szybkość ładowania strony.
Jest ona przecież bardzo ważna, przede wszystkim dla właścicieli e-commerce, a tandem WordPress + WooCommerce należy do najczęściej stosowanych w Polsce rozwiązań. To dlatego chciałem wykonać te testy z uwzględnieniem właśnie WooCommerce.
Porównanie WordPress 5.5 z 5.4 – środowisko testowe
Środowiskiem testowym był szybki hosting WordPress w cyberfolks.pl. Na to rozwiązanie składają się komponenty sprzętowe oraz programistyczne. Sprzętowe to szybkie procesory i macierze NVMe, zapewniające bardzo wydajną pracę systemu dyskowego.
Po pierwsze – zasoby programowe obejmują LS Cache po stronie serwerowej, w pełni kompatybilne z popularną wtyczką przyspieszającą WordPress LiteSpeed Cache.
Po drugie ważnym komponentem o istotnej roli dla szybkości, a zwłaszcza – wydajności, jest REDIS – serwer umożliwiający cacheowanie obiektowe.
Ponieważ w teście chodziło o porównanie WordPress 5.5 z 5.4, zainstalowałem obie wersje w osobnych folderach na tym samym koncie hostingowym. Korzystałem z wygodnego mechanizmu instalacji Installatron, dostępnego w ramach panelu DirectAdmin (wygodny przycisk „instaluj WordPress”). Być może należysz do osób obawiających się autoinstalatorów.
Wielu deweloperów woli własne, w pełni customowe paczki i w pełni rozumiem takie podejście. Celem testu było szybkie porównanie dwóch tak samo skonfigurowanych systemów. Porównanie wyłącznie pod kątem szybkości działania, bez wnikania w zagadnienia bezpieczeństwa czy funkcjonalności.
Po instalacji (kilkadziesiąt sekund dla każdej wersji) zalogowałem się do kokpitu każdego z WordPress’ów oraz zainstalowałem WooCommerce. Wybrałem bezpłatny motyw Storefront i zaimportowałem przykładową bazę produktów. Taką prostą bazę kilkudziesięciu produktów demo możesz wgrać samodzielnie, korzystając z pliku sample-data/sample_products.csv w folderze z wtyczką.
Porównanie WordPress 5.5 i 5.4 – certyfikat SSL i tak konieczny
Ponieważ mówimy o porównaniu szybkości, to zależało mi na działaniu protokołu HTTP/2 i funkcji PUSH. Te rozwiązania wymagają protokołu HTTP/S, dlatego certyfikat SSL był konieczny. W rezultacie postanowiłem zainstalować szybko bezpłatny certyfikat SSL Let’s Encrypt. W panelu DirstAdmin generowanie certyfikatu SSL to prosta czynność dlatego certyfikat wygenerowałem w ok. 30 sekund i w związku z tym od razu wszystko było gotowe do pracy.
WordPress 5.5 i WordPress 5.4 instalowałem w tej samej roboczej domenie, a tylko w różnych ścieżkach, wystarczył jeden certyfikat SSL. Jeśli chcesz dowiedzieć się, jak instalować SSL Lets’s Encrypt – opis znajdziesz w systemie pomocy.
Porównanie WordPress 5.5 i 5.4 – uruchomienie REDIS
Porównanie systemów zakładało dwa warianty, tj. wersję bez pełnego wspomagania tym, co w hostingu WordPress nazywamy pakietem cyber_Boost, oraz z włączonymi wszystkimi funkcjami przyspieszającymi.
Zanim rozpocząłem pomiary – przygotowałem do pracy serwer REDIS. To prosta operacja, podczas gdy logujesz się do panelu DirectAdmin wybierasz opcję „Serwer Redis” i uzyskujesz dane dostępowe. Będą Ci potrzebne:
- Adres serwera
- Port do zestawienia połączenia
- Hasło, które otrzymasz po kliknięciu przycisku
Uzyskane dane dostępowe pozwalają skonfigurować wtyczkę LS Cache. Cały czas chodzi o porównanie WordPress 5.5 i 5.4 więc wszystkie czynności wykonywałem w kokpicie obu instalacji.
Po lewej stronie kokpitu i wybraniu opcji ustawień LiteSpeed Cache wybieram zatem „Pamięć podręczna”, a następnie w zakładce „Object” (szósta zakładka w menu LiteSpeed Cache) włączam opcje:
- Pamięć podręczna obiektów
- Metoda REDIS
- Host – uzupełniam domyślne pole 'localhost’ pole danymi uzyskanymi z panelu
- Port – zastępuje domyślny port serwera REDIS 6379 portem uzyskanym z panelu
- Hasło – uzyskane w panelu
Po zapisaniu zmian uzyskuję u góry ekranu potwierdzenie prawidłowego zestawienia połączenia z serwerem REDIS.
Porównanie WordPress 5.5 z 5.4 może zatem się rozpocząć. Całe środowisko hostingu WordPress jest gotowe, zainstalowane są 2 strony na WordPress ze sklepem WooCommerce, różnią się wyłącznie wersją WordPress’a.
WordPress 5.5 vs 5.4 – pierwsze testy
Pierwsze testy opierały się o pomiar wczytywania strony w Google Chrome – zakładka NetWork, cache lokalne przeglądarki wyłączone. Mierzyłem czas DOM Content Ready oraz Load wskazywane przez Google Chrome. Testy miały dwa wymiary:
- Porównanie WordPress z cache’owaniem przy pomocy REDIS i LiteSpeed Cache oraz bez stosowania cache’owania.
- Porównanie WordPress 5.5 vs WordPress 5.4 pod kątem wydajności
Metodyka porównania zakładała 10-krotne wykonanie testu.
Wyniki poszczególnych pomiarów dla wersji z przyspieszeniem LS Cache i REDIS
| Próba | DOM Content Loaded [ms] | Load [ms] | LiteSpeed Cache | REDIS | Wersja WP |
|---|---|---|---|---|---|
| 1 | 194 | 228 | TAK | TAK | 5.5 |
| 2 | 236 | 271 | TAK | TAK | 5.5 |
| 3 | 216 | 274 | TAK | TAK | 5.5 |
| 4 | 311 | 643 | TAK | TAK | 5.5 |
| 5 | 213 | 260 | TAK | TAK | 5.5 |
| 6 | 490 | 552 | TAK | TAK | 5.5 |
| 7 | 270 | 312 | TAK | TAK | 5.5 |
| 8 | 230 | 267 | TAK | TAK | 5.5 |
| 9 | 257 | 298 | TAK | TAK | 5.5 |
| 10 | 210 | 244 | TAK | TAK | 5.5 |
| 1 | 277 | 290 | TAK | TAK | 5.4 |
| 2 | 279 | 295 | TAK | TAK | 5.4 |
| 3 | 625 | 639 | TAK | TAK | 5.4 |
| 4 | 258 | 276 | TAK | TAK | 5.4 |
| 5 | 261 | 279 | TAK | TAK | 5.4 |
| 6 | 255 | 273 | TAK | TAK | 5.4 |
| 7 | 257 | 278 | TAK | TAK | 5.4 |
| 8 | 253 | 274 | TAK | TAK | 5.4 |
| 9 | 281 | 307 | TAK | TAK | 5.4 |
| 10 | 296 | 315 | TAK | TAK | 5.4 |
Te same testy wykonałem, wyłączając wcześniej wtyczkę LS Cache, a więc jednocześnie rezygnując ze wsparcia REDIS’a.
Wyniki poszczególnych pomiarów dla wersji WordPress BEZ właczonego LS Cache i REDIS
| Próba | DOM Content Loaded [ms] | Load [ms] | LiteSpeed Cache | REDIS | Wersja WP |
|---|---|---|---|---|---|
| 1 | 778 | 796 | NIE | NIE | 5.5 |
| 2 | 1113 | 1113 | NIE | NIE | 5.5 |
| 3 | 670 | 714 | NIE | NIE | 5.5 |
| 4 | 619 | 643 | NIE | NIE | 5.5 |
| 5 | 684 | 706 | NIE | NIE | 5.5 |
| 6 | 671 | 676 | NIE | NIE | 5.5 |
| 7 | 650 | 650 | NIE | NIE | 5.5 |
| 8 | 1080 | 1100 | NIE | NIE | 5.5 |
| 9 | 986 | 1010 | NIE | NIE | 5.5 |
| 10 | 749 | 798 | NIE | NIE | 5.5 |
| 1 | 802 | 829 | NIE | NIE | 5.4 |
| 2 | 1010 | 1030 | NIE | NIE | 5.4 |
| 3 | 655 | 668 | NIE | NIE | 5.4 |
| 4 | 608 | 630 | NIE | NIE | 5.4 |
| 5 | 641 | 660 | NIE | NIE | 5.4 |
| 6 | 712 | 731 | NIE | NIE | 5.4 |
| 7 | 964 | 980 | NIE | NIE | 5.4 |
| 8 | 964 | 973 | NIE | NIE | 5.4 |
| 9 | 619 | 646 | NIE | NIE | 5.4 |
| 10 | 650 | 677 | NIE | NIE | 5.4 |
Po uśrednieniu wyników pomiarów okazywało się, że wyniki wcale nie są korzystne dla nowej wersji WordPress 5.5, popatrzcie sami:
Powyższy wykres pokazuje wyraźnie, że jeśli Twój hosting WordPress ma mechanizmy przyspieszające działanie strony – koniecznie z nich korzystaj! LS Cache oraz REDIS w wypadku tego prostego testu dały w rezultacie ponad dwukrotne skrócenie czasu ładowania, to ogromna różnica!
Podczas gdy porównując WordPress 5.5 i 5.4 widzimy, że aktualizacja WordPress do wersji 5.5 niekoniecznie poprawiła mierzone tym testem parametry. Bez wątpienia różnice rozkładają się na korzyść poprzedniej wersji i są jeszcze bardziej widoczne tam, gdzie nie ma mowy o włączonym cache’owaniu.
Dlatego włączenie technologii przyspieszających WordPress (LiteSpeed Cache i REDIS) bez wątpienia powoduje, że czasy ładowania skracają się radykalnie. Po drugie – różnice między wersjami bezsprzecznie ulegają zatarciu, bo 12,3 tysięcznej części sekundy trudno uznać za istotną różnicę. Podsumowując: bez wątpienia nowe funkcje, które wnosi aktualizacja WordPress 5.5 w pełni ją rekompensują.
Szybkość WordPress zmierzona w oparciu o GTmetrix
Dyskusja tych wyników w naszym gronie wywołała sporo emocji. Okazało się, że różnice wydajnościowe, które w moich testach były niewielkie, w rezultacie u innych osób, w innych miejscach, korzystających z innych łącz o słabszych parametrach – wykazywały przewagę WordPress po aktualizacji.
Aby to rozwikłać postanowiliśmy sięgnąć po inne narzędzie i przeprowadzić test w oparciu o API GTmetrix.
Porównanie WordPress 5.5 i 5.4 – wyniki uwzględniają LS Cache i REDIS
| WordPress 5.4 | WordPress 5.5 | Różnica | |
|---|---|---|---|
| Window onload time [ms] | 833 | 532 | -36% |
| First contentful paint time [ms] | 727 | 496 | -32% |
| Page elements | 28 | 24 | -14% |
| Redirect duration [ms] | 0 | 0 | 0% |
| DOM content loaded duration [ms] | 289 | 61 | -79% |
| DOM content loaded time [ms] | 375 | 449 | +20% |
| DOM interactive time [ms] | 356 | 442 | +24% |
| Page bytes | 391.50 KB | 374.24 KB | -4% |
| Page load time [ms] | 833 | 532 | -36% |
| HTML bytes | 8.08 KB | 9.32 KB | +15% |
| Fully loaded time [s] | 1.601 | 1.605 | 0% |
| YSlow score | 88 | 95 | +8% |
| Pagespeed score | 98 | 98 | 0% |
| Backend duration [ms] | 34 | 37 | +9% |
| Onload duration [ms] | 3 | 1 | -67% |
| Connect duration [ms] | 121 | 121 | 0% |
Zwróć uwagę, że mimo, iż czas DOM content loaded time w WP 5.5 jest znacznie dłuższy, to jednocześnie Window onload time – znacznie się skróciły. To ważne, ponieważ te parametry są brane pod uwagę przez narzędzia pomiarowe Google.
Podsumowując szybkość WordPress…
Testując wersje WP przeprowadziłem pomiary na tym samym serwerze. Były to testy z jednym użytkownikiem i nie objęły testowania wydajnościowego. Najpierw zainstalowałem identyczne sklepy z tym samym zestawem produktów. Następnie tak samo skonfigurowałem funkcje przyspieszające. Wówczas przystąpiłem do pomiarów.
Okazało się, że instalacje WordPress 5.4 i 5.5 wraz z WooCommerce i Storefront gdy różnią się tylko wersją rdzenia, dają inne wyniki.
Niektóre parametry wydają się być lepsze, podczas gdy inne słabsze. Moim zdaniem ważniejsze dla doświadczenia użytkownika są parametry wskazane w teście GTmetrix, a różnice zmierzone w wyszukiwarce okazały się być nieznaczne i zależne od lokalizacji użytkownika.
Reasumując, wydaje się, że pozytywne zmiany zmierzone w GTmetrix, w połączeniu z nowymi funkcjami wynikającymi z aktualizacji WordPress to kolejne, obok bezpieczeństwa i funkcjonalności, argumenty za przejściem na nową wersję.
A jak tam Twój WordPress? Korzystasz już z aktualizacji WordPress do 5.5, czy na razie zostajesz przy 5.4? Daj znać w komentarzu, jakie są Twoje doświadczenia z WordPress’em.
U mnie delikatnie przyspieszyło oraz wynik w PageSpeed się poprawił o kilka punktów. Na szczęście aktualizacje na wszystkich domenach i subdomenach odbyły się bezproblemowo – niektórzy musieli downgradować.
Cześć Filip, dzięki za podzielenie się tym doświadczeniem. Świetnie, że u Ciebie się delikatnie poprawiło. Naszym zdaniem spora w tym zasługa w domyślnie włączonym lazy loading. Trzymam kciuki za Twoje serwisy!
Pytanie czy ten domyślny lazy loading nie gryzie się z lazy loadingiem wtyczek, np WP Rocket.
Potestuj. U mnie bez zmian w testach GTmetrix oraz Pingdom. Używam jedynie WPRocket, nic się nie gryzie.
Jeśli chodzi o moje strony to ja raczej jakiś większych różnic nie zauważyłem. Przeglądając anglojęzyczne blogi wręcz wiele osób narzekało na sporo bugów ze strony wersji 5.5 i to, że WP się wysypuje.
Z naszych obserwacji i relacji to bardziej dotyczy to nieaktualnych wtyczek, niż samego WP. Różnice – jak wynika z naszych pomiarów – nie wydają się generalnie duże, zresztą sami twórcy WP wprowadzając wersje 5.5 nie komunikowali jej jako przełom w szybkości wczytywania, ale raczej serię użytecznych poprawek funkcjonalnych.