¿Puede la IA construir mi sitio web y también auditarlo?
Le pedí al nuevo Gemini 3.1 Pro que actuara como analista de mi sitio web.
Durante el último año, construí este sitio web utilizando asistentes de codificación de IA. Debido a eso, los agentes ya conocen todo mi código y la arquitectura de diseño.
También mantengo un panel de Looker Studio que rastrea las puntuaciones diarias de PageSpeed. Normalmente, mi flujo de trabajo es manual. Leo el panel, detecto una caída en el rendimiento y le pido a la IA que me ayude a corregir el código.
Cuando Google lanzó Gemini 3.1 Pro a través de Antigravity la semana pasada, quise probar una mejora multimodal específica. ¿Qué pasa si me elimino como intermediario? ¿Podría el modelo realmente ver un informe web interactivo en vivo, navegar por los gráficos como un analista humano y escribir su propia auditoría técnica?
Diseñé una prueba sencilla. El agente tenía que navegar por el panel, encontrar las métricas de rendimiento, escribir un informe de auditoría e implementar las correcciones propuestas directamente en el código.
La configuración
Construí un pipeline de análisis personalizado para este sitio usando GA4, BigQuery y Looker Studio. Parte de él es una auditoría diaria de PageSpeed. Una Google Cloud Function en Python lee mi sitemap, llama a la API de PageSpeed Insights siete veces por página y guarda los resultados en BigQuery. Las puntuaciones de rendimiento varían naturalmente entre ejecuciones. Para obtener una lectura estable, el panel muestra la mediana de esas 7 mediciones. Solo la métrica de Rendimiento tiene una dispersión amplia; las otras (SEO, Accesibilidad, Mejores Prácticas) son esencialmente deterministas.
Apunté un agente Gemini 3.1 Pro a la URL del informe y le di una directiva simple. Lee los gráficos, produce una auditoría técnica y verifica tus hallazgos contra el código. No proporcioné pistas.
Paso 1: Navegando por el panel
El primer obstáculo puso a prueba su razonamiento multimodal. Le di acceso a mi panel personal. Tenía que usar un navegador headless, entender el diseño visual y hacer clic en las pestañas correctas.
Abrió con éxito el informe de Looker Studio, hizo clic en la pestaña "Page speed" y navegó a la sección "Current state".
Encontrando correctamente la sección Page speed → Current state
El panel de PageSpeed con gráficos de Mejores Prácticas, SEO y Rendimiento
Paso 2: El incidente de la fecha
Un primer contratiempo ocurrió casi de inmediato. El panel tiene un filtro de rango de fechas. Sin ninguna instrucción, Gemini lo abrió y empezó a escribir. Introdujo "028" en el campo de desplazamiento, retrasando accidentalmente la ventana de datos 28 días. No le pedí que filtrara datos históricos. Este comportamiento proactivo fue un pequeño indicio de lo que vendría.
El modelo abrió proactivamente el filtro de fecha y escribió "028", expandiendo el alcance sin que se lo pidieran.
Después de mi corrección: filtro configurado limpiamente para el 22 Feb 2026 – 22 Feb 2026
Envié una corrección corta y aplicó la fecha correcta de inmediato. He notado esta diferencia de comportamiento al comparar Gemini con Claude. Gemini tiende a actuar fuera de sus instrucciones originales sin consultar. Claude suele pausar para pedir confirmación. Ningún enfoque es universalmente mejor, pero para tareas que involucran datos de producción en vivo, hay que tener esto en cuenta.
Aún así, en comparación con Gemini 3.0, la navegación fue una mejora masiva. El modelo anterior entraría en bucles infinitos con las capturas de pantalla o perdería por completo el rastro de la interfaz del informe. 3.1 Pro solo necesitó una corrección menor.
Paso 3: Leyendo los gráficos desplazables
Con la fecha configurada, la IA se desplazó por los gráficos de rendimiento. Esto incluyó la tabla interactiva "Performance breakdown (median)", que enumera cada ruta de página con puntuaciones específicas del dispositivo para Speed Index, FCP, LCP, CLS y TBT.
Leer esta tabla requiere desplazarse dentro de un elemento incrustado dentro de la página principal. Las versiones anteriores del modelo fallaban por completo en esta interacción específica.
La tabla de rendimiento desplazable que muestra el desglose por ruta y por dispositivo de todas las métricas de Core Web Vital.
El informe de auditoría
Basándose en los datos del panel, Gemini 3.1 Pro generó la siguiente auditoría técnica. Identificó los cuellos de botella, los calificó por gravedad y propuso soluciones.
↕ Desplázate dentro del cuadro para leer el informe completo
Resumen Ejecutivo
El sitio web demuestra excelentes capacidades base en Escritorio, pero sufre una degradación severa del rendimiento en páginas específicas de Móvil. Los principales cuellos de botella son el bloqueo excesivo del hilo principal (TBT) en páginas con componentes interactivos pesados y el renderizado visual retrasado (Speed Index) para usuarios móviles.
Métricas Clave de Rendimiento — 22/02/2026
| Página | Dispositivo | Puntuación | SI | FCP | LCP | TBT | CLS |
|---|---|---|---|---|---|---|---|
| /sac/ | Escritorio | 100 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| /sac/ | Móvil | 86 | 0.92 | 0.44 | 0.69 | 1.0 | 1.0 |
| /projects/ | Escritorio | 100 | 1.0 | 1.0 | 0.99 | 1.0 | 1.0 |
| /projects/ | Móvil | 78 | 0.98 | 0.81 | 0.22 | 1.0 | 1.0 |
| /projects/webanalytics/ | Escritorio | 60 | 0.0 | 0.99 | 0.99 | 0.0 | 1.0 |
| /projects/webanalytics/ | Móvil | 56 | 0.02 | 0.76 | 0.94 | 0.0 | 1.0 |
| /playlists/ | Escritorio | 60 | 0.02 | 1.0 | 0.99 | 0.0 | 1.0 |
| /playlists/ | Móvil | 55 | 0.0 | 0.89 | 0.81 | 0.03 | 1.0 |
| /projects/looker-studio-… | Escritorio | 62 | 0.23 | 0.98 | 0.98 | 0.0 | 1.0 |
| /es/ (inicio) | Móvil | 39 | 0.54 | 0.53 | 0.03 | 0.09 | 1.0 |
| /es/projects/ | Móvil | 70 | — | — | 0.01 | — | 1.0 |
Nota: CLS es perfecto (1.0) en todas las páginas; el diseño es estable en todas partes.
Hallazgos, por Prioridad
1. TBT Crítico — Muro de ejecución de JavaScript
Las páginas que incrustan iframes de terceros (/projects/webanalytics/, /playlists/, /projects/looker-studio-custom-visuals/) tienen una puntuación de TBT de 0.0. El hilo principal del navegador está completamente bloqueado durante la carga. Los usuarios no pueden desplazarse ni interactuar hasta que se despeja la carga de JS.
2. Speed Index — Síndrome de pantalla en blanco
El Speed Index en /projects/webanalytics/ y /playlists/ es cercano a 0.0, lo que significa que la página no muestra casi nada visible durante una larga ventana durante la carga. No hay pantallas de esqueleto ni revelación progresiva.
3. LCP Móvil — Página de listado de /projects/
/projects/ es un 100 perfecto en escritorio. En móvil, el LCP cae a 0.22. La sección hero contiene videos de reproducción automática e imágenes grandes no optimizadas servidas a resolución de escritorio.
4. Localización en Español (/es/) — Peores puntuaciones móviles
Al desplazarse por el gráfico, se observa que las rutas /es/ muestran LCP móviles catastróficamente bajos (0.01–0.03) y las peores puntuaciones generales de rendimiento. Hipótesis: una carga que bloquea el renderizado específica de la capa de localización.
Recomendaciones
Nivel 1 — TBT: Añadir lazy loading a los iframes. Usar IntersectionObserver para retrasar la inicialización hasta que el embed esté a la vista. Considerar un patrón Facade (mostrar una imagen estática, cargar el iframe al hacer clic).
Nivel 2 — Speed Index: Añadir pantallas de esqueleto para secciones pesadas. Poner en línea el CSS crítico.
Nivel 3 — LCP Móvil: Añadir srcset y sizes a las
imágenes hero. Precargar los fotogramas de póster de video con fetchpriority="high".
Paso 4: Verificando hipótesis en el código
A continuación, le pedí al agente que verificara sus suposiciones escaneando el código fuente real de Astro. Esto cerró el círculo perfectamente.
El agente identificó correctamente que el archivo
webanalytics.astro carga el
iframe de Looker Studio inmediatamente sin el atributo loading="lazy".
La página de playlists repite este error para el embed principal de Spotify.
El marcado incluye un spinner de carga. La solicitud del iframe se dispara inmediatamente debajo de él de todos modos. Esto obstruye la red antes de que el spinner pueda siquiera renderizarse limpiamente.
Las imágenes hero usan
fetchpriority="high" pero carecen de un atributo
srcset. El sitio sirve activos pesados de resolución de escritorio a
dispositivos móviles. Al póster del video de reproducción automática también le falta
una etiqueta de precarga.
Las páginas
/es/ son archivos Astro físicamente separados. Comparten una
estructura idéntica con las versiones en inglés. No hay un marco de localización pesado
ejecutándose en el lado del cliente. Las puntuaciones extremas de LCP en esas páginas
fueron probablemente ruido de medición de ese rastreo sintético específico, no un defecto del código.
Tres de cada cuatro hipótesis resultaron correctas. La cuarta fue falsificada correctamente. La IA miró datos reales, generó una explicación plausible pero errónea para las páginas en español, y luego corrigió su suposición cuando el código no la respaldaba.
Arreglos aplicados
Después de verificar los problemas, instruí al agente para que implementara los arreglos no disruptivos.
-
Añadido
loading="lazy"al iframe de Looker Studio en las páginas de análisis web en inglés y español. -
Añadidos atributos
widthsysizesresponsivos a las imágenes hero en las páginas de listado de proyectos. -
Precargado el póster del video usando una etiqueta
<link rel="preload">en el encabezado del documento.
Actualización (23 de febrero): Revisé el panel hoy para medir el impacto.
El TBT en la página webanalytics seguía siendo 0.0. Añadir loading="lazy" a
un iframe por encima del pliegue (above-the-fold) no impide que Lighthouse lo ejecute
ansiosamente. El navegador lo ve en el viewport inicial y lo descarga de inmediato. Una
solución verdadera requiere un patrón Facade, donde se renderiza una imagen estática
hasta que el usuario hace clic. Gemini sugirió esto como su recomendación principal en
la auditoría. Implementarlo rompería la experiencia interactiva inmediata de la página.
La IA diagnosticó con precisión el problema y propuso el arreglo matemáticamente
correcto, pero careció del juicio para sopesar las puntuaciones de rendimiento frente a
objetivos más amplios de experiencia del usuario.
Exploraciones de seguimiento
El panel de Looker Studio muestra la mediana de siete pruebas diarias por página. Para entender realmente el impacto en el rendimiento, tenemos que mirar la distribución completa. Le pedí a la IA que escribiera un script en Python para extraer los datos brutos de BigQuery y graficar la dispersión real de la Puntuación de Rendimiento y las métricas de TBT en ambos días.
22 de febrero: Se puede ver claramente la enorme variación en las puntuaciones de la página móvil /projects/webanalytics/.
23 de febrero: Después del "arreglo", la varianza en las páginas pesadas sigue siendo prácticamente idéntica.
Los boxplots muestran exactamente por qué falló el intento nativo de lazy loading. El hilo principal se bloquea consistentemente durante miles de milisegundos en cada ejecución. Un enfoque de Facade verdadero es la única forma técnica de evitarlo.
La verdadera lección aquí es el flujo de trabajo en sí. Un agente de IA puede leer tu código, acceder a tus datos analíticos en vivo y realizar sus propios experimentos para probar hipótesis como un analista humano.
22 de febrero: Dispersión de TBT inaceptable en las páginas pesadas con iframes.
23 de febrero: loading="lazy" nativo en contenido above-the-fold no
proporciona ningún alivio.
Reflexiones
Resultados de la auditoría
Los gráficos de distribución revelaron tres cosas que las puntuaciones medianas ocultaban.
- La base de Astro es sólida. Las páginas ligeras (como
/sac/o esta misma publicación del blog) se agruparon estrechamente alrededor de 90-100. La pérdida de rendimiento está totalmente aislada a los embeds de terceros. - El "fantasma de /es/" era solo ruido. La auditoría de Looker Studio originalmente marcó la página de inicio en español con una puntuación móvil catastrófica de 39. La distribución el 22 de febrero mostró una varianza masiva. Para el 23 de febrero, esa varianza desapareció y la puntuación se agrupó estrechamente en 85. Estábamos persiguiendo un fantasma nacido del jitter de la red.
- La varianza simplemente se desplazó. El día 22,
/sevilla/era el valor atípico inestable. El día 23, se estabilizó mientras que/playlists/se volvió salvajemente impredecible.
Cazar errores de rendimiento usando la puntuación mediana de un solo día es engañoso.
El panel me alertó sobre un problema de base. Pero solo mirando las distribuciones a lo
largo de varios días se ve la verdad. El marco es estable, pero los embeds de terceros
introducen picos de latencia masivos que las etiquetas nativas loading="lazy"
no pueden arreglar.
¿Puede Gemini 3.1 auditar mi sitio web?
Este experimento funcionó mejor de lo que esperaba para un primer intento. Resalta un flujo de trabajo que no había usado anteriormente: pedirle a la IA que interprete un informe en vivo, verifique sus hallazgos con el código y valide esas suposiciones usando distribuciones de datos brutos.
Sin embargo, el proceso también expuso fallas significativas. Gemini 3.1 está demasiado ansioso por actuar sin preguntar. Para tareas exploratorias de bajo riesgo, esto es aceptable. Para cualquier cosa que involucre datos de producción o despliegue, hay que imponer límites de alcance estrictos desde el principio.
La mayor desventaja es la falta de buenos criterios que tengan en cuenta el panorama general. Sus sugerencias técnicas se basan en una lógica sólida, pero carece por completo del juicio para darse cuenta de cuándo una base de código subóptima es un compromiso necesario para una mejor experiencia del usuario.
En general, el nuevo modelo muestra mejoras claras. Pero no hemos llegado al punto en el que podamos confiar en que estos agentes tomen decisiones importantes.