Elementor Vagy Egyedi Sablon: A Valós Költség

Az Elementor és az egyedi sablon vitáját rendszerint ízlésbeli kérdésként, néha törzsi hovatartozásként vezetik le. Egyik sem: költségkérdés, méghozzá kiszámítható alakú. Egy oldalszerkesztő a költséget kiveszi az építésből, és áttolja a webhely üzemeltetésébe. Hogy ez jó csere-e, két olyan számon múlik, amelyet szinte senki nem tesz az asztalra: hány oldalból áll a webhely, és milyen gyakran változnak ezek az oldalak.

A vita azért marad eldöntetlen, mert mindkét oldal anekdotákkal érvel. Valaki azt mondja, hogy a szerkesztők lassúak, valaki más közzétesz egy zöld Lighthouse-pontszámot, és semmi nem dől el. A teljesítmény valós költség, de csak egy sor egy hosszabb számlán, amelyen ott vannak a licencmegújítások, a bővítménykészlet, a szerkesztőségi átfutás, az akadálymentesítési javítások és a végén az az ár, amennyiért a saját tartalmát újra ki tudja hozni.

Az Elementor nem rossz eszköz. Webhelyek széles körénél ez a helyes válasz, és egy őszinte összehasonlítás ezt mondja ki elsőként. A hasznos kérdés nem az, hogy jó-e a szerkesztő, hanem az, hogy hol szűnik meg megérni, és ez a határ élesebb, mint a hangzavarból gondolnánk.

Melyik kerül valójában kevesebbe, az Elementor vagy az egyedi sablon? Az Elementor olcsóbb megépíteni és drágább üzemeltetni; az egyedi sablonnál fordítva van. A fordulópont nagyjából ott van, ahol egy webhely túllép 25 oldalon, amelyek kevés, ismétlődő elrendezésből készülnek, amúgy is fizet fejlesztői időt, és teljesítményre vagy akadálymentességre vonatkozó előírást kell teljesítenie, nem csupán megcéloznia. E vonal alatt a szerkesztő általában nyer a teljes költségen. Fölötte az építésen megspórolt összeg két-három év alatt elfogy.

Mit csinál valójában egy oldalszerkesztő a kódjával

Azt állítani, hogy a szerkesztők lassúak, semmit nem ér, mert néha nem azok. Ami állandó, az a mechanizmus, és három részből áll. Mindegyik hajlam, nem bizonyosság, és pontosan ezért nem dönt el semmit a képernyőképekkel vívott párbaj.

A dokumentum mélysége

Egy vizuális szerkesztőnek az elrendezést konténerekként kell ábrázolnia, a konténerek pedig elemek. Egy szekció tartalmaz egy oszlopot, az oszlop tartalmaz egy widgetet, a widget tartalmazza a saját burkolóját, majd a tartalmát. A kézzel írt kód ugyanazt a látványt két vagy három elemben fejezné ki, ahol a szerkesztő hatot vagy hetet ad ki.

Ez a mélység nem ingyenes. A stílus-újraszámítás, az elrendezés és a kirajzolás mind azzal skálázódik, hány csomóponton kell a böngészőnek végigmennie, és milyen összetettek a rájuk illeszkedő szelektorok. A Google DOM-méretről és interaktivitásról szóló útmutatója kijelöli a gyakorlati határokat: a Lighthouse 800 csomópont fölött figyelmeztet, 1 400 fölött pedig túlzottnak minősíti az oldalt. A szerkesztővel készült oldalak rendszeresen átlépik az 1 400-at, egy hosszú oldal több csúszkával és egy megamenüvel pedig elér három-négyezret.

A költséget kétszer fizeti meg. Egyszer az első megjelenítéskor, majd újra minden olyan interakciónál, amely megváltoztatja a fastruktúrát, mert egy harmonika kinyitása vagy egy lista szűrése ugyanarra a munkára küldi vissza a böngészőt.

Oldalanként generált stíluslapok

Az Elementor saját mérnöki írása a CSS-megjelenítés teljesítményéről nyíltan leírja a két kimeneti módot: a CSS vagy egy <style> címkébe kerül a dokumentumban, vagy egy fájlba, amely az oldallal együtt töltődik be. A fájlkimenet statikus, és csak akkor generálódik újra, amikor az oldal megváltozik.

Mindkét módnak van egy könnyen elnézett költsége. A stílus oldalanként generálódik, nem a webhely egészén osztozik rajta, így a látogató, aki a kezdőlapról egy szolgáltatásoldalra lép, friss stíluslapot tölt le ahelyett, hogy egy gyorsítótárazottat használna újra. Belső beágyazásnál a CSS minden kérésnél a HTML-ben utazik, ami felfújja a dokumentumot, és teljesen kiüti a gyorsítótárazást.

A kézzel épített sablon ezt megfordítja. Egy stíluslap, egyszer gyorsítótárazva, mindenhol újrahasználva, és a második oldal, amelyet a látogató megnyit, CSS-ben szinte semmibe nem kerül.

Szkriptek, amelyek az elrendezés megállapodása előtt futnak

A widgetek saját JavaScriptet hoznak magukkal. A csúszkák, fülek, harmonikák, számlálók, felugró ablakok és űrlapok mind saját eseménykezelőket regisztrálnak, és többük csak futásidőben dönti el a végleges méretét. Amikor a tartalom helye csak egy szkript lefutása után derül ki, a böngésző kirajzol egy elrendezést, majd kirajzol egy másikat.

Ez a klasszikus elrendezés-elcsúszási minta, és összeadódik a méret nélküli médiával és a későn betöltődő webes betűtípusokkal. Semmi ebből nem javíthatatlan, de a javítások widgetenként történnek, az oldal minden szerkesztése után újra el kell végezni őket, és aki az oldalt szerkeszti, rendszerint nem az, aki alkalmazta őket.

Core Web Vitals, és hogy melyik mutatót rontja valóban egy szerkesztő

Először a helyes mutatókészletet érdemes tisztázni, mert a szerkesztőkről szóló kommentárok jó része még mindig egy olyan mutatón vitatkozik, amely már nem létezik. Három Core Web Vitals mutató van, és a Google meghatározásai pontosan megadják a jó élmény küszöbeit: a Largest Contentful Paint az oldal betöltésének megkezdésétől számított 2,5 másodpercen belül következzen be, az Interaction to Next Paint legyen 200 ezredmásodperc vagy annál kevesebb, a Cumulative Layout Shift pedig 0,1 vagy annál kevesebb. Mindhármat az oldalbetöltések 75. percentilisén értékelik, mobilra és asztali gépre külön mérve.

A First Input Delay megszűnt. Az Interaction to Next Paint 2024. március 12-én váltotta fel stabil Core Web Vitals mutatóként, és a változás itt azért számít, mert a FID csak az első interakció feldolgozása előtti késleltetést mérte, ami hízelgett a nehéz oldalaknak. Az INP a teljes utat méri a bemenettől a következő kirajzolt képkockáig, az oldal interakcióin át, és a legrosszabbhoz közeli értéket veszi.

Miért az INP az a mutató, amely ellenáll

A Largest Contentful Paint javarészt kiszolgálási kérdés. Jobb tárhely, egy CDN, helyesen méretezett és tömörített képek, előre betöltött főkép, kevesebb megjelenítést blokkoló erőforrás, és a legtöbb szerkesztővel készült webhely 2,5 másodperc alá kerül anélkül, hogy hozzányúlnánk a szerkesztőhöz.

A Cumulative Layout Shift fegyelmi kérdés. Adjon méretet a médiának, tartson helyet mindennek, amit beszúrnak, töltse be úgy a betűtípusokat, hogy ne rendezzék át az oldalt, és a 0,1 elérhető.

Az Interaction to Next Paint szerkezeti kérdés. Azt méri, mennyi munkát kell a fő szálnak elvégeznie, mielőtt válaszolni tud, és a mély kód meg a widgetszkriptek halmaza pontosan ez a munka. Ebből nem lehet kigyorsítótárazni magát, és a gyorsabb kiszolgáló sem segít. Itt tér el leginkább egy Elementor-oldal és egy karcsú egyedi sablon, és ez marad eltérő azután is, hogy a könnyű optimalizálás elkészült. WordPress teljesítményauditról szóló útmutatónk végigveszi, hogyan lehet ezt a három problémát élő webhelyen szétválasztani.

