5 maneras para medir la velocidad de carga de un sitio web

Actualizado el 09/09/2026 — Este artículo fue actualizado con información reciente y secciones nuevas.

«Medir la velocidad de carga de un sitio web» es una búsqueda frecuente entre quienes administran una página en Argentina. La mayoría no sabe por dónde empezar: algunos corren PageSpeed Insights una sola vez y listo, otros usan tres herramientas a la vez y se quedan mirando números sin saber qué hacer con ellos. Esta guía te muestra cómo medir la velocidad de carga de una web con método, qué herramientas usar y qué hacer con los resultados.

La velocidad de carga de un sitio web es el tiempo que tarda una página en descargarse completamente desde que un usuario la solicita hasta que ve todo el contenido renderizado en su navegador. Se mide en segundos o milisegundos con métricas estándar como Time to First Byte (TTFB), First Contentful Paint (FCP) y Largest Contentful Paint (LCP), adoptadas por Google como Core Web Vitals desde 2021. Un tiempo óptimo está por debajo de 2,5 segundos de LCP; el promedio real en 2026 es 2,5 segundos en desktop y 8,6 segundos en mobile.

En pocas palabras: Para medir la velocidad de carga de tu sitio web usá PageSpeed Insights como punto de partida, y sumá GTmetrix o Pingdom si necesitás más detalle. Apuntá a cargar en menos de 2 segundos. Si tardás más de 3 segundos en mobile, estás perdiendo más de la mitad de tus visitas.

¿Cuál es el tiempo medio de carga de una página web en 2026?

El tiempo medio de carga de una página web es de 2,5 segundos en desktop y 8,6 segundos en mobile, según los benchmarks de rendimiento de 2026. Estos promedios representan lo que carga un sitio típico en condiciones de red típicas. Ambos valores superan el estándar recomendado de 2 segundos, lo que significa que la mayoría de los sitios en internet sigue siendo más lenta de lo que debería.

Cuando ves estos números es fácil pensar «si el promedio es 2,5 segundos en desktop, estoy dentro del promedio». Pero el promedio no es el objetivo, es el piso. Si tu sitio está en el promedio, estás en el grupo que pierde visitantes por lentitud junto a la mitad de la web. Tu referencia realista debería ser cargar en menos de 1,5 segundos en desktop y menos de 2,5 segundos en mobile.

En Argentina, donde predominan conexiones 4G y ADSL con latencia variable, el escenario mobile pesa más. Un sitio que tarda 2 segundos en desktop en un servidor de Estados Unidos puede tardar 4 o 5 segundos desde un celular en Buenos Aires con conexión mediocre. Por eso conviene alojar el sitio en un hosting con servidores en la región cuando el público es local.

Umbrales de Google para velocidad aceptable

Google define referencias explícitas para saber si tu sitio es «bueno», «necesita mejora» o «pobre» en velocidad de carga. Estos son los umbrales que usa el buscador para evaluar tu página:

• Carga completa ideal: Menos de 2 segundos. Por encima conviene optimizar; Google empieza a penalizar posiciones.
• LCP «bueno»: Hasta 2,5 segundos. Entre 2,5 y 4 segundos es «necesita mejora»; más de 4 segundos es «pobre».
• INP «bueno»: Hasta 200 milisegundos de respuesta ante clics. Entre 200 y 500 ms es «necesita mejora»; más de 500 ms es «pobre».
• CLS «bueno»: Hasta 0,1 de desplazamiento visual acumulado. Más de 0,25 es «pobre».
• TTFB objetivo: Por debajo de 0,8 segundos, según las guías técnicas de Google para desarrolladores.
• Zona de riesgo crítica: Más de 3 segundos de carga total en mobile. Ahí el abandono se dispara sin remedio.

¿Qué es la velocidad de carga y qué métricas la forman?

La velocidad de carga no es un número único, sino un proceso en etapas, y cada etapa se mide con una métrica distinta. Un sitio puede entregar el primer byte del HTML rápido (TTFB bajo) pero tardar en mostrar la imagen principal (LCP alto), o mostrar el contenido rápido pero responder mal a los clics (INP alto). Por eso hace falta medir varias métricas a la vez, no una sola.

Estas son las cinco métricas que necesitás conocer y que toda herramienta de medición reporta:

• TTFB (Time to First Byte): Mide cuánto tarda el servidor en devolver el primer byte de la respuesta HTML. Refleja la calidad del hosting, la configuración de caché y la distancia física del servidor respecto al usuario. Si tu TTFB supera 0,8 segundos, el hosting o la caché están fallando.
• FCP (First Contentful Paint): Marca el momento en que aparece el primer elemento visible en pantalla. Le dice al usuario que «algo está sucediendo». Un FCP bajo tranquiliza; uno alto da la sensación de sitio «muerto».
• LCP (Largest Contentful Paint): Registra cuándo se renderiza completamente el elemento más grande visible: normalmente una imagen destacada, un video o un titular. Es la métrica central de la velocidad percibida y Core Web Vital principal desde 2021.
• INP (Interaction to Next Paint): Mide cuánto tarda el navegador en responder cuando hacés clic en un botón, tocás un enlace o escribís en un formulario. Reemplazó a FID (First Input Delay) en marzo de 2024. Un INP alto se siente como un sitio «congelado».
• CLS (Cumulative Layout Shift): Cuantifica los saltos y desplazamientos inesperados del diseño durante la carga. Si los elementos se mueven después de renderizados, terminás clickeando el botón equivocado. Un CLS de 0,1 es bueno; 0,25 o más es inaceptable.

LCP, INP y CLS forman en conjunto los Core Web Vitals, la iniciativa de Google que traduce la velocidad en señales de ranking. Google calcula estas métricas con datos reales de navegadores Chrome en el mundo (Chrome UX Report), no solo con pruebas de laboratorio. Si tu sitio no aprueba los Core Web Vitals en datos reales, pierde posiciones en el buscador.

¿Por qué la velocidad de tu sitio impacta directamente en ventas y posicionamiento?

La velocidad de carga afecta tu negocio en tres frentes al mismo tiempo: ranking en Google, retención de visitantes y tasa de conversión. Un sitio lento pierde en los tres frentes a la vez, aunque tengas el mejor contenido del mercado.

1. Google rankea sitios rápidos por encima de sitios lentos

• Factor de ranking confirmado desde 2021: Los Core Web Vitals (LCP, INP, CLS) forman parte oficial de las señales de ranking de Google. No es opcional.
• La indexación mobile-first hace que el móvil cuente más: Google indexa primero la versión mobile de tu sitio. Si tu móvil es lento, perdés posiciones aunque el desktop sea rápido.
• Mejor experiencia, mejor posición: Google busca destacar las webs con navegación fluida y sin frustración. Si tu LCP es lento, quedás atrás de competidores más rápidos.
• El rebote alto es una señal negativa: Los porcentajes de rebote aumentan con tiempos de carga altos. Si la gente se va rápido, Google detecta baja calidad y baja tu posición.

2. El abandono sube exponencialmente después de 3 segundos

• 53% de abandono: Más de la mitad de los usuarios cierra una página que tarda más de 3 segundos en cargar, según investigaciones de Google sobre comportamiento móvil.
• Abandono en cascada: Incluso quien logra esperar la carga inicial tiende a irse si las transiciones dentro del sitio siguen siendo lentas.
• Sin segunda oportunidad: El usuario que abandona por lentitud rara vez vuelve. Probó tu sitio una vez, fue lento, y buscó en otro lado.
• El efecto es peor en mobile: En celulares la impaciencia es mayor. Si esperó más de 2 segundos, ya se fue.

3. En e-commerce, la velocidad se traduce directamente en dinero

• Amazon publicó históricamente: Cada 100 milisegundos adicionales de carga le costaban 1% de las ventas totales. Si estás 500 ms lento, perdés 5% de ingresos solo por ese motivo.
• Atención limitada del cliente: Para que alguien compre necesitás mostrar el producto rápido. Si tarda, pierde el foco y se va.
• Carritos abandonados se disparan: En tiendas online, cada segundo de demora en la página del carrito o del checkout se traduce en órdenes perdidas.
• El efecto es medible: Si acelerás tu sitio de 4 a 2 segundos, podés ver un aumento de conversión de entre 10% y 30% en el primer mes.

¿Qué porcentaje de sitios aprueba los Core Web Vitals en 2026?

El 55,9% de los sitios rastreados en internet supera simultáneamente los umbrales de LCP, INP y CLS, según el Chrome UX Report de mayo de 2026. Eso significa que casi 56 de cada 100 sitios aprueba. Suena bien hasta que pensás en la inversa: 44% de internet sigue siendo deficiente en velocidad y experiencia de usuario.

Estos números guardan matices importantes:

