Web Performance
Experiencia útil bajo condiciones reales
En Atlas, Web Performance describe cuán rápida y previsiblemente una experiencia Web se vuelve útil, responde a entradas y permanece visualmente estable bajo condiciones reales de ejecución, dispositivo y red. Es una definición operativa propia, no normativa universal. Su scope es browser/Web platform: incluye Web móvil, no performance de UI nativa de mobile-architecture.
La pregunta no termina cuando dispara load: una página puede mostrar contenido pronto y trabarse después. Importan navegación posterior, sesiones largas y operaciones completas. Métricas son proxies de resultados relevantes para personas, no una puntuación única del Atlas. Performance tampoco equivale a SEO: los requisitos del producto y sus usuarios deben orientar la arquitectura.
Un score Lighthouse resume una evaluación sintética bajo condiciones particulares; obtener 100 no demuestra la distribución de experiencias reales. Core Web Vitals tampoco agota Web Performance: deja fuera, entre otras cosas, memoria, consumo de CPU, latencia completa de operaciones de negocio y numerosos problemas de APIs y navegación.
Core Web Vitals: señales con alcance
Revisión de fuentes: 2026-10-20. Web Vitals de Google conserva el conjunto estable LCP, INP y CLS y estos umbrales recomendados de clasificación «good»:
| Señal | Dimensión | Umbral recomendado |
|---|---|---|
| LCP | Carga de contenido principal visible | ≤ 2.5 s |
| INP | Respuesta a interacciones | ≤ 200 ms |
| CLS | Inestabilidad visual inesperada | ≤ 0.1, sin unidad |
Google recomienda evaluarlos en p75, separando mobile y desktop. Ese percentil expresa que al menos 75% de las observaciones logra ese valor o mejor; no es la media ni declara irrelevante al resto. Una media puede ocultar dispositivos lentos y colas. Otros percentiles pueden corresponder mejor al riesgo del producto: estos valores no son SLOs universales ni requisitos del Atlas.
LCP observa cuándo se representa el mayor elemento contentful visible elegible. Pueden contribuir respuesta servidor, descubrimiento, descarga y demora de rendering. No equivale a tiempo de descarga de imagen, todos los recursos listos ni interactividad garantizada.
INP considera clicks, taps y teclado durante el lifecycle de la página, representando una interacción de latencia alta con tratamiento de outliers. Incluye demora hasta procesar entrada, handlers y presentación hasta el siguiente paint. No mide únicamente arranque ni toda la espera asíncrona hasta que un pago remoto finaliza.
CLS refleja el mayor grupo de desplazamientos inesperados dentro de una ventana de sesión; no suma indiscriminadamente todos los shifts de una visita larga. Reservar espacio para contenido tardío puede importar tanto como descargarlo antes. INP y CLS estables conservan alcance de lifecycle, relevante al comparar SPA y MPA.
Señales de apoyo y superficies de medición
TTFB observa hasta el primer byte de respuesta en el scope considerado. Para navegación puede incluir redirects, conexión, red, cache y servidor: no es CPU del backend solamente. Entender qué respuesta registra la herramienta importa al comparar plataformas. FCP marca primer contenido pintado, que puede no ser el contenido útil esperado. TBT diagnostica bloqueo del main thread durante una ventana medida, principalmente en laboratorio; no es Core Web Vital, reemplazo de INP ni garantía de buena interacción posterior.
PerformanceObserver observa entradas de performance; su existencia no implica soporte de todos sus tipos. Navigation Timing expone fases de navegación del documento, como redirects, conexión y respuesta; Resource Timing ayuda a atribuir cargas de recursos y fetches. User Timing permite marks/measures con semántica propia, por ejemplo «resumen de checkout utilizable». No basta iniciar timers sin pregunta de decisión.
Madurez de especificación e implementación difieren: Performance Timeline es Candidate Recommendation Draft del 2025-05-21; Event Timing es Working Draft del 2026-10-13, no W3C Recommendation. MDN identifica LargestContentfulPaint y PerformanceEventTiming como Baseline desde diciembre de 2025 en motores modernos; versiones anteriores pueden carecer de soporte. LayoutShift sigue con disponibilidad limitada. No generalizar cobertura ni confundir la entrada de una API con la metodología completa de una métrica.
Field y laboratorio responden preguntas distintas
Field/RUM observa usuarios reales: dispositivos, redes, geografías, caches, recorridos y duraciones diversas. Puede ser incompleto, ruidoso, muestreado o lento de acumular. Lab/synthetic controla condiciones para reproducir, diagnosticar y comparar cambios, pero limita esa diversidad. Las diferencias entre lab y field pueden producir resultados opuestos sin medición defectuosa. Investigar contexto, no elegir el dataset favorable.
| Pregunta de investigación | Evidencia útil | Límite de la inferencia |
|---|---|---|
| ¿Qué población sufre demoras durante checkout? | Distribuciones field segmentadas por recorrido y entorno. | Una correlación no identifica por sí sola el componente causal. |
| ¿Una dependencia serial explica la espera? | Reproducción controlada y atribución de fases. | El entorno sintético puede no representar la frecuencia real del problema. |
| ¿Conviene conservar el cambio? | Mecanismo reproducible y contraste field comparable. | Un promedio global puede esconder un segmento perjudicado. |
CrUX es field de población Chrome elegible, no telemetría de todos los usuarios. Su API publica agregados de ventana deslizante de 28 días, actualizados diariamente. First-party RUM puede diferir por población, browser, muestra, agregación, ventana, implementación o semántica de rutas. No concluir automáticamente que uno está mal.
Segmentar por mobile Web/desktop, ruta, versión, geografía, dispositivo, red, autenticación o cache cuando ayude, conservando muestras suficientes. No definir mobile como lento ni representar toda audiencia con el portátil del desarrollador o un perfil «Slow 4G». La instrumentación también cuesta: observers, payloads y cardinalidad consumen recursos; muestreo altera visibilidad de casos raros y percentiles. URLs, navegación y características del dispositivo requieren decisiones de privacidad y gobierno.
Navegaciones y evolución actual de la plataforma
Separar primera navegación completa, siguientes documentos, transiciones SPA/soft y restauraciones back/forward. bfcache puede restaurar una página desde memoria con gran rapidez; elegibilidad y comportamiento dependen de página y browser. No es HTTP cache ni asegura restauración en cada visita.
Estado revisado 2026-10-20: Chrome ofrece APIs de soft navigation desde 151, sin cobertura equivalente en los otros motores según su documentación actual. La propuesta de detección no constituye semántica universal de la Web. CrUX anunció el 2026-10-13 variantes experimentales que mezclan navegaciones completas y soft, manteniendo sin cambios sus métricas estables mientras evalúa las nuevas. No confundir APIs entregadas en Chrome con variantes experimentales del dataset ni comparar ambos alcances como idénticos. La conclusión durable es observar transiciones significativas durante la sesión, no solo el documento inicial.
Dónde aparecen trabajo y espera
Red, HTML, CSS, JavaScript, layout, paint y composición condicionan contenido e interacción. Sus dependencias forman caminos de espera; streaming, datos tardíos y activación impiden reducirlos a una secuencia única rígida. rendering-strategies explica cómo CSR mueve trabajo al cliente, SSR al servidor por request y generación estática al build, con combinaciones híbridas. Ninguna es universalmente más rápida.
HTML temprano puede facilitar descubrimiento; un servidor lento, datos encadenados o hydration pesada pueden anular ventajas. Streaming entrega partes progresivamente sin garantizar utilidad ni respuesta. Hydration puede agregar transferencia, parse/compile y ejecución según framework; activación parcial o selectiva puede reducir o diferir trabajo sin eliminarlo.
Los bytes JavaScript no describen CPU: ejecución, garbage collection y rendering inducido también importan. Tareas largas del main thread pueden demorar entrada y paint incluso con bundles pequeños. Workers permiten trasladar ciertos cálculos, con restricciones de acceso al DOM, transferencia y coordinación: no son mejora automática.
Recursos, dependencias y ownership
Importan recursos necesarios, descubrimiento y prioridad, no solo cantidad. Preload indiscriminado compite con lo crítico; prefetch puede acelerar una navegación que quizá nunca ocurra. Lazy loading reduce trabajo inicial y puede trasladar espera a la interacción. Imágenes requieren representación, dimensiones y variantes adecuadas; fuentes afectan transferencia, aparición de texto y estabilidad. Son decisiones contextuales, no una receta de formatos.
Las guías de resource hints y fuentes Web explican esos mecanismos. El browser conserva su propia planificación: una señal de prioridad expresa intención, no capacidad adicional ni una garantía de orden idéntico en todas las redes.
Analytics, anuncios, chat y consentimiento agregan red, ejecución y posibles shifts. Exigir responsable, valor de negocio, costo y posibilidad de diferir o aislar fallo; no asumir que todo tercero puede eliminarse. Bajar payload reduce transferencia potencial, pero multiplicar requests añade overhead; compresión cambia bytes por CPU y demora. No hay tamaño o algoritmo ideal universal.
communication incluye waterfalls entre recursos browser, consultas cliente y servicios. backend-for-frontend puede agrupar consultas y adaptar payloads, pero también añade salto, serialización y fan-out. Paralelizar dependencias independientes puede reducir espera; hacerlo sin límites compite por conexiones, capacidad, ancho de banda y CPU. El backend contribuye a Web Performance aunque no ejecute en el browser.
Cache, estado y composición
HTTP cache reutiliza respuestas, no equivale a un store de aplicación. Una cache service worker tampoco adquiere autoridad comercial. CDN/edge puede reducir distancia y carga de origen para recursos reutilizables; freshness, invalidación, geografía y datos privados cambian el resultado. Personalización puede combinar shell público cacheado y datos privados; no implica «sin cache», ni CDN implica «rápido».
client-state-management afecta alcance de rendering, recomputación, refresh e invalidación; elegir biblioteca no garantiza rendimiento. unidirectional-data-flow hace explícito el flujo, pero puede contener cadenas costosas. micro-frontends permite evolución y carga por partes; también puede duplicar runtimes, bundles y bootstraps. Compartir dependencias reduce duplicación a cambio de coordinación de versiones y autonomía. Evaluar consecuencias concretas, no condenar el enfoque por sus bytes.
offline-first puede ofrecer datos locales rápido aunque estén vencidos; utilidad desconectada y performance son preguntas distintas. synchronization consume red, CPU y storage, pero su corrección no se puede eliminar para mejorar una métrica. Optimizar no convierte una copia vieja o un resultado pendiente en confirmación autoritativa.
Objetivos, presupuestos y aprendizaje
Performance es una quality del sistema. quality-attribute-scenarios ayuda a precisar estímulo, entorno, respuesta y medida: después de Pay, qué feedback debe aparecer, para qué población y bajo qué carga. Puede convertirse en architectural-drivers cuando afecta tareas relevantes; no siempre domina prioridades.
Una métrica observa; un performance budget fija límite u objetivo sobre bytes, requests o resultados medidos. Puede ser guardrail de ingeniería sin ser automáticamente un SLO con semántica operacional. Lab en CI puede detectar regresiones, sin probar experiencia field. Cambios de población, campaña, contenido o red también mueven distribuciones: correlacionar con versiones antes de atribuirlos al código.
El presupuesto necesita scope, medición y responsable de decidir excepciones. Limitar bytes puede proteger transferencia, sin controlar el trabajo que esos bytes disparan. Un objetivo de feedback tampoco equivale al de confirmación final: confundirlos incentiva optimizaciones que mejoran el indicador y dejan intacta la espera importante.
trade-off-analysis conserva frescura, seguridad, complejidad, mantenibilidad y autonomía. estimation permite aproximar transferencia y round trips, sin sustituir benchmark/RUM. cost-efficiency recuerda que precomputar o ampliar edge puede subir costos aunque baje latencia. Mejores CWV no prueban menor impacto ambiental. accessibility sigue separada: rapidez no justifica romper semántica, teclado o tecnologías asistivas. internationalization cambia texto, fuentes, layout y variantes de cache; optimizar no autoriza perder significado o soporte lingüístico.
Contenido temprano, feedback, skeletons y optimismo pueden mejorar percepción, no acelerar mágicamente servidor/red. Placeholders mal dimensionados crean shifts; una representación optimista no puede anunciar un pago confirmado sin evidencia.
Síntesis Atlas para investigar: observar experiencia → elegir recorrido/señal → segmentar y atribuir → formular hipótesis → reproducir/experimentar → cambiar → validar en lab y field → conservar o revisar. No es un método formal universal ni exige esperar producción para diseñar según drivers conocidos. Atribución pregunta por qué: ¿LCP depende de servidor, descubrimiento, descarga o rendering?
systems-thinking exige resultado extremo a extremo: menos JS con más round trips puede empeorarlo. Tras mejorar aparece otro cuello; detener ajuste cuando objetivos y riesgo lo justifiquen. scaling puede aliviar saturación servidor, no CPU cliente o layout; optimización frontend tampoco elimina límites backend. Requests/segundo describe throughput, no directamente experiencia humana.
Commerce: hipótesis sobre un recorrido completo
Ejemplo propio: catálogo público con generación estática/cache es candidato, no garantía. Revisar LCP, transferencia y cache hits. En producto con SSR, respuesta BFF y datos tardíos pueden demorar descubrimiento de imagen principal y paint: el LCP cruza servidor y cliente.
Checkout combina validación, estado y actualización visual; INP puede revelar respuesta lenta a entrada. Medir aparte «Place Order → confirmación visible» con inicio, resultado y población definidos, sin inventar umbral ni confundir feedback con finalización comercial. Banner promocional, imagen o fuente tardía puede mover totales y acciones: CLS observa esa inestabilidad inesperada.
El Web BFF consulta Orders, Payments e Inventory: paralelismo válido puede ayudar, una dependencia lenta o fan-out serial puede dominar. Browse, Checkout y Account como Micro Frontends pueden repetir runtime; comparar costo real y autonomía, no descartarlas solo por tamaño.
Supongamos RUM aceptable en desktop e INP pobre en ciertos móviles Web: es una hipótesis sobre ejecución/dispositivo, no evidencia ya medida del Atlas ni diagnóstico definitivo. Reproducir el mecanismo; probar otra descomposición de bundle o rendering; contrastar lab y distribuciones field comparables. Una ejecución Lighthouse favorable no demuestra mejora para esa población. frontend-and-client-architecture conserva el recorrido hacia decisiones vecinas.
Las fuentes cumplen funciones diferentes: Google define su programa Web Vitals; W3C publica especificaciones de interfaces; MDN documenta uso y compatibilidad; Chrome/CrUX describe implementaciones y datasets propios. La definición operativa, el recorrido Commerce y el ciclo de investigación son síntesis Atlas. No convierten recomendaciones de una herramienta en contratos universales.