Medir Core Web Vitals
Los datos de campo de visitantes reales le avisan que hay un problema de rendimiento semanas después de que ya afectó el posicionamiento y las conversiones; una prueba de laboratorio le avisa antes de publicar. Este endpoint carga una URL en un entorno controlado y mide Largest Contentful Paint, Cumulative Layout Shift e Interaction to Next Paint tal como los experimentaría una visita real, cuando usted lo pida, sin esperar a que se acumule suficiente tráfico real para tener una señal.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
Por qué una prueba de laboratorio se gana su propio lugar junto a los datos de campo
Los datos de rendimiento de usuarios reales son la verdad de referencia, pero son necesariamente históricos: le dicen cómo se comportó una página para los visitantes que ya tuvo, lo que significa que una regresión solo aparece en los datos después de haberlos afectado. Una prueba de laboratorio invierte ese orden: mide una página en condiciones controladas y repetibles antes de que llegue a los visitantes reales, que es exactamente el momento en que una regresión de rendimiento resulta más barata de atrapar, justo antes de una publicación y no semanas después.
Las tres métricas y qué mide realmente cada una
Haga POST a /web/vitals con una URL, reciba un task_id de inmediato y obtenga las puntuaciones por webhook firmado o mediante un enlace firmado cuando la ejecución asíncrona termine. Largest Contentful Paint mide cuánto tarda en renderizarse el elemento visible más grande, y representa qué tan rápido se siente que una página cargó; Cumulative Layout Shift mide cuánto salta el contenido de forma inesperada mientras una página se estabiliza, y representa la estabilidad visual; Interaction to Next Paint mide qué tan receptiva se siente una página cuando alguien hace clic o toca algo, y representa la interactividad. Juntas cubren carga, estabilidad y capacidad de respuesta: tres formas distintas en que una página puede sentirse lenta aunque las otras dos estén bien.
De métrica interna a señal de posicionamiento
Estas tres métricas pasaron a formar parte formal de cómo los motores de búsqueda evalúan la experiencia de página porque se eligieron para reflejar lo que los usuarios realmente notan, y no números técnicos que correlacionan poco con la frustración real: una página que puntúa bien en las tres suele sentirse rápida y estable para un visitante real, no solo rápida en un cronómetro. Por eso vale la pena probarlas antes del lanzamiento: una regresión que eventualmente aparecería como un problema de posicionamiento ya es visible en una puntuación de laboratorio mucho antes de que existan suficientes datos de campo para confirmarla.
Su lugar dentro de un proceso de publicación
Los equipos que tratan el rendimiento como una compuerta de publicación corren esto sobre una URL de staging antes de cada despliegue, y otra vez en producción justo después, para atrapar regresiones causadas por una imagen nueva, un script agregado o un cambio de fuente antes de que los visitantes sientan la lentitud. Con precio por solicitud más por URL, probar un lote de páginas clave cuesta en proporción directa a cuántas se revisen, lo que hace práctico condicionar toda una publicación a las métricas en vez de revisar solo la página de inicio y esperar que el resto aguante.
Qué puede hacer con ella
Compuerta de rendimiento antes de publicar
Un equipo corre las métricas sobre una URL de staging antes de cada despliegue y bloquea la publicación si el LCP o el CLS retroceden más allá de un umbral acordado.
Verificación posterior al lanzamiento
Un equipo vuelve a revisar las métricas en producción justo después de una publicación para confirmar que el despliegue no introdujo un salto de diseño o una regresión de capacidad de respuesta que las pruebas anteriores no detectaron.
Prueba de impacto de scripts de terceros
Un equipo mide las métricas antes y después de agregar un nuevo script de analítica o publicidad para cuantificar su impacto exacto en la carga y la interactividad.
Comparación frente a la competencia
Un equipo de marketing prueba las métricas de páginas de la competencia junto a las propias para ver dónde un rediseño podría cerrar una brecha real de rendimiento.
Preguntas frecuentes
¿Cómo pruebo las Core Web Vitals con la API?
Envíe la URL de la página por POST a /web/vitals, guarde el task_id devuelto y reciba las puntuaciones de LCP, CLS e INP por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API de Core Web Vitals?
No, no hay plan gratuito ni prueba; cuesta $0.040 por solicitud más $0.001 por URL, y una tarea fallida nunca se cobra.
¿Son datos de laboratorio o datos de campo de usuarios reales?
Es una prueba de laboratorio ejecutada en un entorno controlado, que mide una página bajo condiciones consistentes en vez de agregar sesiones reales de visitantes.
¿Por qué una puntuación de laboratorio a veces difiere de los datos de campo?
Las pruebas de laboratorio corren bajo condiciones fijas mientras que los datos de campo reflejan la mezcla real de dispositivos, conexiones y ubicaciones de los visitantes reales, así que ambos se complementan en vez de ser intercambiables.
¿Qué mide INP en comparación con la antigua métrica FID?
INP mide la capacidad de respuesta de las interacciones a lo largo de toda la visita a una página y no solo la primera, dando una imagen más completa de cómo se siente usar la página.
¿Puedo probar varias páginas antes de una publicación?
Sí, tiene precio por solicitud más por URL, así que probar todo un conjunto de páginas clave antes de publicar escala en proporción directa a las páginas revisadas.
¿Ya está disponible este endpoint?
Sí, está en producción y aceptando solicitudes.
¿Se conservan los datos de la página probada después?
No, el contenido de la página y los resultados se eliminan después del período de retención y nunca se usan para entrenamiento.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/vitals \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/vitals", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/vitals",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/vitals", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/vitals", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://ejemplo.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.vitals",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |