El punto de partida: medir antes de tocar
El error más común es optimizar a ciegas. Antes de cambiar una línea, corrí Lighthouse en PageSpeed Insights sobre la versión móvil — que es la que Google usa como señal primaria de ranking — y anoté las cinco categorías. Sin foto inicial no hay forma de saber si un cambio suma o resta. Esa disciplina de medir → cambiar → volver a medir es todo el método; el resto son detalles.
Lighthouse móvil, julio 2026. FCP 1,1s · LCP 1,7s · TBT 0ms · CLS 0. Corré el test vos mismo →
El proceso, paso a paso
No llegué al 100 de una. Fue iteración: cada aviso de Lighthouse se convertía en una tarea concreta. Este fue el orden real.
Medir el estado real
Correr el test, leer cada categoría y cada aviso — incluso los marcados "sin puntuar". El objetivo no es el número: es la lista de tareas que el reporte te regala.
Construir el piso técnico
HTML semántico con un solo H1, jerarquía de encabezados limpia, schema Person y Article completos, y Core Web Vitals en verde. Sin esta base, todo lo demás se construye sobre arena.
Hacer el contenido citable por la IA
Definiciones tempranas en la primera oración de cada sección, datos con fecha y fuente, un llms.txt válido y contenido atomizable. La IA cita lo que puede extraer sin ambigüedad.
Preparar el sitio para agentes
Árbol de accesibilidad bien formado, ARIA real en cada componente interactivo, CLS en cero y todo el contenido en el DOM desde el primer byte — sin render por JavaScript, que muchos agentes no ejecutan.
Perseguir cada aviso
Eliminar reflows forzados (usar ResizeObserver, no getBoundingClientRect en el init), purgar CSS muerto, diferir lo no crítico, pausar animaciones fuera de viewport. Cada corrida bajó un poco más el tiempo de bloqueo, de 644ms a 52ms.
El checklist, por capa
Esto es lo que hay que cumplir, ordenado por las tres capas. La clave que casi nadie ve: la mayoría de los ítems sirven a más de una capa a la vez. Optimizar bien es transversal, no aislado.
Que Google te indexe y rankee
- Un solo
<h1>por página y jerarquía de encabezados sin saltos. - Core Web Vitals en verde: LCP
<2,5s, INP<200ms, CLS<0,1en el percentil 75 de usuarios reales. - Schema.org completo y válido (Person, Organization, Article, FAQPage, BreadcrumbList según corresponda).
- Canonical, sitemap.xml referenciado desde
robots.txt, y meta description única por página. - Imágenes con
alt, dimensiones explícitas y formato moderno (WebP/AVIF). - E-E-A-T visible: autor con credenciales verificables, fuentes enlazadas, fechas.
Que la IA generativa te cite
- Definición citable temprana: la primera oración de cada sección responde la pregunta, extraíble sin contexto.
- Contenido atomizable: H2 que son preguntas reales, respuestas autocontenidas, datos con número y fuente.
- llms.txt válido en la raíz: con H1, links y extensión suficiente — no un archivo vacío.
- Entidad verificable: schema Person con
sameAsa perfiles y fuentes de terceros que confirmen quién sos. - Todo el contenido en el HTML, no inyectado por JS — muchos crawlers de IA no ejecutan JavaScript.
- Honestidad explícita: marcar lo que no está confirmado. La IA cita fuentes que matizan, no las que exageran.
Que los agentes puedan operarte
- Árbol de accesibilidad bien formado: cada elemento interactivo con nombre programático, roles y jerarquías válidos.
- ARIA real, no decorativo:
aria-expanded,role="tablist"y labels descriptivos que reflejen el estado verdadero. - CLS en cero: nada que se mueva entre que el agente identifica un elemento y el momento en que interactúa.
- llms.txt (comparte con GEO) y, si aplica a tu stack, WebMCP para exponer acciones.
- Navegación por teclado completa y foco visible — la misma base que sirve a lectores de pantalla.
Lo que hice distinto (y por qué)
Dos decisiones que van contra el consejo habitual, tomadas a propósito. Primero: cero frameworks. HTML, CSS y JS puro, todo inline en un solo archivo. Menos capas de abstracción es menos JavaScript bloqueando el hilo principal — por eso el TBT es 0ms. Segundo: no minifico el CSS. Lighthouse lo marca como mejora posible, pero el código legible es parte del producto: mi público lee el fuente, y Brotli ya comprime el archivo a una fracción. Optimizar no es obedecer cada aviso: es entender cuál aplica a tu caso.
Y una aclaración que prefiero hacer yo antes que un crítico: en un sitio estático de una página, el 100 es el escenario fácil — por eso acá funciona como piso demostrable, no como hazaña. La vara real no es este sitio contra un e-commerce: es este sitio contra los de quienes venden rendimiento y no pasan su propio test.
El resultado no es un truco de una tarde: es la misma entidad que el resto del sitio documenta. En términos del framework GEO-ABCD, esta excelencia técnica es la dimensión D — Data & Structure — que sostiene a las otras tres.
No hace falta que me creas. Corré el test sobre este sitio y después sobre el tuyo — el mismo diagnóstico con el que empecé.
Verificar este sitio en PageSpeed →¿Optimizar para Lighthouse mejora el ranking?
Con matiz, y conviene decirlo con precisión. Los Core Web Vitals sí son factor de ranking confirmado desde 2021, y Lighthouse los mide. Pero el puntaje 100 de Lighthouse no es el factor: Google rankea con datos de usuarios reales (CrUX, percentil 75, ventana de 28 días), no con el test de laboratorio. Lighthouse es la herramienta de diagnóstico; los Core Web Vitals de campo son la señal. Un 100 es la base técnica que te pone en condiciones — no la garantía de posición. Quien te venda "Lighthouse 100 = primer puesto" te está mintiendo; lo honesto es: es la T de E-E-A-T hecha número, el piso sobre el que compite el contenido.
