≡En resumen
- El rendimiento web se degrada solo: cada plugin, imagen o script nuevo suma peso si nadie lo vigila.
- Un presupuesto de rendimiento fija límites (peso, tiempos, Core Web Vitals) que no se pueden superar sin decidirlo.
- Los datos de campo (RUM y CrUX) dicen cómo lo viven los usuarios; las pruebas de laboratorio explican por qué.
- CrUX usa una ventana de 28 días: una mejora tarda semanas en reflejarse del todo en Search Console.
- Las alertas automáticas convierten el rendimiento en un indicador vigilado, como la disponibilidad.
01 ¿Qué es el website performance?
Website performance es el término inglés para el rendimiento de un sitio web. Las técnicas para hacer una web más rápida (caché, imágenes, JavaScript, servidor) las explicamos en la ficha de optimización de velocidad. Esta ficha trata lo que viene después, y que casi nadie hace: cómo mantener el rendimiento en el tiempo con un presupuesto de rendimiento y un sistema de monitorización.
02 Por qué el rendimiento empeora aunque nadie toque el código
Una web optimizada el día del lanzamiento rara vez sigue igual un año después. El rendimiento se pierde poco a poco, con decisiones pequeñas que nadie mide:
Contenido nuevo
Imágenes subidas sin comprimir, vídeos incrustados en la portada o carruseles con diez diapositivas.
Scripts de terceros
Píxeles publicitarios, chats, mapas de calor y herramientas de pruebas A/B que se añaden y no se retiran.
Plugins y dependencias
Cada actualización o funcionalidad nueva puede añadir CSS y JavaScript a todas las páginas.
Servidor y tráfico
Más visitas, más productos o una base de datos que crece sin mantenimiento elevan el tiempo de respuesta.
03 El presupuesto de rendimiento (performance budget)
Un presupuesto de rendimiento es un conjunto de límites que el equipo acuerda no superar. La guía de web.dev los clasifica en tres tipos: límites de cantidad (peso de imágenes, kilobytes de JavaScript, número de fuentes), tiempos de hitos de carga y reglas basadas en puntuaciones de herramientas como Lighthouse. Sus ejemplos incluyen menos de 170 KB de JavaScript en páginas de producto en móvil.
| Tipo de límite | Métrica | Límite de ejemplo |
|---|---|---|
| Experiencia real | LCP en el percentil 75, móvil | ≤ 2,5 s |
| Experiencia real | INP en el percentil 75, móvil | ≤ 200 ms |
| Experiencia real | CLS en el percentil 75 | ≤ 0,1 |
| Cantidad | JavaScript comprimido por página | Según plantilla, por ejemplo ≤ 170 KB |
| Cantidad | Scripts de terceros | Número máximo acordado y revisado cada trimestre |
| Servidor | Tiempo hasta el primer byte | Objetivo fijado por plantilla y medido con datos reales |
04 Datos reales (RUM) frente a pruebas de laboratorio
El rendimiento se mide de dos maneras que se complementan. Los datos de campo o RUM (real user monitoring) se recogen en los navegadores de los visitantes reales, con sus móviles, sus redes y sus hábitos. Los datos de laboratorio se obtienen con una prueba controlada, siempre en las mismas condiciones, como un test de velocidad.
| Fuente | Qué mide | Para qué sirve | Limitación |
|---|---|---|---|
| RUM propio | Métricas de cada visita en tu web, con la librería web-vitals o una herramienta de monitorización | Ver cambios en horas, segmentar por página, país o dispositivo | Requiere instalar código y, a menudo, consentimiento |
| CrUX | Datos agregados de usuarios de Chrome que cumplen los requisitos | Es la fuente que usan Search Console y PageSpeed Insights | Solo webs y páginas con tráfico suficiente, ventana de 28 días |
| Laboratorio | Una carga simulada con dispositivo y red fijos (Lighthouse, WebPageTest) | Diagnosticar la causa y probar cambios antes de publicar | No refleja la variedad real de usuarios ni mide bien el INP |
PageSpeed Insights muestra en la misma pantalla los datos de CrUX (arriba) y una prueba de Lighthouse (abajo). Cuando no coinciden, manda el dato de campo: es lo que viven tus usuarios y lo que evalúa Google.
05 Cómo funciona CrUX y por qué las mejoras tardan en verse
28 días
Ventana móvil de los datos de la CrUX API
Fuente: Chrome for Developers, documentación de la CrUX API
04:00 UTC
Hora aproximada de actualización diaria de la CrUX API
Fuente: Chrome for Developers, documentación de la CrUX API
p75
Percentil con el que se evalúan las Core Web Vitals
Fuente: web.dev, Web Vitals
Como CrUX promedia 28 días, si corriges un problema hoy el dato solo refleja la mejora por completo unas cuatro semanas después. El conjunto mensual de BigQuery se publica el segundo martes del mes siguiente. Por eso conviene tener RUM propio: te dice en horas si un cambio ha funcionado, mientras CrUX confirma la tendencia.
06 Monitorización y alertas: cómo montar el sistema
-
1
Elige las páginas testigo
Una por plantilla importante: portada, categoría, producto o servicio, artículo y formulario.
-
2
Fija la línea base
Anota LCP, INP, CLS, peso y tiempo de servidor actuales en móvil y escritorio.
-
3
Automatiza el laboratorio
Lanza Lighthouse CI u otra prueba en cada despliegue y haz que falle si se supera el presupuesto.
-
4
Recoge datos reales
Envía las métricas de campo a tu analítica o a una herramienta RUM, respetando el consentimiento.
-
5
Define alertas
Aviso por correo o chat si el p75 de una métrica supera el umbral varios días seguidos o si la web deja de responder.
-
6
Revisa cada mes
Compara con CrUX y Search Console, y decide qué optimizar o qué retirar.
07 Rendimiento, negocio y siguiente paso
Las Core Web Vitals forman parte de los sistemas de clasificación de Google, pero su efecto más directo está en la conversión: una página que tarda en responder pierde usuarios antes de que lleguen al formulario o al carrito. Por eso el rendimiento debe revisarse junto con el resto de factores técnicos en una auditoría SEO técnica.
Una tienda en WooCommerce tiene como presupuesto un LCP móvil de 2,5 s. Antes de una campaña, marketing añade un vídeo en la cabecera de la portada. La prueba automática del despliegue marca un LCP de laboratorio de 4 s y bloquea la publicación. El equipo sustituye el vídeo por una imagen optimizada con reproducción al hacer clic y la campaña arranca sin penalizar la conversión. Si tu web ya está por encima de sus límites, empieza por mejorar la velocidad web y después fija el presupuesto; con WordPress lento, revisa primero plugins y caché.
Preguntas frecuentes sobre Website Performance
Significa rendimiento web: lo rápido, estable y disponible que es un sitio para sus usuarios. Se mide sobre todo con las Core Web Vitals (LCP, INP y CLS) y con la disponibilidad del servidor.
Es un conjunto de límites acordados, como el peso máximo de JavaScript, el número de scripts de terceros o un LCP de 2,5 segundos, que el equipo no puede superar sin decidirlo de forma explícita.
RUM mide la experiencia de los visitantes reales en sus dispositivos y redes. El laboratorio simula una carga en condiciones fijas; sirve para diagnosticar y probar cambios, pero no refleja la variedad real.
El Chrome UX Report es el conjunto público de datos de rendimiento de usuarios reales de Chrome. Lo usan PageSpeed Insights y Search Console, y agrega los datos en una ventana de 28 días.
Porque los datos de CrUX promedian los últimos 28 días. La mejora se refleja de forma gradual y tarda unas cuatro semanas en verse por completo.
Sí, las Core Web Vitals forman parte de las señales de experiencia de página que Google tiene en cuenta, aunque pesan menos que la relevancia del contenido. Su impacto más visible suele estar en la conversión y en la tasa de abandono.
De forma continua con datos reales y en cada despliegue con pruebas automáticas. Además, conviene una revisión mensual de tendencias con CrUX y Search Console.
PageSpeed Insights y Search Console para datos de CrUX, Lighthouse CI o WebPageTest para laboratorio, la librería web-vitals o una herramienta RUM para datos propios y un monitor de uptime para la disponibilidad.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