• Desktop vs mobile: La brecha sigue siendo enorme. Desktop tiene tasas de aprobación más altas; mobile sigue rezagado.
• Regresión en Android: El Chrome UX Report de 2026 detectó un retroceso de rendimiento en dispositivos Android: las páginas se hacen más pesadas y nadie optimiza a la par.
• No es un estado estable: Un sitio que aprueba hoy puede dejar de aprobar en tres meses si suma peso (scripts, imágenes, plugins) sin control.
• Si aprobás, ya estás adelante: Si tu sitio aprueba los tres Core Web Vitals, superaste a casi la mitad de la web. No es poco como punto de partida.

¿Cómo medir la velocidad de carga de una web paso a paso?

Para medir la velocidad de carga de una web con datos confiables hay que elegir bien la herramienta, medir la página correcta, separar mobile de desktop y repetir la prueba varias veces antes de sacar conclusiones. Estos son los pasos en orden:

• Elegí la herramienta correcta: Empezá por PageSpeed Insights. Es gratis, no requiere registro, y devuelve datos de campo reales (Chrome UX Report) más análisis de laboratorio (Lighthouse).
• Medí la página que importa: No midas la home por defecto. Medí la página que más genera conversiones o tráfico, o donde tenés productos clave. La home es el lugar obvio pero no siempre el crítico.
• Probá mobile y desktop por separado: Los resultados pueden diferir mucho. La mayoría de tus visitantes llega en mobile, así que ese resultado es prioritario.
• Repetí tres veces y promediá: Los servidores fluctúan. Corré tres mediciones, esperá 30 minutos entre cada una y promediá los valores antes de sacar conclusiones.
• Anotá las métricas clave en una hoja: Tiempo de carga total, LCP, INP, CLS. Son tu línea de base. Dentro de un mes volvés a medir y comparás contra estos números. Sin línea de base no sabés si mejoraste.
• No confundas field data con lab data: PageSpeed Insights muestra los dos. El field data son experiencias reales de usuarios de Chrome; el lab data es simulación sintética. Priorizá field data en las decisiones.

¿Cuáles son las herramientas para medir velocidad de carga más usadas en 2026?

Existen varias herramientas especializadas que analizan tu URL y devuelven tiempos, puntajes y recomendaciones accionables. Cada una tiene una fortaleza distinta, y usarlas en conjunto da un diagnóstico más confiable que confiar en una sola.

1. PageSpeed Insights de Google — el estándar obligado

PageSpeed Insights es la herramienta oficial de Google para medir velocidad web. Es el punto de partida obligado para cualquier diagnóstico.

• Puntaje de 0 a 100: Cuanto mayor, mejor. Pero el dato más útil está en el detalle, no en el número.
• Field data (datos de campo): Rendimiento real experimentado por usuarios de Chrome en el mundo, tomado del Chrome UX Report. Es el dato que Google usa para ranking.
• Lab data (datos de laboratorio): Simulación controlada generada con Lighthouse en condiciones fijas. Útil para detectar problemas técnicos concretos.
• Oportunidades de mejora: Lista accionable de qué corregir y cuánto tiempo ahorrarías con cada ajuste.
• Diagnósticos: Sección que explica los problemas detectados en lenguaje técnico pero accesible.

Es gratis, no pide cuenta ni credenciales, evalúa mobile y desktop por separado, y los datos son públicos. Si vas a usar una sola herramienta, que sea esta.

2. Pingdom — la cascada visual más clara

Pingdom es popular entre desarrolladores y webmasters por su capacidad de mostrar exactamente qué está frenando tu sitio.

• Vista en cascada (waterfall): Muestra el tiempo de carga de cada recurso individual: imágenes, scripts, hojas de estilo, fuentes.
• Peso de página y solicitudes: Te dice cuántos MB pesa tu página y cuántas requests hace. A veces el problema es que hay 150 requests cuando deberían ser 50.
• Ubicación de la prueba configurable: Podés elegir desde dónde simular la carga, aunque es simulación, no datos reales.
• Resultado visual fácil de interpretar: Pegás la URL y en segundos tenés el resultado, sin registro.

Usá Pingdom cuando PageSpeed Insights te diga que algo está lento pero no te quede claro qué es. La cascada de Pingdom lo hace obvio.

3. GTmetrix — análisis profundo con video de carga

GTmetrix funciona sobre Lighthouse (el motor de auditoría de Google) y genera informes que rivalizan con herramientas de pago.

