Auditoria Google Lighthouse para PrestaShop: Interpretacion de cada puntuacion

Que mide Google Lighthouse

Google Lighthouse es una herramienta de auditoria automatizada integrada en Chrome DevTools que evalua las paginas web en cuatro categorias principales: Rendimiento, Accesibilidad, Buenas Practicas y SEO. Cada categoria produce una puntuacion de 0 a 100, y cada puntuacion se calcula a partir de metricas y comprobaciones especificas que tienen diferentes pesos. Comprender lo que estas puntuaciones realmente significan para una tienda PrestaShop, y cuales son los objetivos realistas, es esencial antes de dedicar tiempo a la optimizacion.

Lighthouse funciona en dos entornos. Los datos de laboratorio provienen de un entorno simulado con limitacion controlada de red y ralentizacion de CPU. Los datos de campo provienen de usuarios reales a traves del Chrome User Experience Report (CrUX). Las puntuaciones que ves al ejecutar Lighthouse en Chrome DevTools son datos de laboratorio. Las puntuaciones que Google usa para fines de ranking (Core Web Vitals) provienen de datos de campo. Esta distincion es importante porque los resultados de laboratorio y de campo a menudo difieren significativamente, y optimizar para uno no siempre mejora el otro.

Para las tiendas PrestaShop, Lighthouse es particularmente revelador porque la configuracion predeterminada de PrestaShop y la mayoria de los temas no estan optimizados para los estandares de rendimiento modernos. Una tienda PrestaShop tipica sin optimizar obtiene entre 15 y 40 en Rendimiento, de 60 a 80 en Accesibilidad, de 70 a 85 en Buenas Practicas y de 75 a 90 en SEO. Estas puntuaciones base te indican donde se encuentran las mayores oportunidades de mejora.

Puntuacion de Rendimiento: La categoria mas compleja

La puntuacion de Rendimiento es un compuesto ponderado de seis metricas. Cada metrica captura un aspecto diferente de la velocidad de carga e interactividad de la pagina. Comprender las metricas individuales es mucho mas util que centrarse en el numero general.

Largest Contentful Paint (LCP)

LCP mide cuando el elemento de contenido visible mas grande termina de renderizarse. En una pagina de producto PrestaShop, esto suele ser la imagen principal del producto. En una pagina de categoria, podria ser la primera imagen de producto o un banner de categoria. Google considera LCP bueno cuando esta por debajo de 2,5 segundos, necesita mejora entre 2,5 y 4 segundos, y deficiente por encima de 4 segundos.

Los problemas de LCP especificos de PrestaShop incluyen imagenes de productos sobredimensionadas servidas sin un dimensionamiento responsivo adecuado, CSS que bloquea el renderizado de modulos que se cargan en cada pagina, tiempos de respuesta del servidor ralentizados por consultas de base de datos no optimizadas (especialmente en paginas de categoria con muchos productos) y JavaScript de modulos de terceros que retrasa el proceso de renderizado.

Para mejorar LCP en PrestaShop, comienza con la optimizacion de imagenes. Asegurate de que las imagenes de productos esten correctamente dimensionadas para cada contexto (no sirvas una imagen de 2000x2000 cuando el area de visualizacion es de 400x400). Habilita la carga diferida para imagenes debajo del pliegue, pero asegurate de que la imagen LCP NO tenga carga diferida, ya que esto retrasa su renderizado. Implementa indicaciones de precarga para la imagen LCP usando una etiqueta <link rel="preload"> en el encabezado de la pagina. En el lado del servidor, habilita OPcache, configura el almacenamiento en cache de consultas MySQL y asegurate de que tu alojamiento tenga recursos adecuados.

Cumulative Layout Shift (CLS)

CLS mide la estabilidad visual. Cada vez que un elemento visible cambia de posicion despues de renderizarse inicialmente, contribuye a la puntuacion CLS. Google considera CLS bueno cuando esta por debajo de 0,1, necesita mejora entre 0,1 y 0,25, y deficiente por encima de 0,25.