Ami valóban javult

Itt a méltányosság nem udvariasság, hanem pontosság, mert az Elementort érő kritika jó része a 2019-es változatnak szól.

Az Elementor ma 4.2.4-es verzióként érhető el a WordPress bővítménytárában, WordPress 6.8-at vagy újabbat és PHP 7.4-et vagy újabbat igényel, és 10 milliónál több aktív telepítést jelent. A V4 szerkesztő az elemarchitektúrát az köré építette újra, amit az Elementor atomi elemeknek nevez, CSS-központú megközelítéssel és, a cég saját szavaival, „a régi DOM-felfúvódás terhe nélkül”. Az Elementor közlése szerint az Atomic Editor a 4.0-tól kezdve minden új webhelyen az alapértelmezett élmény.

Két megszorítás többet nyom a latban, mint maga a hír. Először is a meglévő webhelyek ezt nem kapják meg frissítéssel. Az Elementor egyértelműen közli, hogy a 4.0-ra frissítés nem érinti a jelenlegi élő webhelyeket, és hogy az új funkciók kézzel kapcsolhatók be, így egy 2022-ben épült webhely megtartja a 2022-es kimenetét, amíg valaki újra nem építi. Másodszor, a migráció alatt a V3 és a V4 elemek ugyanazon az oldalon élnek egymás mellett, vagyis a félig migrált oldal mindkét architektúrát és mindkét többletterhet viszi.

Kezelje a javulást valósként és előremutatóként. Megváltoztatja, hogy milyen lehet egy új Elementor-webhely. Azt nem változtatja meg, hogy a meglévő most milyen.

A bezáródás mechanizmusa, rendesen megfogalmazva

Ez a legerősebb érv a szerkesztő ellen, és szinte mindig rosszul mondják el. A szokásos változat, amely szerint egy képernyőnyi törött rövidkód marad Önnek, nem egészen az, ami történik, és könnyen elhessegethető. A pontos változat rosszabb.

Az Elementor adatszerkezeti dokumentációja pontosan megmondja, hol laknak az oldalai: a szerkesztő az oldal adatait és elrendezését JSON formátumban menti WordPress bejegyzés-metaadatként, a wp_postmeta táblába, és a dokumentáció megjegyzi, hogy ez privát egyéni mezőben tárolódik, amely a WordPress vezérlőpultján nem látszik. Az elrendezése, a stílusa és a szövegeinek nagy része olyan sorosított szerkezetben ül, amelyet csak az Elementor tud olvasni.

Vesse ezt össze a WordPress alaprendszerével. A blokkszerkesztő a blokkokat a post_content mezőbe sorosítja HTML-ként, HTML-megjegyzés-határolókkal, az attribútumokat pedig JSON-literálként viszi a megjegyzésekben. Az alaprendszer kimondott célja egyetlen igazságforrás, amely olvasható marad, és kompatibilis mindennel, ami a WordPress-tartalomhoz hozzáér. Vegye ki a blokkszerkesztőt, és a tartalommezőben továbbra is érvényes HTML marad.

Ennyi az egész különbség. Az egyik rendszer ott tartja a tartalmát, ahol a WordPress mindig is tartotta a tartalmat. A másik egy privát mezőbe teszi mellé.

Mit jelent ez a három év múlva esedékes újratervezésre

Kapcsolja ki az Elementort, és az oldalak nem szelíden esnek vissza. A WordPress a post_content mezőt jeleníti meg, amely egy szerkesztővel készült oldalnál rendszerint üres vagy töredék, így az oldal nem egyszerű lesz, hanem üres. Semmi nem törlődött, de semmi nem is jelenik meg.

