U ovom članku ćemo pisati o page builderima za WordPress – ponukani činjenicom da oni omogućavaju brzu, a time i jeftinu izradu web stranica. Prije nekoliko godina bismo na ovo možda i gledali afirmativno, ali vremena su se promijenila, tehnologije postale kompleksnije, i brza izrada weba jednostavno više ne može biti prednost. U nastavku ćemo objasniti zašto.
Dakle, brza izrada weba moguća je uz korištenje gotovih rješenja, među njima su page builderi za WordPress vjerojatno najpopularniji. Najpoznatiji page builderi za WordPress su Divi i Elementor, ali sve zvučnije ime je i Gutenberg – koji je u ovoj grupi ponajprije inercijom (stoga što dolazi kao core funkcionalnost WordPress-a, dakle razvija ga isti tim kao i WordPress). Gutenberg ovdje želimo isticati kao rješenje koje nadmašuje sve page buildere na tržištu u pogledu brzine rada, stabilnosti, te količine bugova (logično je da ih ima najmanje zbog programerske zajednice koja sudjeluje u njegovom razvoju, baš kao i WordPress), a u nastavku članka ćemo objasniti zašto se on i ne može smatrati klasičnim page builderom – barem u pogledu toga da na jednostavan i brz način omogućava izradu weba.
No, ovisno koga pitate, i u kakvom su sukobu interesa, mogli biste čuti dijametralno suprotne odgovore na pitanje koji je page builder najbolji za korištenje. Mi ćemo vam reći – nijedan, i dokazati u nastavku svoju tezu, ali ako već želite koristiti neki od njih, objasnit ćemo i zašto je Gutenberg najbolji izbor.
Mogućnosti Divi i Elementora premašuju mogućnosti Gutenberga?
Da i ne. Ovisi o tome koga pitate, te na što mislite pod “mogućnostima”. U samom startu, out-of-the-box, Divi i Elementor naizgled djeluju kao “zemlja čudesa”, sa brojnim modulima za izgradnju najrazličitijih vrsta sadržaja, nevjerojatno atraktivnog dizajna (ne samo za front-end, već i back end), s animacijama za svaku interakciju (ne samo za posjetitelja, već i administratora dok uređuje sadržaj).
No, ovdje ćemo sada postaviti jednu tezu koju ćemo kasnije do kraja elaborirati. Sada ćemo ju iznijeti, jer će se oko nje vrtiti ostatak ovog članka. Sljedeće što ćemo iznijeti je neoboriva istina, ma što tko mislio o tome.
Nitko ozbiljan neće razvijati web stranicu s Elementorom i Divi-em
Pa odmah da malo elaboriramo, zašto nitko ozbiljan ne bi razvijao web stranicu s Elementorom i Divi-em?
Zato što sve te funkcionalnosti, sva ta atraktivnost, animacije, poskakivanje, cupkanje i igranje elemenata dizajna (kako s prednje, tako i sa stražnje strane weba) dolazi uz dva ogromna nedostatka. A ta dva nedostatka su ono što razlikuje ozbiljnu web stranicu od neozbiljne. Ta dva nedostatka su:
- Performanse – u nastavku ćemo se još baviti ovom temom detaljnije, ali recimo za sada da oba ova page buildera za sobom vuku ogromne količine datoteka, skripti, stilova, grafika. Što više funkcionalnosti, to je potrebno više resursa. A što je potrebno više resursa, manje u realnom svijetu dobivamo brzine.
- Stabilnost – puka količina programskog koda koju vaš web pogoni ekvivalentna je igranju ruskog ruleta s vlastitom web stranicom – niti u jednom trenutku niste sigurni koja linija će izazvati kratki spoj, ali po zakonu velikih brojeva, stvari će u jednom trenutku krenuti nizbrdo. Zašto? Zato što bilo tko koga biste eventualno zaposlili ili angažirali da vam održava web stranicu, ne može učinkovito apsolvirati svu tu količinu programskog koda i imati ju zaista pod kontrolom. Zapamtite – page builderi su poput ljudi koji se žele svidjeti svima – na prvi pogled djeluju privlačno, ali kada zagrebete ispod površine, ili još gore, kada se trebate na njih osloniti, vrlo brzo pronalazite ozbiljne nedostatke.
Performanse
Opet, ovisi koga pitate, Divi i Elementor mogu raditi brzo (na front-endu, u back endu, kod uređivanja sadržaja, rade očajno, i iza toga stojimo, jer optimizacija u backend nije moguća). No, da bi Divi i Elementor radili brzo na front endu, potrebno je temeljito optimizirati fotografije, očistiti, komprimirati i spojiti javascript i css datoteke, očistiti html kod, smanjiti broj HTTP zahtjeva, konfigurirati lazy load, asinhrono (ili deferred – odgođeno) učitavati JS i CSS datoteke, te optimizirati server, konfigurirati caching, i sl. No, za to već treba developersko znanje, to se ne može postići samo aktivacijom nekog plugina. Zapravo, da začinimo stvar s malo ironije – baš korištenje Divi i Elementora, pluginova koji su namijenjeni laicima, te ciljaju na jednostavno korištenje, onemogućava jednostavnu optimizaciju brzine rada web stranice. Zapravo, što kompleksniji page builder, više je potrebno developerskog znanja za brz i stabilan rad web stranice.
Gotovo u pravilu, tvrtke (pojedinci) koji “razvijaju” web stranice Divi-em ili Elementorom, zanemaruju konačni korak – optimizacija brzine i stabilnosti web stranice, jer, iako su web stranice izrađene page builderima u startu spore, one mogu raditi brže, no na to se često ne pazi. Najčešće, to se događa iz tri razloga:
- cijeli budžet projekta (s obzirom da se radi o web stranicama niske vrijednosti) potrošen je na kreiranje web stranice, te nije ostalo vremena / resursa za dodatne potrebne korake,
- razina tehničkog poznavanja problematike je preniska,
- klijent brzinu rada i stabilnost ne percipira kao dovoljno važan faktor u životnom ciklusu web stranice.
Stabilnost
Divi sadrži cca 1000 datoteka. Elementor cca 800. No, ovdje govorimo o “golim” builderima, koji se često proširuju dodatnim pluginovima za različite vrste sadržaja. Iz našeg iskustva, rijetko stvari ostanu na instalaciji samog buildera – često se dodaju i po nekoliko proširenja, što znači da pojedinačni builder u realnom scenariju može sadržavati i do nekoliko tisuća datoteka, a većim dijelom se tu radi o PHP, javascript i CSS datotekama koje se najčešće sve “odjednom” učitavaju u trenutku uređivanja sadržaja.
Mogućnost konflikta između javascript datoteka
Potencijal za konflikt je ogroman, posebno zato što i Divi i Elementor koriste skripte nekih drugih developera. Npr., možda ste prilikom korištenja Divi-a primijetili da je skrolanje web stranicom nekako elegantnije od klasičnog. To je zato što Divi koristi smoothscroll.js skriptu nekog trećeg programera. Hoće li taj programer ažurirati tu skriptu ako dođe do konflikta s nekim komadom javascript koda, i hoće li Divi to ažuriranje ugraditi u svoj plugin, to nitko ne zna. A svaki potencijalni javascript problem odražava se direktno na mogućnost uređivanja sadržaja, jer npr. Divi (i Elementor) gotovo u potpunosti funkcionira u asinhronom modu rada (AJAX), pa svaka javascript greška može značiti nemogućnost pozadinske komunikacije sa serverom, te nemogućnost spremanja promjena prilikom ažuriranja. Ova paradigma primijenjiva je na mnoge funkcionalnosti page buildera, pa vam je možda sada jasnije odakle ona ranija analogija sa ruskim ruletom.
I da, Gutenberg bi mogao patiti od iste problematike – ali ne pati. Zašto? Zato što je, kao što smo rekli, od početka projektiran za brzinu, modularnost, stabilnost, rasterećen nepotrebnih modula, ugrađen je u jezgru WordPress-a, te je kao takav najkompatibilniji mogući page builder za WordPress.
Stvar o kojoj nitko ne priča
Jedan od aspekata o kojem se rijetko priča jest sporost rada page buildera upravo kod onog za što su i zamišljeni – uređivanja sadržaja. A tu je situacija u pravilu očajna. Prosječan shared hosting (kakvog koristi većina ljudi koji koriste page buildere) može se gotovo srušiti tijekom rutinskog uređivanja sadržaja.
Evo jedan stvarni primjer – jedan od klijenata koji nam je došao s potrebom za “krpanjem” stranice koja je rađena u Divi-u. U nastavku analiziramo brzinu rada front end uređivača (dakle, vizualnog real-time Divi uređivača kakvog koristi većina ljubitelja Divi-a).
Ako pogledate samo tri brojke na fotki iznad, shvatiti ćete sve boljke ovakvih page buildera.
- Preko 3000 http zahtjeva,
- učitano gotovo 200MB resursa,
- vrijeme učitavanja preko 1 minute.
OK, tih minuta i pol nisu minuta i pol čekanja (barem ne u potpunosti), 3000 zahtjeva nije odjednom (iako, s obzirom na količinu i u kojem su se periodu odvili, možemo pretpostaviti da je udar na resurse servera velik), inicijalni sadržaj (inicijalni HMTL) je učitan za cca 7s, MB se (djelomično) odnosi na sadržaj weba, no tzv. preview, u kojem Divi “povlači” hrpu resursa naknadno, asinhrono (radi se o fotkama, posebnim sadržajnim modulima, skriptama i sl.), je trajao 1.6 minuta, i u tih 1.6 minuta poslao preko 3000 zahtjeva na server! Sve skupa je ogromno opterećenje za server, i ono je trajalo gotovo dvije minute. I još jedna napomena – kompletne statistike odnose se na browser koji je u mirovanju. Dakle, nismo skrolanjem po stranici “isprovocirali” lazy load ili naknadno učitavanje skripti, stilova ili fotki – sve se odvilo na jedan refresh stranice. Da smo skrolali, rezultat bi bio puno tragičniji.
Srećom, hosting na kojem se web nalazi posjeduje “Resource usage” alat cPanela, pa i s te strane možemo pratiti udar na resurse servera:
Na fotki iznad možete vidjeti nekoliko stvari:
- Samo jedno učitavanje Divi-a “zakucalo” je hosting paket u blokadu po gotovo svim parametrima – od procesora, memorije, I/O (input/output) pa do broja dopuštenih istovremenih procesa.
- Tirkizne linije označavaju greške – u tom trenutku je izgubljena veza sa serverom. Moglo je doći do grešaka prilikom čitanja / pisanja u bazu podataka, te do greške prilikom obrade podataka (rezultata kompajliranja samog PHP koda)
- U tom trenutku, tih par minuta, od resursa hosting paketa nije ostalo gotovo ništa za posjetitelje web stranice. Ako se netko s vanjske strane našao usred dodavanja proizvoda u košaricu, slanja narudžbe, i sl., dobre su šanse da se načekao/la, a možda čak i odustao/la od narudžbe. Postoji čak i šansa da je izgubljen kontakt s web stranicom, da proizvod nikad nije ni dodan u košaricu, ili da posjetitelj misli da je poslao/la narudžbu, koja nikad nije došla!
A koliko se grešaka zapravo i generiralo, može se vidjeti i u konzoli Google Chrome-a:
S obzirom da Divi većinu resursa učitava putem Ajax-a, greške možemo pratiti u javascript konzoli Google Chrome-a. I imamo što i vidjeti – na fotki iznad možete vidjeti tri statusa greške – 404, 500 i 503. Greška 404 upućuje na resurs koji nije dohvaćen (iz više razloga, bilo da ga nema (iako znamo da ga ima jer je kasnije učitan), bilo da je privremeno ili trajno nedostupan). Greška 500 upućuje na neispravan programski kod, u ovom slučaju uslijed pogrešne komunikacije sa serverom. Greška 503 označava trenutak kad je naš hosting paket napokon odustao – to je statusna greška koja najčešće označava da je komunikacija sa serverom nemoguća, te da server više nije u mogućnosti obrađivati zahtjeve.
Stvarni primjer brzine rada Gutenberga
Za usporedbu, naš web codeart.studio, čija je naslovnica rađena u Gutenbergu, te nije jednostavna (posjeduje solidnu količinu sadržaja), ima sljedeće statistike prilikom učitavanja Gutenberga uređivača u back end-u:
- 282 http zahtjeva (deset puta manje nego Divi),
- 22.7 MB učitanih resursa (za naslovnicu koja je sve samo ne “lagana”),
- učitavanje dovršeno za 5.44 s, 16 puta brže od Divi.
Brojke jednostavno nisu usporedive. OK, sve skupa nije laboratorijski eksperiment sa strogo definiranim pravilima, ali jest primjer iz stvarnog svijeta, i to je ono što nas i zanima.
Dakle, da sumiramo – Divi i Elementor (koji pate od sličnih boljki) imaju dva ozbiljna problema – performanse, i stabilnost. Ta dva ozbiljna problema, čine ih neozbiljnim rješenjem za razvoj web stranice / web shopa.
A hoće li itko ozbiljan razvijati web stranicu s Gutenbergom?
Da i ne. Opet, ovisi koga pitate. Page builder svakako nije potreban za izgradnju web stranice (ili web shopa). Zapravo, ozbiljne web stranice ga često nemaju.
Ali ovo je članak s razlogom pisan o page builderima. Dakle, u startu, Gutenberg je moderan, rekli bi, “cutting-edge” page builder baziran na React-u, koji je od svog začetka fokusiran na brzinu rada, jednostavnost upotrebe, te modularnost. U tom smislu, graditi web stranicu na Gutenbergu kao takvom nije moguće out of the box.
No, modularnost Gutenberga čini ga odličnim izborom za developere koji znaju kako proširivati njegove mogućnosti kako bi svojim klijentima izgradili web po mjeri, ali im opet omogućili samostalno održavanje sadržaja. I u tom smislu, Gutenberg ne samo da nema ograničenja, već su mu mogućnosti daleko iznad Divi-a i Elementora, pa i bilo kojeg drugog page buildera na tržištu.
I za kraj – da, Divi i Elementor jesu “flashy” u odnosu na monokromatski crno-bijeli Gutenberg. No, citirat ćemo čovjeka u crnom, Johnny Casha:
“Well, you wonder why I always dress in black
Why you never see bright colors on my back
And why does my appearance seem to have a somber tone
Well, there’s a reason for the things that I have on”
Bitno je ono što je ispod površine 😉
I da zaključimo:
Ako je vaš budžet za izradu web stranice / trgovine tek nekoliko tisuća kuna, na tržištu će se sigurno naći netko tko će vam web izraditi za te novce. Kakav će konačan rezultat biti, vidjet ćete i sami. Ako vam je web stranica važna dugoročno, u smislu da tražite stabilno i brzo rješenje koje će biti kompatibilno s tehnologijama koje dolaze u narednim godinama, projekt izrade web stranice mora biti veći od 15.000 kn – jer razvoj web stranice bez page buildera trajat će nekoliko tjedana (a u nekom slučaju i nekoliko mjeseci).
