Migracja z Elementora i Divi do Astro lub Next.js

Migracja z Elementora i Divi: dlaczego warto odejść od page builderów

Żeby była jasność, rozumiem zalety WordPressa z Elementorem albo Divi. To bezdyskusyjnie jeden z najszybszych sposobów, żeby postawić stronę. Niski próg wejścia, wizualny edytor, tysiące gotowych bloków i dla kogoś, kto zaczyna, to sensowny wybór (moje pierwsze doświadczenia też były bardzo Wordpressowe). Problem pojawia się nieco później, gdy na stronie przybywa użytkowników, zaczyna zarabiać i myślimy raczej jak powiększyć zyski. I rzecz właśnie w tym, że każdy punkt w Core Web Vitals przekłada się na pozycje w Google i konwersję.

Okazuje się, że wizualny edytor zaczyna nam ciążyć. Prosta strona firmowa potrafi ważyć kilka megabajtów, generować kilkaset zagnieżdżonych <div>-ów i ładować kilkanaście plików JavaScriptu, z których realnie używana jest garść. Do tego dochodzi, z czasem coraz żmudniejszy, comiesięczny rytuał aktualizacji wtyczek, konflikty wersji i ryzyko awarii.

Artykuł mówi o tym, jak przejście na nowoczesny stack Astro albo Next.js pomoże Ci w sprawie rosnących problemów z WordPressem. To realny skok w wydajności, bezpieczeństwie i komforcie pracy (DX). Przeczytajcie więcej, na czym dokładnie polega problem, jak wybrać framework i jak przeprowadzić migrację tak, żeby nie stracić SEO ani nerwów.

Dlaczego Elementor i Divi spowalniają WordPressa

Core Web Vitals: przeładowany DOM i div soup

Page buildery budują layout przez zagnieżdżanie kontenerów, więc sekcja zawiera wiersz, wiersz zawiera kolumnę, kolumna zawiera moduł, moduł zawiera własny wrapper — i tak w kółko. Ostatecznie, prosty blok „nagłówek + tekst + przycisk" potrafi wygenerować kilkanaście poziomów zagnieżdżenia:

<div class="et_pb_section et_pb_section_0 et_section_regular">
  <div class="et_pb_row et_pb_row_0">
    <div class="et_pb_column et_pb_column_4_4 et_pb_column_0">
      <div class="et_pb_module et_pb_text et_pb_text_0">
        <div class="et_pb_text_inner">
          <h2>Witaj</h2>
        </div>
      </div>
    </div>
  </div>
</div>

W wypadku czystego, dobrze napisanego kodu, ten sam fragment to kwestia jednej linijki. Przeglądarka musi przetworzyć każdy z tych węzłów, przeliczyć layout i style, a im głębsze drzewo DOM, tym dłuższy czas do interaktywności (TTI) i gorszy Interaction to Next Paint (INP). Do tego każda wtyczka dorzuca własne CSS i JS ładowane globalnie, na każdej podstronie, niezależnie od tego, czy dany komponent w ogóle występuje. W ten właśnie sposób, powstaje wydajnościowy koszmarek, nie mówiąc już o bardzo niskiej czytelności kodu.

Utrzymanie WordPressa: aktualizacje, konflikty i awarie

Typowo, instalacja WordPressa z Elementorem to sam WordPress, motyw, Elementor, Elementor Pro i kilkanaście wtyczek pomocniczych. Każdy z tych elementów aktualizuje się w swoim rytmie. Wystarczy, że jedna wtyczka nie nadąży za nową wersją PHP albo za zmianą w Elementorze, i w rezultacie mamy konflikty. W najlepszym wypadku będzie to ostrzeżenie w konsoli, a w najgorszym białą stronę na produkcji. Wiem, jak bardzo bywa to uciążliwe i stresujące, szczególnie gdy ostatnie czego chcemy to problemy techniczne. Ostatecznie, zamiast skupienia się na biznesie, musimy gasić pożary, których spokojnie moglibyśmy uniknąć w Astro czy Next.js.