Las tiendas PrestaShop sufren comunmente de CLS causado por imagenes que se cargan sin dimensiones definidas (el navegador no sabe cuanto espacio reservar, por lo que el contenido salta cuando la imagen se carga), fuentes web que se cargan y causan redistribucion del texto (FOUT, Flash of Unstyled Text), banners o barras de notificacion inyectados dinamicamente por modulos, banners de consentimiento de cookies que empujan el contenido de la pagina hacia abajo, e imagenes de productos con carga diferida en cuadriculas que desplazan los productos circundantes cuando aparecen.

Corregir CLS en PrestaShop requiere establecer atributos explicitos de width y height en todas las imagenes (o usar CSS aspect-ratio), precargar fuentes web criticas con font-display: swap o font-display: optional, reservar espacio para elementos dinamicos como banners de cookies usando CSS min-height, y asegurarse de que los modulos publicitarios o promocionales inyecten contenido sin desplazar los elementos existentes.

First Contentful Paint (FCP)

FCP mide cuando aparece el primer fragmento de contenido en la pantalla. Esto podria ser texto, una imagen, un SVG o un elemento canvas. Para PrestaShop, FCP esta fuertemente influenciado por el tiempo que tarda el servidor en responder (Time to First Byte) y la cantidad de recursos que bloquean el renderizado (CSS y JavaScript) que deben descargarse antes de que el navegador pueda pintar algo.

La configuracion predeterminada de PrestaShop carga una cantidad significativa de CSS y JavaScript de forma sincrona en el encabezado de cada pagina. Cada modulo instalado puede agregar sus propios archivos CSS y JavaScript. Una tienda con 30 modulos podria cargar de 15 a 25 archivos CSS separados y de 20 a 30 archivos JavaScript antes de que aparezca cualquier contenido. Esto aumenta directamente el FCP.

Total Blocking Time (TBT)

TBT mide el tiempo total entre FCP y Time to Interactive en el que el hilo principal estuvo bloqueado lo suficiente como para impedir la capacidad de respuesta a la entrada. Cualquier tarea mas larga de 50 milisegundos tiene su tiempo excedente contado en el TBT. Por ejemplo, una tarea de 200 milisegundos contribuye con 150 milisegundos al TBT.

Las tiendas PrestaShop son conocidas por valores TBT altos. Los culpables comunes incluyen jQuery y sus plugins ejecutandose de forma sincrona, JavaScript de modulos que realiza manipulaciones pesadas del DOM al cargar la pagina, codigo de analitica y seguimiento de multiples modulos, scripts de paginas de producto que inicializan sliders, funcionalidad de zoom y selectores de combinaciones simultaneamente, y widgets de chat e incrustaciones de redes sociales.

Reducir TBT requiere diferir JavaScript no critico, dividir tareas largas en fragmentos asincronos mas pequenos, eliminar JavaScript no utilizado de modulos y cargar widgets de terceros despues de que la pagina se vuelva interactiva.

Speed Index

Speed Index mide que tan rapido se llena el area visible de la pagina. Captura la progresion visual general de la carga de la pagina. Una pagina donde el encabezado, la navegacion y la primera fila de productos aparecen rapidamente pero el resto se carga gradualmente tendra un Speed Index mejor que una pagina donde todo aparece de una vez despues de un largo retraso.

Para PrestaShop, Speed Index mejora cuando priorizas el renderizado del contenido visible sin desplazamiento (above-the-fold). Esto significa incluir CSS critico en linea (el CSS necesario para renderizar la porcion visible de la pagina sin desplazamiento), diferir imagenes debajo del pliegue y evitar JavaScript que bloquee el renderizado del contenido visible.

Interaction to Next Paint (INP)

INP reemplazo a First Input Delay (FID) como Core Web Vital en marzo de 2024. Mide la capacidad de respuesta de una pagina durante todo su ciclo de vida, no solo en la primera interaccion. Cada clic, toque y pulsacion de tecla se mide, y la peor latencia de interaccion (aproximadamente) se convierte en el valor INP. Google considera INP bueno por debajo de 200 milisegundos.

Las tiendas PrestaShop a menudo tienen un INP deficiente en las paginas de producto donde hacer clic en un atributo de combinacion activa una solicitud AJAX sincrona que bloquea la interfaz, en las paginas de categoria donde los clics en filtros facetados causan un procesamiento pesado de JavaScript, y en cualquier pagina donde el JavaScript de un modulo monopoliza el hilo principal durante la interaccion del usuario.

Puntuacion de Accesibilidad

La puntuacion de Accesibilidad evalua si tu pagina puede ser utilizada por personas con discapacidades, incluyendo aquellas que usan lectores de pantalla, navegacion por teclado u otras tecnologias de asistencia. Lighthouse comprueba elementos especificos de cumplimiento con WCAG 2.1 y asigna a cada uno un peso basado en el impacto en el usuario.

Problemas comunes de Accesibilidad en PrestaShop

La falta de texto alternativo en las imagenes es el problema mas frecuente. Las tiendas PrestaShop con miles de productos a menudo tienen productos subidos sin descripciones de texto alt. Lighthouse marca cada imagen sin un atributo alt. La solucion es agregar texto alt significativo a todas las imagenes de productos a traves del back office, lo que tambien beneficia al SEO.

El contraste de color insuficiente es extremadamente comun en los temas de PrestaShop. El disenador del tema puede haber elegido colores visualmente atractivos pero que no cumplen con la relacion de contraste minima WCAG de 4,5:1 para texto normal y 3:1 para texto grande. Los problemas tipicos incluyen texto gris claro sobre fondo blanco (a menudo usado para precios de productos, descripciones o enlaces en el pie de pagina), texto blanco sobre botones de color donde el color no es lo suficientemente oscuro, y texto de marcador de posicion en campos de busqueda.

Las etiquetas de formulario faltantes afectan a los formularios de busqueda, formularios de suscripcion al boletin y formularios de contacto de PrestaShop. Muchos temas usan texto de marcador de posicion como unica indicacion del proposito de un campo de entrada, pero los marcadores de posicion no son etiquetas accesibles. Cada entrada debe tener un elemento <label> asociado.

La jerarquia de encabezados incorrecta es comun cuando los temas saltan niveles de encabezado (pasando de <h1> a <h3>) o cuando los modulos inyectan contenido con niveles de encabezado que rompen el esquema del documento de la pagina.

Los atributos ARIA faltantes en elementos interactivos como menus desplegables, dialogos modales e interfaces de pestanas significan que los lectores de pantalla no pueden transmitir el proposito y estado de estos elementos a los usuarios.

Objetivos realistas de Accesibilidad

La mayoria de los temas PrestaShop con esfuerzo pueden alcanzar de 85 a 95. Un 100 perfecto es alcanzable pero requiere modificaciones en las plantillas del tema, que pueden sobrescribirse durante las actualizaciones. Concentrate primero en los elementos de mayor impacto: texto alt de imagenes, contraste de colores, etiquetas de formularios y navegacion por teclado para los flujos principales del usuario (navegar, agregar al carrito, finalizar compra).

Puntuacion de Buenas Practicas

La categoria de Buenas Practicas cubre senales generales de calidad en el desarrollo web: uso de HTTPS, evitar APIs obsoletas, ausencia de errores en la consola y encabezados de seguridad.

Problemas comunes de Buenas Practicas en PrestaShop

Los errores en la consola del navegador son marcados por Lighthouse. Las tiendas PrestaShop frecuentemente tienen errores de JavaScript por conflictos de modulos, llamadas a funciones jQuery obsoletas o solicitudes AJAX fallidas. Cada error en la consola reduce la puntuacion de Buenas Practicas. Revisa la consola del navegador en cada tipo de pagina (inicio, categoria, producto, carrito, finalizar compra) y corrige o suprime los errores.