Gyakorlatilag ez két projektté alakít egy újratervezést. Nem sablont vált, hanem tartalommigrációt hajt végre: oldalanként kinyeri a megjelenített HTML-t, vagy feldolgozza a JSON-t, majd minden elrendezést újraépít az új rendszerben. Migrációként tervezze be, és kezelhető marad. Az újratervezés közepén fedezze fel, és ez fogja szétverni az ütemtervet. Ugyanaz a fegyelem érvényes, mint bármely CMS-migrációnál, ahol az eredményt eldöntő munka azelőtt zajlik, hogy bármit lekapcsolnának.

Az őszinte érv az Elementor mellett

Van a webhelyeknek egy valódi köre, ahol a szerkesztő nem kompromisszum, hanem a helyes mérnöki döntés, és ez a kör nagy.

Egy tíz-húsz oldalas bemutatkozó webhely. Nincs házon belüli fejlesztő, és nem is akarnak felvenni. Egy marketinges, akinek ma délután kell megváltoztatnia egy címsort, kicserélnie egy fotót vagy közzétennie egy céloldalt, jegy, ág és élesítés nélkül. Olyan büdzsé, amelybe egyedi építés valóban nem fér bele, ahol az alternatíva nem egy jobb webhely, hanem egy rosszabb, vagy semmilyen.

Ennél a profilnál a szerkesztő fejlesztői függőséget vált előfizetésre, és ez rendszerint jó csere. Az a webhely, amelyet a szervezetben senki nem tud frissíteni, rosszabb vagyontárgy, mint egy kicsit nehezebb webhely, amely teljes egészében a marketingcsapaté. Az egyedi útnak nem a lassúság a kudarcmódja, hanem az a webhely, amely elavul, mert minden változtatáshoz külsős kell.

Van egy második őszinte érv is: az első bevételig eltelő idő. Ha egy hiteles webhely három hét alatt kerül élesbe három hónap helyett, annak olyan értéke van, amelyet egyetlen Core Web Vitals szám sem fog meg, és egy induló vállalkozásnál ez az érték gyakran nagyobb mindannál, amiről fentebb szó esett.

Döntési szabály: Elementor vagy egyedi sablon

Íme egy szabály, amelyet a saját webhelyére alkalmazhat, nem egy általánosra. Pontozza ezt a hat szempontot, és hármat vagy többet tekintsen annak a pontnak, ahol a szerkesztő többe kerül, mint amennyit megspórol.

Oldalszám a sablonszámhoz képest. Ha nagyjából 25 oldalnál több készül nyolcnál kevesebb különböző elrendezésből, akkor az ismétlésért fizet. Egy sablon egyszer fejezi ki ezt az ismétlést, egy szerkesztő 25 helyen tartatja karban.

Szerkesztőségi átfutás. Ha hetente néhánynál több tartalmi változtatás történik, és nem egy ember végzi, akkor az eszközök és az ellenőrzési folyamat többet számítanak, mint a szerkesztési élmény.

Egy már meglévő dizájnrendszer. Ha a Figmában valódi tokenkészlet van, egy sablon egyszer kódolhatja és ki is kényszerítheti. Egy szerkesztő semmit nem tud kikényszeríteni, mert minden oldal mindent felülírhat.

Többnyelvű tartalom. Minden nyelv megsokszorozza a karbantartandó szerkesztőstruktúrákat, és a fordítóbővítmények rosszul viselik a post_content mezőn kívül tárolt elrendezést.

Szerződésben rögzített teljesítménykeret. Ha a Core Web Vitals megjelenik egy tenderben, egy SLA-ban vagy egy ügyfélszerződésben, olyan alsó korlát kell, amelyet Ön ural, nem olyan szám, amelyben reménykedik.

Akadálymentességi kötelezettség. Lentebb tárgyaljuk, és önmagában is gyakran eldönti a kérdést.

Ha ezek közül egyik sem igaz, használja a szerkesztőt, és a megtakarítást költse tartalomra. Ha négy vagy több igaz, az egyedi sablon nem luxus, hanem a webhely élettartamára nézve az olcsóbb megoldás.

A középút, amelyet a legtöbb összehasonlítás kihagy

Van egy harmadik lehetőség, és ez sem egyedi sablon, sem külső gyártó szerkesztője. A WordPress alaprendszere az 5.9-es verzió óta, 2022 januárjától szállítja a teljes webhelyszerkesztést, és a Site Editor mára a termék érett része.

