Eliminar JavaScript no usat: guia tècnica - Ighenatt Blog

El JavaScript és el recurs més car d’una pàgina web. No només pels bytes que transfereix, sinó pel temps de CPU que consumeix en parsejar-se, compilar-se i executar-se. I el problema real és que entre un 35% i un 45% del JavaScript que carrega un web mitjà no s’executa mai durant la primera interacció de l’usuari.

Eliminar aquest codi innecessari millora directament les mètriques de velocitat web que Google utilitza com a senyals de rànquing: LCP, INP i temps total de càrrega.

Per què el JavaScript no utilitzat perjudica els teus Core Web Vitals

Quan el navegador descarrega un arxiu JavaScript, ha de fer tres coses abans que el codi sigui funcional: descarregar-lo, parsejar-lo i executar-lo. Cadascuna d’aquestes fases consumeix temps i recursos.

Segons web.dev, cada 100KB de JavaScript afegeix entre 150 i 300ms de temps de processament en un dispositiu mòbil de gamma mitjana. Un smartphone amb un processador Snapdragon 680 processa JavaScript entre 3 i 5 vegades més lentament que un MacBook Pro.

L’impacte en els Core Web Vitals és triple:

• LCP: els scripts que bloquegen el renderitzat retarden la pintura del contingut principal. Un script síncron a l’encapçalament pot afegir 500ms o més al LCP.
• INP (Interaction to Next Paint): el fil principal del navegador no pot processar interaccions de l’usuari mentre executa JavaScript. Com més JS s’executi, major serà el retard entre el clic de l’usuari i la resposta visual.
• TBT (Total Blocking Time): les tasques de JavaScript que duren més de 50ms bloquegen el fil principal. El TBT acumulat correlaciona directament amb una mala experiència d’interactivitat.

El codi JavaScript que no s’executa mai durant la càrrega inicial continua consumint temps de parsejament i compilació. El navegador no pot saber per endavant quines funcions s’executaran, de manera que processa tot l’arxiu.

Com identificar JavaScript no utilitzat amb Chrome DevTools

Chrome DevTools inclou l’eina Coverage, que mesura quin percentatge de cada arxiu CSS i JavaScript s’executa realment durant la càrrega i la interacció.

Passos per usar-la:

1. Obre Chrome DevTools (F12).
2. Obre el panell Coverage: Ctrl+Shift+P > escriu “Coverage” > selecciona “Show Coverage”.
3. Prem el botó de recàrrega per iniciar la gravació des de la càrrega de la pàgina.
4. Interactua amb la pàgina (scroll, clics en menús, formularis) per simular un ús real.
5. Observa la columna “Usage Visualization”: les barres vermelles indiquen codi no executat.

Què has de buscar:

• Arxius amb més del 50% de codi no usat: són candidats a optimització o eliminació.
• Bundles de tercers grans: biblioteques completes carregades per usar una sola funció.
• Polyfills innecessaris: codi de compatibilitat per a navegadors que els teus usuaris no fan servir.

La pestanya Network complementa aquesta anàlisi mostrant la mida de cada arxiu JavaScript descarregat i si bloqueja el renderitzat (columna “Initiator” i marca “render-blocking”).

JavaScript de tercers: el pitjor culpable (i com gestionar-lo)

Els scripts de tercers representen el 57% del JavaScript total en webs comercials segons HTTP Archive. Analítiques, chatbots, píxels de remarketing, ginys de xarxes socials, eines de tests A/B: cadascun afegeix la seva càrrega de JavaScript al fil principal.

El problema no és només el pes. Cada script de tercers pot:

• Fer peticions HTTP addicionals que competeixen per l’amplada de banda.
• Executar codi al fil principal que bloqueja la interactivitat.
• Carregar les seves pròpies dependències (un giny de xat pot portar React complet encara que el teu lloc no l’usi).
• Fallar silenciosament i deixar listeners orfes que consumeixen memòria.

Estratègies per gestionar scripts de tercers

Auditar regularment: revisa cada script de tercers i pregunta’t si el necessites realment. Un píxel d’una campanya que va acabar fa 6 mesos continua executant-se en cada càrrega de pàgina.

Consolidar amb Google Tag Manager: GTM permet gestionar múltiples scripts des d’una interfície centralitzada. Tot i que GTM té el seu propi cost de rendiment (~30-80KB), consolidar 5-10 scripts individuals en GTM sol ser més eficient.

Carregar després de la interacció: per a scripts no crítics (xat en viu, enquestes), retarda la càrrega fins que l’usuari interactua amb la pàgina. Un listener de scroll o clic que injecta l’script a demanda elimina el seu impacte en la càrrega inicial.