Ograniczenia page builderów przy nietypowych funkcjach

Dopóki robisz to, co przewidzieli twórcy widgetów, generalnie wszystko powinno być ok. Jednak problemy zaczynają się przy nietypowej funkcjonalności biznesowej, na przykład własnym konfiguratorze produktu, integracji z zewnętrznym API, niestandardowym layoutem, który nie mieści się w siatce buildera. Wtedy i tak lądujesz w kodzie, tyle że w kodzie obudowanym warstwami abstrakcji page buildera, które trzeba obejść, a nie wykorzystać.

Astro czy Next.js po migracji z WordPressa?

Wybór zależy od tego, czym strona faktycznie jest. Zapoznaj się z poniższą tabelką.

Astro dla stron firmowych, blogów i landing page po WordPressie

Jeśli migrujesz stronę firmową, bloga albo landing, w 8 na 10 przypadków Astro jest właściwym wyborem. Filozofia frameworka stawia serwer na pierwszym miejscu, czyli domyślnie do przeglądarki trafia czysty HTML i CSS oraz zero JavaScriptu. Interaktywność dodajesz punktowo, poprzez architekturę wysp (Islands Architecture). JavaScript trafia do klienta tylko wtedy, gdy naprawdę jest potrzebny, i tylko dla konkretnego komponentu. Mamy więc pełną kontrolę, gdzie i kiedy używamy JS-a.

W praktyce oznacza to, że statyczna strona firmowa w Astro (obecnie stabilna wersja to Astro 7) może nie ładować ani jednego kilobajta JS-a, jeśli nie ma na niej interaktywnych elementów. To jest dokładnie ta „prosta strona", którą chciał mieć klient przechodzący z WordPressa, ale z profesjonalnymi narzędziami, systemem komponentów i type-safe zarządzaniem treścią.

Next.js dla aplikacji, paneli i e-commerce po WordPressie

Next.js (aktualnie linia 16.x z Turbopackiem jako domyślnym bundlerem) wybieramy wtedy, gdy strona jest w rzeczywistości aplikacją, czyli posiada rezerwacje, panel użytkownika z logowaniem, koszyk i checkout, dynamiczne dashboardy. Server Components, SSR i ISR (inkrementalna regeneracja statyczna) dają pełną kontrolę nad tym, co renderuje się na serwerze, a co na kliencie. Do tego dochodzi cały ekosystem Reacta.

Najprościej rzecz ujmując: wybierz Astro, jeśli głównym zadaniem strony jest prezentacja treści; jeśli strona coś „robi" i ma stan aplikacyjny, najlepszy będzie Next.js. Warto dodać, że Astro potrafi renderować komponenty Reacta jako wyspy, więc te światy nie wykluczają się nawzajem.

Jak zastąpić widgety Elementora i Divi w Astro lub Next.js

W kontekście migracji, często pojawia się wątpliwość, jak kontynuować budowę strony bez tradycyjnych widgetów. W rzeczywistości, podstawowe koncepcje konstrukcji witryn nadal istnieją, lecz manifestują się w nowocześniejszych i potężniejszych formach.

Komponenty zamiast widgetów z page buildera

Zamiast ręcznie przeciągać „karuzelę" z panelu Divi, tworzy się reużywalny komponent, który następnie wywołuje się w miejscach, gdzie jest potrzebny. W Astro wygląda to następująco:

---
// src/components/Hero.astro
interface Props {
  title: string;
  subtitle: string;
  ctaLabel: string;
  ctaHref: string;
}
const { title, subtitle, ctaLabel, ctaHref } = Astro.props;
---
<section class="hero">
  <h1>{title}</h1>
  <p>{subtitle}</p>
  <a href={ctaHref} class="btn">{ctaLabel}</a>
</section>

I użycie:

