Gutenberg, Elementor czy Divi w 2026: porównanie page builderów

W 2026 roku decyzję o wyborze buildera w WordPressie w dużej mierze wyznaczają trzy narzędzia. Gutenberg jest częścią rdzenia WordPressa. Katalog wtyczek WordPress.org podaje ponad 10 milionów aktywnych instalacji Elementora, a strona Elementora mówi o ponad 22 mln zbudowanych stron. To różne miary i nie należy ich łączyć. Divi nie publikuje porównywalnej, zweryfikowanej liczby aktywnych instalacji, więc precyzyjny ranking zasięgu tej trójki byłby pozorną dokładnością.

Wersje, na których sprawdzono to porównanie 12 października 2026: WordPress 7.1.3, Elementor 4.3.4 (WordPress.org podaje Requires at least 6.8 i Tested up to 7.1.3) oraz Divi 5, które Elegant Themes wyprowadziło z fazy beta 26 lutego 2026.

Wybór między nimi nie jest konkursem piękności. To kompromis między narzutem zasobów, uzależnieniem od dostawcy, sposobem pracy deweloperów i tym, jak nietechniczny klient edytuje stronę po przekazaniu. Ten przewodnik omawia każdą z tych osi razem z kompromisem, przed którym naprawdę stoisz.

Krótka odpowiedź: Gutenberg dla stron z treścią, gdzie zespół redakcyjny zostanie przeszkolony, a deweloper utrzymuje theme.json. Elementor dla agencji produkujących landing page, gdzie osoba bez umiejętności programistycznych ma publikować strony bez dotykania kodu. Divi dla freelancerów pracujących w pojedynkę, którzy przekazują gotowe strony nietechnicznym klientom w ramach długiej umowy serwisowej.

#Jak Gutenberg, Elementor i Divi zapisują treść

Różnica architektoniczna nie jest hasłem, tylko tym, co trafia do bazy danych i do przeglądarki.

#Gutenberg

Znaczniki bloków są zapisywane w post_content jako HTML z ogranicznikami w komentarzach (<!-- wp:paragraph -->). Przy renderowaniu bloki generują semantyczny HTML, a style pochodzą z theme.json i arkuszy stylów bloków. Gdyby dało się wyłączyć Gutenberga (w praktyce niemożliwe, bo jest w rdzeniu), HTML nadal byłby poprawnie parsowany. Po migracji na inną platformę treść pozostaje przenośna.

Jedno zastrzeżenie, które pomija większość porównań: bloki dynamiczne, takie jak Latest Posts, Query Loop czy Navigation, zapisują tylko samozamykający się komentarz z atrybutami JSON, a swój kod budują przy każdym żądaniu przez funkcję renderującą.

<!-- wp:latest-posts {"postsToShow":3,"displayPostDate":true} /-->

Treść statyczna przetrwa każdą zmianę motywu i eksport. Treść dynamiczna potrzebuje kodu, który zarejestrował dany blok. Gałąź trunk rdzenia WordPressa zawiera obecnie 115 katalogów bloków w src/wp-includes/blocks/; blok dodany przez wtyczkę, którą później usunięto, ma ten sam problem co każdy builder, tylko w mniejszej skali.

#Elementor

Treść strony jest zapisywana w postmeta _elementor_data jako drzewo JSON z definicjami widżetów. Stała znajduje się w pliku core/base/document.php Elementora:

const ELEMENTOR_DATA_META_KEY = '_elementor_data';
const BUILT_WITH_ELEMENTOR_META_KEY = '_elementor_edit_mode';

Sama kolumna post_content jest w przypadku stron Elementora zwykle pusta. Po dezaktywacji Elementora front-end pokazuje to, co jest w post_content, czyli zazwyczaj nic. Często powtarzany “bałagan shortcode’ów” to cecha Divi 4, nie Elementora: Elementor zostawia pustą stronę, a nie nawiasy.

#Divi