A fontos megkötést a Site Editor dokumentációja kereken kimondja: a Site Editor csak akkor érhető el, ha blokksablont telepít és aktivál. Aktív blokksablonnal a szerkesztők megkapják az Identity, Styles, Pages, Navigation, Patterns és Templates felületeket, és a WordPress 6.3 óta innen kezelhetik és szerkeszthetik az oldalakat. A globális stílusok, a tipográfia, a színpaletták és az elrendezés egyszer állnak be a sablon theme.json fájljában, és a teljes webhelyen érvényesülnek.

Ez megoldja a szerkesztő valódi értékének nagy részét. A marketing megváltoztathat egy oldalt, szerkesztheti a fejlécet, átstilizálhatja a webhelyet, és élesítés nélkül közzéteheti. Ráadásul megkapja azt is, amit a szerkesztő nem ad: a tartalmat a post_content mezőben, a fejlesztő által meghatározott dizájnrendszert, semmilyen külső licencet, és a Site Editorban egy exportot, amely a sablont a saját sablonfájljaival és stílusaival együtt zip-be csomagolja.

Amit nem old meg, az a fegyelem. Egy laza theme.json fájlú blokksablon és egy rakás külső blokkbővítmény az alaprendszeren belül reprodukálja a szerkesztő problémáit, a bezáródást is beleértve, mert azok a blokkok a bővítménnyel együtt hagyják el az oldalait. Emellett továbbra is fejlesztő kell a rendes beállításához, egy meglévő Elementor-webhely átköltöztetése pedig továbbra is tartalommigráció.

Akadálymentesség, ahol a szerkesztők csendben elbuknak

Ez az a kudarcmód, amelyet senki nem mutat be bemutatón, és amelyből jogi ügy lesz, nem lassú oldal.

A címsorok sorrendje az elrendezést követi, nem a jelentést. Valaki H3-at választ, mert a H2 túl nagynak tűnt, és a dokumentum szerkezete megszűnik leírni a tartalmat. Ez a WCAG 2.2 1.3.1 Info and Relationships sikerkritériuma A szinten, fölötte pedig a 2.4.6 Headings and Labels AA szinten. A szerkesztőben semmi nem akadályozza meg, mert ott a címsorvezérlő stílusvezérlő.

Az alapértelmezett kontrasztok. Az 1.4.3 Contrast (Minimum) AA szinten legalább 4,5:1 arányt kér a normál szöveghez és 3:1-et a nagy szöveghez, az 1.4.11 Non-text Contrast pedig legalább 3:1-et a kezelőfelületi elemekhez és a grafikus objektumokhoz a szomszédos színekhez képest. A világosszürke szövegtörzs fehéren és a halvány ikonok árnyalt szekción a két leggyakoribb hiba, amelyet szerkesztős webhelyeken találunk, és mindkettő egyenesen egy olyan sablonból jön, amely a bemutatón jól mutatott.

A fókuszsorrend egymásba ágyazott konténerekben. A 2.4.3 Focus Order A szinten megköveteli, hogy a fókuszálható elemek a jelentést és a kezelhetőséget megőrző sorrendben kapják meg a fókuszt, a 2.4.7 Focus Visible pedig AA szinten látható fókuszjelzést kér. A mélyen egymásba ágyazott konténerek, az abszolút pozicionált rétegek és a felugró ablakok mindkettőt rendszeresen elrontják, a szerkesztős sablonok pedig gyakran eltávolítják az alapértelmezett fókuszkeretet, mert rendetlennek tűnt.

Az Egyesült Királyságban ez sok szervezetnek nem választás kérdése. A GOV.UK kifejezetten kimondja, hogy a közszféra szervezeteinek teljesíteniük kell a WCAG 2.2 AA szintet a Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 alapján, és akadálymentességi nyilatkozatot kell közzétenniük. Ez a követelmény egyre inkább átszivárog a magánszektor beszerzéseibe a beszállítói kérdőíveken keresztül. A generált kód utólagos javítása lényegesen nehezebb, mint az Ön által írt kódé.

