Construir · Rendimiento
Rendimiento desde el principio
Optimizar al final consiste en quitar cosas que no debían haberse puesto. Es más caro y funciona peor.
Respuesta directa
El rendimiento se decide sobre todo al elegir qué carga la página, no al comprimirlo después. Una librería que no se añade no hay que optimizarla.
Y una precisión que evita malentendidos: los Core Web Vitals son datos de campo, de usuarios reales. Una medición en local sirve para detectar regresiones, no para declarar que se cumplen.
Las tres métricas, su umbral y qué miden
| Métrica | Qué mide | Umbral «bueno» al percentil 75 |
|---|---|---|
| LCP · Largest Contentful Paint | Rendimiento de carga: cuánto tarda en aparecer el elemento principal. | 2,5 segundos |
| INP · Interaction to Next Paint | Interactividad: cómo responde la página a la interacción. | 200 milisegundos |
| CLS · Cumulative Layout Shift | Estabilidad visual: cuánto se mueve el diseño mientras carga. | 0,1 o menos |
Por qué el percentil 75 y por qué «de campo»
Los umbrales no se miden sobre una visita: se miden sobre el percentil 75 de las visitas reales. Eso significa que tres de cada cuatro personas deben tener esa experiencia o mejor.
La fuente oficial es explícita en que cada métrica «es medible en campo y refleja la experiencia real» de las personas que visitan el sitio. Por eso una medición en local, sin latencia ni dispositivos reales, no puede declarar cumplimiento.
Lo que se decide en construcción
- Qué se carga: cada librería, fuente o script de terceros es una decisión, no un detalle.
- Dimensiones en las imágenes: reservar espacio evita que el diseño salte.
- Prioridad del hero: lo primero que se ve se pide primero, sin carga diferida.
- Carga diferida para el resto: para que no compita con lo importante.
- CSS y JS solo donde hacen falta: no cargar en todas las páginas lo que usa una.
- Presupuestos por plantilla: un límite acordado que el QA comprueba.
CLS es el que más sorprende
El desplazamiento del diseño no se ve mirando: ocurre en milisegundos y luego la página parece correcta. Solo aparece midiendo.
En este sitio tuvimos 0,146 en la página del diagnóstico, por encima del umbral de referencia. La causa: un contenedor que empezaba con altura cero y crecía a más de 800 píxeles al montarse la interfaz, empujando todo lo de abajo. Se corrigió reservando el espacio medido, no estimado.
Por qué no publicamos nuestras cifras como cumplimiento
Medimos en local y obtenemos números muy buenos. No significan nada como cumplimiento: no hay latencia de red, ni dispositivos reales, ni usuarios.
Declararlos como Core Web Vitals sería un falso resultado. Los datos de campo solo existen después de publicar y con tráfico suficiente.
Preguntas frecuentes
¿Una puntuación de 100 en laboratorio significa que cumplo?
No. Es una medición sintética útil para detectar regresiones. El cumplimiento de los Core Web Vitals se determina con datos de usuarios reales, que no existen antes de publicar.
¿Basta con optimizar las imágenes?
Ayuda mucho y no basta. Lo que suele pesar más son los scripts de terceros, que además bloquean la interacción. En este sitio no hay ninguno, y eso explica el margen mejor que cualquier optimización de imagen.
Fuentes primarias
Cada afirmacion sensible de esta pagina se apoya en una de estas fuentes, consultada en la fecha indicada. Las listas de bots, capacidades y borradores cambian: se reverifican en cada revision.
| Entidad | Documento | Consultada |
|---|---|---|
| Google · web.dev | Web Vitals | 2026-08-30 |
| Google Search Central | Guía de optimización para funciones de IA generativa (actualizada 2026-07-10) | 2026-08-30 |
Siguiente decisión
Continúa con una pregunta concreta
Cuándo WordPress sí y cuándo no
Una lectura relacionada dentro del mismo método.
Cuándo WordPress sí y cuándo no →
Reconstrucción y mejora de webs existentes
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Reconstrucción y mejora de webs existentes →
Ilustraciones conceptuales; no son fotografías de clientes.