Do Divi 4 układ był zapisany w shortcode’ach wewnątrz post_content: [et_pb_section][et_pb_row][et_pb_column][et_pb_text].... Po dezaktywacji Divi 4 front-end pokazuje surowe nawiasy shortcode’ów. Divi 5 zastąpiło ten format. Elegant Themes pisze, że “nowy format zapisu Divi 5 naśladuje natywne bloki WordPressa”, i podaje dwa powody: WordPress odchodzi od shortcode’ów na rzecz bloków, a strona zbudowana z shortcode’ów wolniej się parsuje, bo nie ma właściwej hierarchii (Elegant Themes, tłumaczenie własne).

Wniosek: Gutenberg generuje przenośny HTML, a Elementor i Divi własne struktury, które wiążą treść ze środowiskiem wtyczki. Uzależnienie istnieje przy wszystkich trzech. Przydatne pytanie brzmi, czy skrypt migracyjny w ogóle potrafi sparsować dany format. JSON w postmeta da się sparsować. Głęboko zagnieżdżone atrybuty shortcode’ów dałoby się sparsować tylko z trudem.

#Udział page builderów WordPress w rynku w 2026

Elementor jest zdecydowanie najczęściej używanym builderem zewnętrznym: W3Techs wykrył go 12 października 2026 na 31,5% stron WordPress, a WordPress.org podaje ponad 10 milionów aktywnych instalacji. Gutenberga nie ma na tych listach z powodu strukturalnego: jest dostarczany w rdzeniu WordPressa, więc sensowne pytanie dotyczy tego, ile stron używa go jako głównego narzędzia do układu, a nie tego, czy jest zainstalowany.

Dwa zastrzeżenia, zanim zacytujesz te liczby. Po pierwsze, Divi jest tu niedoszacowane: jest dystrybuowane głównie jako motyw, a nie wtyczka, więc wykrywanie wtyczek przez W3Techs pomija większość stron na Divi, a wielomilionowa liczba zwykle podawana dla Divi pochodzi z marketingu Elegant Themes, a nie z niezależnego pomiaru. Po drugie, udział w instalacjach to nie udział w nowych projektach: udział WPBakery to w dużej mierze starsze motywy z ThemeForest, a nowsze buildery, takie jak Bricks, mają małe liczby bezwzględne, ale rosną od niedawna. Przy wyborze buildera w 2026 roku praktyczny odczyt jest prosty: Elementor ma największy ekosystem i największą pulę specjalistów do zatrudnienia, Divi ma lojalną, ale trudniej mierzalną bazę, a Gutenberg jako jedyny na pewno jest w każdej instalacji WordPressa, z którą będziesz pracować.

#Porównanie funkcji Gutenberga, Elementora i Divi

Przed omówieniem kolejnych osi całe porównanie na jednym ekranie. Czytaj wiersze, nie kolumny: ciekawe różnice są tam, gdzie jeden builder robi coś strukturalnie, czego pozostałe nie potrafią.

Układ tabeli jest spójny: Elementor i Divi wygrywają w wierszach o swobodnej kontroli wizualnej i dużej bibliotece gotowych szablonów, Gutenberg w wierszach o przenośności, zgodności z rdzeniem i modelu rozszerzeń. Jedyny wiersz, w którym ta trójka mocno się rozjeżdża, to zapis treści, i właśnie ten wiersz po dwóch, trzech latach zamienia się w pozycję kosztową.

#Szybkość stron w Elementorze, Divi i Gutenbergu

Popularne podsumowanie mówi, że Gutenberg jest lekki, Elementor przeładowany, a Divi pośrodku. To podsumowanie nie wytrzymuje konfrontacji z kodem źródłowym. Rdzeń domyślnie ładuje całą bibliotekę bloków, Elementor ma stabilny eksperyment z lżejszym kodem, a Divi zastąpiło swój format shortcode’ów. O wyniku na prawdziwej stronie decydują cztery mechanizmy.

#Czy WordPress ładuje style wszystkich bloków na każdej stronie

