Gratis y centrado en la privacidad

Simulador de Rendimiento Web

Última actualización:

Estima una puntuación de rendimiento general a partir de métricas Core Web Vitals.

Se ejecuta localmente en su navegador. Sus datos no salen del dispositivo.

Que resuelve esta herramienta

Que resuelve esta herramienta

Usa esta herramienta antes de ejecutar Lighthouse o encargar una auditoría de rendimiento completa. Introduce los Core Web Vitals que has medido (o esperas) y modela cómo diferentes condiciones de dispositivo y red cambian la puntuación general simulada: para priorizar el trabajo de optimización en los factores que marcarán la diferencia para tus usuarios peor atendidos.

Valores de entrada

Resultados

Cómo interpretar la salida de la simulación

La puntuación es un modelo direccional: refleja cómo interactúan las métricas de entrada bajo el perfil seleccionado, no un sustituto de los datos de campo medidos. Úsala para priorizar y después valídala con Lighthouse o CrUX.

  • LCP tiene el mayor peso individual en el modelo porque refleja la carga del contenido más grande: mejorarlo normalmente mueve más la puntuación.
  • Las penalizaciones de INP se vuelven más prominentes bajo perfiles de CPU de gama baja, donde la duración de las tareas JavaScript amplifica el retraso.
  • CLS contribuye menos a la puntuación que LCP o INP pero puede empujar una página límite por debajo de un umbral.
  • El perfil de red multiplica el tiempo de carga efectivo: una página que puntúa bien en Lab/Cable puede puntuar significativamente peor en Móvil 3G.
  • Ejecuta la simulación en varias páginas, páginas de detalle de producto, páginas de artículo y páginas de categoría, no solo en la página de inicio, que suele ser la más rápida.

Supuestos

  • Las entradas son valores sintéticos y no reemplazan mediciones de campo reales de CrUX o datos RUM.
  • Los umbrales de puntuación son aproximaciones de la metodología de puntuación de Lighthouse y pueden no coincidir exactamente.

Siguiente paso

Explora el siguiente paso

Estima una puntuación de rendimiento general a partir de métricas Core Web Vitals.

Revisión editorial

Cómo se construyó esta página

Esta página combina la herramienta en vivo, ayuda de entradas, ejemplos trabajados y límites operativos para que Simulador de Rendimiento Web sea útil sin depender de anuncios.

Revisado por Klartext Tools frente al flujo actual de Simulador de Rendimiento Web el 2026-02-24.

Última actualización:

Usar con criterio

Supuestos

  • Las entradas son valores sintéticos y no reemplazan mediciones de campo reales de CrUX o datos RUM.
  • Los umbrales de puntuación son aproximaciones de la metodología de puntuación de Lighthouse y pueden no coincidir exactamente.

Alcance de la página

Qué cubre esta página

  • Cómo usar esta herramienta
  • Entradas y escenarios de ejemplo
  • Cómo interpretar la salida de la simulación
  • Casos de uso
  • Buenas prácticas
  • Por qué esto importa
  • Qué hace esta herramienta

Ejemplos trabajados

Página de escritorio bien optimizada

Buenos Core Web Vitals en una conexión por cable con un dispositivo de alta gama: una línea base para una página de marketing de carga rápida.

FCP
0,9 s
LCP
1,8 s
INP
80 ms
CLS
0,02
Red
Lab / Cable
CPU
Dispositivo alta gama

Puntuación de rendimiento alta: útil como punto de referencia antes de aplicar throttling móvil.

Cambia a Móvil 3G y Dispositivo gama baja después de cargar para ver cómo se degrada la puntuación con las mismas métricas.

Página móvil lenta con LCP alto

Una página con una imagen hero pesada y respuesta de servidor lenta, probada en un dispositivo de gama media con throttling 3G.

FCP
3,2 s
LCP
5,8 s
INP
320 ms
CLS
0,14
Red
Móvil 3G
CPU
Dispositivo gama media

Puntuación de rendimiento baja: muestra cómo LCP por encima de 4 segundos genera la mayor degradación bajo condiciones restringidas.

Reduce LCP a 2,5 s manteniendo las demás entradas fijas para aislar la contribución de LCP a la mejora de la puntuación.

Cómo usar esta herramienta

Introduce los Core Web Vitals de un Lighthouse reciente o de tus datos de campo CrUX. Usa mediciones reales en lugar de valores predeterminados para obtener resultados útiles en términos de orientación.

  1. Introduce FCP y LCP en segundos, INP en milisegundos y CLS como decimal.

  2. Selecciona el perfil de red que mejor representa a tu audiencia objetivo. Lab/Cable para benchmarks de escritorio, Móvil 4G o 3G para condiciones de campo realistas.

  3. Selecciona el perfil de CPU que coincide con el nivel de dispositivo que más te importa.

  4. Ejecuta la simulación y anota la puntuación principal y los indicadores de estado por métrica.

  5. Cambia una entrada a la vez para identificar qué métrica contribuye más a la degradación de la puntuación bajo el perfil seleccionado.

Entradas y escenarios de ejemplo

Prueba un escenario bien optimizado y un escenario móvil degradado para entender cómo el modelo de puntuación pondera cada métrica.

Página de escritorio bien optimizada

Buenos Core Web Vitals en una conexión por cable con un dispositivo de alta gama: una línea base para una página de marketing de carga rápida.

Entradas de ejemplo

FCP
0,9 s
LCP
1,8 s
INP
80 ms
CLS
0,02
Red
Lab / Cable
CPU
Dispositivo alta gama

Resultado de ejemplo: Puntuación de rendimiento alta: útil como punto de referencia antes de aplicar throttling móvil.

Cambia a Móvil 3G y Dispositivo gama baja después de cargar para ver cómo se degrada la puntuación con las mismas métricas.

Página móvil lenta con LCP alto

Una página con una imagen hero pesada y respuesta de servidor lenta, probada en un dispositivo de gama media con throttling 3G.

Entradas de ejemplo

FCP
3,2 s
LCP
5,8 s
INP
320 ms
CLS
0,14
Red
Móvil 3G
CPU
Dispositivo gama media

Resultado de ejemplo: Puntuación de rendimiento baja: muestra cómo LCP por encima de 4 segundos genera la mayor degradación bajo condiciones restringidas.

Reduce LCP a 2,5 s manteniendo las demás entradas fijas para aislar la contribución de LCP a la mejora de la puntuación.

Por qué esto importa

Las métricas de Core Web Vitals como LCP, INP y CLS tienen umbrales concretos que afectan al ranking de búsqueda y a la experiencia del usuario, pero los valores de laboratorio no siempre se traducen en rendimiento real de campo en redes lentas o dispositivos de gama baja. Esta herramienta simula cómo se comportan tus métricas de rendimiento bajo distintos perfiles de red y CPU para que puedas identificar riesgos de rendimiento y priorizar optimizaciones antes de publicar.

Buenas prácticas

  • Prioriza reducir el Time to First Byte antes de optimizar los tamaños de activos: el tiempo de respuesta del servidor afecta a todas las demás métricas posteriores.
  • Simula la carga en páginas de contenido representativas, no solo en la página de inicio: las páginas de producto y artículos suelen cargar significativamente más activos.
  • Usa presets de conexión que reflejen la distribución real de tu tráfico, no solo el nivel más rápido.

Casos de uso

  • Estima materiales antes de comprar para reducir desperdicio en el proyecto.
  • Compara escenarios en la obra y ajusta cantidades en tiempo real.
  • Crea planes de proyecto más claros con una lógica de cálculo transparente.

Continuar la auditoría de salud del sitio

Guías

  • Cómo validar robots.txt antes del lanzamiento de un sitio

    La mayoría de errores de robots en un lanzamiento se pueden evitar. El problema no es que robots.txt sea difícil. El problema es que los equipos lo revisan demasiado tarde, prueban demasiado poco o confunden unas cuantas URLs correctas con una política de rastreo segura.

  • Cómo verificar hreflang antes de un lanzamiento multilingüe

    Los errores de hreflang son costosos porque desperdician el trabajo de localización después del lanzamiento. Una versión multilingüe puede parecer estructuralmente completa y aún así fallar en la segmentación por idioma si los enlaces recíprocos, el mapeo de URLs o la disponibilidad de páginas no se comprueban antes de publicar.

