WebGPU je svugdje, ali WebGL i dalje drži većinu
Krajem 2025. WebGPU je napokon postao dostupan u svim glavnim preglednicima. Chrome, Firefox, Safari i Edge nude stabilnu podršku, a većina većih JavaScript enginea ima vlastite WebGPU rendere. Na papiru, to izgleda kao trenutak u kojem WebGL odlazi u povijest.
U praksi se to nije dogodilo. Produkcijski timovi koji rade 3D web sadržaje i dalje se u velikoj mjeri oslanjaju na WebGL 2. WebGPU se uvodi selektivno, prvenstveno u scenarijima gdje postoje jasna uska grla: ekstreman broj draw callova, masivni sustavi čestica, kompleksni compute zadaci ili napredni post‑processing lanci.
Aktualni vodiči za migraciju u ekosustavu Three.js i Babylon.js vrlo su eksplicitni: WebGPU nije univerzalno brži. On je moćniji i fleksibilniji API, ali traži više rada oko upravljanja resursima, vlastiti toolchain i dublje razumijevanje GPU pipelinea. Za velik dio tipičnih web scena, dobro optimizirani WebGL 2 i dalje isporučuje stabilan FPS, predvidljiv frame pacing i jednostavniji razvoj.
Za koje projekte WebGL ostaje racionalni default?
Većina 3D sadržaja na webu ne cilja AAA razinu kompleksnosti. Tipični projekti su:
- marketinške kampanje i interaktivne landing stranice
- proizvodne prezentacije s nekoliko konfiguracija modela
- lagane podatkovne vizualizacije i dashboardi
- edukativne simulacije s ograničenim brojem objekata
Za takve slučajeve ključni kriteriji su:
- brzo vrijeme izrade i jednostavniji pipeline
- maksimalna kompatibilnost s preglednicima i starijim uređajima
- umjerena kompleksnost shader koda
- predvidljivo ponašanje na mobilnim uređajima
WebGL 2 ovdje i dalje pobjeđuje po omjeru uloženog truda i dobivenog rezultata. Enginei poput Three.js i dalje primarno ciljaju WebGL renderer kao „prvi izbor”, dok se WebGPU renderer učitava kao opcionalni modul. U produkciji je i dalje uobičajeno ograničiti broj dinamičkih svjetala, konsolidirati materijale i pažljivo planirati draw callove, umjesto da se odmah preskoči na WebGPU.
Slično vrijedi i za Babylon.js. Iako taj engine agresivno usvaja WGSL, compute shadere i napredni WebGPU pipeline, velik dio ekosustava ostaje na WebGL‑u. Razlog je jasan: WebGL i dalje pokriva stariji hardver, jeftine Android uređaje, integrirane GPU‑ove u uredskim prijenosnicima i kioske u maloprodaji.
Kada WebGPU stvarno donosi mjerljivu prednost?
WebGPU je dizajniran da ukloni ograničenja koja su se godinama gomilala oko WebGL‑a i njegovog nasljeđa iz OpenGL ES‑a. U praksi, on najviše dobiva u sljedećim scenarijima:
Ekstreman broj draw callova
Velike scene s tisućama objekata i materijala tradicionalno se lome na CPU strani, gdje WebGL driver i JavaScript runtime troše previše vremena na pripremu svakog draw calla. WebGPU omogućava unaprijed snimljene command buffere, efikasnije batchiranje i bolje iskorištavanje više jezgrenih CPU‑ova.
Primjeri:
- veliki konfiguratori gradilišta ili pametnih gradova
- masivne arhitektonske vizualizacije s puno instanciranih elemenata
- kompleksne igre u pregledniku s otvorenim svjetovima
Compute‑intenzivni zadaci
WebGPU donosi prvi ozbiljan compute model na webu. To otvara vrata simulacijama koje su ranije bile nepraktične ili preskupe za održavanje u WebGL‑u, gdje se sve moralo „gurati” kroz fragment shadere i trikove s render targetima.
Primjeri:
- GPU‑akcelerirane fizikalne simulacije (tekućine, dim, tkanine)
- napredni AI i ML modeli koji rade direktno na GPU‑u
- proceduralno generiranje terena i sadržaja u realnom vremenu
Napredni post‑processing i custom pipelinei
WebGPU daje puno veću kontrolu nad render pipelineom: više render passova, fleksibilne render targete, precizno upravljanje sinkronizacijom i memorijom. To je idealno za timove koji žele vlastite HDR lance, prilagođene tone mapping algoritme ili kompleksne efekate kao što su volumetrijsko osvjetljenje i temporalni anti‑aliasing.
No, cijena te fleksibilnosti je veća kompleksnost. Potrebno je više vremena za razvoj, više testiranja i često vlastiti interni alatni lanac za izradu i validaciju shader koda.
Zašto industrija preporučuje konzervativnu migraciju
Timovi koji već imaju stabilne WebGL aplikacije suočavaju se s klasičnom dilemom: prepisati sve na WebGPU ili nastaviti održavati postojeći pipeline. Aktualne smjernice industrije snažno naginju drugoj opciji.
Ako aplikacija već postiže ciljani FPS na ključnim platformama i nema planiranih velikih nadogradnji (novi efekti, drastično veći broj objekata, zahtjevnije simulacije), preporuka je ostati na WebGL‑u i fokusirati se na optimizaciju.
Tipične WebGL optimizacije koje i dalje imaju smisla
- Reduciranje overdrawa – bolje prostorno sortiranje objekata, korištenje depth pre‑passa, agresivniji culling i jednostavnije geometrije za nebitne dijelove scene.
- Instancing i batching – korištenje instancinga za ponavljajuće objekte (stabla, stolice, rasvjeta) i grupiranje draw callova po materijalu, shaderu i render stanju.
- LOD sustavi – više razina detalja za udaljene objekte, dinamičko prebacivanje meshova ovisno o udaljenosti, smanjenje broja trokuta u pozadini.
- Kompresija tekstura – korištenje modernih formata (ASTC, ETC2, BCn) gdje je moguće, uz fallback na starije formate, kako bi se smanjio bandwidth i poboljšao frame pacing.
- Profiliranje pipelinea – sustavno mjerenje vremena po rendering passu, shaderu i draw call grupi, umjesto nasumičnih optimizacija.
U mnogim slučajevima, ove optimizacije donose veći i sigurniji dobitak od rane migracije na WebGPU, posebno za timove s ograničenim resursima i bez dubokog iskustva s modernim GPU API‑jima.
Hibridni modeli: WebGL kao baza, WebGPU kao akcelerator
Kako WebGPU sazrijeva, u praksi se sve više pojavljuje hibridni pristup. Ideja je jednostavna: WebGL renderer ostaje osnovni sloj za prikaz scene, dok se WebGPU koristi ciljano, tamo gdje mjeri razliku.
Postoji nekoliko tipičnih obrazaca:
Odvojeni moduli i „pro” verzije
Jedna varijanta je da aplikacija ima dvije razine funkcionalnosti:
- standardnu verziju koja koristi WebGL i cilja najširu publiku
- naprednu verziju koja koristi WebGPU za dodatne efekte ili veće scene
Primjer su B2B platforme gdje korisnici na desktopu s jakim GPU‑om mogu uključiti „high‑fidelity” način rada, dok mobilni korisnici ostaju na WebGL‑u s reduciranom kompleksnošću.
Compute i simulacije u WebGPU‑u, rendering u WebGL‑u
Drugi obrazac je korištenje WebGPU‑a samo za compute dio. Simulacija se izvršava u WebGPU compute shaderima, a rezultati se zatim prenose u WebGL teksture ili buffere za prikaz.
To je osobito korisno za sustave čestica, fizikalne simulacije ili složen animacijski sustav. Rendering pipeline ostaje isti, što smanjuje rizik i količinu koda koji treba održavati.
Specijalizirani WebGPU passovi
Treća varijanta je uvođenje WebGPU‑a samo za određene rendering passove, poput naprednog post‑processinga, globalne iluminacije ili shadow cache sustava. Osnovna geometrija i dalje se crta u WebGL‑u, ali određeni teški efekti prelaze na WebGPU kako bi rasteretili CPU i GPU.
Ovi hibridni modeli postaju de facto standard u 2026. godini jer kombiniraju najbolje od oba svijeta: stabilnost i kompatibilnost WebGL‑a s performansama i fleksibilnošću WebGPU‑a.
Rizici i skriveni troškovi potpune migracije
Potpuni prelazak na WebGPU zvuči atraktivno, ali nosi niz rizika koje je lako podcijeniti:
- Održavanje dvostrukog koda – u prijelaznom razdoblju mnogi timovi moraju održavati i WebGL i WebGPU renderer, što povećava trošak testiranja i integracije.
- Alatni lanac i debug – WebGPU zahtijeva nove alate za profiliranje, validaciju shader koda i analizu performansi. Uspostava tog toolchaina nije trivijalan zadatak.
- Razlike među preglednicima – iako je WebGPU „standardiziran”, implementacijske razlike i dalje postoje. Potrebno je dodatno testiranje na različitim driverima i OS‑ovima.
- Edukacija tima – prelazak s relativno visokorazinske WebGL abstrakcije na eksplicitni resursni model WebGPU‑a traži vrijeme i iskustvo. Pogreške u upravljanju memorijom i sinkronizacijom mogu biti skupe.
Zbog toga mnoge tvrtke odlučuju WebGPU uvoditi iterativno, kroz manje module i eksperimentalne značajke, umjesto da cijeli pipeline prepišu odjednom.
WebGL 2026.: profilirani, ali ključan sloj
Slika u 2026. nije crno‑bijela. WebGPU je postao univerzalno dostupan i realna je opcija za nove, ambiciozne projekte. No WebGL ne nestaje; on se profilira.
Umjesto da bude jedini GPU API na webu, WebGL postaje konzervativni, ali iznimno važan sloj za kompatibilnost i predvidljivost. Za projekte koji ciljaju široku publiku, rade u kratkim ciklusima i imaju ograničene resurse za održavanje, WebGL ostaje prva opcija.
Strategija koja se nameće je sljedeća:
- novi projekti s visokim performansnim zahtjevima i bez naslijeđenih ograničenja mogu krenuti s WebGPU‑om kao primarnim API‑jem
- postojeće stabilne WebGL aplikacije trebaju prvo iscrpiti mogućnosti optimizacije unutar postojećeg pipelinea
- WebGPU se uvodi kao nadogradnja, kroz hibridne modele i specifične module, umjesto kao trenutna potpuna zamjena
U tom smislu, „stari” WebGL pipeline i dalje je najbolji izbor u velikom broju realnih projekata. Ne zato što je tehnološki napredniji, već zato što bolje odgovara ograničenjima budžeta, vremena, ciljne publike i heterogenog hardvera na kojem web i dalje živi.