Mennyibe kerül valójában az egyes utak

A licencsor, amelyet maga is ellenőrizhet

Először a licencárak, mert ez az egyetlen szám ebben a szakaszban, amely nem tőlünk származik. Az Elementor közvetlenül GBP-ben teszi közzé az árakat, így átváltás nincs a képben. Az Elementor árazási oldalán, 2026. szeptember 2-án olvasva, az éves csomagok az Essential 48 GBP-s éves árától az Advanced Solo 72 GBP-s és az Advanced 84 GBP-s árán át az Expert évi 168 GBP-jéig tartanak. Az újabb csomagolt szintek évi 144 GBP az Elementor One és évi 348 GBP a One Agency esetében.

A lenti többi szám az általunk adott sáv, nem közzétett ár, és brit kis- vagy középvállalati webhelyet feltételez, nem webáruházat.

Építés, éves üzemeltetés és a végén az újratervezés

Olvassa ezt prózaként, mert a táblázat csak összefoglal. A szerkesztős webhely háromszoros vagy nagyobb különbséggel a legolcsóbb megépíteni, és a legdrágább üzemeltetni, mert az éves összeg viszi az Elementor-licencet, mellette a prémium kiegészítőket, amelyek szinte mindig vele járnak, mellette a köré növő bővítménykészletet, mellette az időszakos teljesítménymunkát, amely soha nem lesz egészen kész.

Az újratervezési oszlopban dől el az összehasonlítás. Egy szerkesztős webhely újraépítése többe kerül, mint egy sablonosé, a fent kifejtett okból: a tartalmat ki kell nyerni, mielőtt újra lehetne építeni. Öt év alatt egy 4 000 GBP-s szerkesztős webhely és egy 20 000 GBP-s egyedi közelebb kerül egymáshoz, mint bármelyik fél várná, és hogy melyik nyer, az oldalszámon és a szerkesztési gyakoriságon múlik, nem ízlésen. Webhelyköltség-bontásunk bemutatja, hogyan viselkednek ezek a sávok nagyobb projekteknél, webfejlesztési szolgáltatásunk pedig leírja, mit tartalmaz egy egyedi építés.

Ha már szerkesztőn van, és ki akar szállni

A migráció kezelhető, ha jól sorrendezi, és fájdalmas, ha nem.

Kezdje leltárral, ne tervvel. Kérdezze le a bejegyzés-metaadatokat, hogy kiderüljön, mely oldalak hordoznak ténylegesen szerkesztői adatot, mert a legtöbb webhelyen jóval kevesebb, mint várná, a blogbejegyzések pedig rendszerint már egyszerű tartalmak. Utána osztályozzon: újraépítés, átalakítás vagy törlés. A legtöbb webhelyen ott egy hosszú farok olyan oldalakból, amelyeket egy éve senki nem nézett meg, és amelyek migrációjáért senkinek nem kellene fizetnie.

Nyerje ki a tartalmat, mielőtt újraépít. Jelenítse meg és mentse el minden megmaradó oldal HTML-jét, vagy dolgozza fel a metaadatokban lévő JSON-t, hogy a tartalom a bővítménytől független formában legyen meg. Tegye ezt azokkal az oldalakkal is, amelyeket kézzel akar újraépíteni, mert ez az egyetlen másolata, amint a bővítmény eltűnik.

Tartsa meg a webcímeket. Az újraépítés nem ok a címek megváltoztatására, és minden megváltoztatott cím átirányítást kíván a saját pontos megfelelőjére.

Utána oldalanként haladjon, tartsa telepítve az Elementort, amíg az utolsó oldal is le nem került róla, és mérje az Interaction to Next Paint értékét előtte és utána valós terepi adatokon, ne laborpontszámon, mert a laborpontszám egy gyors laptopon azt fogja mondani, hogy a probléma sosem létezett.

Hová vezet mindez

