Gutenberg mot Elementor mot Divi 2026: sammenligning av sidebyggere

Tre byggere avgjør mye av valget av sidebygger for WordPress i 2026. Gutenberg følger med WordPress-kjernen. Utvidelseskatalogen på WordPress.org oppgir over 10 millioner aktive Elementor-installasjoner, mens Elementors eget nettsted sier at over 22 millioner nettsteder er bygget med det. Det er to ulike mål, og de bør ikke slås sammen. Divi publiserer ikke et direkte sammenlignbart, revidert tall for aktive installasjoner, så en presis rangering av de tre etter utbredelse ville vært falsk presisjon.

Versjonene denne sammenligningen ble kontrollert mot 12. oktober 2026: WordPress 7.1.3, Elementor 4.3.4 (WordPress.org oppgir Requires at least 6.8 og Tested up to 7.1.3) og Divi 5, som Elegant Themes erklærte ute av beta 26. februar 2026.

Valget mellom dem er ingen skjønnhetskonkurranse. Det er en avveining mellom ekstra ressursbelastning, leverandørinnlåsing, utviklerarbeidsflyt og hvordan en ikke-teknisk kunde redigerer nettstedet etter overlevering. Denne guiden går gjennom hver akse og avveiningen du faktisk står overfor.

Kort svar: Gutenberg for innholdsnettsteder der en redaksjon skal læres opp og en utvikler vedlikeholder theme.json. Elementor for byråarbeidsflyt med landingssider, der noen uten utviklerbakgrunn skal publisere sider uten å røre kode. Divi for frilansere som jobber alene og overleverer ferdige nettsteder til ikke-tekniske kunder med en langsiktig vedlikeholdsavtale.

#Hvordan lagrer Gutenberg, Elementor og Divi innhold

Den arkitektoniske forskjellen er ikke et slagord, den er det som havner i databasen og sendes over nettet.

#Gutenberg

Blokkmarkup lagres i post_content som HTML med kommentarskilletegn (<!-- wp:paragraph -->). Ved rendring gir blokkene semantisk HTML; stilene ligger i theme.json og blokkenes stilark. Deaktiver Gutenberg (i praksis umulig, siden den er kjerne), og HTML-en lar seg fortsatt tolke. Flytt til en annen plattform, og selve innholdet er portabelt.

Ett forbehold som de fleste sammenligninger hopper over: dynamiske blokker som Latest Posts, Query Loop eller Navigation lagrer bare en selvlukkende kommentar med JSON-attributter og bygger markupen sin ved hver forespørsel gjennom en render callback.

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

Statisk innhold overlever ethvert temabytte og enhver eksport. Dynamisk innhold trenger det som registrerte blokken. Trunk i WordPress-kjernen har i dag 115 blokkmapper under src/wp-includes/blocks/; en blokk lagt til av en utvidelse som senere fjernes, har samme problem som enhver bygger, bare i mindre skala.

#Elementor

Sideinnholdet lagres som postmeta i _elementor_data, et JSON-tre med widgetdefinisjoner. Konstanten står i Elementors core/base/document.php:

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

Selve kolonnen post_content er stort sett tom for Elementor-sider. Deaktiver Elementor, og forsiden faller tilbake på det som står i post_content, som vanligvis er ingenting. Det ofte gjentatte “kortkoderotet” er et trekk ved Divi 4, ikke ved Elementor: Elementor etterlater en tom side, ikke parenteser.

#Divi

Fram til Divi 4 lå oppsettet i kortkoder inne i post_content: [et_pb_section][et_pb_row][et_pb_column][et_pb_text].... Deaktiver Divi 4, og forsiden viser rå kortkodeparenteser. Divi 5 erstattet dette formatet. Elegant Themes skriver at “det nye lagringsformatet i Divi 5 etterligner WordPress’ native blokker” og gir to grunner: WordPress går fra kortkoder til blokker, og en side bygget av kortkoder er tregere å tolke fordi den mangler et ordentlig hierarki (Elegant Themes, egen oversettelse).