Funkcja wp_should_load_separate_core_block_assets() w wp-includes/script-loader.php kończy się jedną linią:

return apply_filters( 'should_load_separate_core_block_assets', false );

Domyślna wartość filtra to false, więc bez ingerencji strona z jednym akapitem ładuje cały arkusz wp-block-library. Zmieniają to dwie rzeczy. Motywy blokowe automatycznie ustawiają filtr na true w _add_default_theme_supports(). Od WordPressa 6.9 motywy klasyczne są traktowane tak samo przez wp_load_classic_theme_block_styles_on_demand(), podpiętą pod wp_default_styles z priorytetem 0. Kto twierdzi, że Gutenberg jest lekki z natury, ma albo motyw blokowy, albo aktualną instalację. Na motywie klasycznym ze starszą wersją WordPressa to twierdzenie jest nieprawdziwe.

#Jak włączyć Optimized Markup w Elementorze

Menedżer eksperymentów Elementora oznacza e_optimized_markup jako stabilny i opisuje go słowami “Zmniejsz rozmiar DOM, usuwając znaczniki HTML w różnych elementach i widżetach” (Elementor, tłumaczenie własne). Jego wartości domyślne:

'default' => self::STATE_INACTIVE,
'new_site' => [
    'default_active' => true,
    'minimum_installation_version' => '3.30.0',
],

Nowe instalacje od wersji 3.30.0 mają go włączonego. Instalacja agencyjna z 2019 roku, która była tylko aktualizowana, już nie. Ten sam opis ostrzega, że zmiana “może wymagać aktualizacji własnego kodu CSS/JS” (Elementor, tłumaczenie własne), dlatego niewiele osób przełącza go na działającej stronie. Duża część tego, co artykuły porównawcze nazywają zupą divów w Elementorze, wynika z tej strategii migracji, a nie z samej wtyczki.

#Lazy loading i brak wymiarów obrazów w Elementorze

W pliku includes/controls/groups/image-size.php Elementor wywołuje wp_get_attachment_image() tylko wtedy, gdy ma ID załącznika i zarejestrowany w WordPressie rozmiar obrazu. Przy własnych wymiarach sam buduje znacznik, z zakodowanym na sztywno loading="lazy" i bez width ani height. Funkcja rdzenia wp_get_loading_optimization_attributes() bez tych wymiarów kończy działanie wcześniej, zanim zdąży zdecydować o fetchpriority. Obraz hero z własnym rozmiarem jest więc ładowany leniwie, nawet gdy jest elementem LCP. To pierwsze miejsce do sprawdzenia w audycie strony na Elementorze.

#Divi 5 a szybkość strony

Elegant Themes opisuje Divi 5 jako szybkie i stwierdza, że strony nadal działające w trybie zgodności wstecznej nie dostają “ulepszeń wydajności Divi 5”, dopóki nie zostaną zmigrowane (Elegant Themes, tłumaczenie własne). Producent nie publikuje niezależnego benchmarku, więc od strony na Divi 4 zaktualizowanej do Divi 5 bez uruchomienia migratora nie należy oczekiwać zmiany szybkości.

#Co przyspiesza stronę niezależnie od buildera

Speculative loading jest częścią rdzenia od WordPressa 6.8 i działa na poziomie dokumentu, niezależnie od buildera. Domyślnie to prefetch z gorliwością conservative i dotyczy tylko przyjaznych bezpośrednich odnośników oraz niezalogowanych odwiedzających.

Pomiar porównawczy jest coś wart tylko wtedy, gdy dotyczy tej samej strony, tego samego hostingu i tego samego okresu, z danymi terenowymi zamiast jednego pomiaru laboratoryjnego. Strona na Gutenbergu ma też własny tryb awarii: bez centralnego rejestru wzorców redaktorzy kopiują wzorzec hero, modyfikują go w miejscu i strona kończy z wieloma wariantami hero bez jednego źródła. Przewaga wydajnościowa Gutenberga nie przetrwa dryfu redakcyjnego, jeśli nikt nie odpowiada za theme.json i bibliotekę wzorców.

#Co się dzieje po wyłączeniu Elementora lub Divi

Większość porównań miesza dwa osobne pytania. Pierwsze dotyczy tego, jak szybki jest builder w normalnym działaniu, i zostało omówione wyżej. Drugie dotyczy tego, co dzieje się z Core Web Vitals i z samą treścią, jeśli builder zostanie kiedyś usunięty. To drugie pytanie jest kosztem uzależnienia wyrażonym jako problem z renderowaniem i to ono rozstrzyga, czy strona przetrwa własne narzędzia.

W przypadku Gutenberga dezaktywacja nie ma znaczenia, bo edytor blokowy jest w rdzeniu i nie da się go wyłączyć. Przydatniejszym eksperymentem myślowym jest eksport treści: znaczniki bloków to poprawny HTML, więc wyeksportowany wpis zachowuje strukturę, nagłówki, listy i odwołania do obrazów. Largest Contentful Paint i Cumulative Layout Shift zależą wtedy od motywu i obrazów, a nie od środowiska edytora, które musi startować przy każdym żądaniu.

W przypadku Elementora front-end zależy od tego, czy wtyczka odczyta _elementor_data i wstrzyknie przy renderowaniu własny CSS i JavaScript. Usuń wtyczkę, a układ znika. Zostaw ją, a każda strona niesie budżet arkuszy stylów i skryptów buildera, czyli właśnie ten ciężar, który obciąża LCP przez CSS blokujący renderowanie i podnosi Interaction to Next Paint przez obsługę zdarzeń dołączaną do każdego widżetu. Builder nie jest tylko narzędziem, którym kiedyś zbudowano stronę, tylko stałą zależnością tego, jak ta strona się renderuje.

Divi 4 działa tak samo przez shortcode’y. Moduły muszą zostać rozwiązane przez aktywne środowisko Divi, więc jego CSS i JavaScript trafiają na każdą stronę, a dezaktywacja zostawia na front-endzie surowe nawiasy shortcode’ów. Divi 5 zmienia format zapisu, nie zależność: jego treść nadal potrzebuje Divi, żeby wyglądać zgodnie z projektem.

Jedno zdanie, które ma znaczenie dla strony budowanej na lata: w Gutenbergu treść przeżywa narzędzie, a w Elementorze i Divi treść jest wynikiem działania narzędzia i bez niego się nie wyrenderuje. Każdy projekt naprawy wydajności na stronie mocno opartej na builderze prędzej czy później trafia na tę ścianę, bo nie da się usunąć ciężaru środowiska bez usunięcia układu.

#Własne bloki Gutenberga czy widżety Elementora

W tym miejscu porównanie przestaje dotyczyć użytkowników końcowych.

Gutenberg zakłada proces budowania oparty na React i ESNext. Żeby wdrożyć własny blok, potrzebujesz kroku budowania (zwykle @wordpress/scripts), pliku metadanych block.json i rejestracji po obu stronach. Podręcznik edytora blokowego opisuje block.json jako plik, który “upraszcza proces definiowania i rejestrowania bloku” (WordPress Block Editor Handbook, tłumaczenie własne), z jedną definicją używaną na serwerze i w edytorze. Krzywa nauki jest realna: firmy WordPressowe wychowane na klasycznych motywach PHP mocno to odczuwają za pierwszym razem. W zamian własne bloki zachowują się jak pełnoprawne elementy WordPressa: obsługa REST API, szablony bloków, wzorce bloków i nadpisania z theme.json są dostępne bez dodatkowej pracy.

Elementor pozwala osobie bez umiejętności programistycznych publikować strony bez kodu. API własnych widżetów istnieje, ale większość agencji nigdy go nie używa; składają strony z wbudowanej biblioteki widżetów i pakietów zewnętrznych. To jest właściwy powód, dla którego Elementor wygrywa przy przekazywaniu stron od agencji do klienta: klient może edytować stronę, nie psując jej, a agencja nie dostaje późnym wieczorem telefonu o błędzie składni.

