Crear mi sitio gratis

El banco de conocimiento Velocidad

Velocidad: los límites de Google y nuestro requisito

Las tres medidas que usa Google (Core Web Vitals), los límites de lo bueno, nuestro propio requisito para cada sitio que construimos (el contenido principal en menos de 0,7 segundos) y cómo probamos la velocidad de cada sitio.

2 min de lectura6 secciones6 fuentes

Tres medidas y sus límites#

Google mide cómo se percibe el sitio con tres medidas. La evaluación se hace en el percentil 75, es decir, cómo va en tres de cada cuatro visitas [1]. Google usa las medidas en sus sistemas de experiencia en la página [2].

LCP: lo rápido que aparece el contenido principalBueno: como máximo 2,5 sNecesita mejorar: de 2,5 s a 4 sMalo: más de 4 s2,5 s4 sINP: lo rápido que responde la página a los clicsBueno: como máximo 200 msNecesita mejorar: de 200 ms a 500 msMalo: más de 500 ms200 ms500 msCLS: cuánto salta la páginaBueno: como máximo 0,1Necesita mejorar: de 0,1 a 0,25Malo: más de 0,250,10,25

✓ Bueno ! Necesita mejorar ✕ Malo

Mostrar como tabla
MedirBuenoNecesita mejorarMalo
LCPcomo máximo 2,5 s2,5-4 smás de 4 s
INPcomo máximo 200 ms200-500 msmás de 500 ms
CLScomo máximo 0,10,1-0,25más de 0,25
Fuente: web.dev (Google). Evaluado en el percentil 75 de las visitas reales.

De dónde salen las cifras#

Las cifras vienen del Chrome UX Report: datos anónimos de usuarios reales de Chrome que comparten estadísticas. Solo se incluyen los sitios con suficientes visitas, y Google no dice dónde está el umbral [3]. Si faltan datos de tu sitio, lo decimos. Nunca adivinamos una cifra.

Nuestro requisito: menos de 0,7 segundos#

Los límites de Google son un nivel mínimo. En los sitios que construimos y gestionamos exigimos más: el contenido principal debe aparecer en 0,7 segundos en un ordenador y el servidor debe responder en 0,2 segundos. En el móvil, donde Google supone una red 4G más lenta, la página debe superar con margen el límite de lo bueno de Google. Los requisitos se aplican tanto al nuevo diseño como a la copia del sitio actual del cliente [4] [5].

MedirEl límite de lo bueno de GoogleNuestro requisito para nuestros sitios
La respuesta del servidor (TTFB)como máximo 0,8 s (recomendación)como máximo 0,2 s
Aparece el primer contenido (FCP)como máximo 1,8 s (recomendación)como máximo 0,8 s
Aparece el contenido principal (LCP), ordenadorcomo máximo 2,5 scomo máximo 0,7 s
Aparece el contenido principal (LCP), móvil con 4Gcomo máximo 2,5 scomo máximo 2,5 s, objetivo 1,0 s
Respuesta al hacer clic (INP)como máximo 0,2 scomo máximo 0,1 s
Desplazamiento del diseño (CLS)como máximo 0,1como máximo 0,1, objetivo 0,02
Rendimiento en Lighthouse90+ se considera bueno90-100
SEO y accesibilidad en Lighthousesin requisito de Google95-100
LCP, INP y CLS son las Core Web Vitals de Google. TTFB y FCP son recomendaciones de Google, no requisitos de clasificación. Nuestros requisitos son objetivos técnicos que fijamos para tener margen; unas cifras perfectas no garantizan ninguna posición.

Cómo probamos la velocidad#

  • Cada sitio que construimos o mostramos en vista previa se prueba con PageSpeed Insights de Google, en móvil y ordenador, al menos una vez por semana y después de cada cambio. Un sitio que no cumple el requisito aparece al instante en nuestra operativa, con lo que hay que arreglar [6].
  • Cada sitio que analizamos, también el actual del cliente, se prueba de la misma manera. El comercial ve la cifra con su fuente, por ejemplo cuántos segundos tarda en aparecer el contenido principal en el móvil, comparada con el límite de Google.
  • Si el sitio tiene suficientes visitas, también mostramos la medición de Google de visitantes reales (el Chrome UX Report), que es la que usa Google [3].

Esto es lo que hacemos para que el sitio sea rápido#

  • La página se envía terminada desde el servidor, con los estilos más importantes directamente en la página, para que nada tenga que esperar a los scripts.
  • La imagen principal se obtiene primero y en el tamaño adecuado para la pantalla; las imágenes más abajo se cargan cuando el visitante se desplaza hasta ellas.
  • Las fuentes están en nuestro propio servidor, y un estilo de reserva con las mismas medidas evita que el texto salte cuando llega la fuente.
  • La página siguiente se obtiene por adelantado cuando el visitante señala un enlace, para que se abra al instante.
  • El trabajo de fondo en el servidor va siempre después de las páginas de los visitantes.
  • Mostramos la medición de Google en el análisis cuando existe, con fecha y fuente.

Imágenes#

Cómo deben nombrarse, describirse y cargarse las imágenes, y cuáles son los mitos sobre EXIF y GPS, está en Imágenes y nombres de archivo.

¿Qué tan rápido es tu sitio web?

El análisis gratuito mide la velocidad en móvil y ordenador.

0 SEK · sin registro · respuesta en un minuto aproximadamente

Siguiente temaCronología →Qué pasa el primer día, las primeras semanas y los primeros meses después de que nos hagamos cargo, y cuándo puedes esperar ver una diferencia.

Fuentes de esta página

  1. Web Vitals: métricas y umbrales web.dev (Google) · Documentación oficial
  2. Core Web Vitals y la Búsqueda de Google Google Search Central · Documentación oficial
  3. Chrome UX Report: metodología Chrome for Developers · Documentación oficial
  4. Largest Contentful Paint (LCP) web.dev (Google) · Documentación oficial
  5. Time to First Byte (TTFB) web.dev (Google) · Documentación oficial
  6. Acerca de PageSpeed Insights Google for Developers · Documentación oficial

Banco de conocimiento actualizado el 15 de octubre de 2026. ¿Has encontrado algo que no es correcto? Avísanos y lo corregiremos.