Lærdommen: Gutenberg gir portabel HTML, mens Elementor og Divi gir proprietære strukturer som binder innholdet ditt til utvidelsens kjøretid. Innlåsing finnes hos alle tre. Det nyttige spørsmålet er om et migreringsskript i det hele tatt kan tolke formatet. JSON i postmeta kan tolkes. Dypt nøstede kortkodeattributter kunne bare tolkes med smerte.

#Markedsandel for sidebyggere i WordPress 2026

Elementor er klart den mest brukte tredjeparts sidebyggeren: W3Techs fant den på 31,5 % av WordPress-nettstedene 12. oktober 2026, og WordPress.org oppgir over 10 millioner aktive installasjoner. Gutenberg vises ikke i disse listene av en strukturell grunn: den følger med i WordPress-kjernen, så det meningsfulle spørsmålet er hvor mange nettsteder som bruker den som sitt viktigste layoutverktøy, ikke om den er installert.

To forbehold før du siterer disse tallene noe sted. For det første er Divi undertalt her: det leveres hovedsakelig som tema, ikke som utvidelse, så W3Techs’ utvidelsesdeteksjon går glipp av de fleste Divi-nettstedene, og millionstallet som vanligvis oppgis for Divi, kommer fra Elegant Themes’ egen markedsføring og ikke fra en uavhengig måling. For det andre er andel av installasjoner ikke andel av nye prosjekter: WPBakerys andel er i stor grad eldre ThemeForest-temaer, mens nyere byggere som Bricks viser små totaltall, men vokser fra et nylig utgangspunkt. For valg av bygger i 2026 er den praktiske lesningen enkel: Elementor har det største økosystemet og den største rekrutteringsbasen, Divi har en lojal, men mindre målbar brukerbase, og Gutenberg er den eneste som garantert finnes på hver WordPress-installasjon du noen gang kommer til å røre.

#Funksjoner i Gutenberg, Elementor og Divi sammenlignet

Før argumentasjonen akse for akse kommer hele sammenligningen på én skjerm. Les radene, ikke kolonnene: de interessante forskjellene er der én bygger gjør noe strukturelt som de andre ikke kan.

Mønsteret i tabellen er konsekvent: Elementor og Divi vinner radene om fri visuell kontroll og et stort ferdig malbibliotek, Gutenberg vinner radene om portabilitet, samsvar med kjernen og utvidelsesmodellen. Den ene raden der de tre ikke ligger nær hverandre, er innholdslagring, og det er raden som blir en kostnadspost to eller tre år senere.

#Sidehastighet i Elementor, Divi og Gutenberg

Den populære oppsummeringen sier at Gutenberg er slank, Elementor er oppblåst og Divi ligger midt imellom. Den oppsummeringen overlever ikke kildekoden. Kjernen laster blokkbiblioteket i sin helhet som standard, Elementor har et stabilt eksperiment for slankere markup, og Divi har erstattet kortkodeformatet sitt. Fire mekanismer avgjør resultatet på et ekte nettsted.

#Laster WordPress alle blokkstiler på hver side

wp_should_load_separate_core_block_assets() i wp-includes/script-loader.php slutter med én enkelt linje:

return apply_filters( 'should_load_separate_core_block_assets', false );

Standardverdien for filteret er false, så uten inngrep laster en side med ett avsnitt hele stilarket wp-block-library. To ting endrer dette. Blokktemaer setter filteret til true automatisk i _add_default_theme_supports(). Fra WordPress 6.9 får klassiske temaer samme behandling gjennom wp_load_classic_theme_block_styles_on_demand(), koblet til wp_default_styles med prioritet 0. Den som hevder at Gutenberg er slank av natur, har enten et blokktema eller en oppdatert installasjon. På et klassisk tema med en eldre WordPress-versjon stemmer påstanden ikke.

#Slik slår du på optimalisert markup i Elementor

Elementors eksperimentbehandler oppgir e_optimized_markup som stabil, beskrevet som “Reduser DOM-størrelsen ved å fjerne HTML-tagger i ulike elementer og widgeter” (Elementor, egen oversettelse). Standardverdiene:

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

Nye installasjoner fra 3.30.0 får det slått på. En byråinstallasjon fra 2019 som bare har blitt oppdatert, får det ikke. Den samme beskrivelsen advarer om at endringen “kan kreve oppdatering av egen CSS/JS-kode” (Elementor, egen oversettelse), og det er grunnen til at få slår på bryteren på et nettsted i drift. Mye av det sammenligningsartikler kaller Elementors div-suppe, er en egenskap ved denne migreringsstrategien heller enn ved selve utvidelsen.

#Lat innlasting og manglende bildedimensjoner i Elementor

I includes/controls/groups/image-size.php kaller Elementor wp_get_attachment_image() bare når den har en vedleggs-ID og en registrert bildestørrelse i WordPress. Med egne dimensjoner bygger den taggen selv, med en hardkodet loading="lazy" og uten width eller height. Kjernens wp_get_loading_optimization_attributes() avslutter tidlig uten disse dimensjonene, før den rekker å bestemme fetchpriority. Et hero-bilde med egendefinert størrelse lastes derfor lat selv når det er LCP-elementet. Det er det første stedet å se i en revisjon av et Elementor-nettsted.

#Divi 5 og sidehastighet

Elegant Themes beskriver Divi 5 som raskt og opplyser at sider som fortsatt kjører i bakoverkompatibel modus, ikke får “ytelsesforbedringene i Divi 5” før de er migrert (Elegant Themes, egen oversettelse). Leverandøren publiserer ingen uavhengig ytelsestest, så et Divi 4-nettsted som er oppgradert til Divi 5 uten å kjøre migreringsverktøyet, bør ikke forventes å endre hastighet.

#Ytelsesgrep som gjelder alle tre byggerne

Spekulativ innlasting har vært en del av kjernen siden WordPress 6.8 og virker på dokumentnivå, uavhengig av byggeren. Standard er prefetch med eagerness conservative, og det gjelder bare for pene permalenker og utloggede besøkende.

En sammenligningsmåling er bare verdt noe når den bruker samme side, samme hosting og samme tidsvindu, med feltdata og ikke én enkelt laboratoriekjøring. Et Gutenberg-nettsted har også sin egen feilmodus: uten et sentralt mønsterregister kopierer redaktører et hero-mønster, tilpasser det direkte, og nettstedet ender med mange hero-varianter og ingen felles kilde. Ytelsesgevinstene i Gutenberg overlever ikke redaksjonell glidning med mindre noen eier theme.json og mønsterbiblioteket.

#Hva skjer når du deaktiverer Elementor eller Divi

To separate spørsmål blandes sammen i de fleste sammenligninger. Det ene er hvor rask byggeren er i vanlig drift, som er dekket ovenfor. Det andre er hva som skjer med Core Web Vitals, og med selve innholdet, hvis byggeren noen gang fjernes. Det andre spørsmålet er innlåsingsskatten uttrykt som et rendringsproblem, og det er det som avgjør om et nettsted kan overleve sitt eget verktøy.

Med Gutenberg er deaktivering en ikke-hendelse, fordi blokkredigereren er kjerne og ikke kan slås av. Det nyttige tankeeksperimentet er i stedet å eksportere innholdet: blokkmarkup er gyldig HTML, så et eksportert innlegg beholder struktur, overskrifter, lister og bildereferanser. Largest Contentful Paint og Cumulative Layout Shift styres da av temaet og bildene, ikke av en redigererkjøretid som må starte ved hver forespørsel.

Med Elementor er forsiden avhengig av at utvidelsen leser _elementor_data og legger inn egen CSS og JavaScript ved rendring. Fjern utvidelsen, og oppsettet er borte; behold den, og hver side bærer byggerens budsjett for stilark og skript, som er nettopp vekten som presser LCP gjennom renderblokkerende CSS og trekker Interaction to Next Paint opp gjennom hendelseshåndtererne som knyttes til hver widget. Byggeren er ikke bare måten en side en gang ble bygget på, den er en permanent kjøretidsavhengighet for hvordan siden rendres.

Divi 4 oppfører seg på samme måte gjennom kortkoder. Modulene må løses opp av den aktive Divi-kjøretiden, så CSS og JavaScript følger med hver side, og deaktivering etterlater rå kortkodeparenteser på forsiden. Divi 5 endrer lagringsformatet, ikke avhengigheten: innholdet trenger fortsatt Divi for å rendres slik det er designet.