Divi jest pośrodku. Divi Builder jest przyjazny dla osób nietechnicznych, podobnie jak Elementor, a API motywów potomnych i modułów Divi jest bliższe modelowi deweloperskiemu Gutenberga niż API widżetów Elementora. Trafiają tu zwykle freelancerzy pracujący w pojedynkę, którzy projektują, ale nie piszą w React.

Jeśli zastanawiasz się, czego się uczyć: deweloper WordPressa w 2026 roku wdraża bloki Gutenberga i szablony FSE, zna Elementora na tyle, żeby przenosić z niego strony, i wie, że Divi istnieje na potrzeby klientów w stałej obsłudze.

#Elementor czy Gutenberg do elastycznego projektowania

#Reguły projektowe w theme.json w Gutenbergu

Umową między projektem a edytorem jest theme.json. Aktualna wersja schematu to 3, zdefiniowana w rdzeniu jako const LATEST_SCHEMA = 3; w class-wp-theme-json.php. Wersji 4 nie ma, niezależnie od tego, co twierdzą podsumowania roku. W praktyce ważniejsza od styles jest sekcja settings, bo to settings decyduje, czego zespół redakcyjny może dotykać:

{
  "version": 3,
  "settings": {
    "color": { "custom": false, "defaultPalette": false },
    "typography": { "fluid": true, "customFontSize": false }
  }
}

Z takim plikiem z edytora znika dowolny wybór koloru. Dlatego duże zespoły redakcyjne przechodzą na bloki: nie dla czasu ładowania, tylko dlatego, że edytor ma ograniczenia zapisane w Gicie.

#Punkty przerwania dla urządzeń w Elementorze

Elementor nadal bardziej przypomina narzędzie graficzne i jest to opis sposobu pracy, a nie zarzut. Konkretna różnica funkcjonalna to punkty przerwania. Plik core/breakpoints/manager.php Elementora definiuje siedem urządzeń: mobile, tablet i desktop są domyślnie aktywne, a cztery kolejne można włączyć (mobile extra, tablet extra, laptop i widescreen). Edytor w rdzeniu nie ma odpowiednika. Oferuje płynną typografię przez settings.typography.fluid, czyli wartości clamp() między minimum a maksimum, a cała reszta przechodzi przez CSS motywu.

Przy projekcie, który określa inne odstępy i inną kolejność dla każdego urządzenia, budowa w Gutenbergu kosztuje czas dewelopera, którego budowa w Elementorze nie wymaga. Kto twierdzi inaczej, ten coś sprzedaje.

#Divi jako zamknięty ekosystem

Divi przenosi swój system projektowy do własnego interfejsu i pozostaje zamkniętym ekosystemem: nie ma go w katalogu wtyczek WordPress.org, a aktualizacje przychodzą w ramach członkostwa Elegant Themes. Dla wielu agencji to nie jest wada, dopóki członkostwo trwa, i wyraźna wada w chwili, gdy stronę ma przejąć klient.

#Czy aktualizacje psują Elementora, Divi lub Gutenberga

Stara formuła “Gutenberg prawie nigdy się nie psuje, buildery psują się ciągle” jest zbyt wygodna. Miejsca awarii są po prostu inne.

Bloki psują się przez walidację bloków. Gdy blok zmienia zapisywany kod bez definicji deprecated obejmującej starą wersję, edytor zgłasza, że blok zawiera nieoczekiwaną lub nieprawidłową treść. Front-end tego nie odczuwa, zespół redakcyjny tak. Dotyczy to prawie zawsze własnych bloków albo bloków z wtyczek, rzadko bloków rdzenia, bo rdzeń utrzymuje swoje definicje przestarzałych wersji.

