Gutenberg vs. Elementor w WordPress, a wskaźniki Core Web Vitals

Od niedawna głośno zrobiło się o Core Web Vitals – Podstawowych Wskaźnikach Internetowych. Są to metryki, które Google uznaje za ważne w kontekście doświadczenia użytkownika strony. Na tyle ważne, aby włączyć je do algorytmu oceniającego strony pod kątem ich rankowania w wyszukiwarce. I co można zauważyć na grupach facebookowych, coraz więcej osób zaczyna myśleć o porzuceniu wtyczki Elementor. W zastępstwie wymienia się Gutenberga – edytor blogowy wbudowany w WordPressa. Przyjrzyjmy się zatem tej walce: Gutenberg vs. Elementor – co możemy zyskać gdy porzucimy Elementor na rzecz Gutenberga i zastanówmy się, czy warto to zrobić.

W tym artykule porównamy edytor blokowy z Elementorem pod względem:

• rozmiaru drzewa DOM,
• semantyki kodu,
• liczby i rozmiaru załadowanych assetów,
• zapytań wysyłanych do bazy danych,
• różnicy w prędkości działania.

Gutenberg vs. Elementor – Testujemy na motywie Astra

Aby przeprowadzić szybkie porównanie zdecydowałam się zainstalować motyw Astra, który posiada gotowe do zaimportowania dema stron startowych. W przypadku niektórych dem, możemy wybrać page builder, w którym została stworzona dana strona startowa. Dzięki temu łatwo możemy porównać 2 takie same dema, utworzone za pomocą różnych page builderów.

Na potrzeby tego testu wybrałam starter o nazwie “Online Health Coach”. Do pierwszego WordPressa wgrałam demo utworzone w edytorze blokowym, a do drugiego w Elementorze.

Na pierwszy rzut oka widać, że templatka na edytor blokowy jest nieco uboższa. Brakuje niektórych elementów dekoracyjnych, które znajdziemy w wersji na Elementor, ale z grubsza można powiedzieć, że strony są bardzo, bardzo podobne. Strona utworzona w edytorze blokowym nie odbiega pod względem jakości dizajnu od strony na Elementorze.

Po stronie edycji, doświadczenie redaktora korzystającego z Gutenberga jest niestety gorsze niż gdyby korzystał z Elementora. Motyw Astra, podobnie zresztą jak 99% motywów z repozytorium WordPressa, nie do końca jest dostosowany pod edytor blokowy. Zaniedbano tu niestety bardzo ważną rzecz – aby style po stronie edytora odzwierciedlały w 100% style na frontendzie. A przez to doświadczenie użytkownika-redaktora jest dosyć słabe.

Pamiętajmy tu jednak, że dotyczy to tylko backendu strony – i będzie dotkliwe dla osób redagujących stronę. Frontend został dosyć dobrze dostosowany. Na plus muszę też zaliczyć twórcom motywu, że do stron startowych wykorzystali tylko natywne bloki WordPressa i nie wymuszają instalowania żadnych dodatkowych wtyczek z blokami.

Generalnie, jeśli przymkniemy oko na niedoskonałości po stronie backendu, to na combo Astra + edytor blokowy możemy utworzyć całkiem przyzwoitą stronę firmową. Na pewno wizualnie nie gorszą niż to, co możemy utworzyć za pomocą Elementora.

Przyjrzyjmy się zatem temu czy coś zyskamy jeśli zdecydujemy się na edytor blokowy.

Czym właściwie jest page builder?

Zanim porównamy te dwa page buildery, zastanówmy się najpierw nad tym czym właściwie jest page builder.

Page builder to interfejs użytkownika, w którym poszczególne elementy strony dodajemy poprzez przeciągnięcie wybranych bloków/modułów. Każdy z tych bloków/modułów wygeneruje pewien kod HTML. Dzięki czemu nie trzeba samodzielnie pisać kodu strony, a tworzenie stron staje się dostępne dla szerszej grupy użytkowników.

Moim zdaniem, redaktor posługujący się page builderem powinien jednak poznać przynajmniej podstawy HTMLa. Ponieważ musi podejmować pewne decyzje, które mają wpływ na strukturę wygenerowanego kodu, np. na głębokość zagnieżdżonych w sobie elementów czy stosowanie odpowiednich poziomów nagłówków.