Den ene setningen som betyr noe for et nettsted som skal vare: med Gutenberg overlever innholdet verktøyet, og med Elementor eller Divi er innholdet verktøyets utdata og kan ikke rendres uten det. Hvert prosjekt for ytelsesutbedring på et byggertungt nettsted møter til slutt denne veggen, fordi du ikke kan fjerne kjøretidsvekten uten også å fjerne oppsettet.

#Egne Gutenberg-blokker eller Elementor-widgeter

Her slutter sammenligningen å handle om sluttbrukere.

Gutenberg forutsetter en byggeprosess med React og ESNext. For å levere en egen blokk trenger du et byggesteg (vanligvis @wordpress/scripts), en metadatafil block.json og registrering på begge sider. Håndboken for blokkredigereren beskriver block.json som filen som “forenkler prosessen med å definere og registrere en blokk” (WordPress Developer Resources, egen oversettelse), med én definisjon som brukes både på serveren og i redigereren. Læringskurven er reell: WordPress-byråer som vokste opp med klassiske PHP-temaer, møter den hardt første gang. Gevinsten er at egne blokker oppfører seg som fullverdige WordPress-borgere: støtte for REST API, blokkmaler, blokkmønstre og overstyring i theme.json følger med gratis.

Elementor lar noen uten utviklerbakgrunn publisere sider uten kode. API-et for egne widgeter finnes, men de fleste byråer rører det aldri; de setter sammen sider fra det innebygde widgetbiblioteket og tredjepartspakker. Dette er den egentlige grunnen til at Elementor vinner overleveringer fra byrå til kunde: kunden kan redigere nettstedet uten å ødelegge det, og byrået får ingen telefon sent på kvelden om en syntaksfeil.

Divi ligger imellom. Divi Builder er like vennlig for ikke-tekniske brukere som Elementor; API-et for undertemaer og moduler i Divi ligger nærmere utviklermodellen i Gutenberg enn widget-API-et i Elementor. Frilansere som jobber alene, og som driver med design, men ikke React, havner ofte her.

Hvis du lurer på hvilken du bør lære: en WordPress-utvikler i 2026 leverer Gutenberg-blokker og FSE-maler, kan nok Elementor til å migrere nettsteder bort fra det, og vet at Divi finnes for vedlikeholdsavtaler med kunder.

#Elementor eller Gutenberg for fleksibelt design

#Designregler med theme.json i Gutenberg

Kontrakten mellom design og redigerer er theme.json. Gjeldende skjemaversjon er 3, definert i kjernen som const LATEST_SCHEMA = 3; i class-wp-theme-json.php. Det finnes ingen versjon 4, uansett hva årsoppsummeringer påstår. Den praktisk viktige delen er ikke styles, men settings, fordi settings avgjør hva redaksjonen får lov til å røre:

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

Med denne filen forsvinner den frie fargevelgeren fra redigereren. Det er derfor store redaksjoner går over til blokker: ikke for lastetiden, men fordi redigereren har grenser som ligger i Git.

#Bruddpunkter per enhet i Elementor

Elementor føles fortsatt mer som et grafisk verktøy, og det er en arbeidsmåte, ikke en fornærmelse. Den konkrete funksjonelle forskjellen er bruddpunkter. Elementors core/breakpoints/manager.php definerer sju enheter: mobil, nettbrett og desktop er aktive som standard, og fire til kan slås på (mobile extra, tablet extra, laptop og widescreen). Kjerneredigereren har ingen tilsvarende funksjon. Den tilbyr flytende typografi gjennom settings.typography.fluid, altså clamp()-verdier mellom et minimum og et maksimum, og alt annet går gjennom CSS i temaet.

For et design som angir ulik avstand og rekkefølge per enhet, er det her et Gutenberg-bygg koster utviklertid som et Elementor-bygg ikke gjør. Den som påstår noe annet, driver salg.

#Divi som lukket økosystem