• Puntajes de rendimiento separados: Estructura, estilo y JavaScript por separado, no solo un número general.
• Cascada de recursos: Como Pingdom, pero con más nivel de detalle.
• Video de carga: Ves frame a frame cómo carga tu página. Es invaluable para entender la experiencia visual real.
• Recomendaciones priorizadas: Qué arreglar primero para mayor impacto.
• Planes pagos con monitoreo: Útil si hacés cambios constantemente y necesitás seguimiento programado.

Requiere registro gratuito pero vale la pena. Es de las mejores opciones cuando necesitás entender el problema a fondo.

4. Monitis — perspectiva multiubicación

Monitis evalúa tu página desde varios puntos del mundo: América, Europa, Asia. Útil si tu audiencia está distribuida geográficamente.

• Resultados desde múltiples continentes: Ves cómo se comporta tu sitio según la ubicación del visitante.
• Detecta problemas regionales: Si tu sitio es rápido en Europa pero lento en América Latina, sabés dónde invertir en optimización o en CDN.
• Plan gratuito funcional: No necesitás pagar para empezar a usarlo.

5. Dotcom-Monitor — reportes detallados desde el mundo

Dotcom-Monitor permite analizar velocidad desde diferentes lugares del mundo y genera reportes con desglose de cada etapa de carga.

• Múltiples ubicaciones simultáneamente: Una sola medición desde cinco o más lugares de la web.
• Análisis detallado: Desglose paso a paso de la carga.
• Integración con alertas: En planes pagos, alertas automáticas si algo se degrada.

Extra: monitoreo continuo con DebugBear

Las cinco herramientas anteriores hacen pruebas puntuales, es decir, medís una vez. DebugBear suma otra capa: monitoreo continuo que alerta automáticamente cuando un cambio en tu sitio empeora la performance.

• Soluciona el problema clásico: Publicás un cambio, nadie mide nada, y 20 días después descubrís que el LCP subió a 5 segundos. Con DebugBear te enterás el mismo día del deploy.
• Alertas automáticas: Si una métrica degrada más que un umbral configurable, te avisa por mail o Slack.
• Histórico de mediciones: Ves gráficamente cómo evolucionó la velocidad mes a mes.
• Planes pagos con soporte: No tiene opción gratuita completa, pero el freemium permite monitorear una página.

¿Cuándo usar cada herramienta? Resumen práctico

Esta tabla resume para qué situación sirve cada una:

Regla de oro: Si todas las herramientas coinciden en el mismo problema, ese problema es real y crítico. Si solo una lo reporta, probablemente sea un falso positivo.

¿Field data o lab data? Qué importa realmente para Google

El field data importa más que el lab data para el ranking en Google, porque es el que refleja la experiencia real de tus usuarios y el que el buscador usa para evaluar Core Web Vitals. Desde junio de 2026, Google enfatiza explícitamente en sus guías técnicas priorizar field data en las decisiones de optimización. El lab data sirve sobre todo para debugging.

La diferencia entre ambos es clave:

• Field data (datos de campo): Experiencias reales de usuarios con Chrome, en distintos dispositivos, redes y ubicaciones geográficas. Es variado e impredecible. Google usa esto para evaluar tu sitio en Core Web Vitals.
• Lab data (datos de laboratorio): Se genera en condiciones controladas y repetibles: una conexión específica, un dispositivo específico, un navegador específico. Es reproducible pero no representa a toda tu audiencia.

La paradoja es que el lab data es más fácil de mejorar porque podés controlar las variables, pero si tu field data es malo, no importa cuánto mejores el lab data: Google rankea en base al field data.

¿Dónde consultás cada uno? PageSpeed Insights muestra los dos en el mismo informe: field data en la sección superior (si está disponible para tu página) y lab data en la sección de «Diagnósticos». Google Search Console también ofrece un informe de Core Web Vitals solo con field data, separado por página.

Nuestra recomendación: priorizá field data en tus páginas de conversión, las que generan ingresos directos. Usá lab data para encontrar la causa técnica cuando el field data salga mal. Son complementarias, no reemplazables.

Ejemplo práctico: de 7,4 segundos a 2,9 segundos de carga

Martina Rodríguez administra una tienda online de indumentaria femenina en Buenos Aires construida en WooCommerce. Notó que muchas visitas no completaban la compra y decidió medir la velocidad con PageSpeed Insights, GTmetrix y Pingdom de forma simultánea.