Elementor i Divi psują się przez luki między wersjami. Dla Elementora 4.3.4 katalog wtyczek WordPress.org podaje Requires at least 6.8 i Tested up to 7.1.3. Wtyczka szybko nadąża za rdzeniem, ale nadąża, a nie jest z nim dostarczana. Divi dokłada datę w 2026 roku: Elegant Themes obiecuje wspierać Divi 4 “co najmniej przez kolejne 12 miesięcy, a dłużej, jeśli będzie to wykonalne” od 26 lutego 2026, z poprawkami bezpieczeństwa i zgodności (Elegant Themes, tłumaczenie własne).

Dla umowy serwisowej oznacza to: przy blokach po aktualizacji rdzenia sprawdź własne bloki i wzorce. Przy Elementorze i Divi sprawdź też kolejność aktualizacji rdzenia, buildera, motywu i dodatku Pro, i rób to na stagingu, nie na produkcji.

#Ile kosztuje migracja z Elementora lub Divi

Dwa tryby awarii wynikają bezpośrednio z tego, jak buildery zapisują treść.

Pierwszy to strona na Elementorze, na której zapisane szablony wstawiano do stron zamiast przypisywać je przez warunki Theme Buildera. Wstawienie zapisanego szablonu kopiuje jego treść do strony, więc późniejsza zmiana szablonu nie dociera do kopii. Dodanie jednego pola do powtarzalnego układu oznacza wtedy ręczną edycję każdej strony.

Drugi to długo działająca strona na Divi 4. Zmiana motywu oznacza ręczną przebudowę każdej strony, bo shortcode’y Divi są powiązane z modułami Divi i żaden zewnętrzny migrator nie zachowuje wiernie układu. Pozostanie w Divi jest łatwiejsze: migrator Divi 5 konwertuje wszystkie moduły Divi 4 w całej witrynie i najpierw zachowuje kopię zapasową treści wpisów z Divi 4.

Z Elementora na bloki nie ma przycisku. Proces, który sprawdza się w praktyce:

1. Policz zasoby. Użyj WP-CLI, żeby wypisać wszystkie wpisy z _elementor_edit_mode, i posortuj używane w nich typy widżetów według częstości.
2. Ustal mapowanie. Dla najczęstszych typów wybierz cel: blok rdzenia, wzorzec albo własny blok. Wszystko, czego nie ma na tej liście, jest przebudowywane ręcznie, a nie konwertowane automatycznie.
3. Zamroź adresy URL. Migracja zmienia kod, nie adresy. Tam, gdzie slug jednak się zmienia, przekierowanie trafia do tego samego wdrożenia.
4. Zmierz przed i po. Te same adresy URL, to samo narzędzie i dane terenowe z odpowiednio długiego okresu.
5. Dopiero wtedy dezaktywuj wtyczkę. Nie wcześniej, bo post_content na stronach Elementora jest zwykle puste.

wp post list --post_type=any --meta_key=_elementor_edit_mode --meta_value=builder --format=count

Przenośność Gutenberga jest praktyczną odpowiedzią na to wszystko. Znaczniki bloków przetrwają zmianę motywu, rotację wtyczek, a nawet eksport do stron statycznych.

#Wzorce synchronizowane czy globalne widżety Elementora

Najostrzej Gutenberg i Elementor różnią się przy masowej pracy redakcyjnej.

Gutenberg ma wzorce synchronizowane (wcześniej bloki wielokrotnego użytku; WordPress 6.3 zmienił ich nazwę). Dokumentacja WordPressa mówi to wprost: po zmianie wzorca synchronizowanego zmiana pojawia się we wszystkich miejscach, w których jest używany, a redaktor może odłączyć pojedyncze wystąpienie, żeby edytować je lokalnie. Ta funkcja ma znaczenie dla zespołów redakcyjnych prowadzących magazyn, bazę wiedzy albo dokumentację. W połączeniu z szablonami bloków i częściami szablonów w FSE daje prawdziwe dziedziczenie: zmień część szablonu ze stopką artykułu, a zmiana pojawi się w każdym artykule.