Ver guías

Comparativas

  • Auditor de robots.txt vs probador de robots.txt

    Estas herramientas se solapan, pero responden preguntas distintas durante un lanzamiento. El auditor de robots.txt es mejor cuando necesitas revisar el archivo completo como una política. El probador de robots.txt es mejor cuando necesitas una respuesta clara para una URL concreta y un bot concreto.

  • Herramientas SEO de lanzamiento gratuitas vs. de pago para equipos pequeños

    Los equipos pequeños suelen llegar a un punto de decisión antes del lanzamiento: ¿son suficientes las herramientas basadas en navegador gratuitas o esta publicación justifica una suite SEO de pago? La respuesta honesta depende menos de la ideología y más de la escala, la responsabilidad y la cantidad de riesgo concentrado en la ventana de lanzamiento.

Ver comparativas

Herramientas y temas

Revisado por Klartext Tools

  • Revisado con el proceso editorial de Klartext Tools para flujos prácticos en el navegador.
  • Los supuestos y límites aparecen en la propia página antes de los bloques de apoyo a la decisión.
  • Incluye ejemplos y FAQ para contrastar el resultado con un segundo escenario.

Preguntas frecuentes

¿Es esto un sustituto de Lighthouse?
No. Es una simulación orientativa para planificación y priorización. Úsala para comparar escenarios con rapidez y después valídala con Lighthouse o con datos de campo de CrUX una vez que los cambios estén desplegados.
¿Qué métrica suele afectar más?
LCP e INP a menudo dominan la velocidad percibida y la capacidad de respuesta. LCP es más sensible al tamaño de las imágenes y los recursos que bloquean el renderizado; INP es más sensible a las tareas largas de JavaScript y la contención del hilo principal.
¿Cuál es la diferencia entre el perfil de red y el perfil de CPU?
El perfil de red simula la velocidad de conexión y la latencia; eso afecta a la rapidez con la que cargan los activos. El perfil de CPU simula la potencia de procesamiento del dispositivo; eso afecta a la rapidez con la que el navegador puede analizar, ejecutar JavaScript y responder a la interacción del usuario. Un dispositivo de gama media con 4G puede seguir produciendo un INP alto si el hilo principal está saturado de tareas de JavaScript.
¿Por qué mejorar FCP importa menos que mejorar LCP?
FCP marca cuándo aparece el primer contenido, pero LCP marca cuándo termina de cargarse el elemento visible más grande: lo que está mucho más estrechamente vinculado a la percepción de finalización de carga. El modelo de puntuación pondera LCP más fuertemente porque refleja mejor el sentido del usuario de si la página está lista para usar.
¿A qué valor de CLS debo aspirar?
El umbral de Google para una buena puntuación de CLS es 0,1 o inferior. Los valores entre 0,1 y 0,25 se consideran necesitan mejora. Por encima de 0,25 es deficiente. Las causas comunes de CLS alto incluyen imágenes sin dimensiones explícitas, banners inyectados dinámicamente y fuentes web que causan desplazamientos de diseño al intercambiarse.
¿Qué calcula Simulador de Rendimiento Web frente a un simulador rendimiento web online básico?
Simulador de Rendimiento Web está diseñado para un caso de uso concreto: Estima una puntuación de rendimiento general a partir de métricas Core Web Vitals. La herramienta está pensada para flujos de utilidades web y herramientas seo y mantiene resultados repetibles cuando trabajas con los mismos datos.
¿Qué entradas cambian más los resultados en simulador rendimiento web?
Empieza por FCP (segundos), LCP (segundos), INP (ms). Cambios pequeños en esos campos suelen mover más la salida, así que conviene comparar al menos dos escenarios antes de decidir.
¿Sirve Simulador de Rendimiento Web para comparar escenarios rápidamente?
Sí. Simulador de Rendimiento Web está pensado para comparar escenarios hipotéticos con rapidez y contrastar supuestos en el navegador sin salir del flujo de trabajo.

Recomendaciones entre categorías

Si el problema va más allá de esta categoría, estas herramientas de otras áreas te ayudan con el siguiente paso.