Divi bringer designsystemet sitt inn i sitt eget grensesnitt og forblir et lukket økosystem: det finnes ikke i utvidelseskatalogen på WordPress.org, og oppdateringer kommer gjennom medlemskapet hos Elegant Themes. For mange byråer er det ingen ulempe så lenge medlemskapet løper, og en tydelig ulempe når en kunde skal overta nettstedet.

#Ødelegger oppdateringer Elementor, Divi eller Gutenberg

Den gamle formelen “Gutenberg ryker nesten aldri, byggere ryker hele tiden” er for bekvem. Bruddpunktene er bare forskjellige.

Blokker ryker gjennom blokkvalidering. Når en blokk endrer den lagrede markupen sin uten en deprecated-definisjon som dekker den gamle versjonen, melder redigereren at blokken inneholder uventet eller ugyldig innhold. Forsiden påvirkes ikke, redaksjonen gjør det. Dette rammer nesten alltid egne blokker eller blokker fra utvidelser, sjelden kjerneblokker, fordi kjernen vedlikeholder sine deprecations.

Elementor og Divi ryker gjennom versjonsgap. For Elementor 4.3.4 oppgir utvidelseskatalogen på WordPress.org Requires at least 6.8 og Tested up to 7.1.3. Utvidelsen følger kjernen raskt, men den følger etter heller enn å komme samtidig. Divi legger til en dato i 2026: Elegant Themes lover å støtte Divi 4 “i minst de neste 12 månedene, og lenger hvis det er praktisk mulig” fra 26. februar 2026, med sikkerhets- og kompatibilitetsrettelser (Elegant Themes, egen oversettelse).

For en vedlikeholdsavtale betyr dette: med blokker sjekker du egne blokker og mønstre etter en kjerneoppdatering. Med Elementor og Divi sjekker du også rekkefølgen som kjerne, bygger, tema og Pro-tillegg oppdateres i, og du gjør det på staging, ikke i produksjon.

#Hva koster det å migrere bort fra Elementor eller Divi

To feilmoduser følger direkte av hvordan byggerne lagrer innhold.

Et Elementor-nettsted der lagrede maler ble satt inn i sider i stedet for å bli tildelt gjennom visningsbetingelser i Theme Builder. Når en lagret mal settes inn, kopieres innholdet inn i siden, så en senere endring i malen når ikke kopiene. Å legge til ett felt i et gjentatt oppsett betyr da å redigere hver side for hånd.

Et Divi 4-nettsted som har kjørt lenge. Et temabytte betyr at hver side må bygges om manuelt, fordi Divi-kortkoder er bundet til Divi-moduler og ingen tredjeparts migreringsverktøy bevarer oppsettet trofast. Å bli i Divi er enklere: migreringsverktøyet i Divi 5 konverterer alle Divi 4-moduler på hele nettstedet og tar først en sikkerhetskopi av innleggsinnholdet fra Divi 4.

Fra Elementor til blokker finnes det ingen knapp. Prosessen som holder i praksis:

1. Tell opp beholdningen. Bruk WP-CLI til å liste alle innlegg med _elementor_edit_mode og sorter widgettypene de bruker etter hyppighet.
2. Definer kartleggingen. For de vanligste typene velger du et mål: kjerneblokk, mønster eller egen blokk. Alt som ikke har en plass på listen, bygges om for hånd og konverteres ikke automatisk.
3. Frys URL-ene. Migreringen endrer markup, ikke adresser. Der en slug likevel endres, går omdirigeringen ut i samme utrulling.
4. Mål før og etter. Samme URL-er, samme verktøy og feltdata over et tilstrekkelig langt tidsvindu.
5. Deaktiver utvidelsen først da. Ikke tidligere, fordi post_content på Elementor-sider vanligvis er tom.

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

Gutenbergs portabilitet er det praktiske svaret på alt dette. Blokkmarkup overlever temabytter, utskifting av utvidelser og til og med arbeidsflyter med eksport til statiske nettsteder.

#Synkroniserte mønstre eller globale widgeter i Elementor

Der Gutenberg og Elementor skiller lag tydeligst, er i redaksjonelt arbeid i stor skala.

