Saltar al contenido
Auditoría Lighthouse

¿Cómo rinde tu sitio? Comparalo con el nuestro.

Pegá tu URL y la auditamos en vivo con la API de Google PageSpeed (la misma que usa Lighthouse). Comparamos contra gitconnections.com — 96/100 mobile y 100/100 desktop — y te damos una lectura escrita por IA de qué cambiar primero.

Compará tu sitio con gitconnections.com

Usamos la API pública de Google PageSpeed. No guardamos tu URL. Cada audit tarda entre 15 y 40 segundos; Ambos los corre en paralelo.

Auditar como:
Nuestras métricas · 6 de junio de 2026 · commit 93af574

Esto es lo que sacó gitconnections.com

Auditamos nuestro propio sitio con la misma herramienta. Estos son los números reales — no demos.

96Performance
100Accessibility
100Best Practices
100SEO
3 corridas secuenciales

Las medidas detrás de la mediana

Lighthouse mobile tiene varianza de ±5 a 10 puntos entre corridas en el simulador (Slow 4G + 4× CPU throttle). Por eso reportamos la mediana, no un best run cherry-picked.

RunPerfLCPFCPTBTCLS
Run 1962.0 s1.2 s180 ms0
Run 2962.7 s1.0 s0 ms0
Run 3962.7 s1.0 s0 ms0
Mediana962.7 s1.0 s0 ms0
Core Web Vitals

Las métricas que Google usa para rankear

No todas pesan igual. Estas son las que mueven la aguja en Search Console, con los umbrales que Google considera buenos.

  • LCP2.7 s

    Largest Contentful Paint — cuánto tarda el contenido principal en ser visible.

    Bueno: ≤ 2.5 s · best run: 2.0 s

  • FCP1.0 s

    First Contentful Paint — primer pixel pintado.

    Bueno: ≤ 1.8 s · best run: 1.0 s

  • TBT0 ms

    Total Blocking Time — tiempo que la página bloqueó al usuario por JS.

    Bueno: ≤ 200 ms · best run: 0 ms

  • CLS0

    Cumulative Layout Shift — cuánto se mueven los elementos al cargar.

    Bueno: ≤ 0.1 · best run: 0

  • Speed Index1.2 s

    Velocidad percibida de pintado del viewport visible.

    Bueno: ≤ 3.4 s

De 75 a 96

Cómo llegamos acá

El baseline del sitio era 75 perf / 5.0 s LCP en Lighthouse mobile. Bueno-tirando-a-promedio, pero no competitivo. El plan: ganarle a un sitio rival que marcaba 87 / 3.0 s, sin sacrificar el carácter visual (parallax, pinned-scroll cinematic, video de hero en desktop, ornamento del arbolito que crece con el scroll).

Pasaron 8 commits a lo largo de una semana, en este orden de impacto:

  1. Self-hostear las imágenes de Unsplash (WebP, 3 tamaños) para evitar el handshake DNS+TLS extra.
  2. Matar la imagen grayscale de 144 KB que estaba detrás de una sección a opacity 0.14 (la cambiamos por un gradient radial CSS — indistinguible visualmente).
  3. Eliminar lenis (smooth-scroll lib). El CSS nativo scroll-behavior: smooth hace lo mismo, y Lenis lo estaba sobrescribiendo.
  4. Cambiar font-display: swap a fallback: el LCP deja de esperar a que llegue Sora.
  5. Sacar framer-motion: reemplazado por ~150 líneas de rAF custom + IntersectionObserver. Visual idéntico, mucho menos JS shippeado.
  6. Reducir Sora de 4 a 3 pesos (el 700 se usaba en 5 lugares de páginas no críticas y cae a 600 imperceptiblemente).
  7. Y el último — el más quirúrgico — convertir 3 secciones grandes (FAQ, Contact, Parallax) en Server outer + Client island. El árbol que React tiene que hidratar en el browser bajó dramáticamente. Esa sola operación movió la mediana de 86 → 96 perf y el TBT de 10 ms → 0 ms.

Cero deps runtime nuevas en todo el proceso. El código terminó más simple, no más complicado.

El recap completo (commit por commit, con diffs) vive en docs/performance-overhaul-2026-06.md en el repo.