<Hero
  title="Szybkie strony, które konwertują"
  subtitle="Astro i Next.js zamiast wolnego WordPressa"
  ctaLabel="Umów konsultację"
  ctaHref="/kontakt/"
/>

Fundamentalna różnica polega na tym, że widget w kreatorze stron to konfiguracja ukryta w bazie danych, niewidoczna w systemie kontroli wersji (Git) i niemożliwa do wersjonowania. Natomiast komponent to kod – czytelny, testowalny, wersjonowany i spójny na każdej podstronie.

Stylizacja bez ciężkiego CSS-a z motywu WordPressa

Zamiast klikać w panelu i generować tony nieużywanego CSS-a, stylujesz w kodzie. Najczęściej wygląda to tak:

• Tailwind CSS — utility-first, świetny do szybkiej pracy, z automatycznym usuwaniem nieużywanych klas na etapie builda.
• CSS Modules — klasyczny CSS scopowany do komponentu, bez ryzyka kolizji nazw.
• Vanilla Extract — CSS pisany w TypeScripcie, w pełni type-safe.

Wspólną cechą jest to, że do przeglądarki trafia tylko ten CSS, który jest faktycznie używany. Żadnych kilkuset kilobajtów stylów motywu, z których korzystasz w 5%.

Panel treści po migracji: MDX, Headless CMS albo WordPress headless

To najczęstsze pytanie klienta i tutaj trzeba podjąć decyzję co do kierunku. Realnie są dwa:

1. Podejście Git-based (Markdown / MDX), czyli treść żyje w plikach w repozytorium. Idealne, gdy treści dogląda ktoś techniczny albo gdy to Ty jako deweloper prowadzisz publikacje. Astro daje tu potężne narzędzie: Content Collections z walidacją schematu przez Zod. Dostajesz autouzupełnianie i błąd na etapie builda, jeśli ktoś zapomni pola:

// src/content.config.ts
import { defineCollection, z } from 'astro:content'
import { glob } from 'astro/loaders'
 
const blog = defineCollection({
  loader: glob({ pattern: '**/*.mdx', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.coerce.date(),
    tags: z.array(z.string()),
  }),
})
 
export const collections = { blog }

Dodam na marginesie, jako były użytkownik WordPressa, że przejście na MDX i Next.js było jedną z najlepszych decyzji technologicznych, jaką mogłem podjąć w wypadku bloga. Właśnie z tego rozwiązania korzystam przy okazji pracy nad tym artykułem.

2. Podejście Headless CMS, w którym nietechniczny klient musi samodzielnie edytować treść w wizualnym edytorze. Wtedy warstwa treści siedzi w Sanity, Storyblok albo Strapi, a frontend (Astro/Next.js) pobiera ją przez API. Klient dostaje wygodny panel, Ty zachowujesz szybki, statyczny frontend.

Migracja z Elementora i Divi do Astro lub Next.js krok po kroku

Krok 1: audyt WordPressa i architektura danych

Zanim napiszesz pierwszą linijkę, zdecyduj, co zostaje, a co piszesz od nowa. Zwykle zostaje treść (wpisy blogowe, teksty podstron, zdjęcia z biblioteki mediów) i struktura URL-i. Piszemy od nowa layout i system komponentów. Zinwentaryzuj wszystkie typy stron, czyli zacznij od strony głównej, oferty, bloga, pojedynczego wpisu, kontaktu, stron landingowych. Każdy typ to osobny szablon w nowym projekcie.

Krok 2: eksport treści i czyszczenie shortcode'ów Elementora lub Divi

Treść z WordPressa wyciągniesz przez REST API (/wp-json/wp/v2/posts) albo WPGraphQL. Haczyk polega na tym, że treść zapisana Elementorem lub Divi jest naszpikowana shortcode'ami i wrapperami, które trzeba wyczyścić, by nie przenosić „div soup" jeden do jednego.

