Poniżej konkretne, techniczne porównanie Kadence (Theme + Kadence Blocks) vs Elementor, bez marketingu i bez „religii builderów”. Skupia się dokładnie na tym, co faktycznie robi różnicę w wydajności i jakości kodu.

1. Architektura renderowania

🟢 Kadence

• Oparte o natywne bloki Gutenberga

• Render:

  • HTML generowany serwerowo (PHP) + zapisany w treści posta

  • React używany tylko w edytorze

• Frontend:

  • praktycznie brak runtime JS do layoutu

Efekt:
➡ HTML istnieje bez JS
➡ Strona działa nawet przy wyłączonym JS

🔴 Elementor

• Własny system widgetów (nie bloki WP)

• Render:

  • layout + style + logika zależne od JS

• Duża część struktury:

  • div-in-div-in-div

Efekt:
➡ JS jest krytyczny dla wyglądu
➡ więcej punktów awarii i opóźnień

2. DOM (ilość i głębokość)

🟢 Kadence

Przykład: sekcja z tekstem i przyciskiem

html
<section>
  <div class="kb-row">
    <div class="kb-column">
      <p>Tekst</p>
      <a class="kb-button">Kup</a>
    </div>
  </div>
</section>

• Minimalna liczba wrapperów

• Logiczna struktura

• Łatwe do nadpisania CSS-em

🔴 Elementor

Ten sam efekt:

html
<div class="elementor-section">
  <div class="elementor-container">
    <div class="elementor-row">
      <div class="elementor-column">
        <div class="elementor-widget-wrap">
          <div class="elementor-widget-text-editor">
            <div class="elementor-widget-container">
              <p>Tekst</p>
            </div>
          </div>
          <div class="elementor-widget-button">
            <div class="elementor-widget-container">
              <a class="elementor-button">Kup</a>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

• 2–3× więcej elementów DOM

• większy koszt layout/reflow

• trudniejsza ingerencja CSS

3. CSS – sposób ładowania

🟢 Kadence

• CSS:

  • modularny

  • ładowany tylko dla użytych bloków

• Styl:

  • głównie klasy

  • bardzo mało inline-style

• Możliwość:

  • pełnego cache’owania

Efekt:
➡ mniejsze pliki
➡ brak CLS z powodu JS

🔴 Elementor

• CSS:

  • globalny + per-strona

  • często generowany dynamicznie

• Dużo:

  • inline-style

  • style="" w HTML

• Styl zależny od JS

Efekt:
➡ większe CSS
➡ trudniejsze cache
➡ ryzyko CLS

4. JavaScript

🟢 Kadence

• Frontend JS:

  • tylko jeśli dany blok go wymaga (np. slider)

• Brak:

  • JS do layoutu

• Brak:

  • frameworków na froncie

Typowo:
~5–20 KB JS (gzip)

🔴 Elementor

• Zawsze ładowane:

  • core JS

  • frontend handlers

  • dependencies

• JS:

  • obsługuje layout, animacje, breakpointy

Typowo:
~150–300 KB JS (gzip)

5. Core Web Vitals (praktyka, nie teoria)

🟢 Kadence

• LCP:

  • szybki (HTML gotowy od razu)

• CLS:

  • bardzo niski (brak JS layout shift)

• INP:

  • świetny (mało JS)

Bez problemu: 90–100 / 100
(nawet bez „czarów”)

🔴 Elementor

• LCP:

  • opóźniony przez CSS/JS

• CLS:

  • częsty (fonty, inline-style, animacje)

• INP:

  • cierpi przez JS

Typowo: 60–80
(po optymalizacji)

6. Kompatybilność z cache i optymalizacją

🟢 Kadence

• Świetnie współpracuje z:

  • LiteSpeed Cache

  • Redis Object Cache

• HTML:

  • stabilny

  • przewidywalny

🔴 Elementor

• Cache:

  • często wymaga wykluczeń

• Problemy:

  • dynamiczny CSS

  • warunki JS

7. Utrzymanie i przyszłość

🟢 Kadence

• Zgodne z:

  • kierunkiem rozwoju WordPressa

• Treść:

  • zostaje po wyłączeniu wtyczki

• Łatwiejsza migracja

🔴 Elementor

• Lock-in:

  • po wyłączeniu → „goły HTML bez stylu”

• Silne uzależnienie od pluginu

TL;DR (techniczna konkluzja)

Jedno zdanie, które idealnie oddaje różnicę

Kadence powstało w świecie Gutenberga i Core Web Vitals, a Elementor w świecie shortcodes i „byle działało na wszystkim”.