Los encabezados de seguridad faltantes reducen la puntuacion. PrestaShop no establece encabezados como Content-Security-Policy, X-Content-Type-Options, Permissions-Policy o Referrer-Policy por defecto. Anadirlos a traves de tu .htaccess o la configuracion del servidor web mejora la puntuacion de Buenas Practicas y la postura de seguridad de tu sitio.

Las APIs obsoletas generan advertencias cuando temas o modulos PrestaShop mas antiguos usan APIs de JavaScript que los navegadores han declarado obsoletas. Ejemplos comunes incluyen document.write(), XMLHttpRequest sincrono y el listener del evento unload. Estos se encuentran tipicamente en modulos mas antiguos que no han sido actualizados para los estandares modernos de los navegadores.

El contenido mixto (cargar recursos HTTP en una pagina HTTPS) se marca severamente. Esto ocurre cuando los activos de modulos, fuentes externas o pixeles de seguimiento usan URLs HTTP. Asegurate de que todos los recursos se carguen a traves de HTTPS.

Las imagenes sin ancho y alto explicitos (lo que tambien afecta al CLS en Rendimiento) tambien se marcan aqui. Los temas PrestaShop que usan solo CSS para dimensionar imagenes sin establecer atributos HTML activan esta comprobacion.

Objetivos realistas de Buenas Practicas

Una tienda PrestaShop bien mantenida deberia apuntar de 90 a 100. La mayoria de los problemas de Buenas Practicas son sencillos de solucionar mediante la configuracion del servidor y la limpieza de modulos.

Puntuacion SEO

La auditoria SEO comprueba los requisitos basicos de SEO tecnico. Esta es la categoria mas facil para obtener una buena puntuacion porque las comprobaciones son directas y PrestaShop maneja muchas de ellas por defecto.

Que comprueba Lighthouse para SEO

La auditoria verifica que la pagina tenga una etiqueta <title> valida, una meta descripcion, una etiqueta meta viewport valida, que los enlaces tengan texto descriptivo (no solo "haz clic aqui"), que la pagina no este bloqueada para la indexacion, que las imagenes tengan atributos alt, que el documento tenga un hreflang valido si sirve multiples idiomas, que el tamano de fuente sea legible en moviles y que los objetivos tactiles (botones, enlaces) esten adecuadamente dimensionados y espaciados.

Problemas SEO comunes en PrestaShop

Las meta descripciones faltantes o duplicadas son comunes en las paginas de categoria, especialmente las generadas automaticamente. PrestaShop permite establecer meta descripciones por categoria y por producto, pero muchos propietarios de tiendas dejan estos campos vacios durante las importaciones masivas de productos.

El texto de enlace no descriptivo aparece cuando los temas usan texto generico como "Leer mas" o "Detalles" para los enlaces de productos sin contexto adicional. Tanto los lectores de pantalla como Lighthouse marcan estos enlaces.

Los objetivos tactiles pequenos afectan a los usuarios moviles. Los temas PrestaShop con cuadriculas de productos compactas en movil pueden tener enlaces y botones demasiado cercanos entre si o demasiado pequenos. Google recomienda un objetivo tactil minimo de 48x48 pixeles CSS con al menos 8 pixeles de espaciado entre objetivos adyacentes.

Los recursos bloqueados pueden hacer que Lighthouse informe que los archivos JavaScript o CSS son inaccesibles. Esto ocurre cuando robots.txt bloquea el acceso a los directorios de activos. El robots.txt predeterminado de PrestaShop a veces bloquea directorios que contienen archivos CSS o JavaScript necesarios para el renderizado.

Objetivos SEO realistas

Una tienda PrestaShop deberia apuntar de 90 a 100 en la auditoria SEO. La mayoria de los elementos son correcciones de configuracion simples. El unico desafio persistente es el texto alt de imagenes en tiendas con catalogos grandes e importaciones historicas que omitieron el texto alt.

