Durant anys, el mantra 'no bloquejar mai el fil principal' ha estat el dogma sagrat del desenvolupament web modern. El trobem a totes les guies de rendiment, i amb raó: el fil principal del navegador és un entorn d'un sol fil que comparteix recursos amb el motor de renderització, els gestors d'esdeveniments i altres tasques crítiques. No obstant, aplicar aquesta regla de manera absoluta pot portar-nos a decisions contraproduents. Hi ha escenaris on moure dades a un worker o context aïllat resulta més costós que processar-les directament al fil principal. Aquest article explora quan té sentit bloquejar el fil principal i com empreses com Q2BSTUDIO integren aquesta perspectiva en el desenvolupament d'aplicacions a mida eficients.
Per entendre el dilema, hem de recordar com funcionen els contextos aïllats al navegador. El fil principal executa JavaScript, gestiona el DOM i pinta la interfície. Els Web Workers, Service Workers i altres entorns (com els Offscreen Documents a les extensions) viuen en espais de memòria separats. Per comunicar-se, utilitzen postMessage(), que internament invoca el Structured Clone Algorithm (SCA). Aquest algoritme recorre tota l'estructura de dades, la serialitza, la copia i la reconstrueix al context destí. És una operació síncrona de complexitat O(n), és a dir, el cost creix linealment amb la mida de les dades. Per a objectes petits és imperceptible, però quan parlem d'imatges de diversos megabytes, el temps de serialització pot superar el temps de processament real.
Existeix una alternativa: els Transferable Objects. En transferir un objecte com ArrayBuffer o ImageBitmap, el navegador canvia la propietat de la dada sense copiar-la, cosa que és extremadament ràpida. No obstant, no totes les dades són transferibles; un objecte JavaScript pla o una cadena Base64 no ho són. A més, en transferir es perd l'accés a l'origen. En extensions de Chrome, la missatgeria interna (chrome.runtime.sendMessage) força la serialització JSON, per tant els Transferable Objects simplement no són una opció en aquest context. Això ens obliga a replantejar l'arquitectura.
Imaginem un cas real: una extensió que captura pantalles i permet retallar-les. Seguint la recomanació habitual, s'envia la captura a un Offscreen Document (un context de fons amb DOM) per processar el retall en un canvas. La captura retorna una URL en Base64 que pot pesar més d'1 MB en una pantalla 1080p, i fins a 4 MB en pantalles Retina (amb devicePixelRatio = 2 o 3). En enviar aquest payload mitjançant postMessage(), el fil principal es bloqueja durant la serialització, després viatja al worker, es deserialitza, es processa (un retall ràpid d'uns 50 ms) i es retorna el resultat serialitzat de nou. El resultat: una latència de 2 a 3 segons, inacceptable per a una acció que hauria de sentir-se instantània. A més, sorgeixen problemes amb l'escalat de coordenades pel DPR, que a l'Offscreen Document val 1 per defecte, requerint càlculs manuals addicionals.
La solució va ser trencar la regla i executar el processament directament al fil principal de la pestanya activa, usant un content script. El fons envia la URL Base64 al content script, que dibuixa en un canvas, aplica el retall amb el DPR real (obtingut del DOM) i copia el resultat al porta-retalls. Tot en menys d'un segon. El fil principal es bloqueja durant aquest breu interval, però l'usuari ha sol·licitat explícitament l'acció i el temps és acceptable. Aquesta experiència demostra que el precepte hauria de ser 'no bloquejar mai el fil principal durant massa temps', no 'no bloquejar-lo mai'.
Quan té sentit, doncs, bloquejar el fil principal? La clau està a distingir entre tasques intensives en còmput (CPU-bound) i tasques intensives en dades (data-bound). Les primeres, com la compressió d'imatges, simulacions físiques o l'entrenament de models d'IA, requereixen molt temps de processament i poca transferència; aïllar-les en un worker redueix el bloqueig. Les segones, com retallar una imatge, filtrar un array o aplicar transformacions lleugeres, tenen un cost de processament baix però un cost de transferència alt si les dades són grans. En aquests casos, moure les dades al worker pot afegir més latència de la que estalvia. L'equació és simple: Temps total = Cost de serialització + Trànsit + Processament en segon pla + Deserialització. Si el processament domina, aïllar és avantatjós; si la transferència domina, és millor quedar-se al fil principal.
A Q2BSTUDIO apliquem aquest raonament a cada projecte. Quan desenvolupem solucions cloud a AWS o Azure, avaluem el volum de dades que flueix entre serveis i el cost computacional de cada operació. Els nostres sistemes d'IA i agents IA processen grans volums d'informació, però dissenyem pipelines que minimitzen les transferències innecessàries. De la mateixa manera, en ciberseguretat analitzem logs en temps real, on la latència de moviment de dades pot comprometre la detecció primerenca. Les solucions de BI/Power BI que implementem optimitzen la càrrega de dades perquè els dashboards responguin sense demores, evitant sobrecarregar el fil principal amb transformacions pesades que podrien executar-se al backend. Tot això forma part de la nostra filosofia d'automatització de processos software, on cada decisió tècnica es basa en mètriques reals, no en dogmes.
Mesurar és fonamental. Podem usar performance.mark() i performance.measure() al voltant de les crides postMessage() per quantificar el cost de transferència. Si aquest cost supera el temps de processament, reconsiderar l'arquitectura. També és útil analitzar la mida de les dades: si superen uns pocs centenars de kilobytes i l'operació és lleugera, probablement convingui executar-la al fil principal. Eines com Lighthouse o les Chrome DevTools permeten identificar colls d'ampolla de serialització.
En conclusió, bloquejar el fil principal no és un pecat si es fa amb coneixement de causa. La recomanació universal d'aïllar tot el treball pesat prové d'una època en què les aplicacions web eren més senzilles i les dades més petites. Avui, amb aplicacions riques en multimèdia, IoT i anàlisi en temps real, necessitem un enfocament matisat. A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, defensem la presa de decisions informades: mesurar, comparar i triar l'estratègia que ofereixi la millor experiència d'usuari. Ja sigui mitjançant aplicacions a mida, cloud AWS/Azure, IA, ciberseguretat o BI/Power BI, el nostre objectiu és construir programari que no només funcioni, sinó que ho faci amb el rendiment que els usuaris esperen. De vegades, això significa bloquejar el fil principal durant mig segon. I està bé.