Gutenberg har synkroniserte mønstre (tidligere gjenbrukbare blokker; WordPress 6.3 ga dem nytt navn). WordPress-dokumentasjonen er tydelig: når et synkronisert mønster endres, slår endringen gjennom alle steder der det brukes, og en redaktør kan løsrive én enkelt forekomst for å redigere den lokalt. Dette er funksjonen som betyr noe for redaksjoner som driver et magasin, en kunnskapsbase eller et dokumentasjonsnettsted. Sammen med blokkmaler og maldeler i FSE får du ekte arv: endre maldelen for artikkelbunnen, og hver artikkel gjenspeiler endringen.

Elementor har globale widgeter i Pro og temadeler i Theme Builder. Maler i Theme Builder brukes etter visningsbetingelser, så de forplanter seg. Lagrede maler som er satt inn i en side, gjør det ikke. Redaksjoner som ikke lærte forskjellen tidlig, ender med mange kopier av samme hero, glidning mellom dem og en vedlikeholdsregning.

Divi har globale moduler og Theme Builder, på samme måte som Elementor.

For et innholdsnettsted med 500 artikler er synkroniserte mønstre og blokkmaler i Gutenberg det eneste av de tre alternativene som skalerer uten å være avhengig av et betalt tillegg.

#Sidebyggere og det europeiske tilgjengelighetsdirektivet

Det europeiske tilgjengelighetsdirektivet (European Accessibility Act, direktiv 2019/882) gjelder fra 28. juni 2025 og omfatter netthandelstjenester, altså salg og booking gjennom et nettsted eller en app, ikke alle bedriftsnettsteder. Mikroforetak som yter tjenester, er unntatt. Det første spørsmålet er derfor ikke hvilken bygger, men om siden lar en besøkende bestille, booke eller inngå en avtale. Hvis ja, er byggeren bare verktøyet som oppfyller eller bommer på kravet.

Ingen bygger gir samsvar rett ut av esken. Feilene som går igjen i revisjoner, er de samme i alle tre:

• Knapper som bare inneholder et ikon og ikke har noe tilgjengelig navn.
• Karuseller og trekkspillmenyer der fokusrekkefølgen ikke lenger følger leserekkefølgen etter absolutt posisjonering.
• Kontraster i merkevarepaletten som ikke når terskelen 4,5:1, fordi ingen sjekket dem.
• Overskriftsnivåer som hopper fra H2 til H4, fordi nivået ble valgt etter skriftstørrelse.

Kjerneblokker gir semantiske elementer, noe som gir et bedre utgangspunkt, men det er malen som tar designbeslutningen, ikke blokken.

I Norge gjelder reglene om universell utforming av IKT både private og offentlige aktører. Uutilsynet skriver at “Både private og offentlige virksomheter, lag og organisasjoner må følge regelverket”, og at reglene omfatter “nettløsninger, apper og automater” (Uutilsynet).

Et beslektet EU-spørsmål gjelder skrifttyper. Innstillingen Load Google Fonts Locally i Elementor er av som standard ('std' => '0' i includes/settings/settings.php). På et nettsted med besøkende fra EU bør du slå den på eller vertsdrifte skriftene på annen måte, fordi en skriftforespørsel til Google sender den besøkendes IP-adresse til en tredjepart.

#Lisens og langsiktig kostnad for Elementor Pro og Divi

Lisensspørsmålet betyr mindre enn spørsmålet om fornyelse og migrering. Leverandørenes faktureringsmodeller, slik de er publisert på deres egne sider:

• Elementor fakturerer Pro årlig, planene er gradert etter antall nettsteder (fra ett nettsted opp til ubegrenset på byråplanen), og abonnementene fornyes til listepris.
• Elegant Themes selger Divi som årlig medlemskap eller som livstidsmedlemskap med engangsbetaling, og begge tillater ubegrenset antall nettsteder. Selskapet tar ikke betalt per nettsted.

Regningen som senker prosjekter, er ikke lisensen, men migreringskostnaden om tre år og den redaksjonelle glidningen om to år. “Gutenberg er gratis” er også bare halvt sant: uten blokkutvidelser betaler du utviklertid for mønstre og tokens, og med blokkutvidelser betaler du lisenser som alle andre steder. Den egentlige besparelsen med Gutenberg er den lave migreringskostnaden.