Datos de laboratorio vs. datos de campo

Comprender la diferencia entre datos de laboratorio y de campo es critico para interpretar correctamente los resultados de Lighthouse y priorizar el trabajo de optimizacion.

Datos de laboratorio (Lighthouse)

Cuando ejecutas Lighthouse desde Chrome DevTools o la linea de comandos, crea un entorno simulado. Limita la conexion de red (tipicamente a una velocidad 4G lenta de aproximadamente 1,6 Mbps con 150ms de latencia) y ralentiza la CPU (tipicamente una ralentizacion de 4x). Este entorno simulado produce resultados consistentes y reproducibles pero no refleja la experiencia de ningun usuario real especifico.

Los datos de laboratorio son utiles para depurar problemas especificos, comparar resultados antes y despues de cambios de optimizacion e identificar cuellos de botella especificos en el proceso de carga. Pero las puntuaciones no deben tomarse como representacion de la experiencia real del usuario.

Datos de campo (CrUX)

El Chrome User Experience Report (CrUX) recopila datos de rendimiento reales de usuarios de Chrome que han optado por informar estadisticas de uso. Estos datos se agregan en el percentil 75, lo que significa que el valor informado representa la experiencia del 75 por ciento de tus usuarios que estan en ese umbral o mejor.

Los datos de campo son lo que Google realmente usa para las senales de ranking a traves de Core Web Vitals. Puedes ver tus datos de campo en Google Search Console en el informe Core Web Vitals, en PageSpeed Insights (que muestra tanto datos de laboratorio como de campo) y a traves de la API CrUX o el conjunto de datos BigQuery.

Por que difieren las puntuaciones

Las puntuaciones de laboratorio son tipicamente mas bajas que las puntuaciones de campo para las tiendas PrestaShop porque Lighthouse usa una limitacion agresiva. Una tienda en un servidor rapido con CDN podria obtener 35 en el modo laboratorio de Lighthouse pero tener metricas de campo perfectamente aceptables porque los usuarios reales en conexiones decentes experimentan la tienda mucho mas rapido que el entorno simulado 4G lento. A la inversa, las tiendas con problemas que solo se manifiestan en condiciones reales (errores de JavaScript de versiones especificas de navegador, ralentizaciones de widgets de terceros o latencia geografica para usuarios lejos del servidor) pueden tener mejores puntuaciones de laboratorio que de campo.

Que priorizar

Para fines de ranking en Google, prioriza los datos de campo y los Core Web Vitals (LCP, INP, CLS). Para la depuracion y el trabajo de optimizacion del desarrollador, usa datos de laboratorio porque son consistentes y proporcionan informacion diagnostica detallada. Si tus datos de campo muestran Core Web Vitals aprobados pero tu puntuacion de Rendimiento de laboratorio es 40, tus usuarios estan bien y Google no te penalizara. Si tu puntuacion de laboratorio es 90 pero los datos de campo muestran Core Web Vitals no aprobados, tienes un problema que las pruebas de laboratorio no estan capturando.

Objetivos de puntuacion realistas para PrestaShop

Establecer objetivos realistas previene el desperdicio de esfuerzo persiguiendo rendimientos decrecientes. Aqui estan los objetivos alcanzables para una tienda PrestaShop 1.7 u 8.x tipica.

Rendimiento: 50 a 75 (Movil), 80 a 95 (Escritorio)

Las puntuaciones de Rendimiento movil por encima de 75 son extremadamente dificiles para tiendas PrestaShop con paginas de producto ricas, multiples modulos y contenido dinamico. La simulacion movil con limitacion es severa. Una puntuacion de 50 a 65 en movil con Core Web Vitals aprobados en datos de campo es un buen resultado. Las puntuaciones de escritorio de 85 a 95 son alcanzables con optimizaciones estandar.