Poza tymi decyzjami nie mamy jednak za dużego wpływu na jakość kodu, który zostanie wygenerowany przez page builder. To jego twórcy zadecydowali jaki kod HTML zostanie wygenerowany z danego bloku/ modułu. Porównując różne page buidery, zobaczymy, że dane sekcje na stronie wyglądają podobnie, mimo że ich kod może być bardzo różny.

O tym jak duże mogą być te różnice przekonamy się za chwilę. Porównamy te same sekcje utworzone przy pomocy Gutenberga i Elementora.

Gutenberg vs. Elementor – Drzewo DOM

Drzewo DOM jest tworzone przez przeglądarkę podczas ładowania strony i jest odzwierciedleniem struktury HTML strony w formie grafu. Z niego tworzone jest drzewo renderowania. Na podstawie niego przeglądarka oblicza rozmieszczenie poszczególnych elementów na stronie oraz “maluje” stronę w oknie przeglądarki.

Im bardziej rozbudowane drzewo DOM, tym więcej danych przeglądarka musi przetworzyć. Rozmiar drzewa DOM ma więc wpływ na prędkość ładowania strony i dlatego jest uwzględniony w audycie Core Web Vitals.

Weźmy więc nasze 2 strony i porównajmy choćby jedną sekcję – np. hero w topie strony. Mamy tutaj w 1 kolumnie tytuł z zajawką i przyciskiem, a w 2 kolumnie obraz.

Drzewo DOM będące reprezentacją powyższej sekcji wygląda tak:

No i nawet nie wnikając za bardzo w szczegóły, na pierwszy rzut oka widzimy, że różnica jest spora. Mimo, że wizualnie obie sekcje wyglądają praktycznie tak samo, to Elementor generuje bardziej rozbudowany kod. Praktycznie każdy element posiada 2 dodatkowe divy jako wrappery, które tak naprawdę są zupełnie zbędne.

W przeciwieństwie do Elementora kod wygenerowany z Gutenberga jest prosty i nie odbiega od kodu, który byśmy sami napisali, np. kodując tę sekcję samodzielnie.

Policzmy jeszcze tylko elementy HTML w tej tylko sekcji:

• Gutenberg: 13 elementów HTML
• Elementor: 34 elementy HTML

Dla całej strony głównej z naszego przykładu liczba elementów na drzewie DOM wygląda następująco:

• Gutenberg: 283 elementów
• Elementor: 539 elementów

Jeśli zdecydujemy się porzucić Elementor i zbudować stronę na WordPresowym edytorze blokowym będzie ona zbudowana z prostszego i znacznie lepszej jakości kodu HTML.

Gutenberg vs. Elementor – Semantyka kodu

HTML pozwala opisać strukturę informacji zawartych wewnątrz strony internetowej, nadając odpowiednie znaczenie semantyczne poszczególnym fragmentom tekstu. Na przykład formując hiperłącza, akapity, nagłówki, listy.

Wikipedia

Wszystkie znaczniki HTML, poza <div> i <span>, nadają znaczenie poszczególnym elementom na stronie. Dzięki czemu, treści na stronie mogą być odpowiednio interpretowane przez różne urządzenia (np.głosowy czytnik ekranu) lub algorytmy (np. bot Google).

Gdy stosujemy semantycznie poprawne tagi HTML, strona staje się dostępna dla wszystkich grup użytkowników. Również tych, którzy w danym momencie nie mogą poruszać się po stronie w tradycyjny sposób. Witryna staje się dostępna także dla programów, których działanie zależy od prawidłowej interpretacji treści na stronie. A dodatkowo dostajemy plusik od Google.

Tworząc stronę za pomocą page buildera nie mamy wpływu, jaki kod zostanie wygenerowany z danego bloku/moduł, ale to my decydujemy jaki blok/moduł zdecydujemy się użyć. A więc mamy pewien wpływ na semantykę wygenerowanego kodu.

I tak np. sekcję z listą logotypów partnerów, taką jak ta:

Możemy utworzyć za pomocą bloku Kolumny i do każdej kolumny wstawić obrazek z logotypem. W tym przypadku obrazy będą zagnieżdżone w elementach <div> pochodzących z bloku Kolumny.

Lub możemy wstawić blok Galeria i do galerii dodać obrazy z logotypami. Wygeneruje nam to element listy <ul>, bardziej adekwatny semantycznie jeśli chcemy dodać listę logotypów.