#Hvilken sidebygger bør du velge i 2026

En beslutningsregel fra praksis:

Velg Gutenberg hvis:

• Nettstedet er innholdstungt (blogg, dokumentasjon, magasin, kunnskapsbase)
• En redaksjon skal læres opp, ikke antas å være kompetent fra første dag
• Du kan sette av utviklertid til theme.json og et forvaltet mønsterbibliotek
• Du forventer at nettstedet skal overleve enhver enkelt leverandør av utvidelser

Velg Elementor hvis:

• Leveransen er landingssider og redaktøren er markedssjefen
• Designet trenger ulike verdier per bruddpunkt
• Overleveringen fra byrå til kunde er feilmodusen du mest trenger å unngå
• Du har regnet på fornyelseskostnaden på tvers av porteføljen og godtatt den

Velg Divi hvis:

• Du er frilanser alene eller et studio med to personer og har mange langvarige vedlikeholdsavtaler med kunder
• Livstidslisens med ubegrenset antall nettsteder får regnestykket til å gå opp på tvers av mange små nettsteder
• Kundene er ikke-tekniske og redigerer sjelden

Og det ubehagelige tilfellet: hvis ingen i teamet kan røre theme.json og redaksjonen likevel forventer fritt design, er et halvhjertet blokkbygg verre enn et ryddig konfigurert Elementor-nettsted. Bemanningen avgjør det prosjektet, ikke teknologien.

Feil spørsmål er “hvilken bygger er best i 2026?” Riktig spørsmål er “hvilken avveining kan teamet mitt bære de neste fire årene?”

#Vanlige spørsmål om Gutenberg, Elementor og Divi

Er Gutenberg en sidebygger? I 2026 ja: med FSE, blokkmaler, maldeler, theme.json og synkroniserte mønstre dekker den funksjonene til en sidebygger for de fleste bruksområder.

Kan jeg kjøre Elementor og Gutenberg sammen? Teknisk sett ja. I drift ender du med å betale begge ytelsesskattene og forvirre redaktørene. Velg én per nettsted.

Hvilken blokksuite for Gutenberg bør jeg legge til? GenerateBlocks for nettsteder der ytelse kommer først, Kadence for markedsføringsnettsteder med rikere design, Stackable for arbeid med landingssider. Ingen av dem er nødvendige: native blokker og theme.json dekker de fleste tilfeller.

Kommer Elementor til å forsvinne? Lite sannsynlig: WordPress.org oppgir over 10 millioner aktive installasjoner. Det som endrer seg, er standardveien, fordi Gutenberg følger med kjernen og nå kan dekke mer av arbeidet med hele nettstedet.

Fungerer WooCommerce med Gutenberg? Ja. Fra WooCommerce 8.3 er blokkene Cart og Checkout standard for nye installasjoner med blokktema. Butikker basert på kortkoder fungerer fortsatt, og eksisterende butikker beholder kassen sin til de velger å bytte.

Hvorfor klager utviklere på Elementor? DOM-dybde på gamle installasjoner, innlåsing i postmeta og migreringsskatten. Klagen handler mindre om visuell redigering og mer om det den visuelle redigereren etterlater seg.

Er FSE klart for produksjon? For nye bygg, ja. For migrering av store eksisterende nettsteder med klassisk tema, delvis: hybride oppsett (blokktema for nye maler, klassisk for eldre deler) fungerer i praksis.

Kan jeg migrere fra Elementor til Gutenberg automatisk? Nei. Hver troverdig migrering er manuell eller halvmanuell. Verktøy som lover automatisk konvertering, gir HTML som uansett må ryddes for hånd.

#Sist oppdatert: 2026-10-12

Forfatter: wppoland.com

Vil du gjøre et rent brudd med Elementor eller Divi? Snakk med WordPress-utviklerteamet vårt om en migrering til Gutenberg, eller se nylige bygg med blokktema i porteføljen vår. For arbeid med Core Web Vitals, se optimalisering av WordPress-hastighet.