El 13 de julio de 2026 pasamos kiwop.com por PageSpeed Insights y el informe móvil devolvió cinco resultados: 100 en Rendimiento, 100 en Accesibilidad, 100 en Buenas prácticas, 100 en SEO y 3/3 en Agentic Browsing, la categoría nueva que mide si los agentes de IA pueden usar una web. Con First Contentful Paint en 1,1 segundos, Total Blocking Time en 0 milisegundos y Cumulative Layout Shift en 0, emulando un móvil de gama media sobre una red 4G lenta.
No es una captura afortunada ni una página vaciada para la ocasión: es la web real que sirve nuestro negocio, y el resultado de decisiones de arquitectura que cualquier equipo puede copiar. En este artículo las contamos todas. Y como de capturas no hay que fiarse, puedes repetir el examen ahora mismo mientras lees.
Qué significan las cinco cifras
Las cuatro primeras son las categorías clásicas de Lighthouse, el motor de análisis de Google. Rendimiento mide la experiencia de carga real (LCP, TBT, CLS); Accesibilidad, que la web sea operable por cualquier persona y tecnología de asistencia; Buenas prácticas, la higiene técnica y de seguridad; SEO, que los buscadores puedan entenderla e indexarla.
La quinta es la novedad de 2026. Agentic Browsing llegó con Lighthouse 13.3 en mayo y mide otra cosa: si un agente de IA puede leer tu web y operar en ella, por ejemplo rellenar un formulario o seguir un flujo de compra. No da una nota sobre 100 sino un ratio de checks superados, y Google la marca como experimental. La mayoría de webs todavía no lo pasa; si quieres saber cómo está la tuya, hicimos un test gratuito de Agentic Browsing de dos minutos.
La receta: siete decisiones de ingeniería
1. El HTML llega con el contenido dentro
kiwop.com se sirve renderizado desde el servidor: el HTML que recibe el navegador (o el crawler, o el agente) ya contiene todo el contenido. Nada de esperar a que un framework de JavaScript pinte la página en el cliente. Esta sola decisión sostiene a la vez el Rendimiento, el SEO y la mitad del Agentic Browsing.
El cómo: Astro renderiza en el servidor (Node 24 y PM2 en clúster) y manda el HTML ya montado. Ni el contenido ni los enlaces dependen de que el navegador ejecute JavaScript, así que un crawler o un agente sin motor de JS lee la página entera igual que tú.
2. El elemento LCP es texto visible desde el primer frame
El error más común que vemos en auditorías: un hero con fade-in que retrasa justo lo que Google mide. Nuestro H1 es visible desde el primer fotograma, sin animaciones de entrada y sin esperar a la fuente (font-display evita el baile tipográfico). Resultado: Largest Contentful Paint en 1,7 segundos en un móvil emulado con red lenta.
El cómo: El H1 llega con su color final desde el primer frame (nada de opacity 0 con fundido de entrada) y la fuente usa font-display optional para que no haya reflow al cargar. El elemento que Google mide como LCP ya está pintado antes de que llegue el CSS decorativo.
3. Total Blocking Time 0: el JavaScript espera a que lo necesites
La página apenas ejecuta JavaScript en el arranque, y todo lo decorativo (animaciones, contadores, el fondo generativo del hero) se activa solo cuando el usuario interactúa o el elemento entra en pantalla. El hilo principal queda libre: 0 milisegundos bloqueados.
El cómo: El JavaScript de animaciones y contadores no se ejecuta en el arranque: se activa con requestIdleCallback o al entrar en pantalla. El hilo principal queda libre justo cuando Lighthouse mide el bloqueo, y el Total Blocking Time se queda en 0 ms.
4. CLS 0: nada salta
Todas las imágenes y embeds llevan dimensiones explícitas, lo que se inyecta tiene su espacio reservado y las fuentes cargan sin reordenar el texto. Un layout estable ya no es solo comodidad visual: con Agentic Browsing, un botón que se mueve es un clic de agente que falla.
El cómo: Cada imagen lleva width y height en el HTML, las fuentes reservan su espacio y nada se inyecta por encima de lo ya pintado. El layout no se mueve ni un píxel después del primer render.
5. Imágenes AVIF con negociación en el servidor
El HTML referencia la imagen clásica (.jpg) y es el servidor quien sirve la versión AVIF cuando el navegador la acepta. Mismo URL, entre un 60% y un 80% menos de peso, cero cambios en el código de la página.
El cómo: nginx guarda imagen.jpg.avif junto al original y, cuando el navegador manda Accept image/avif, lo sirve en su lugar con Vary Accept. El HTML nunca cambia: el src del img apunta siempre al .jpg y la negociación ocurre en el servidor. Un AVIF pesa la mitad que el JPEG equivalente.
6. Caché en capas delante del renderizado
Entre la base de datos y el visitante hay varias capas de caché (aplicación, render del servidor y CDN), cada una con su política de invalidación. El efecto práctico: casi todas las visitas reciben HTML ya cocinado, a milisegundos del usuario.
El cómo: Payload cachea en memoria, Redis guarda el render con stale-while-revalidate, nginx cachea el HTML del SSR y Cloudflare lo sirve desde el borde. El visitante casi nunca toca la base de datos: recibe bytes que ya estaban listos.
7. La accesibilidad tratada como interfaz de máquina
Labels en todos los campos, botones reales, jerarquía de encabezados sin saltos, landmarks y contraste AA. Es lo correcto para las personas y, además, es la interfaz que usan los agentes: navegan por el árbol de accesibilidad, no por los píxeles. El 100 de Accesibilidad y el 3/3 de Agentic Browsing salen del mismo trabajo.
El cómo: HTML nativo antes que divs, un solo h1 por página, label en cada campo, foco visible y contraste de 4,5:1 como mínimo. Lo mismo que hace la página usable con lector de pantalla la hace legible para un agente: la accesibilidad dejó de ser una capa cosmética.
El examen nuevo: cómo se pasa Agentic Browsing
La categoría audita cuatro frentes: accesibilidad orientada a agentes (names, labels, integridad del árbol), estabilidad de layout, presencia de llms.txt e integración con WebMCP, el estándar propuesto para declarar las acciones de tu web como herramientas que un agente puede invocar.
En nuestro caso, el 3/3 corresponde a los tres checks aplicables a la página: accesibilidad de agentes, estabilidad y llms.txt. WebMCP sigue en origin trial (Chrome 150 o superior) y es el siguiente paso natural para webs transaccionales: que un agente no tenga que adivinar dónde hacer clic para comprarte.
El siguiente escalón ya está sobre la mesa: WebMCP. En lugar de que el agente adivine cómo rellenar un formulario mirando el DOM, la web le ofrece herramientas declaradas (buscar, reservar, comprar) que puede llamar directo. Está en fase de origin trial y kiwop.com es de las primeras en prepararse. Agentic Browsing mide si un agente puede leer y moverse por tu web; WebMCP mide si puede operar en ella.
Cómo lo mides tú mismo
Nada de esto es opinión: se comprueba en dos minutos y sin registro.
- Abre PageSpeed Insights, pega tu URL y mira el informe móvil (es más exigente que el de escritorio y es el que cuenta).
- Para Agentic Browsing necesitas Lighthouse 13.3 o superior: en Chrome, DevTools, Lighthouse, marca la categoría Agentic Browsing y ejecuta.
- Ve el código fuente (Ctrl+U): si el texto principal está ahí sin ejecutar JavaScript, un agente lo leerá igual.
- Comprueba tu robots.txt y tu llms.txt: que no bloqueen a GPTBot, ClaudeBot ni PerplexityBot.
Si alguna de las cuatro categorías clásicas baja de 90, ya sabes por dónde empezar; las siete decisiones de la receta te dicen dónde mirar.
Lo que no hicimos
- Servir una versión ligera solo para el test: el informe es de la web real en producción, con analítica, chat y formularios funcionando.
- Esconder contenido a Lighthouse para inflar la nota: se llama cloaking y tarde o temprano se paga.
- Lazy-load del elemento LCP: es el error que más corregimos en auditorías, porque retrasa exactamente lo que Google mide.
La checklist si quieres replicarlo
- Contenido principal visible sin ejecutar JavaScript (compruébalo en el código fuente).
- robots.txt sin bloquear GPTBot, ClaudeBot ni PerplexityBot.
- llms.txt publicado en la raíz del dominio.
- Datos estructurados Schema.org del negocio (Organization, Service, Product, FAQPage).
- Jerarquía de encabezados limpia, landmarks y alt en las imágenes.
- Labels en todos los campos de formulario y botones semánticos.
- Dimensiones explícitas en imágenes y embeds: CLS por debajo de 0,1.
- Sin popups ni overlays que tapen el contenido al llegar.
- LCP por debajo de 2,5 segundos en móvil.
- Camino a la conversión sin registro forzoso ni CAPTCHA intermedio.
Preguntas frecuentes
¿De verdad sirve sacar 100 en PageSpeed Insights?
Sirve como señal, no como fin. El 100 correlaciona con unos Core Web Vitals buenos, y esos sí influyen en posicionamiento y conversión. Pero la nota es un medio: lo que importa es que la página cargue rápido para una persona real y que sea legible para un buscador o un agente. Un 100 conseguido con trucos que empeoran la experiencia no vale nada.
¿Qué es Agentic Browsing y en qué se diferencia del SEO?
Es la categoría que Lighthouse añadió en mayo de 2026 (versión 13.3). Mide si un agente de IA (ChatGPT, Claude o Perplexity operando un navegador) puede entender y recorrer tu web: nombres y etiquetas claros, contenido en el HTML, y robots y llms.txt que no lo bloqueen. El SEO clásico optimiza para el rastreo y el ranking; Agentic Browsing optimiza para que una IA pueda actuar en tu página, no solo indexarla.
¿Necesito rehacer toda mi web para llegar a 100?
Casi nunca. La mayoría de sitios pierden puntos por cuatro o cinco causas repetidas: un LCP con fundido de entrada, JavaScript pesado en el arranque, imágenes sin dimensiones y sin comprimir, y formularios sin labels. Se arreglan una a una. Rehacer la web solo tiene sentido cuando el problema es estructural, por ejemplo si todo el contenido se pinta con JavaScript en el cliente.
¿Una web WordPress puede sacar 100?
Puede acercarse, pero le cuesta más. El stack de plugins y temas suele arrastrar CSS y JavaScript que no usas, y ahí se van los puntos de Performance y de Total Blocking Time. Se llega lejos con caché, un tema ligero y podar lo que sobra; el 100 limpio y estable suele pedir una arquitectura pensada para rendimiento, como la que usamos en kiwop.com.
¿Qué significa el 3/3 de Agentic Browsing?
Que la página pasa los tres checks que le aplican de esa categoría: accesibilidad orientada a agentes, integridad del contenido en el HTML y acceso permitido a los rastreadores. No todas las auditorías aplican los mismos checks; en nuestro caso los tres relevantes están en verde.
¿Esto seguirá siendo válido dentro de un año?
Los fundamentos sí: HTML con el contenido dentro, poco JavaScript, imágenes ligeras y accesibilidad real llevan años siendo la base y lo seguirán siendo. Lo que cambia es la superficie de medida: Agentic Browsing es de 2026 y WebMCP viene detrás. Por eso construimos sobre principios, no sobre trucos: cuando llega la métrica nueva, ya la cumples.
¿Quieres estos números en tu web?
Empieza por el test de Agentic Browsing: dos minutos, sin registro, y sales con tu lista de huecos concreta. Si prefieres que lo midamos nosotros, la auditoría de IA te dice qué ven hoy los agentes y los modelos en tu web y en qué orden arreglarlo, y con el servicio GEO nos ocupamos de que la IA te cite y sus agentes puedan operar en tu web. Sin humo: el informe de PageSpeed delante, antes y después. Y si quieres que tu web sea la siguiente con estos números, habla con un arquitecto.