Jeśli spojrzymy na Gutenberga to od razu widać, że zespół, który tworzy to narzędzie, przywiązuje bardzo dużą wagę, aby wygenerowany kod był semantycznie poprawny.

I tak:

• blok Paragraf wygeneruje nam element <p>
• blok Lista wygeneruje element <ul> lub <ol> w zależności od wybranej opcji
• blok Cytat wygeneruje element <blockquote>
• blok Obraz wygeneruje kod <figure><img>
• blok Galeria to lista zdjęć i wygeneruje kod <figure><ul><li><img>

To są podstawowe tagi HTML, ale nawet bardziej złożone bloki jak Media i Text czy Okładka mają bardzo elegancki kod.

A jak sprawa ma się w przypadku Elementora? Pod względem semantyki może nie ma tutaj wielkiej tragedii. Jednak wszystkie semantyczne tagi umieszczone są w dodatkowych divach, które robią za wrappery, np:

• moduł Edytor Tekstu generuje kod <div><div><p>
• moduł Nagłówek generuje kod <div><div><h..>
• moduł Lista Ikon generuje kod <div><div><ul><li><span><span>
• moduł Prosta Galeria generuje kod <div><div><div><div><figure><div><a><img>

Jest to totalnie zbędne i stąd bierze się w Elementorze 2-krotnie większe drzewo DOM w porównaniu z Gutenbergiem, o czym pisałam nieco wyżej.

Spójrz w kod strony, która została wygenerowana Twoim ulubionym page builderem i zastanów się nad jego jakością. Warto też porównać sobie pod tym względem kilka builderów, ponieważ jakość generowanego przez nich kodu jest bardzo różna.

Gutenberg vs. Elementor – Assety

Liczba żądań i ilość przesyłanych danych są metrykami branymi pod uwagę przy wyliczaniu budżetu wydajnościowego witryny. Mają również wpływ na wyniki strony w Core Web Vitals. Więcej na ten temat: https://web.dev/performance-budgets-101/.

Dodatkowo, jeśli znaczną część żądań stanowią pliki CSS i JS to jest duża szansa, że większa część zawartego w nich kodu pozostaje niewykorzystana na stronie. A to obniża ocenę w Core Web Vitals i odpala kolejne flagi w raporcie: Ogranicz nieużywany JavaScript i Ogranicz nieużywany kod CSS.

Zbyt dużo kodu CSS i JS może także powodować odpalenie flagi: Wyeliminuj zasoby blokujące renderowanie.

To ile i jakich rozmiarów pliki zostają załadowane na stronie, ma bardzo duży wpływ na szybkość ładowania witryny i wyniki w Core Web Vitals. Jeśli ładujemy sporo niepotrzebnych assetów, co często ma miejsce w przypadku page builderów czy motywów typu all-in-one, które możemy zakupić m.in. na Themeforest, to niestety będzie nam ciężko osiągnąć dobre wyniki w Core Web Vitals.

Spójrzmy teraz na nasze strony testowe i przyjrzyjmy się liczbie żądań HTTP, niezbędnych do pobrania wszystkich plików (CSS, JS, mediów, fontów itp.):

• 24 żądania, 938 kB danych – Gutenberg
• 51 żądań, 1.9 MB danych – Elementor

Już na pierwszy rzut oka widać, że na stronie z Elementorem ładuje się dwa razy więcej plików. Przesyłanych danych też jest ponad 2 razy więcej.

Jeśli prześledzimy skąd się bierze ta różnica to szybko zauważymy, że odpowiedzialna jest za to wtyczka Elementor. Na naszej stronie, ładuje dodatkowe 8 plików CSS oraz 10 dodatkowych plików JS (w tym kilka bibliotek jak np. Swiper 139 kB).

Warto też sobie porównać same tylko pliki JavaScript, różnica przesłanych kB jest ponad 15-krotna!

Sprawdźmy teraz ile mamy nieużywanego kodu w plikach CSS i JS. Wykorzystamy do tego narzędzie Coverage, które znajduje się w Google Chrome Tools. Od razu widzimy jak wiele zasobów Elementora nie wykorzystujemy, mimo że zostają one w całości załadowane na stronie.

Gutenberg vs. Elementor – Zapytania do bazy danych