A választás nem világnézeti kérdés. A szerkesztő jogos válasz egy kicsi, lassan változó, fejlesztő nélküli webhelyre, és sokkal gyakrabban a helyes válasz, mint ahogy azt a fejlesztők bevallani szeretik. Akkor szűnik meg helyes válasz lenni, amikor belép a képbe az oldalszám, a sablonok újrahasznosítása, a szerkesztőségi átfutás vagy egy kemény teljesítmény- vagy akadálymentességi követelmény, és az ezen a ponton túli maradás ára csendben fizetődik: éves licencekben, javításokban, végül egy migrációban.

A Mecanik mindkettőt építi. Ott üzemeltetünk szerkesztős webhelyeket, ahol ez az értelmes gazdaságosság, és lecseréljük őket, amikor ez megszűnik, rendszerint az alaprendszerre épülő blokksablonra, nem teljesen egyedi építésre. Ha egyenes választ szeretne arra, hogy a webhelye a vonal melyik oldalán áll, webfejlesztési és WordPress-fejlesztési oldalaink leírják, hogyan mérjük fel, a WordPress-fejlesztő felvételekor felteendő kérdésekről szóló útmutató pedig azt, hogyan tegye próbára azt, akivel beszél, minket is beleértve.

Gyakran ismételt kérdések

Rossz az Elementor a SEO szempontjából? Nem. Az Elementor nem gátolja az indexelést, és egy jól megépített Elementor-oldal ugyanúgy rangsorol, mint bármelyik másik. A keresésre gyakorolt nyomás közvetett, és a Core Web Vitals mutatókon csapódik le, főleg az Interaction to Next Paint értékén, mert a mély generált kód és a widgetszkriptek több munkát adnak a fő szálnak. A mutatók csak az egyik tényezőt jelentik a sok közül, így egy lassú, de jobb tartalmú szerkesztős oldal továbbra is megveri a gyors, de gyengébb tartalmú oldalt.

Mi történik az oldalaimmal, ha kikapcsolom az Elementort? Az elrendezés eltűnik. Az Elementor az oldal szerkezetét JSON formában, a wp_postmeta tábla egy privát egyéni mezőjében tartja, nem a post_content mezőben, így a bővítmény kikapcsolása után a WordPress csak azt jeleníti meg, ami a post_content mezőben van, ez pedig egy szerkesztős oldalnál rendszerint üres vagy töredék. Semmi nem törlődik, de semmi nem is jelenik meg, az oldalak visszaszerzése pedig adatmigráció, nem sablonváltás.

Mennyibe kerül egy egyedi WordPress sablon az Egyesült Királyságban? Az általunk adott sávok nagyjából 12 000 és 40 000 GBP között vannak egyedi sablonra, 6 000 és 18 000 GBP között a WordPress alaprendszerére épített blokksablonra, és 2 000 és 6 000 GBP között egy szerkesztős webhelyre. Az egyedi szám az első napon néz ki a legrosszabbul és öt évre nézve a legjobban, mert nincs benne licenc, kisebb a bővítménykészlete, és a végén sokkal olcsóbb az újratervezés.

Meg tud felelni egy Elementor-webhely a Core Web Vitals mutatóknak? Igen, és sok meg is felel. A 2,5 másodperc alatti Largest Contentful Paint és a 0,1 alatti Cumulative Layout Shift jó tárhellyel, méretezett médiával és a widgetek mértéktartó használatával általában elérhető. A 200 ezredmásodperc alatti Interaction to Next Paint az, amelyik ellenáll, mert a fő szál munkáját tükrözi, nem a kiszolgálást, és ez az a mutató, ahol a szerkesztős kód és a widgetszkriptek a legtöbbe kerülnek.

Jobb alternatíva a blokksablon az Elementornál? Gyakran igen, és ez az a lehetőség, amelyet a legtöbb összehasonlítás kihagy. A blokktartalom a post_content mezőben HTML-ként, megjegyzés-határolókkal tárolódik, ezért túléli a sablonváltást, a Site Editor pedig lehetővé teszi a marketingnek, hogy élesítés nélkül szerkesszen sablonokat és stílusokat. Nem munka nélküli: a Site Editorhoz blokksablon kell, és valakinek rendesen meg kell határoznia a dizájnrendszert, különben ugyanazt a problémát építette újra az alaprendszeren belül.