Elementor ma globalne widżety w wersji Pro i części motywu w Theme Builderze. Szablony Theme Buildera działają według warunków wyświetlania, więc zmiany się rozchodzą. Zapisane szablony wstawione do strony już nie. Zespoły redakcyjne, które wcześnie nie poznały tej różnicy, kończą z wieloma kopiami tego samego hero, rozjazdem między nimi i rachunkiem za utrzymanie.

Divi ma globalne moduły i Theme Builder, podobnie jak Elementor.

Dla serwisu z 500 artykułami wzorce synchronizowane i szablony bloków w Gutenbergu to jedyne rozwiązanie z tej trójki, które skaluje się bez płatnego dodatku.

#Page buildery a Europejski akt w sprawie dostępności

Europejski akt w sprawie dostępności (dyrektywa 2019/882) stosuje się od 28 czerwca 2025 i obejmuje usługi handlu elektronicznego, czyli sprzedaż i rezerwacje przez stronę lub aplikację, a nie każdą stronę firmową. Mikroprzedsiębiorstwa świadczące usługi są wyłączone. Pierwsze pytanie nie dotyczy więc buildera, tylko tego, czy strona pozwala odwiedzającemu zamówić, zarezerwować albo zawrzeć umowę. Jeśli tak, builder jest jedynie narzędziem, które spełnia wymóg albo go nie spełnia.

Żaden builder nie zapewnia zgodności od razu po instalacji. Błędy powtarzające się w audytach są takie same we wszystkich trzech:

• Przyciski zawierające tylko ikonę, bez dostępnej nazwy.
• Karuzele i akordeony, w których kolejność fokusu po pozycjonowaniu bezwzględnym nie odpowiada już kolejności czytania.
• Kontrasty w palecie marki, które nie spełniają progu 4.5:1, bo nikt ich nie sprawdził.
• Poziomy nagłówków skaczące z H2 na H4, bo poziom wybrano według rozmiaru czcionki.

Bloki rdzenia generują elementy semantyczne, co poprawia punkt wyjścia, ale decyzję projektową podejmuje szablon, nie blok.

Pokrewna kwestia w UE to czcionki. Ustawienie Load Google Fonts Locally w Elementorze jest domyślnie wyłączone ('std' => '0' w includes/settings/settings.php). Na stronie obsługującej odwiedzających z UE włącz je albo hostuj czcionki u siebie w inny sposób, bo zapytanie o czcionkę do Google przekazuje adres IP odwiedzającego podmiotowi trzeciemu.

#Licencja Elementor Pro czy Divi i koszt w dłuższym okresie

Pytanie o licencję ma mniejsze znaczenie niż pytanie o odnowienia i migrację. Modele rozliczeń producentów według ich własnych stron:

• Elementor rozlicza wersję Pro rocznie, plany różnią się liczbą stron (od jednej strony do nielimitowanej liczby w planie agencyjnym), a subskrypcje odnawiają się po cenie katalogowej.
• Elegant Themes sprzedaje Divi w ramach członkostwa rocznego albo jednorazowego członkostwa dożywotniego i oba pozwalają na nielimitowaną liczbę stron. Firma nie pobiera opłat za każdą stronę.

Projekty pogrąża nie licencja, tylko koszt migracji za trzy lata i dryf redakcyjny za dwa. “Gutenberg jest darmowy” to też tylko połowa prawdy: bez wtyczek blokowych płacisz czasem dewelopera za wzorce i tokeny, a z wtyczkami blokowymi płacisz za licencje jak wszędzie. Realna oszczędność Gutenberga to niski koszt migracji. Zakres prac i sposób wyceny strony na blokach opisuje cennik stron WordPress.

#Jaki page builder wybrać w 2026

Reguła decyzyjna z perspektywy praktyka:

Wybierz Gutenberga, jeśli:

• Strona opiera się na treści (blog, dokumentacja, magazyn, baza wiedzy)
• Zespół redakcyjny zostanie przeszkolony, a nie z góry uznany za kompetentny od pierwszego dnia
• Możesz zaplanować czas dewelopera na theme.json i zarządzaną bibliotekę wzorców
• Spodziewasz się, że strona przetrwa dłużej niż którykolwiek pojedynczy dostawca wtyczek