Liczba zapytań do bazy danych oraz czas wykonania tych zapytań ma wpływ na TTFB (time-to-first-byte). Czyli na metrykę, która określa czas oczekiwania na pierwszy bajt danych z serwera. Duża liczba zapytań do bazy czy nieoptymalne zapytania SQL zwiększają czas reakcji serwera, więc lepiej starać się ograniczać liczbę zapytań. W WordPressie możemy to zrobić np. poprzez usunięcie wtyczki, która generuje spowalniające stronę zapytania do bazy. Więcej na temat TTFB przeczytasz na stronie: https://web.dev/time-to-first-byte/.

Na naszych stronach testowych skorzystamy z wtyczki Query Monitor, która w prosty sposób pozwala zobaczyć jakie zapytania SQL są wysyłane do bazy, jakie jest źródło tych zapytań (np. konkretna wtyczka), a także namierzyć wolne zapytania.

Widzimy, że wtyczka Elementor dokłada nam 66 zapytań i odpowiada za 2/3 wszystkich zapytań do bazy wykonywanych podczas ładowania strony. Wbudowany w WordPressa edytor blokowy sam z siebie nie dokłada dodatkowych zapytań do tych, które są domyślnie wykonywane przez samego WordPressa.

Gutenberg vs. Elementor – jak wpływają na prędkość strony?

Przede wszystkim, edytor blokowy wbudowany w WordPressa nie wpływa w żaden dodatkowy sposób na prędkość ładowania strony. Od strony frontendu działa to właściwie tak samo jak w klasycznym edytorze. Statyczny HTML zostaje wczytany z bazy danych na etapie ładowania WordPressa i później jest wyświetlony przez motyw.

Wtyczka Elementor to osobna aplikacja, która po zainstalowaniu i aktywowaniu staje się taką nakładką na domyślny edytor blokowy w WordPressie. Wtyczka ta ma swoje własne assety (np. pliki CSS, JS), własną logikę działania i własny zespół programistów, od których zależy jakość zastosowanych rozwiązań. A także własne cele biznesowe, które mogą powodować, że maksymalizacja zysku będzie ważniejsza niż np. jakość wygenerowanego kodu.

Patrząc na opisane powyżej wskaźniki, we wszystkich Elementor wypada znacznie gorzej od edytora blokowego. Nic dziwnego więc, że strona zbudowana na domyślnym edytorze blokowym osiąga 2 razy lepsze rezultaty w Core Web Vitals, nawet bez żadnych działań optymalizacyjnych z naszej strony.

Ten i tak już dobry wynik strony z samym edytorem blokowym, można jeszcze poprawić, dobierając (lub samodzielnie kodując) lżejszy motyw. Ale i tak jest całkiem nieźle, szczególnie że nie dokonywałam jeszcze na tej stronie żadnych optymalizacji.

Czy warto już teraz przestawić się z Elementora na Gutenberga?

Zyski z porzucenia Elementora na rzecz wbudowanego w WordPressa edytora są oczywiste. Szczególnie teraz, gdy wyniki z Core Web Vitals będą się liczyć jako czynnik rankingowy w Google. Dodatkowo, jakość wygenerowanego kodu HTML jest wystarczająco dobra, że nawet webdeveloper ze spokojnym sumieniem może wyklikać stronę z bloków 😛

Z drugiej strony, Gutenberg raczej nigdy nie będzie posiadał tak bogatej palety opcji ustawiania styli dla każdego bloku z osobna, gdyż nie do końca jest on narzędziem do projektowania stron. Jest on bardziej narzędziem do generowania HTMLa. Jego twórcy dbają o zachowanie dobrych praktyk webmasterskich. Z założenia większość wygenerowanego kodu HTML ma dziedziczyć styl po globalnych ustawieniach, a nie być ustawiana indywidualnie dla każdego bloku z osobna.

I spodziewam się, że dla niektórych użytkowników, którzy nie za bardzo orientują się w dobrych praktykach, a zdążyli się już przyzwyczaić do mnogości opcji jakie daje Elementor, to może być ciężkie do przeskoczenia.

Gutenberg cały czas se rozwija i poszerza swoje funkcje. Swój pełny potencjał osiągnie dopiero za kilka lat. Jednak już teraz można na nim wiele zrobić i już dziś jesteśmy w stanie w nim utworzyć całkiem dobrą, i przede wszystkim szybką, stronę firmową.

A wy co myślicie? Czy warto przesiąść się z Elementora na edytor blokowy? A może już próbowaliście to robić? Napiszcie w komentarzu, chętnie przeczytam o Waszych doświadczeniach.