LCP, CLS, FCP, TTFB, INP, compresión Brotli, caché, minificación y HTTP/2: todo lo que necesitas saber sobre las 22 reglas de rendimiento que Google usa para posicionar tu web.
Resumen: El rendimiento web no es un detalle técnico que se atiende al final: es la base del ascenso. Un tiempo de carga lento, métricas Core Web Vitals en rojo y recursos sin comprimir lastre tu posicionamiento igual que una mochila mal cargada lastra a un montañero. Esta guía cubre las 22 reglas de rendimiento que auditan herramientas como SEOmator y Google Lighthouse, con umbrales reales, ejemplos de código y datos de una auditoría propia.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Antes de trazar la ruta, hay que conocer el terreno. Google lleva años incorporando métricas de velocidad a su algoritmo de ranking, y en 2021 hizo oficial que los Core Web Vitals son un factor de posicionamiento directo con el Page Experience Update.
La lógica es sencilla: una página lenta genera mala experiencia de usuario. El usuario la abandona antes de leer el contenido (rebote), Google lo registra y rebaja su posición en resultados. Tres consecuencias en cadena que penalizan el ascenso orgánico.
Los datos lo confirman: según un estudio de Google, cuando el tiempo de carga pasa de 1 a 3 segundos, la probabilidad de que el usuario abandone aumenta un 32 %. A 5 segundos, la cifra se dispara al 90 %.
El rendimiento también afecta al crawl budget: Googlebot dedica tiempo limitado a rastrear cada dominio. Las páginas lentas consumen más presupuesto de rastreo y dejan páginas sin indexar. En sitios grandes con miles de URLs, esto se convierte en un problema real de visibilidad.
Clave: el rendimiento no compite con el SEO; es SEO. Una web rápida es la base sobre la que se construye todo lo demás.
Los Core Web Vitals son el conjunto de métricas que Google usa para medir la experiencia real de usuario en tres dimensiones: carga, interactividad y estabilidad visual.
Qué mide: el tiempo hasta que el elemento de contenido más grande visible en el viewport (normalmente una imagen hero o un bloque de texto principal) queda completamente pintado.
| Resultado | Umbral |
|---|---|
| ✅ Bueno | < 2,5 s |
| ⚠️ Mejorable | 2,5 – 4,0 s |
| ❌ Malo | > 4,0 s |
Cómo mejorarlo:
<link rel="preload"> en el <head> para que el navegador descargue la imagen antes de parsear el HTML completo.<!-- Preload de la imagen LCP + fetchpriority -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="Descripción" width="1440" height="600" fetchpriority="high">Qué mide: la inestabilidad visual acumulada durante la carga. Cada vez que un elemento se desplaza inesperadamente (porque una imagen llega tarde y empuja el contenido), se suma al CLS.
| Resultado | Umbral |
|---|---|
| ✅ Bueno | < 0,1 |
| ⚠️ Mejorable | 0,1 – 0,25 |
| ❌ Malo | > 0,25 |
Cómo mejorarlo:
width y height en todas las imágenes: permite al navegador reservar el espacio antes de cargar el archivo.loading="lazy" a imágenes above the fold: causa el salto de layout en el elemento más visible.font-display: swap: evita que el texto se reposicione cuando carga la fuente personalizada.Qué mide: la latencia de respuesta a las interacciones del usuario (clics, taps, pulsaciones de teclado). Sustituyó a FID como métrica oficial en marzo de 2024.
| Resultado | Umbral |
|---|---|
| ✅ Bueno | < 200 ms |
| ⚠️ Mejorable | 200 – 500 ms |
| ❌ Malo | > 500 ms |
Cómo mejorarlo:
scheduler.yield().Qué mide: el tiempo hasta que el navegador pinta el primer elemento de contenido: texto, imagen o canvas. Es la primera señal visual de que la página está cargando.
| Resultado | Umbral |
|---|---|
| ✅ Bueno | < 1,8 s |
| ⚠️ Mejorable | 1,8 – 3,0 s |
| ❌ Malo | > 3,0 s |
Cómo mejorarlo:
<style> en el <head>. El resto del CSS puede cargarse de forma diferida.defer o async a los scripts que no son necesarios en la carga inicial.<!-- Preload de fuente web -->
<link rel="preload" href="/fuentes/inter.woff2" as="font" type="font/woff2" crossorigin>Qué mide: el tiempo desde que el navegador envía la petición HTTP hasta que recibe el primer byte de respuesta del servidor. Es una métrica de infraestructura: refleja el rendimiento del servidor, la red y la caché.
| Resultado | Umbral |
|---|---|
| ✅ Bueno | < 800 ms |
| ⚠️ Mejorable | 800 ms – 1,8 s |
| ❌ Malo | > 1,8 s |
Cómo mejorarlo:
La compresión reduce el tamaño de los recursos que viajan por la red antes de que lleguen al navegador. El navegador los descomprime localmente en milisegundos: es una de las optimizaciones con mejor ratio coste-beneficio disponibles.
Gzip lleva décadas siendo el estándar. Brotli (desarrollado por Google) ofrece una compresión un 20–30 % mejor que Gzip en archivos de texto, manteniendo la misma velocidad de descompresión. Brotli tiene soporte en el 98 % de los navegadores modernos.
| Tipo de archivo | Comprimible | Ahorro típico |
|---|---|---|
| HTML | Sí | 60–80 % |
| CSS | Sí | 70–85 % |
| JavaScript | Sí | 60–80 % |
| JSON / XML | Sí | 60–75 % |
| SVG | Sí | 50–70 % |
| Imágenes (WebP, AVIF, JPG) | No (ya comprimidas) | < 5 % |
| Fuentes WOFF2 | No (ya comprimidas) | < 3 % |
Cómo activar Brotli:
En Nginx:
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json image/svg+xml;En Apache (con mod_brotli):
AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascriptEn Cloudflare, Brotli se activa desde el panel sin configuración adicional en el servidor.
Verificación rápida: abre DevTools > Network, recarga la página y revisa la cabecera
Content-Encodingde los recursos HTML/CSS/JS. Si vesbr, Brotli está activo. Si vesgzip, está usando Gzip. Si no ves ninguno, la compresión está desactivada.
La caché permite que los recursos descargados en una visita se reutilicen en visitas posteriores sin volver a pedirlos al servidor. El resultado es una carga casi instantánea en visitas recurrentes y menor carga en el servidor.
# Recursos estáticos con hash en el nombre (se pueden cachear indefinidamente)
Cache-Control: public, max-age=31536000, immutable
# HTML: siempre revalidar
Cache-Control: no-cache
# Recursos sin hash: cachear con revalidación
Cache-Control: public, max-age=86400, must-revalidate¿Por qué distinguir entre HTML y estáticos? Los archivos CSS y JS en proyectos modernos llevan un hash en el nombre (main.a3f8c2.css). Si cambian, el hash cambia y el navegador descarga el nuevo archivo. Por eso se pueden cachear durante 1 año sin riesgo. El HTML, en cambio, no tiene hash y debe revalidarse en cada visita para servir la versión más reciente.
El servidor puede responder con una cabecera ETag que identifica la versión actual del recurso. En la siguiente visita, el navegador pregunta “¿sigue siendo válida esta versión?” con If-None-Match. Si nada ha cambiado, el servidor responde con un 304 Not Modified sin cuerpo, ahorrando casi todo el ancho de banda.
Un CDN no solo acerca los recursos geográficamente: también los cachea en los edge servers. La primera petición viaja hasta el origen; las siguientes se sirven desde el edge en milisegundos.
La minificación elimina todo lo que el navegador no necesita para ejecutar el código: espacios en blanco, saltos de línea, comentarios, nombres de variables largos (en JS) y propiedades redundantes (en CSS). El resultado es un archivo funcionalmente idéntico pero significativamente más pequeño.
Qué elimina la minificación:
Ahorros típicos:
| Recurso | Original | Minificado | Ahorro |
|---|---|---|---|
| CSS del framework | 150 KB | 45 KB | 70 % |
| Bundle JS principal | 800 KB | 280 KB | 65 % |
| Bootstrap CSS | 200 KB | 160 KB | 20 % |
Herramientas:
npm run build el output ya está minificado.Nota: la minificación actúa sobre el código ya generado. Combínala con la compresión Brotli/Gzip: ambas son complementarias y suman sus efectos.
HTTP/2 fue el mayor avance en el protocolo HTTP en 15 años. Su característica más relevante para el rendimiento web es el multiplexing: permite enviar múltiples recursos simultáneamente por una sola conexión TCP, eliminando el cuello de botella de HTTP/1.1 donde cada recurso abría su propia conexión.
Ventajas de HTTP/2 frente a HTTP/1.1:
| Característica | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Conexiones por dominio | 6 en paralelo | 1 (multiplexada) |
| Compresión de cabeceras | No | Sí (HPACK) |
| Priorización de recursos | No | Sí |
| Server Push | No | Sí |
HTTP/3 (basado en QUIC en lugar de TCP) va un paso más lejos: elimina el problema del head-of-line blocking de TCP y mejora el rendimiento especialmente en conexiones móviles con pérdida de paquetes. Su adopción está creciendo rápidamente: Cloudflare lo soporta de forma transparente.
Cómo verificar que usas HTTP/2: abre DevTools > Network y añade la columna “Protocol”. Si ves h2, tu servidor usa HTTP/2. Si ves h3, ya estás en HTTP/3. Si ves http/1.1, toca actualizar la configuración del servidor o mover el tráfico a través de un CDN moderno.
Implicación práctica: con HTTP/2, la técnica de “domain sharding” (repartir recursos en varios subdominios para abrir más conexiones paralelas) deja de ser útil e incluso puede ser contraproducente. Consolidar recursos en un solo dominio es la práctica correcta.
Más allá de los Core Web Vitals y las técnicas principales, hay un conjunto de buenas prácticas que las herramientas de auditoría revisan sistemáticamente.
Un DOM excesivamente grande (más de 1.500 nodos) ralentiza los cálculos de layout del navegador, consume más memoria y hace más lento el JavaScript que manipula el árbol. El objetivo es mantener el DOM por debajo de 800–1.500 nodos en páginas normales.
Los scripts y hojas de estilo en el <head> sin async o defer bloquean el renderizado hasta que se descargan y procesan. Reglas básicas:
<!-- CSS crítico: inline en <head> -->
<style>/* CSS above-the-fold */</style>
<!-- CSS no crítico: carga diferida -->
<link rel="stylesheet" href="no-critico.css" media="print" onload="this.media='all'">
<!-- Scripts: siempre defer o async -->
<script src="analytics.js" defer></script>Las fuentes web sin optimizar son una fuente frecuente de FCP lento y CLS. Buenas prácticas:
font-display: swap en la declaración @font-face: muestra el texto con la fuente del sistema mientras carga la web font.<link rel="preload" as="font">.Los GIFs animados pueden pesar varios MB. Un video equivalente en MP4 o WebM pesa un 80–95 % menos y ofrece mejor calidad. El truco:
<!-- Reemplaza el GIF con un video sin controles -->
<video autoplay loop muted playsinline>
<source src="animacion.webm" type="video/webm">
<source src="animacion.mp4" type="video/mp4">
</video>Cuando tu web carga recursos de dominios externos (Google Fonts, analytics, CDN de terceros), el navegador necesita establecer la conexión DNS + TCP + TLS antes de poder descargar el recurso. Puedes adelantar este trabajo con:
<!-- Preconnect: establece la conexión completa antes de necesitarla -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- dns-prefetch: solo resuelve el DNS (más ligero, para dominios menos críticos) -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">El peso total de la página (todos los recursos sumados) afecta directamente al tiempo de carga en conexiones lentas y datos móviles. Objetivo: < 1 MB en páginas de contenido normal, < 3 MB en páginas con mucho media.
En una auditoría reciente de rendimiento de escala14.com con SEOmator (categoría perf) obtuvimos un score de 91/A: 15 reglas superadas, 7 advertencias y 0 fallos críticos.
Qué pasó al 100 %:
font-display: swap y preloadÁreas de mejora identificadas:
googletagmanager.com: el script de GTM se carga desde un dominio externo sin preconnect declarado, lo que añade latencia de conexión innecesaria.fetchpriority="high": la imagen hero del header es el LCP candidate, pero no tiene fetchpriority ni <link rel="preload">. Añadir ambos reduce el LCP entre 0,2 y 0,5 s según el dispositivo.Dos cambios concretos, ambos implementables en menos de 30 minutos: añadir <link rel="preconnect" href="https://www.googletagmanager.com"> en el <head> y fetchpriority="high" en el <img> de la imagen hero.
Conocer las métricas es el primer paso; medirlas con las herramientas correctas es el segundo.
| Herramienta | Qué mide | Cuándo usarla |
|---|---|---|
| PageSpeed Insights | CWV con datos de campo (CrUX) + Lighthouse lab | Primera revisión y seguimiento periódico |
| Lighthouse (DevTools) | Análisis de laboratorio completo (score, oportunidades, diagnósticos) | Durante el desarrollo, antes de publicar |
| Search Console (CWV) | CWV de campo segmentados por URL y dispositivo | Monitorización continua de rendimiento real |
| WebPageTest | Waterfall detallado, filmstrip, comparativa A/B | Diagnóstico profundo de recursos concretos |
| SEOmator | 22 reglas de rendimiento + 251 reglas SEO completas | Auditoría técnica integral del dominio |
| Chrome UX Report (CrUX) | Datos de campo reales de usuarios de Chrome | Validar que los cambios mejoran la experiencia real |
Datos de laboratorio vs. datos de campo: Lighthouse mide en condiciones controladas (conexión simulada, sin caché, dispositivo estándar). Los datos de campo del CrUX reflejan experiencias reales de usuarios reales. Ambos son útiles, pero para el ranking de Google solo cuentan los datos de campo cuando hay suficiente volumen. En sitios con poco tráfico, Google usa los datos de laboratorio como referencia.
Core Web Vitals
width y height; sin contenido que cause desplazamiento).Compresión y transferencia 6. Brotli (o Gzip como mínimo) activo en todos los recursos de texto (HTML, CSS, JS, JSON). 7. Imágenes en formato moderno (WebP/AVIF); ningún JPG o PNG sin justificación. 8. Peso total de página < 1 MB en páginas estándar. 9. Videos MP4/WebM en lugar de GIFs animados.
Caché 10. Recursos estáticos con hash sirven con Cache-Control: max-age=31536000, immutable. 11. HTML con Cache-Control: no-cache para garantizar la versión más reciente. 12. CDN configurado para cachear respuestas en el edge.
CSS y JavaScript 13. CSS y JS minificados en el build de producción. 14. Sin recursos que bloqueen el render (scripts con defer o async; CSS crítico inline). 15. Bundle JS inicial < 150 KB gzip.
Conexión y protocolo 16. HTTP/2 activo (verificado en la columna Protocol de DevTools). 17. <link rel="preconnect"> para todos los dominios externos de recursos críticos. 18. fetchpriority="high" y <link rel="preload"> en la imagen LCP candidate.
¿Cuánto afecta realmente el rendimiento al posicionamiento en Google? El rendimiento es un factor de ranking confirmado desde el Page Experience Update de 2021. Sin embargo, Google lo pondera junto a la relevancia del contenido: una página muy relevante con rendimiento mediocre puede posicionarse por encima de una rápida pero con contenido pobre. El rendimiento desempata cuando el contenido es comparable entre competidores.
¿Con qué frecuencia debo medir los Core Web Vitals? Search Console actualiza los datos de CWV periódicamente. Una buena práctica es revisar el informe de CWV en Search Console una vez al mes, y después de cualquier cambio significativo en el sitio (rediseño, nuevo JS de terceros, cambio de hosting). PageSpeed Insights lo puedes lanzar en cualquier momento para una revisión puntual.
¿Qué es más importante: el score de Lighthouse o los datos de campo del CrUX? Para el ranking de Google, los datos de campo (CrUX) son los que cuentan. El score de Lighthouse es útil para diagnosticar y guiar mejoras, pero un score de 100 en Lighthouse no garantiza que los usuarios reales experimenten un LCP por debajo de 2,5 s. Usa Lighthouse para optimizar y CrUX para verificar.
¿Brotli o Gzip? ¿Cuál implemento primero? Si tu servidor o CDN soporta Brotli, actívalo: ofrece un 20–30 % más de compresión sin coste adicional en descompresión para el navegador. Brotli tiene soporte en el 98 % de los navegadores modernos. Gzip sigue siendo el fallback correcto para clientes que no soportan Brotli, pero en la práctica hoy apenas quedan.
¿El rendimiento web es responsabilidad del desarrollador o del SEO? De ambos. El SEO técnico define los objetivos y los umbrales; el desarrollador implementa las mejoras. En la práctica, la mayoría de cambios de rendimiento (compresión, caché, minificación, HTTP/2) se configuran a nivel de servidor o en el pipeline de build, no en el código de la página. Por eso es fundamental que el equipo técnico y el equipo SEO trabajen juntos en la misma expedición.
¿Una web con Astro tiene buen rendimiento automáticamente? Astro genera HTML estático por defecto, lo que da un TTFB naturalmente bajo y elimina JavaScript innecesario en el cliente (Islands Architecture). Pero no es magia: sigues necesitando comprimir correctamente en el servidor, configurar la caché, optimizar imágenes y añadir preconnect para recursos externos. El framework te da una base sólida; tú afinas el equipamiento.
El rendimiento web es el terreno sobre el que se construye todo lo demás. Sin una base sólida de velocidad, las mejoras de contenido, la estructura de enlaces internos y la autoridad de dominio rinden por debajo de su potencial. Es como intentar llegar a la cima con equipo en mal estado: el esfuerzo existe, pero no se traduce en avance real.
Las 22 reglas que cubren herramientas como SEOmator no son una lista arbitraria de tecnicismos: son los factores que determinan si tu web sube o baja en los resultados de búsqueda. Auditarlos, entenderlos y aplicarlos es parte del equipamiento de cualquier proyecto que quiera conquistar las primeras posiciones.
Solicitar auditoría SEO gratuita → Ver servicios SEO → Cómo optimizar imágenes para SEO → URLs canónicas e indexación SEO →
Al encargar una web nueva todos miran el diseño y nadie pregunta por la velocidad. Y es una decisión de cimientos: arreglarla después suele costar rehacerla. Esto es lo que debes exigir desde el primer día.
Una web lenta no solo frustra a tus visitantes: Google la penaliza y la baja en resultados. Descubre cómo medirlo tú mismo en 2 minutos y qué hacer si suspende el test.
Aprende a auditar las 13 reglas críticas de JavaScript rendering en SEO: DOM renderizado, diferencias entre HTML crudo y renderizado, detección de SSR, recursos bloqueados y modificaciones post-render. Guía técnica con ejemplos de código y checklist accionable.
/ Volver al campamento
Más de 20 artículos publicados sobre SEO, diseño web y marketing digital, con datos reales y reglas auditables.