Wybierz Elementora, jeśli:

• Produktem są landing page, a edytuje je marketing manager
• Projekt wymaga innych wartości dla różnych punktów przerwania
• Przekazanie strony od agencji do klienta to tryb awarii, którego najbardziej musisz uniknąć
• Przeliczyłeś koszt odnowień w całym portfolio i go akceptujesz

Wybierz Divi, jeśli:

• Jesteś freelancerem pracującym w pojedynkę albo dwuosobowym studiem z długą listą klientów w stałej obsłudze
• Licencja dożywotnia bez limitu stron sprawia, że rachunek się zgadza przy wielu małych stronach
• Klienci są nietechniczni i rzadko edytują

I niewygodny przypadek: jeśli nikt w zespole nie potrafi pracować z theme.json, a zespół redakcyjny nadal oczekuje swobodnego projektowania, połowiczna budowa na blokach jest gorsza niż starannie skonfigurowana strona na Elementorze. O takim projekcie decyduje skład zespołu, nie technologia.

Złe pytanie brzmi “który builder jest najlepszy w 2026?”. Właściwe pytanie brzmi “który kompromis mój zespół udźwignie przez najbliższe cztery lata?”.

#Najczęstsze pytania o Gutenberga, Elementora i Divi

Czy Gutenberg to page builder? W 2026 roku tak: z FSE, szablonami bloków, częściami szablonów, theme.json i wzorcami synchronizowanymi pokrywa zakres funkcji page buildera w większości zastosowań.

Czy mogę używać Elementora i Gutenberga jednocześnie? Technicznie tak. Operacyjnie płacisz oba podatki wydajnościowe i wprowadzasz redaktorów w błąd. Wybierz jedno narzędzie na stronę.

Jaki zestaw bloków do Gutenberga warto dodać? GenerateBlocks dla stron, gdzie najważniejsza jest wydajność, Kadence dla stron marketingowych z bogatszym projektem, Stackable do pracy nad landing page. Żaden nie jest wymagany: natywne bloki i theme.json pokrywają większość przypadków.

Czy Elementor zniknie? Mało prawdopodobne: WordPress.org podaje ponad 10 milionów aktywnych instalacji. Zmienia się domyślna ścieżka, bo Gutenberg jest w rdzeniu i obsługuje już więcej pracy nad całą witryną.

Czy WooCommerce działa z Gutenbergiem? Tak. Od WooCommerce 8.3 bloki Cart i Checkout są domyślne w nowych instalacjach na motywach blokowych. Sklepy oparte na shortcode’ach nadal działają, a istniejące sklepy zachowują dotychczasowy checkout, dopóki same nie zdecydują się na zmianę.

Dlaczego deweloperzy narzekają na Elementora? Głębokość DOM w starych instalacjach, uzależnienie przez postmeta i koszt migracji. Zarzuty dotyczą mniej edycji wizualnej, a bardziej tego, co edytor wizualny po sobie zostawia.

Czy FSE nadaje się do produkcji? Przy nowych projektach tak. Przy migracji dużych istniejących stron na motywach klasycznych częściowo: konfiguracje hybrydowe (motyw blokowy dla nowych szablonów, klasyczny dla starszych) sprawdzają się w praktyce.

Czy da się automatycznie przenieść stronę z Elementora na Gutenberga? Nie. Każda wiarygodna migracja jest ręczna albo półautomatyczna. Narzędzia obiecujące automatyczną konwersję i tak generują HTML wymagający ręcznego czyszczenia.

#Ostatnia aktualizacja: 2026-10-12

Autor: wppoland.com

Chcesz czysto odejść od Elementora lub Divi? Porozmawiaj z naszym zespołem deweloperów WordPress o migracji na Gutenberga albo przejrzyj ostatnie realizacje na motywach blokowych w naszym portfolio. W sprawie Core Web Vitals zobacz optymalizację szybkości WordPress.