No persigas una puntuacion de Rendimiento movil de 100. El esfuerzo requerido para pasar de 70 a 100 en movil tipicamente implica eliminar funcionalidad que tu tienda necesita (zoom de imagenes de producto, actualizaciones dinamicas del carrito, selectores de combinaciones). En su lugar, concentrate en cumplir los umbrales de Core Web Vitals en datos de campo.

Accesibilidad: 85 a 95

Este rango es alcanzable con correcciones en las plantillas del tema y disciplina en el contenido. El esfuerzo continuo principal es asegurar que todos los nuevos productos tengan texto alt y que los nuevos modulos no introduzcan regresiones de accesibilidad.

Buenas Practicas: 90 a 100

Alcanzable con la configuracion del servidor, la limpieza de errores de consola y mantener los modulos actualizados. Esta puntuacion tiende a degradarse con el tiempo a medida que se anaden nuevos modulos, por lo que el monitoreo regular ayuda.

SEO: 90 a 100

El mas facil de alcanzar y mantener. La mayoria de los elementos son correcciones de configuracion unicas.

Lista de verificacion de mejoras accionables

Esta lista de verificacion prioriza las optimizaciones por impacto, comenzando con los cambios que producen las mayores mejoras de puntuacion con el menor esfuerzo.

Alto impacto, bajo esfuerzo

Habilita la funcion CCC (Combine, Compress, Cache) de PrestaShop en los ajustes de Rendimiento para fusionar y minimizar archivos CSS y JavaScript. Agrega atributos width y height a todas las imagenes en las plantillas del tema. Establece dimensiones explicitas en las imagenes de productos. Habilita el almacenamiento en cache del navegador mediante encabezados de cache apropiados en la configuracion del servidor. Comprime los recursos de texto con Gzip o Brotli. Elimina o desactiva modulos que no estes usando activamente. Agrega encabezados de seguridad a la configuracion del servidor.

Alto impacto, esfuerzo medio

Implementa la inclusion de CSS critico en linea para el contenido visible sin desplazamiento. Difiere JavaScript no critico con el atributo defer o async. Optimiza y dimensiona correctamente las imagenes de productos (sirve diferentes tamanos para diferentes contextos usando srcset). Precarga recursos criticos (imagen LCP, archivos de fuentes principales). Corrige todos los errores de la consola del navegador. Agrega el texto alt faltante a todas las imagenes de productos y categorias.

Impacto medio, mayor esfuerzo

Implementa un CDN para activos estaticos e imagenes. Cambia a un tema PrestaShop mas orientado al rendimiento si tu tema actual es fundamentalmente lento. Optimiza el rendimiento del lado del servidor (indices de base de datos, OPcache, Redis para cache). Implementa el servicio de imagenes WebP con respaldo JPEG. Audita y optimiza el JavaScript de modulos de terceros para el bloqueo del hilo principal.

Monitoreo a lo largo del tiempo

Una auditoria Lighthouse unica es menos valiosa que el monitoreo regular. Las puntuaciones cambian a medida que agregas productos, instalas modulos, actualizas temas y modificas configuraciones. Configura pruebas automatizadas de Lighthouse usando herramientas como la API de Google PageSpeed Insights, web.dev Measure o Lighthouse CI autoalojado. Ejecuta pruebas como minimo semanalmente y despues de cualquier cambio significativo en la tienda.

Rastrea tanto las puntuaciones generales como las metricas individuales. Una caida de la puntuacion de Rendimiento de 65 a 55 es preocupante, pero saber que fue causada por una regresion de CLS de un modulo de banner recien instalado es informacion accionable. Sin rastreo a nivel de metricas, estas adivinando las causas.

Presta especial atencion a los Core Web Vitals en Google Search Console. Google actualiza estos datos mensualmente, y cualquier regresion de "Bueno" a "Necesita mejora" o "Deficiente" puede afectar tus rankings de busqueda. Configura alertas para cambios en Core Web Vitals para que puedas responder antes de que el impacto se vuelva visible en los datos de trafico.