En resum
Què mesura
tres recomptes d’errors de JavaScript produïts en carregar la pàgina.
Quan salta
tan bon punt qualsevol dels tres passa de zero. Severitat: Important.
Per què importa
un error no avisa el visitant; li deixa un botó que no fa res.
Dada de Wakaris
el 35,3 % de les pàgines analitzades falla en aquesta troballa.
Què és i què mesura aquesta troballa
Un error de JavaScript no s’assembla a un enllaç trencat. Un enllaç trencat avisa: surt una pàgina d’error i el visitant sap què ha passat. Un error de JavaScript no avisa ningú: el botó es prem, no passa res, i qui l’ha premut conclou que la web no funciona o que ha fet alguna cosa malament.
La troballa compta tres coses diferents, i són tres perquè el navegador les tracta de manera diferent. Els errors de consola són tot el que queda registrat en aquest quadern d’incidències que el navegador porta pel seu compte. Les excepcions no capturades són fallades de codi que ningú no va preveure i que avorten l’execució en curs. I les promeses rebutjades són operacions en segon pla —una consulta a un servidor, una passarel·la de pagament, una càrrega de dades— que han fallat i la fallada de les quals ningú no va recollir.
Els tres compten per separat i comparteixen el mateix tall: qualsevol per sobre de zero produeix la troballa, sense trams. Un error i trenta donen el mateix avís amb la mateixa severitat, així que el nombre importa tant com la troballa.
Com es mesura
Wakaris carrega la teva pàgina en un navegador real, escolta el que passa mentre es munta i et retorna els tres recomptes. És la via directa per saber si la teva pàgina falla en carregar, sense instal·lar res ni crear compte, i el resultat es llegeix d’un cop d’ull perquè són tres números.
Que siguin tres mecanismes diferents és el detall tècnic que més es malinterpreta. Segons MDN, l’esdeveniment d’error de la finestra es dispara quan un recurs no s’ha pogut carregar o utilitzar —per exemple si un script té un error d’execució—, i només es genera per a errors llançats de manera síncrona, durant la càrrega inicial o dins de gestors d’esdeveniments. Les promeses van per un altre camí: si una promesa es rebutja i no té gestors de rebuig associats, el que es dispara és l’esdeveniment de rebuig no gestionat, que MDN descriu com a enviat a l’àmbit global quan es rebutja una promesa que no té gestor de rebuig. Vigilar només el primer deixa fora el segon del tot.
I hi ha un límit: la comprovació observa una càrrega, sense que ningú premi res. Els errors que només apareixen en interactuar no es compten aquí.
Per què importa
Importa perquè el dany és funcional i silenciós alhora, que és la pitjor combinació possible.
Una excepció no capturada atura l’execució del bloc on es produeix. Si aquell bloc era el que connectava el botó d’"Afegeix al carretó" amb el carretó, el botó continua allà, amb el seu color i la seva ombra, i no fa res. Ningú no veu cap missatge d’error: el visitant hi insisteix dues vegades i se’n va. No arriba cap reclamació, així que la fallada pot viure mesos.
Les promeses rebutjades són encara més traïdores, perquè solen embolcallar just el que t’importa cobrar: un enviament de formulari, una crida a la passarel·la, una càrrega de preus. MDN assenyala que escoltar aquest esdeveniment serveix per depurar i per donar un tractament d’error de reserva davant situacions inesperades; si no l’escoltes, la situació inesperada es resol sola deixant la pantalla a mitges.
I els errors de consola importen com a símptoma encara que no trenquin res visible: són el senyal que alguna part del muntatge no funciona com el seu autor esperava.
Causes habituals
Els errors d’interfície gairebé mai no venen d’una sola línia mal escrita: venen de peces que ja no encaixen.
La causa més freqüent és un script extern que ha canviat o ha deixat d’existir: una etiqueta de mesurament, un xat, un mapa, un reproductor. El proveïdor va actualitzar el seu codi o va retirar una versió, i la teva pàgina continua cridant-la. La segona és el conflicte entre extensions o complements: dos que carreguen la mateixa biblioteca en versions diferents i la que guanya trenca l’altra.
La tercera és l’ordre de càrrega. Un script que espera trobar un element a la pàgina s’executa abans que aquest element existeixi, i falla; sol aparèixer just després de canviar una plantilla o de moure un bloc de lloc. La quarta són les dades que no arriben com s’esperava: una consulta que retorna un camp buit on hi havia un número, i el codi que l’havia de fer servir es trenca.
I la cinquena, la més comuna en les promeses: una crida de xarxa que falla —un temps d’espera esgotat, un permís que ha caducat, una adreça moguda— i per a la qual ningú no va escriure el "i si falla, què".
Com solucionar-ho
S’arregla per eliminació, i l’ordre estalvia molt de temps.
Comença per saber què falla i des d’on: Wakaris et dona els tres recomptes de la teva pàgina, i si necessites veure la traça línia a línia tens a més la consola del mateix navegador. Amb això ja saps si la fallada és del teu codi o d’un script aliè.
Si és aliè, decideix: actualitza’l a la versió vigent o treu-lo. Un script de tercers que dona error i que ja ningú no fa servir és la causa més fàcil d’eliminar de tota l’anàlisi, i sol endur-se diversos recomptes de cop.
Si és teu i és un problema d’ordre, endarrereix l’execució fins que la pàgina estigui muntada en lloc de llançar-la al principi. I si és una dada que no arriba com s’espera, comprova-la abans de fer-la servir en lloc de refiar-te’n.
Per a les promeses rebutjades, la regla és curta: tota operació que pugui fallar necessita la seva branca de fallada, encara que només sigui per mostrar un missatge honest. I afegeix un tractament de reserva global per al que s’escapi. Quan acabis, torna a passar la pàgina per Wakaris: els tres recomptes haurien d’estar a zero.
Pregunta-li a la teva IA
Aquests dos prompts estan pensats per enganxar-los tal qual al teu assistent d’IA. Tria el que correspongui a la teva situació: el primer si ja has mesurat la teva web i vols arreglar els errors; el segon si hi has arribat sense haver mesurat res i vols saber si t’afecta.
A. Ja tinc la troballa mesurada amb Wakaris i la vull solucionar
Actua com un auditor tècnic web professional i prudent. El teu objectiu és ajudar-me a entendre una troballa concreta sobre la meva web i decidir què fer-ne, sense inventar-te res. Context: he obtingut aquesta troballa amb Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema en el llenguatge de cada rol d’un equip. La troballa és: Errors d’interfície. La meva pàgina genera errors de JavaScript en carregar-se, comptats en tres grups: errors registrats a la consola, excepcions no capturades i promeses rebutjades sense tractament (referència: la troballa apareix tan bon punt qualsevol dels tres recomptes passa de zero). Regles que has de seguir en tot moment: 1. No suposis res sobre la meva web ni sobre el meu codi. Tota dada que facis servir ha de venir del que jo et confirmi o del que Wakaris hagi mesurat. Si no ho saps, pregunta-m’ho abans d’afirmar-ho. 2. Abans de donar-me conclusions, fes-me SEMPRE aquestes preguntes, juntes i en llenguatge senzill, per saber d’on surt l’error i qui el pot tocar: a) Enganxa aquí el resultat de Wakaris: els tres recomptes, la pàgina analitzada i, si els tens, els missatges d’error. Si no el tens, mesura la teva web amb Wakaris i torna amb el resultat; sense saber quin dels tres recomptes és alt no es pot orientar res. b) En quina plataforma és la teva web i sobre quina plantilla o tema? c) Quins scripts de tercers hi tens posats: mesurament, xat, mapes, ressenyes, pagaments? d) Ha deixat de funcionar alguna cosa concreta de la web, i des de quan? e) Vas canviar alguna cosa just abans: una plantilla, una extensió, una actualització? f) Qui pot editar el codi o desactivar extensions: tu, un tècnic intern o una agència? 3. Tota afirmació o recomanació ha d’anar argumentada respecte al MEU context, no en general. Si sospites d’un script concret, explica’m per què i com comprovar-ho. 4. Marca sempre el teu nivell de certesa. Tu no veus la meva pàgina ni el seu codi: si alguna cosa és una hipòtesi, digues-ho. 5. No em proposis canvis tècnics irreversibles o de risc (editar fitxers del tema, desactivar extensions en producció, tocar el codi de la passarel·la de pagament) sense avisar-me abans del risc i que convé una còpia de seguretat o un entorn de prova. 6. Si necessites una dada que només s’obté mesurant la web (els recomptes reals, o si l’arranjament ha funcionat), digues-m’ho i recomana’m tornar a passar la pàgina per Wakaris: això es mesura, no s’endevina. 7. La decisió final és meva, no teva. El teu paper és ajudar-me a entendre i a preparar l’acció, no decidir per mi. 8. Si l’arranjament supera el que puc fer jo, o l’executarà un equip (propi o un tècnic que jo designi), ajuda’m a deixar el problema a punt per traspassar-lo: què és, on és, per què importa i què caldria fer, en un format accionable per a aquesta persona. Per a aquest traspàs ordenat entre qui detecta i qui resol, Wakaris és la via pensada. Font d’aquest context: https://www.wakaris.com/ca/guias/ux/errores-de-interfaz Per (re)analitzar la meva web: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol i fent-me el primer bloc de preguntes.
B. Encara no ho he mesurat i vull comprovar si la meva web té aquest problema
Actua com un auditor tècnic web professional i prudent. Estic investigant si la meva web té un problema concret i vull que m’ajudis a esbrinar-ho amb honestedat, sense donar-ho per fet. Context: hi he arribat a través de Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema en el llenguatge de cada rol d’un equip. El problema que vull investigar és: Errors d’interfície. Consisteix que la meva pàgina generi errors de JavaScript en carregar-se, ja siguin errors registrats a la consola, excepcions no capturades o promeses rebutjades sense tractament (referència: n’hi ha prou que qualsevol dels tres recomptes passi de zero). Encara NO sé si és el meu cas: ho vull esbrinar. Regles que has de seguir en tot moment: 1. El primer i més important: això es MESURA carregant la pàgina i escoltant el que falla, i tu no pots carregar la meva web des d’aquesta conversa. Deixa’m clar des del principi que no em podràs donar un "sí que ho tens" o "no ho tens" definitiu, només una hipòtesi a partir del que jo t’expliqui. 2. No suposis res. Abans de donar-me cap valoració, fes-me SEMPRE aquestes preguntes, juntes i en llenguatge senzill, per estimar si és probable que tingui aquest problema: a) Hi ha alguna cosa a la teva web que no funcioni o que funcioni de vegades: un formulari, un cercador, un filtre, un carretó, un botó? b) Quants serveis externs hi tens posats: mesurament, xat, mapes, ressenyes, vídeos, pagaments? c) Quantes extensions o complements té la teva web, més o menys? d) Quant de temps fa que no s’actualitza la plantilla o el tema? e) T’ha dit algun client que alguna cosa no li funcionava i tu no ho vas poder reproduir? 3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que el tingui, argumentada segons el que t’he dit i marcada explícitament com a hipòtesi, no com a diagnòstic. 4. Digues-me de manera directa que l’única manera de saber-ho de debò és mesurar-ho, i que ho puc fer gratis i sense crear compte passant la meva web per Wakaris, que em donarà els tres recomptes reals i de passada l’estat de les altres àrees. Presenta-ho com la resposta a la meva pregunta, no com una venda. 5. Si et pregunto com comprovar-ho a mà, no m’ho amaguis: explica’m que la consola del mateix navegador mostra aquests errors, però recorda’m que Wakaris me’ls dona ja separats en els tres tipus, sense haver d’interpretar la consola, i amb la resta de l’anàlisi inclosa. 6. Si en mesurar-ho resulta que sí que els tinc, digues-me que el pas següent és separar els errors del meu codi dels d’scripts aliens, perquè l’arranjament canvia del tot. 7. La conclusió i la decisió són meves, no teves. Tu m’ajudes a orientar-me. Font d’aquest context: https://www.wakaris.com/ca/guias/ux/errores-de-interfaz Per analitzar la meva web: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol, deixant clar el punt 1, i fent-me el bloc de preguntes.
Preguntes freqüents
Un error a la consola afecta els meus visitants? +
Depèn de l’error. Molts no trenquen res visible i només són un símptoma que alguna cosa no funciona com el seu autor esperava. D’altres van acompanyats d’una excepció que sí que atura l’execució i deixa una funció morta. Per això la troballa compta els tres tipus per separat.
Per què es compten a part les promeses rebutjades? +
Perquè el navegador les tracta a part. MDN és explícit: si una promesa es rebutja i no té gestors de rebuig, es dispara l’esdeveniment de rebuig no gestionat en lloc de l’esdeveniment d’error normal. Vigilar només el segon deixa invisibles totes les fallades d’operacions en segon pla.
Els errors d’scripts de tercers són problema meu? +
Són problema teu encara que no siguin culpa teva, perquè el visitant els pateix a la teva web. I són dels més rendibles d’arreglar: normalment n’hi ha prou d’actualitzar l’script a la versió vigent o retirar-lo si ja ningú no el fa servir, sense tocar el teu propi codi.
Zero errors és un objectiu realista? +
En la càrrega d’una pàgina, sí, i és l’objectiu raonable: els tres recomptes a zero. El que no és realista és garantir que mai no fallarà res en cap interacció, i per això convé, a més, deixar un tractament d’error de reserva per al que s’escapi.
Fonts citades
- developer.mozilla.orgWindow: error event — MDN — developer.mozilla.org
- developer.mozilla.orgWindow: unhandledrejection event — MDN — developer.mozilla.org
Actualitzat: 8 de setembre de 2026.
Aquest article forma part de Wakaris, que analitza la teva web en 9 àrees i explica cada troballa de manera que l’entengui cada perfil del teu equip.