Med dette lidt forsigtige spørgsmål, mener jeg:
Hvis du nu lavede et Elementor site på samme host, med samme Plugins, samme billeder, osv.,
– og –
hvis du så lavde det samme site kun i WordPress’ Gutenberg Editor + evt. noget Custom Coding
… jamen, så ville det ‘rene’ WordPress site (uden Elementor) generelt være hurtigere til at loade.
Og det ville være endnu hurtigere med næsten usvigelig sikkerhed hvis du lige havde tid til at Custom Code hele skidtet fra bunden (og vidste hvad du gjorde).
So what is going on?!
Advarsel: Det følgende kan være lidt teknisk og rammer muligvis forbi målet for medlemmer som er begyndere eller bare er her for at få hjælp til at lave en Sticky Section på deres Elementor osv. Andre mere erfarne medlemmer vil sikkert føle jeg spilder deres tid fordi vi er lidt tilbage i ‘børnehaven’. Bær over med mig. Vi er nødt til at gøre det her så alle kan være med 
Nå, men hvorfor er det så at Elementor er langsom (relativt set)?
Det korte svar er at Elementor (og andre Page Buildere) typisk bruger mere kode til at lave de samme ting end hvis du bruger ‘ren’ WordPress og / eller koder noget fra bunden.
Og hvad betyder det så – sådan helt konkret? Ja, jeg er ikke den store kodemand så jeg har været lidt doven og fundet en god artikel (med video) som giver eksempler jeg synes er til at forstå (ja, selv jeg kan forstå dem! ).
Her er artiklen: https://gutenberghub.com/gutenberg-vs-elementor-html-bloat/
Jeg synes faktisk den forklarer det meget godt!
Vær ops på at artiklen er fra 2020 og der er sket en del forbedringer af Elementor siden – men jeg syntes eksemplerne var så gode, så jeg valgte at linke til den for at interesserede læsere bedre kan forstå det generelle problem. (Som stadig er der – omend i mindre omfang end i 2020.)
Men hvorfor er det så lige at man laver en langsom sidebygger?
Ja, kan man da for hulan ikke bare bygge en mere effektiv Page Builder? En superoptimeret Elementor fra starten?
Ja, og nej. Det er nok for vidt at komme ind på alle årsagerne, men der er i hvert fald to væsentlige:
1) En Page Builder som Elementor er et redskab til at bygge med – så du laver et ekstra lag af værktøjer som skal kunne rigtig mange ting – istedet for bare at have noget kodet rent fra bunden.
2) Mange Page Buildere er ret avancerede værktøjer og bliver bygget på et bestemt tidspunkt med nogle bestemte kodestandarder for øje. Når disse ændrer sig, så kan det være svært pludselig at ændre nogle ting i Page Builderen fordi det simpelthen er så stort et ‘korthus’.
Men er Elementor-folket så bare ligeglade generelt?
Nej, da – de ved da godt hvor skoen trykker. Og der er gjort fremskridt siden artiklen jeg linkede til før, som sagt. Fx med introduktionen af Flexbox Container som formodentlig snart bliver implementeret i alle udgaverne af Elementor.
Der er et eksempel her fra Elementor selv i hvor meget Flexbox kan reducere de såkaldte <div>s i koden: https://elementor.com/…/container-performance-a-closer…/
<div> – eller “The Content Division Element” – er et af de mest udskældte kodelementer som Elementors sidebygger har brugt ‘for mange’ af indtil nu.
(Og hvis du er virkelig frisk kan du jo hoppe over til en af nettets mange kode-tutorials og læse mere om <div>, fx her: https://developer.mozilla.org/…/docs/Web/HTML/Element/div )
Og alt det andet ..
Godt så. Når alt det her er sagt, så er der stadig hele konteksten rundt om Elementor – hosting, Plugins, osv. – som vi snakkede om i første post i denne tema-serie.
Det er vigtigt altid at huske på – det er let at skyde på Elementor for at du har et langsomt site, men hvis du har 117 Plugins og uploader billeder ukomprimeret direkte fra dit kamera, så er det nok ikke Elementor du skal optimere først. 
—
Det var det for nu. Håber nogen fik noget ud af det – ret mig endelig hvis jeg har skrevet noget som ikke er præcist nok.
Forslag eller ønsker til næste opslag i serien om hastighed modtages selvfølgelig også gerne – og ellers så bare fyr den af i kommentarerne hvis I har noget at fyre med
Bemærk: Vi antager at hostingen er den samme. Ellers er der frit slaw ift. at inddrage faktorer I mener er vigtigste – fra optimering af selve Elementors indstillinger over cache til CDN etc.
Forslag – fra Dan Stanley
1. Brug så lidt ekstra plugins som muligt. Som udgangspunkt prøver jeg kun på at bruge EP og så noget CSS/JS
2. Images skal tilpasses i størrelse og komprimeres til WebP. Skal tilpasses mobil.
3. Have fokus på ens layout. Jeg har aldrig brugt f.eks innersection, men istedet brugt inline auto olign.
4. Lad være med at have for mange forskellige fonte og sørg for at de serveres locally, dvs. upload de fonte du vil bruge til EP og fravælg Google Fonts.
5. Imens man udvikler på f.eks desktop, altid check mobilview.
6. Minimér video og animationer medmindre de giver mening.
7. Have fokus på over the fold og layout.
8. Brug f.eks code snippet til at indsætte kode istedet for at bruge endnu et plugin.
9. Lad vær med at bruge smart i en fart plugins, og fokusere på at lave det med EP i stedet.
10. Bruge Hello Theme.
11. Fjerne al unødvendig fedt. dvs. plugins, post, pages og optimere database.
12. Nogle af E´s widgets kan faktisk bruges til mere end man regner med f.eks CTA, spacer, tabs, accordion mm. Så istedet for at bruge flere widgets kunne man måske nøjes med en for samme funktion?
*
Gået på klingen om hvilke af disse punkter som er de vigtigste, svarede Dan at det var de første tre – hvis han var tvunget til at vælge 🙂
Undertegnede er meget enig heri. Det handler om at have et godt øje for kontektsten, især Plugins, layout og billeder – hvor meget serverkapacitet de mon bruger. Ikke om at stirre sig blind på om det nu er Elementor eller ‘ren’ WordPress eller ‘ren kode’ der er brugt til et website.
Selvfølgelig er der dog særlige forhold ved Elementor ift. hastighedsoptimering, og dem vil vi komme ind på i de kommende indlæg i tema-serien. Stay tuned!