Google Lighthouse: els errors que la puntuació no us mostra

Imagina que portes mesos amb la teva web en producció. Les visites arriben, el negoci funciona, ningú no es queixa. Però un dia executes Google Lighthouse i descobreixes que la teva pàgina principal triga 4 segons a pintar el contingut principal a mòbil. Que hi ha 12 elements que no compleixen els mínims de contrast. Que una llibreria de JavaScript té vulnerabilitats conegudes.

Res d'això no genera un error visible. No hi ha cap pantalla vermella ni cap missatge d'alerta. Són problemes que fa mesos que hi són, afectant el rendiment, l'accessibilitat i la seguretat sense que ningú ho noti.

Google Lighthouse és probablement l'eina més accessible per treure'ls a la llum. És gratuïta, triga dos minuts a executar-se i pot revelar-te coses que fa mesos que no veus.

Què és Lighthouse (i què no és)

Lighthouse és una eina open source de Google que audita pàgines web en cinc categories: rendiment, accessibilitat, bones pràctiques, SEO i compatibilitat amb Progressive Web Apps (PWA). Pots executar-la directament des de les DevTools de Chrome, des de la línia d'ordres oa través de PageSpeed ​​Insights.

El que fa és simular la visita d'un usuari a la teva pàgina, recopilar mètriques de càrrega i comportament i generar un informe amb una puntuació de 0 a 100 a cada categoria juntament amb recomanacions concretes.

El que no fa és donar-te una foto completa de la teva web. Lighthouse analitza una pàgina alhora, no un lloc sencer. No substitueix un test de càrrega real, ni una auditoria de seguretat professional, ni proves d'usabilitat amb usuaris reals. És un punt de partida, no pas un diagnòstic final.

Però com a punt de partida, pocs ofereixen tanta informació per tan poc esforç.

L'error més comú: quedar-se a la puntuació

La majoria de la gent executa Lighthouse, mira els quatre números de dalt (90, 85, 100, 92) i tanca la pestanya. Si els números són verds, tot bé. Si algun és a taronja, ja el mirarem. Si està en vermell, potser ens preocupem.

Aquest enfocament desaprofita gairebé tot el que Lighthouse ofereix.

La puntuació és un resum. A sota hi ha desenes d'auditories individuals, cadascuna amb un diagnòstic específic i, en molts casos, amb la indicació exacta del recurs, l'element o la línia de codi que causa el problema. És la diferència entre saber que tens febre i saber què n'està causant.

Veurem què pots trobar si vas més enllà del número.

Rendiment: allò que els teus usuaris senten però no et diuen

La categoria de rendiment no mesura només "si la web és ràpida". Mesura l'experiència de càrrega tal i com la percep un usuari real en un dispositiu real amb una connexió real.

Les mètriques clau que Lighthouse avalua des de la seva actualització a la versió 13 són:

Largest Contentful Paint (LCP). Mesura quant triga a aparèixer l'element visual més gran de la pàgina. Si el vostre LCP supera els 2,5 segons, l'usuari percep que el web triga a carregar, encara que tècnicament ja hagi començat a renderitzar. Lighthouse et diu exactament quin element és el que triga més i per què.

Cumulative Layout Shift (CLS). Mesura quant es mou el contingut mentre la pàgina carrega. Alguna vegada heu intentat prémer un botó i la pàgina s'ha desplaçat just en aquell moment? Això és layout shift. Un CLS alt no només frustra: pot fer que un usuari premi on no vol, amb conseqüències reals en formularis o processos de compra.

Interaction to Next Paint (INP). Mesura quant triga la pàgina a respondre quan l'usuari hi interactua. Un botó que triga 400 mil·lisegons a reaccionar se sent trencat, encara que tècnicament funcioni.

El més interessant de Lighthouse no és que et digui que el teu LCP és 3,8 segons. El més interessant és que et digui que el problema és una imatge hero de 2,4 MB servida sense lazy loading ni format modern. Aquesta és informació sobre la que pots actuar.

Què cerca a la secció de rendiment

Obriu l'informe complet i aneu a la secció "Opportunities" i "Diagnostics". Aquí hi ha els problemes concrets. Alguns dels més habituals:

Imatges sense optimitzar. Lighthouse detecta imatges que podrien reduir el seu pes significativament si es servissin en format WebP o AVIF, si es redimensionessin a la mida real de visualització o si es carreguessin amb lazy loading.

JavaScript que bloqueja el renderitzat. Scripts que es carreguen al <head> sense defer ni async i que impedeixen que la pàgina es pinti fins que s'acaben d'executar. A mòbils amb processadors lents, això pot afegir segons sencers al temps de càrrega.

Recursos de tercers pesants. Widgets de xat, scripts d'analytics, píxels de remàrqueting, fonts web externes. Lighthouse identifica quins recursos de tercers estan penalitzant el teu rendiment i quant de temps afegeixen.

Accessibilitat: els errors que exclouen usuaris

L'auditoria d'accessibilitat de Lighthouse es basa en les regles d'axe-core, un dels motors danàlisi daccessibilitat web més utilitzats. No cobreix el 100% dels criteris de les WCAG (Web Content Accessibility Guidelines), però detecta els problemes més comuns i més fàcils de corregir.

I són més freqüents del que creus.

Contrast insuficient. Text gris clar sobre fons blanc pot quedar elegant al mockup, però si la ràtio de contrast no compleix els mínims de WCAG, una persona amb baixa visió no podrà llegir-lo. Lighthouse t'assenyala cada element que no compleix.

Imatges sense text alternatiu. Cada imatge que no té un alt atribut és invisible per a un lector de pantalla. Lighthouse llista totes les que falten.

Formularis sense etiquetes. Camps de formulari que no estan associats a un <label> són inutilitzables amb teclat o tecnologia asistiva. És un dels errors més comuns i més fàcils d'arreglar.

Ordre de capçaleres trencat. Saltar d'un H1 a un H4 sense passar per H2 i H3 no només és dolent per a SEO: trenca la navegació per a usuaris que usen lectors de pantalla per moure's per l'estructura de la pàgina.

Elements interactius massa petits. Botons o enllaços amb una àrea de toc inferior a 48x48 píxels són difícils de prémer en pantalles tàctils. No només per a persones amb discapacitat motora: per a qualsevol que faci servir un mòbil.

Cadascun daquests problemes és un usuari que no pot completar una acció a la teva web. Depenent del teu sector i mercat, també pot ser un problema legal: la normativa daccessibilitat web és cada vegada més estricta a la UE.

Bones pràctiques: seguretat i errors invisibles

La categoria de "Best Practices" és la que menys atenció rep i, paradoxalment, la que conté algunes de les troballes més crítiques.

Contingut mixt (mixed content). La teva web se serveix per HTTPS, però algun recurs —una imatge, un script, una font— es carrega per HTTP. Això no només genera una advertència al navegador: pot fer que el recurs no es carregui gens en navegadors estrictes, i exposa als teus usuaris a atacs d'intermediari.

Errors a la consola del navegador. Lighthouse reporta si hi ha errors de JavaScript registrats a la consola durant la càrrega. Aquests errors poden indicar funcionalitats trencades que ningú no ha detectat perquè no són visibles a simple vista: un formulari que no valida, un esdeveniment que no es dispara, un component que falla silenciosament.

Biblioteques amb vulnerabilitats conegudes. Si la teva web fa servir una versió de jQuery, Lodash o una altra llibreria amb vulnerabilitats de seguretat documentades, Lighthouse ho detecta. No et diu que la teva web ha estat hackejada, però t'avisa que estàs usant una dependència amb forats coneguts.

Permisos de geolocalització o notificacions a la càrrega. Si la vostra web demana accés a la ubicació o permís per enviar notificacions només carregar, abans que l'usuari hagi interactuat, Lighthouse el marca com una mala pràctica. I té raó: és una de les formes més ràpides que un usuari tanqui la pestanya.

