Zašto je sajt napravljen builderom spor i šta se tu zaista može
Šta page builder zaista šalje browseru, zašto plugin za keširanje to ne popravlja i koji koraci stvarno pomažu bez prepravke sajta.
Marko Stančić9 minuta
Beleška s terena / Performanse
Sajt napravljen page builderom je spor zato što svaka sekcija stiže u browser kao niz ugnežđenih div elemenata, uz generisani CSS po elementu, globalni stylesheet, icon font i jQuery koji se učitavaju na svakoj stranici bez obzira na to šta je na njoj. Plugin za keširanje to ne popravlja, jer keširanje skida vreme koje troši PHP, a ne skida bajtove, zahteve ni posao koji browser mora da odradi na glavnoj niti.
Ovo nije tekst protiv Elementora. I sam sam isporučio sajtove na builderu, i deo posla u mom indeksu je upravo to: šablon implementiran kako treba, u roku i u budžetu u kojem razvoj po meri nije bio opcija. Ali kada klijent posle trećeg plugina za optimizaciju pita zašto je sajt i dalje spor na telefonu, odgovor je uvek na istom mestu: u onome što builder mora da ispiše da bi uopšte radio.
Šta builder zapravo dodaje stranici
Builder je dve stvari odjednom. Editor koji vidite vi i runtime koji dobija posetilac. Editor je razlog zbog kojeg ste ga izabrali. Runtime je razlog zbog kojeg je sajt spor.
Prvo, struktura. Da bi se svaki element mogao pomerati, poravnavati i posebno podešavati po breakpointu, builder oko njega mora da postavi omotače. Jedan naslov u sekciji nije jedan tag, nego lanac omotača, i tek na kraju tog lanca stoji ono što je stvarno sadržaj stranice.
// Jedan naslov, onako kako ga builder isporuči
<div class="elementor-section elementor-top-section">
<div class="elementor-container">
<div class="elementor-column elementor-col-100">
<div class="elementor-widget-wrap">
<div class="elementor-widget elementor-widget-heading">
<div class="elementor-widget-container">
<h2 class="elementor-heading-title">Naše usluge</h2>
// Isti naslov, napisan rukom
<h2>Naše usluge</h2>
Pomnožite to brojem elemenata na dužoj početnoj stranici i dobijate DOM koji se meri hiljadama čvorova umesto stotinama. Svaki čvor je posao: parsiranje, računanje stilova, svaki prolaz layouta, svako ponovno crtanje.
Drugo, CSS. Builder unapred ne zna koji ste razmak, boju ili senku podesili, pa svako vaše podešavanje postaje pravilo vezano za ID tog konkretnog elementa, sa zasebnim varijantama za tablet i telefon. Ta pravila se snimaju u generisani fajl po stranici, uz globalni stylesheet koji nosi stilove svih widgeta koje ste možda upotrebili.
Treće, zavisnosti koje idu svuda. Frontend skripta buildera se oslanja na jQuery, pa jQuery i jquery-migrate ulaze u svaku stranicu, uključujući i onu na kojoj nema nijednog interaktivnog elementa. Uz njih ide icon font sa stotinama glifova zato što ste upotrebili tri ikonice, i biblioteka za slidere zato što jedna sekcija negde na sajtu ima galeriju.
Novije verzije imaju opcije koje ovo stvarno smanjuju: učitavanje resursa samo za widgete koji su na stranici, flex kontejnere umesto starog modela sa sekcijama i kolonama, tanji HTML izlaz. Vredi ih uključiti i na njih se vraćam niže. Ali osnovni runtime ostaje, jer bez njega stranica ne izgleda kako je nacrtana.
Tu je i deo koji je najteže objasniti: višak se ne može samo obrisati. Raspored visi o toj strukturi. Uklonite jedan omotač i sekcija se raspada. Uklonite globalni stylesheet i widgeti ostaju bez nasleđenih stilova. Izlaz nije skup delova koje birate, nego jedan paket koji se uzima ceo.
Zašto plugin za keširanje ne rešava taj problem
Keširanje stranica radi tačno jednu stvar, i radi je dobro. Prva poseta prođe kroz PHP i bazu, rezultat se snimi kao gotov HTML, a svaki sledeći posetilac dobije taj fajl. Vreme do prvog bajta padne, server prestane da se muči pod saobraćajem, i to je stvarna dobit.
Ono što keširanje ne dira je sve posle toga. Broj zahteva je isti. Broj bajtova je isti. CSS koji browser mora da parsira je isti, JavaScript koji mora da izvrši je isti, DOM koji mora da izračuna je isti. Origin je postao brži, a browser ima tačno onoliko posla koliko je imao i pre.
Radni princip
Keširanje menja ko obavlja posao, ne koliko ga ima. Sve što posetilac čeka posle prvog bajta ostaje nepromenjeno.
Ozbiljniji optimizacioni plugini rade i više od keširanja: odlažu JavaScript do prve interakcije, uklanjaju CSS koji stranica ne koristi, ubacuju kritični CSS u zaglavlje dokumenta. To zaista pomaže. Samo treba znati šta se za to plaća.
Uklanjanje neiskorišćenog CSS-a je heuristika. Alat gleda šta je na stranici u trenutku analize, pa se prvo polome stvari koje se pojavljuju uslovno: popup, sadržaj drugog taba, mobilni meni, poruka u korpi. Odlaganje JavaScript-a ne uklanja posao nego ga pomera na prvi dodir posetioca, pa laboratorijski rezultat poraste, a odziv na prvi klik ostane isti ili se pogorša. Oba alata su korisna, ali oba rade na simptomu, ne na uzroku.
Kako se to oseti kroz LCP, CLS i INP
Tri metrike Core Web Vitals mere tri različite vrste bola, i izlaz buildera svaku dodiruje na svoj način. Standardni pragovi za ocenu „dobro” su 2,5 sekunde za LCP, 0,1 za CLS i 200 milisekundi za INP.
LCP najčešće pati zbog glavne slike. U builderu je hero često pozadinska slika podešena na ugnežđenom div elementu, što znači da je zapisana u CSS-u, a ne u HTML-u. Preload skener je ne vidi dok ne parsira stil, ne može joj dati prioritet kao pravoj slici, a nije retko ni da je uz to uključen lazy loading. Najvažnija slika na stranici tako kreće poslednja.
CLS dolazi iz kasnih dolazaka. Web font koji zameni sistemski i pomeri ceo blok teksta. Icon font koji stigne posle prvog crtanja. Ulazne animacije koje pomeraju sekcije dok se skroluje. Slider koji dobije visinu tek kada se inicijalizuje i gurne sve ispod sebe naniže.
INP je najiskreniji od sve tri, jer meri koliko posetilac čeka na odgovor kada nešto stvarno klikne. Glavna nit u tom trenutku izvršava jQuery, runtime buildera i skripte svih widgeta koji su na stranici. Otvaranje menija, prelazak na drugi tab ili slanje forme staju u red iza tog posla.
Važno je i gde merite. Na laptopu s brzom vezom stranica na builderu ume da izgleda sasvim u redu. Na srednjem Android telefonu ista stranica pokaže sve tri odjednom, a upravo taj telefon većina vaših kupaca drži u ruci.
Kada je builder ispravan izbor, a kada prestane da bude
Builder je dobar odgovor češće nego što developeri vole da priznaju. Ako klijent menja sadržaj svake nedelje i ne želi da zbog nove sekcije nekoga zove, ako je raspored običan (hero, tri kolone, poziv na akciju, forma), ako je sajt prezentacija firme, a ne kanal kroz koji ide prihod, i ako budžet ne pokriva namenske šablone, onda je uredno implementiran sajt na builderu bolji ishod od projekta po meri koji nikada nije završen.
Prestaje da bude dobar odgovor u nekoliko prepoznatljivih trenutaka. Kada sajt postane glavni prodajni kanal, pa svaka sekunda učitavanja ima cenu koja se vidi. Kada sadržaj prestane da staje u šablon, pa se svaka nova stranica sklapa ručno umesto da izlazi iz strukture. Kada broj plugina koji krpe builder nadmaši broj plugina koji nose stvarne funkcije. I kada jedna izmena dizajna traži da neko prođe kroz sve stranice i ponovi je na svakoj.
Taj poslednji prag je zapravo pitanje modela sadržaja, a ne performansi. Na platformi za Innovation Properties Group postoje četiri odvojene strukture sadržaja, pretraga nekretnina koja se filtrira kroz URL i kalkulator poslovnog prostora ugrađen u sajt. Takav sistem se ne sklapa iz sekcija, nego se modeluje, i tu builder više nije alat za taj posao.
Šta se realno može bez prepravke, po redosledu isplativosti
Ako prepravka nije na stolu, a najčešće nije, ovo je redosled po kojem se posao isplati. Radite jednu stavku, izmerite istu stranicu, pa prelazite na sledeću.
Slike, pre svega ostalog. Nađite LCP kandidata i proverite da na njemu nije uključen lazy loading, da je u savremenom formatu, da mu je dimenzija bliska onoj u kojoj se prikazuje i da ga browser vidi u HTML-u. Ako widget dozvoljava pravu sliku umesto pozadinske, uzmite pravu sliku.
Fontovi. Svaka težina i svaki stil su poseban fajl. Svedite ih na ono što se stvarno koristi, servirajte ih sa svog domena i podesite ponašanje pri učitavanju. Ako na sajtu ima šest ikonica, cela biblioteka glifova može da ode i da je zameni inline SVG.
Opcije samog buildera. Uslovno učitavanje resursa po widgetu, tanji HTML izlaz, keširanje elemenata u plaćenoj verziji. Uključujte ih jednu po jednu i pregledajte sajt posle svake, jer na starijim stranicama umeju da promene raspored.
Skripte trećih strana. Chat, pikseli, heatmap alati, ugrađeni widgeti. Ovo je često najveći pojedinačni dobitak na glavnoj niti, nema nikakve veze s builderom i rešava se bez rizika po raspored.
Revizija plugina. Dva slidera, dva plugina za forme, popup koji niko ne koristi, galerija iz prošlog redizajna. Svaki od njih ubacuje svoj CSS i JS na svaku stranicu. Brisanje funkcije je uvek brže od minifikovanja njenog koda.
Keš, CDN i pristojan hosting. Ovde ide keširanje, sada kada znate šta od njega očekujete: niži TTFB i stabilan server pod saobraćajem, a ne popravku onoga što se dešava u browseru.
Sama stranica. Predugačka početna je istovremeno sadržajni i tehnički problem. Ono do čega niko ne doskroluje ne mora ni da postoji.
Najbrža optimizacija je obrisati ono što je već na stranici, a ne dodati još jedan plugin koji to skriva.
Gde je plafon i kada se prepravka isplati
Sve nabrojano ima kraj. Struktura omotača, generisani CSS i runtime buildera su pod ispod kojeg se ne stiže bez uklanjanja buildera. Na desktopu i uz dobar hosting uredno očišćena stranica na builderu ume da dobije ocenu „dobro”. Na srednjem telefonu se plafon vidi, i tada je pošteno reći klijentu da smo stigli dokle se ovim putem stiže.
Kada je taj plafon zaista prenizak, izlaz ne mora da bude sve ili ništa. Na skoro svakom sajtu dva ili tri šablona nose većinu saobraćaja: početna, neka lista i stranica usluge ili proizvoda. Njih vredi napisati nativno, kroz izradu WordPress sajta po meri, a ostatak sadržaja mirno ostaje na builderu dok mu ne dođe vreme. Migracija u koracima je jeftinija i manje rizična od velikog redizajna, a dobitak stiže tamo gde se meri.
Sajt na builderu može da bude dovoljno brz. Greška nije u tome što je izabran, nego u očekivanju da isporuči isto što i ručno pisan šablon, i u trošenju budžeta na plugine koji to obećavaju.
Papiri, obavezne stranice prodavnice i detalji naplate koje domaća WooCommerce prodavnica mora da ima pre nego što kartično plaćanje bude odobreno i pušteno u rad.
8 min čitanja
Primena u praksi
Ispitajmo stvarno ograničenje
Ako performanse, arhitektura ili održivost usporavaju proizvod, donesite dokaze. Možemo definisati šta prvo treba da se promeni.
Beleška s terena / Performanse
Sajt napravljen page builderom je spor zato što svaka sekcija stiže u browser kao niz ugnežđenih div elemenata, uz generisani CSS po elementu, globalni stylesheet, icon font i jQuery koji se učitavaju na svakoj stranici bez obzira na to šta je na njoj. Plugin za keširanje to ne popravlja, jer keširanje skida vreme koje troši PHP, a ne skida bajtove, zahteve ni posao koji browser mora da odradi na glavnoj niti.
Ovo nije tekst protiv Elementora. I sam sam isporučio sajtove na builderu, i deo posla u mom indeksu je upravo to: šablon implementiran kako treba, u roku i u budžetu u kojem razvoj po meri nije bio opcija. Ali kada klijent posle trećeg plugina za optimizaciju pita zašto je sajt i dalje spor na telefonu, odgovor je uvek na istom mestu: u onome što builder mora da ispiše da bi uopšte radio.
Šta builder zapravo dodaje stranici
Builder je dve stvari odjednom. Editor koji vidite vi i runtime koji dobija posetilac. Editor je razlog zbog kojeg ste ga izabrali. Runtime je razlog zbog kojeg je sajt spor.
Prvo, struktura. Da bi se svaki element mogao pomerati, poravnavati i posebno podešavati po breakpointu, builder oko njega mora da postavi omotače. Jedan naslov u sekciji nije jedan tag, nego lanac omotača, i tek na kraju tog lanca stoji ono što je stvarno sadržaj stranice.
Pomnožite to brojem elemenata na dužoj početnoj stranici i dobijate DOM koji se meri hiljadama čvorova umesto stotinama. Svaki čvor je posao: parsiranje, računanje stilova, svaki prolaz layouta, svako ponovno crtanje.
Drugo, CSS. Builder unapred ne zna koji ste razmak, boju ili senku podesili, pa svako vaše podešavanje postaje pravilo vezano za ID tog konkretnog elementa, sa zasebnim varijantama za tablet i telefon. Ta pravila se snimaju u generisani fajl po stranici, uz globalni stylesheet koji nosi stilove svih widgeta koje ste možda upotrebili.
Treće, zavisnosti koje idu svuda. Frontend skripta buildera se oslanja na jQuery, pa jQuery i jquery-migrate ulaze u svaku stranicu, uključujući i onu na kojoj nema nijednog interaktivnog elementa. Uz njih ide icon font sa stotinama glifova zato što ste upotrebili tri ikonice, i biblioteka za slidere zato što jedna sekcija negde na sajtu ima galeriju.
Novije verzije imaju opcije koje ovo stvarno smanjuju: učitavanje resursa samo za widgete koji su na stranici, flex kontejnere umesto starog modela sa sekcijama i kolonama, tanji HTML izlaz. Vredi ih uključiti i na njih se vraćam niže. Ali osnovni runtime ostaje, jer bez njega stranica ne izgleda kako je nacrtana.
Tu je i deo koji je najteže objasniti: višak se ne može samo obrisati. Raspored visi o toj strukturi. Uklonite jedan omotač i sekcija se raspada. Uklonite globalni stylesheet i widgeti ostaju bez nasleđenih stilova. Izlaz nije skup delova koje birate, nego jedan paket koji se uzima ceo.
Zašto plugin za keširanje ne rešava taj problem
Keširanje stranica radi tačno jednu stvar, i radi je dobro. Prva poseta prođe kroz PHP i bazu, rezultat se snimi kao gotov HTML, a svaki sledeći posetilac dobije taj fajl. Vreme do prvog bajta padne, server prestane da se muči pod saobraćajem, i to je stvarna dobit.
Ono što keširanje ne dira je sve posle toga. Broj zahteva je isti. Broj bajtova je isti. CSS koji browser mora da parsira je isti, JavaScript koji mora da izvrši je isti, DOM koji mora da izračuna je isti. Origin je postao brži, a browser ima tačno onoliko posla koliko je imao i pre.
Keširanje menja ko obavlja posao, ne koliko ga ima. Sve što posetilac čeka posle prvog bajta ostaje nepromenjeno.
Ozbiljniji optimizacioni plugini rade i više od keširanja: odlažu JavaScript do prve interakcije, uklanjaju CSS koji stranica ne koristi, ubacuju kritični CSS u zaglavlje dokumenta. To zaista pomaže. Samo treba znati šta se za to plaća.
Uklanjanje neiskorišćenog CSS-a je heuristika. Alat gleda šta je na stranici u trenutku analize, pa se prvo polome stvari koje se pojavljuju uslovno: popup, sadržaj drugog taba, mobilni meni, poruka u korpi. Odlaganje JavaScript-a ne uklanja posao nego ga pomera na prvi dodir posetioca, pa laboratorijski rezultat poraste, a odziv na prvi klik ostane isti ili se pogorša. Oba alata su korisna, ali oba rade na simptomu, ne na uzroku.
Kako se to oseti kroz LCP, CLS i INP
Tri metrike Core Web Vitals mere tri različite vrste bola, i izlaz buildera svaku dodiruje na svoj način. Standardni pragovi za ocenu „dobro” su 2,5 sekunde za LCP, 0,1 za CLS i 200 milisekundi za INP.
LCP najčešće pati zbog glavne slike. U builderu je hero često pozadinska slika podešena na ugnežđenom div elementu, što znači da je zapisana u CSS-u, a ne u HTML-u. Preload skener je ne vidi dok ne parsira stil, ne može joj dati prioritet kao pravoj slici, a nije retko ni da je uz to uključen lazy loading. Najvažnija slika na stranici tako kreće poslednja.
CLS dolazi iz kasnih dolazaka. Web font koji zameni sistemski i pomeri ceo blok teksta. Icon font koji stigne posle prvog crtanja. Ulazne animacije koje pomeraju sekcije dok se skroluje. Slider koji dobije visinu tek kada se inicijalizuje i gurne sve ispod sebe naniže.
INP je najiskreniji od sve tri, jer meri koliko posetilac čeka na odgovor kada nešto stvarno klikne. Glavna nit u tom trenutku izvršava jQuery, runtime buildera i skripte svih widgeta koji su na stranici. Otvaranje menija, prelazak na drugi tab ili slanje forme staju u red iza tog posla.
Važno je i gde merite. Na laptopu s brzom vezom stranica na builderu ume da izgleda sasvim u redu. Na srednjem Android telefonu ista stranica pokaže sve tri odjednom, a upravo taj telefon većina vaših kupaca drži u ruci.
Kada je builder ispravan izbor, a kada prestane da bude
Builder je dobar odgovor češće nego što developeri vole da priznaju. Ako klijent menja sadržaj svake nedelje i ne želi da zbog nove sekcije nekoga zove, ako je raspored običan (hero, tri kolone, poziv na akciju, forma), ako je sajt prezentacija firme, a ne kanal kroz koji ide prihod, i ako budžet ne pokriva namenske šablone, onda je uredno implementiran sajt na builderu bolji ishod od projekta po meri koji nikada nije završen.
Prestaje da bude dobar odgovor u nekoliko prepoznatljivih trenutaka. Kada sajt postane glavni prodajni kanal, pa svaka sekunda učitavanja ima cenu koja se vidi. Kada sadržaj prestane da staje u šablon, pa se svaka nova stranica sklapa ručno umesto da izlazi iz strukture. Kada broj plugina koji krpe builder nadmaši broj plugina koji nose stvarne funkcije. I kada jedna izmena dizajna traži da neko prođe kroz sve stranice i ponovi je na svakoj.
Taj poslednji prag je zapravo pitanje modela sadržaja, a ne performansi. Na platformi za Innovation Properties Group postoje četiri odvojene strukture sadržaja, pretraga nekretnina koja se filtrira kroz URL i kalkulator poslovnog prostora ugrađen u sajt. Takav sistem se ne sklapa iz sekcija, nego se modeluje, i tu builder više nije alat za taj posao.
Šta se realno može bez prepravke, po redosledu isplativosti
Ako prepravka nije na stolu, a najčešće nije, ovo je redosled po kojem se posao isplati. Radite jednu stavku, izmerite istu stranicu, pa prelazite na sledeću.
Gde je plafon i kada se prepravka isplati
Sve nabrojano ima kraj. Struktura omotača, generisani CSS i runtime buildera su pod ispod kojeg se ne stiže bez uklanjanja buildera. Na desktopu i uz dobar hosting uredno očišćena stranica na builderu ume da dobije ocenu „dobro”. Na srednjem telefonu se plafon vidi, i tada je pošteno reći klijentu da smo stigli dokle se ovim putem stiže.
Kada je taj plafon zaista prenizak, izlaz ne mora da bude sve ili ništa. Na skoro svakom sajtu dva ili tri šablona nose većinu saobraćaja: početna, neka lista i stranica usluge ili proizvoda. Njih vredi napisati nativno, kroz izradu WordPress sajta po meri, a ostatak sadržaja mirno ostaje na builderu dok mu ne dođe vreme. Migracija u koracima je jeftinija i manje rizična od velikog redizajna, a dobitak stiže tamo gde se meri.
Sajt na builderu može da bude dovoljno brz. Greška nije u tome što je izabran, nego u očekivanju da isporuči isto što i ručno pisan šablon, i u trošenju budžeta na plugine koji to obećavaju.