Usar façanes: una imatge estàtica o botó que simula l’aspecte del giny real. Quan l’usuari fa clic, es carrega l’script complet. L’embed de YouTube és l’exemple clàssic: un thumbnail amb botó de reproducció que carrega l’iframe només en fer clic.

Tree shaking i code splitting: eliminar codi mort en el build

El tree shaking és una tècnica d’optimització que analitza les importacions del teu codi i elimina les funcions i mòduls que no s’usen. Els bundlers moderns (webpack, Rollup, esbuild, Vite) ho implementen de forma nativa quan uses ES Modules (import/export).

Per al bon funcionament del tree shaking:

• Usa import { specificFunction } from 'library' en lloc de import * as library from 'library'.
• Assegura’t que les dependències tenen "sideEffects": false al seu package.json, o declara els efectes secundaris explícitament.
• Evita reexportar mòduls complets en arxius barrel (index.ts que reexporta tot).

El code splitting divideix el teu JavaScript en chunks que es carreguen a demanda. En lloc d’un bundle monolític de 500KB, generes chunks de 50-100KB que es carreguen només quan la ruta o funcionalitat els necessita.

Els frameworks moderns implementen el code splitting automàticament:

• Astro usa l’arquitectura d’illes: els components interactius només s’hidraten quan són visibles (client:visible), eliminant tot el JavaScript dels components estàtics.
• React amb lazy(): permet carregar components a demanda amb React.lazy() i Suspense.
• Dynamic imports: import('./module.js') carrega un mòdul només quan s’executa aquella línia de codi.

La combinació de tree shaking i code splitting pot reduir el JavaScript inicial entre un 40% i un 70%, depenent de la mida del bundle original.

Diferir i carregar de forma asíncrona: defer vs async

Els atributs defer i async a l’etiqueta <script> controlen quan es descarrega i s’executa el JavaScript. Usar-los correctament evita que els scripts bloquegin el renderitzat de l’HTML.

Sense atributs (<script src="app.js">): el navegador atura el parsejament de l’HTML, descarrega l’script, l’executa i després continua amb l’HTML. És el pitjor escenari per al rendiment.

async (<script async src="app.js">): el navegador descarrega l’script en paral·lel al parsejament de l’HTML, però quan acaba la descàrrega, atura el parsejament per executar-lo. L’ordre d’execució no està garantit entre scripts amb async.

defer (<script defer src="app.js">): el navegador descarrega l’script en paral·lel al parsejament de l’HTML i l’executa després que l’HTML s’hagi parsesat completament. L’ordre d’execució es respecta entre scripts amb defer.

Quan usar cadascun

• defer: per a la majoria de scripts. Garanteix que l’HTML es parseja sense interrupcions i que els scripts s’executen en ordre. És l’opció per defecte recomanada.
• async: per a scripts independents que no depenen del DOM ni d’altres scripts, com analítiques o píxels de seguiment.
• Sense atributs: només per a scripts crítics que han d’executar-se abans que el contingut sigui visible (casos molt excepcionals).

Per a scripts amb problemes coneguts de rendiment JavaScript, la combinació de defer amb code splitting assegura que el fil principal es mantingui lliure per respondre a les interaccions de l’usuari.

Preguntes freqüents sobre JavaScript i rendiment

Quant JavaScript és massa per a un web?

No hi ha un límit absolut, però Google recomana mantenir el JavaScript total per sota dels 300KB comprimits per a una bona experiència en dispositius mòbils. Els llocs que superen 1MB de JS sense comprimir solen tenir problemes d’INP i temps de càrrega.

Els plugins de WordPress afegeixen molt JavaScript innecessari?

Sí. Cada plugin de WordPress pot afegir entre 20KB i 200KB de JavaScript. Els pitjors culpables són els page builders, sliders, xats en viu i plugins de xarxes socials. La solució és auditar quins plugins carreguen JS, desactivar els innecessaris i usar alternatives lleugeres.

Com carrego scripts de tercers sense que perjudiquin el meu rendiment?

Utilitza l’atribut defer per a scripts que no són crítics en la càrrega inicial. Per a scripts pesants (xat, analítiques avançades), retarda la seva càrrega fins a la primera interacció de l’usuari. Per a scripts de seguiment, avalua si Google Tag Manager pot consolidar-ne diversos en un de sol.

Reduir el JavaScript innecessari és una de les optimitzacions amb major impacte en els Core Web Vitals. Si vols que analitzem el pes i l’execució de JavaScript al teu lloc i t’ajudem a implementar una estratègia d’optimització, contacta amb nosaltres.