SEO: el que Google no pot llegir

L'auditoria de SEO de Lighthouse no substitueix una eina d'anàlisi de posicionament. No et diu per a quins keywords posiciones ni com està el teu perfil d'enllaços. El que fa és verificar que la teva web no té errors tècnics que impedeixin als cercadors indexar-la i entendre-la correctament.

Meta tags absents. Pàgines sense <title>, sense meta description o amb meta descriptions duplicades. És bàsic, però segueix sent un dels errors més freqüents, especialment en webs dinàmiques on les meta tags es generen automàticament i ningú no verifica el resultat.

Robots.txt que bloqueja recursos. Si el robots.txt està impedint que Google accedeixi a CSS o JavaScript crítics, el cercador no pot renderitzar la teva pàgina correctament i pot malinterpretar-la.

Enllaços sense text descriptiu. Enllaços que diuen "fes clic aquí" o "llegir més" sense context. No només és dolent per a SEO: un usuari amb lector de pantalla que navega per la llista denllaços de la pàgina només veu "fes clic aquí" repetit deu vegades.

Viewport no configurat. Sense l'etiqueta <meta name="viewport">, la vostra web no s'adapta correctament a mòbils. Google prioritza lexperiència mòbil en la seva indexació, i una web sense viewport configurat part amb desavantatge.

Com treure partit a Google Lighthouse

Executar Lighthouse una vegada i mirar els números no serveix de gaire. Per treure'n partit de veritat, convé canviar l'enfocament.

Audita les pàgines que importen, no només la home

La home sol ser la pàgina més optimitzada perquè és la que tothom mira. Però les teves pàgines de producte, el formulari de contacte, el procés de checkout i els landings de campanyes són les que generen negoci. Audita-les.

Executa en mode mòbil

Lighthouse té dues maneres: escriptori i mòbil. El mode mòbil simula un dispositiu Moto G Power amb connexió 4G lenta. És més exigent, però és més representatiu de com hi accedeix la majoria d'usuaris. Si el teu rendiment és bo en mode mòbil, en escriptori serà excel·lent.

Prioritza per impacte, no per puntuació

Un error de contrast en un text decoratiu importa menys que un error de contrast al botó de "Comprar". Lighthouse no sap quina és més important per al teu negoci. Tu sí.

Automatitza les auditories

Lighthouse es pot executar des de la línia de comandes i s'integra amb pipelins de CI/CD. Això permet detectar regressions de rendiment o accessibilitat abans que arribin a producció. Si un deploy fa que el LCP pugi de 2 a 4 segons, ho saps abans que el pateixin els teus usuaris.

No perseguisques el 100

Una puntuació de 100 a totes les categories és possible en una pàgina estàtica sense JavaScript. En un producte digital real, amb analytics, amb xat, amb contingut dinàmic, una puntuació de 100 no és realista ni necessària. El que importa és que no hi hagi errors crítics i que les mètriques estiguin dins dels llindars recomanats.

El que Lighthouse no veu

Lighthouse és una eina d'auditoria automatitzada i, com a tal, té límits. No detecta errors de lògica de negoci, no prova fluxos complets dusuari, no avalua la qualitat del contingut i no substitueix a un test dusabilitat real.

Tampoc no mesura el rendiment sota càrrega real. Lighthouse simula un sol usuari en condicions controlades. Si necessites saber com es comporta la teva web amb 500 usuaris simultanis, necessites eines de testing de càrrega.

Però dins del que sí que cobreix, la relació entre el que costa executar-ho —gratis, dos minuts— i el que et pot revelar és difícil de superar. Un sol informe de Lighthouse pot treure a la llum errors d'accessibilitat que exclouen usuaris, problemes de seguretat que exposen dades i colls d'ampolla de rendiment que estan costant conversions.

L'eina hi és. La qüestió és si la fas servir per veure un número o per trobar el que aquest número amaga.