// Uproszczony przykład czyszczenia treści z shortcode'ów Divi/Elementora
function cleanWpContent(html) {
  return (
    html
      // usuń shortcode'y Divi typu [et_pb_section ...] i [/et_pb_section]
      .replace(/\[\/?et_pb_[^\]]*\]/g, '')
      // usuń shortcode'y Elementora
      .replace(/\[\/?elementor[^\]]*\]/g, '')
      // zredukuj puste wrappery
      .replace(/<div[^>]*>\s*<\/div>/g, '')
      .trim()
  )
}

W praktyce warto pociągnąć treść przez HTML-to-Markdown (np. turndown), żeby dostać czysty MDX gotowy do wrzucenia w Content Collections. To moment, w którym raz na zawsze pozbywasz się bagażu buildera.

Krok 3: przeniesienie designu do systemu komponentów

Rozbij istniejący design na komponenty: Header, Footer, Hero, Card, PricingTable, ContactForm. Zbuduj je raz, poskładaj z nich szablony podstron. Na tym etapie zwykle okazuje się, że połowa wariantów bloków z buildera to były te same układy z drobnymi różnicami — w kodzie sprowadzają się do jednego komponentu z propsami.

Krok 4: SEO po migracji, przekierowania 301 i mapa strony

• Mapowanie starych URL-i (301), jeśli struktura adresów się zmienia, każdy stary URL musi przekierowywać na nowy przekierowaniem 301. Na Cloudflare Pages czy Netlify robisz to plikiem _redirects:

# public/_redirects
/blog/stary-wpis-elementor    /blog/nowy-wpis    301
/uslugi.html                  /oferta/           301

W Astro możesz też zdefiniować przekierowania w konfiguracji, a w Next.js w next.config.js (redirects()).

• Przepisanie meta tagów. title, description, Open Graph, dane strukturalne (JSON-LD). W Astro/Next.js kontrolujesz je bezpośrednio w kodzie komponentu head, bez zależności od wtyczki SEO.
• Nowa mapa strony. W Astro wystarczy oficjalna integracja @astrojs/sitemap, która generuje sitemap.xml na etapie builda.
• Weryfikacja po wdrożeniu. Przed przełączeniem DNS zrób crawl starej i nowej wersji (np. Screaming Frog), porównaj listę URL-i i upewnij się, że żaden indeksowany adres nie zwraca 404, potem po wdrożeniu prześlij nową sitemapę w Google Search Console i obserwuj raport indeksowania.

Efekty migracji: PageSpeed, Lighthouse i waga strony

Konkretne liczby zależą od strony, hostingu i tego, jak bardzo obciążona była instalacja WordPressa. Poniżej typowy, reprezentatywny obraz różnicy przy migracji przeciętnej strony firmowej. Potraktuj to jako rząd wielkości:

Skąd ta różnica? Znika globalny CSS i JS wtyczek, znika przeładowany DOM, a statyczny HTML serwowany z CDN ładuje się błyskawicznie. Jak widać powyżej, przemyślana zmiana architektury to wydajnościowa rewolucja.

Czy warto migrować z Elementora lub Divi do Astro albo Next.js?

Warto migrować

• Liczy się każdy punkt w Core Web Vitals, ponieważ strona rywalizuje o pozycje w Google.

• Strona zauważalnie wolno działa i widać to w danych (Search Console, analityka konwersji).

• Rosną koszty utrzymania — hosting pod obciążony WordPress, licencje wtyczek, czas na aktualizacje i usuwanie konfliktów.

• Design buildera zaczyna ograniczać funkcjonalności biznesowe.

Można odpuścić

• Budżet jest zerowy, a strona spełnia swoją rolę bez presji na wyniki.

• Treść zmienia nietechniczny właściciel co dwa dni i nie ma miejsca na Headless CMS, który by to obsłużył (choć wtedy właśnie CMS jest tutaj najlepszym rozwiązaniem).