Los tres reportes coincidieron: la página principal tardaba 7,4 segundos en cargar completamente desde una conexión 4G en Argentina. PageSpeed le asignó un puntaje de 38/100 en mobile, señalando imágenes sin comprimir como principal culpable (2,1 MB en el hero banner, innecesario). También detectó scripts de terceros —analytics, chat, ads— que se cargaban de forma síncrona.

Con esos datos, Martina ejecutó tres cambios en orden de impacto:

• Compresión de imágenes: Redujo el hero banner de 2,1 MB a 310 KB usando WebP y compresión inteligente. Impacto: 3 segundos menos.
• Activó caché del servidor: Pidió al hosting que habilitara caché de objetos. Impacto: 1,5 segundos menos en visitas repetidas.
• Carga asíncrona de scripts: Postergó la carga de dos plugins de redes sociales que no eran críticos al inicio. Impacto: 0,5 segundos menos.

Al volver a medir con las mismas tres herramientas, el tiempo de carga bajó a 2,9 segundos y PageSpeed le asignó 74/100 en mobile. En el mes siguiente, la tasa de conversión creció un 18% respecto al mes anterior.

Lección: usar múltiples herramientas en simultáneo permitió identificar cuellos de botella concretos —imágenes, scripts— y validar cada mejora con números reales. Redujo 61% del tiempo de carga sin tocar una línea de código de diseño.

Los 7 errores que frenan la carga de tu sitio web

Medir es el primer paso; corregir es el segundo. Estos son los siete errores más comunes que frenan la velocidad de un sitio web y que aparecen una y otra vez en los diagnósticos.

1. Alojamiento web de mala calidad

Ahorrar dinero en hosting sale caro. Un servidor barato comparte recursos con cientos de otros sitios sin control: si uno de esos sitios consume CPU constantemente, tu sitio se ralentiza con él.

• Buscá hosting con discos SSD: Mejoran la velocidad de lectura y escritura respecto a los discos HDD antiguos.
• Priorizá servidores cerca de tu audiencia: Si tu público es argentino, un servidor local o regional reduce la latencia frente a uno alojado en otro continente.
• Evaluá el soporte técnico: Un hosting con soporte en español y horario local resuelve más rápido cuando algo se degrada. Donweb ofrece hosting con servidores locales y soporte en español, pensado justamente para minimizar este tipo de cuellos de botella.

2. Imágenes sin optimizar

• Es el error más frecuente: Subir fotos directo de la cámara o del celular, sin comprimir, agrega megas innecesarios a cada página.
• Usá formatos modernos: WebP o AVIF pesan bastante menos que JPG o PNG con calidad visual equivalente.
• Aplicá lazy loading: Cargar las imágenes fuera de pantalla recién cuando el usuario baja hasta ellas evita gastar tiempo de carga inicial en contenido que todavía no se ve.

3. Falta de caché configurada

• Sin caché, cada visita repite todo el trabajo: El servidor vuelve a generar la página desde cero en cada solicitud, en vez de servir una versión ya lista.
• La caché de página reduce el TTFB: Un plugin de caché o la caché a nivel de servidor devuelve el HTML ya armado, sin pasar de nuevo por la base de datos.
• La caché del navegador acelera visitas repetidas: Le dice al navegador que guarde ciertos archivos localmente para no volver a descargarlos.

4. Demasiados plugins y scripts de terceros

• Cada plugin suma su propio JavaScript y CSS: Un sitio con 30 plugins activos carga decenas de archivos adicionales, aunque la mitad de esos plugins casi no se use.
• Los scripts de terceros son los más difíciles de controlar: Analytics, chat en vivo, píxeles de publicidad; cada uno agrega una solicitud externa que puede demorar la carga si el servidor de terceros está lento.
• Auditá periódicamente qué está instalado: Desactivá o eliminá lo que no se usa. Menos plugins activos significa menos código para descargar y ejecutar.

5. No usar una red de distribución de contenido (CDN)

• Sin CDN, todos los usuarios piden al mismo servidor: Si tu audiencia está repartida geográficamente, los usuarios lejanos del servidor original sufren más latencia.
• Una CDN distribuye copias de tus archivos estáticos: Imágenes, CSS y JS se sirven desde el punto más cercano al usuario, no desde el servidor de origen.
• Es especialmente útil para sitios con tráfico internacional: Si vendés fuera de Argentina, una CDN achica la diferencia de velocidad entre visitantes cercanos y lejanos.

6. CSS y JavaScript sin minificar y bloqueando el renderizado

• Minificar reduce el peso del código: Elimina espacios, comentarios y caracteres innecesarios sin cambiar la funcionalidad.
• El CSS y JS «render-blocking» retrasan la primera pintura: Si el navegador tiene que descargar y procesar todo ese código antes de mostrar algo en pantalla, el FCP se dispara.
• Cargá el JavaScript no crítico de forma diferida: Con atributos como defer o async el navegador puede mostrar el contenido antes de ejecutar scripts secundarios.

7. No usar compresión de archivos ni HTTP/2

• La compresión Gzip o Brotli reduce el peso de la transferencia: El servidor comprime el HTML, CSS y JS antes de enviarlos, y el navegador los descomprime al recibirlos.
• HTTP/2 permite múltiples solicitudes en paralelo: Con el protocolo anterior, el navegador tenía que esperar turno para cada archivo; HTTP/2 los pide todos a la vez por la misma conexión.
• Confirmá que tu hosting lo tenga activado: No todos los planes de hosting habilitan compresión y HTTP/2 por defecto. Vale la pena preguntarlo antes de contratar.

¿Cómo medir la velocidad de mi sitio web gratis y sin instalar nada?

Podés medir la velocidad de tu sitio web gratis entrando a PageSpeed Insights, pegando la URL de tu página y presionando «Analizar», sin crear cuenta ni instalar software. El resultado tarda entre 20 y 40 segundos y devuelve puntaje, métricas Core Web Vitals y una lista de mejoras concretas.

• No necesitás acceso al servidor ni al código: Todas las herramientas de esta guía funcionan solo con la URL pública de tu página.
• Funciona desde cualquier dispositivo: Podés correr la prueba desde el celular mismo si querés un chequeo rápido.
• Combiná dos herramientas para confirmar el diagnóstico: Si PageSpeed Insights y GTmetrix coinciden en el mismo problema, es un problema real, no un error de medición puntual.

Preguntas frecuentes sobre velocidad de carga web

¿Cuánto debería tardar en cargar una página web?

Una página web debería cargar en menos de 2 segundos para considerarse rápida, y en menos de 2,5 segundos de LCP para aprobar el umbral «bueno» de Google. Por encima de 3 segundos en mobile, más de la mitad de los visitantes abandona antes de ver el contenido.

¿Cómo sé si mi sitio es lento?

Sabés que tu sitio es lento si PageSpeed Insights te da un puntaje bajo en mobile, si el LCP supera 2,5 segundos, o si el informe de Core Web Vitals de Google Search Console marca páginas en estado «pobre». Cualquiera de esos tres indicadores por separado ya es una señal de alerta.

¿Con qué frecuencia tengo que medir la velocidad de mi web?

Tenés que medir la velocidad de tu web al menos una vez por mes, y siempre después de instalar un plugin, cambiar de tema o subir imágenes nuevas en volumen. Medir solo cuando «algo se siente lento» llega tarde: para ese momento ya perdiste tráfico y conversiones.

¿La velocidad de carga afecta el SEO?

Sí, la velocidad de carga afecta el SEO porque los Core Web Vitals (LCP, INP, CLS) son señal de ranking oficial de Google desde 2021. Un sitio lento no solo pierde visitantes por abandono, también pierde posiciones frente a competidores más rápidos con contenido similar.

¿Qué diferencia hay entre velocidad de carga y Core Web Vitals?

La velocidad de carga es el concepto general —cuánto tarda tu página en mostrarse completa—, mientras que los Core Web Vitals son un subconjunto específico de tres métricas (LCP, INP, CLS) que Google eligió como estándar de ranking. Podés tener una velocidad de carga aceptable y aun así fallar en algún Core Web Vital puntual, como el CLS por saltos visuales.

¿Por qué mi sitio carga rápido en desktop pero lento en mobile?

Tu sitio carga distinto en mobile porque los celulares tienen menos capacidad de procesamiento que una computadora y suelen conectarse por redes 4G con más latencia que una conexión fija. El mismo peso de página que en desktop se procesa en un segundo, en un celular con conexión mediocre puede tardar el triple.

Medir la velocidad de carga de tu sitio no es un trámite que se hace una vez y se olvida. Es un chequeo recurrente, tan de rutina como revisar las ventas del mes. Con PageSpeed Insights como base, una segunda herramienta para confirmar el diagnóstico, y una línea de base guardada para comparar, vas a saber siempre si tu sitio va para adelante o para atrás en velocidad.