Por qué el rendimiento es la experiencia del usuario (Por Que El Rendimiento Es La Experiencia Del Usuario)

Por qué el rendimiento es UX

El rendimiento no está separado de la experiencia del usuario: es una de sus dimensiones más visibles. Los usuarios experimentan un sitio web a lo largo del tiempo: qué tan rápido aparece el contenido, qué tan rápido pueden actuar y si las interacciones se sienten fluidas o discontinuas. El rendimiento web incluye tanto medidas objetivas como el tiempo de carga y respuesta, como la percepción de la velocidad por parte del usuario. MDN

Una interfaz lenta produce fricción en cada etapa:

• Una pantalla en blanco o faltante te hace preguntarte si el sitio está funcionando o no.
• Un botón que no responde sugiere si la acción se realizó o no.
• Los cambios de diseño modifican el contenido inesperadamente y provocan errores.
• El desplazamiento o la animación atascados hacen que la interfaz parezca poco confiable.
• Los retrasos interrumpen el flujo mental y aumentan la probabilidad de abandono.

Por el contrario, una interfaz rápida y estable no requiere esfuerzo. Los usuarios pueden centrarse en su objetivo en lugar de gestionar la tecnología entre ellos y el objetivo. La orientación de la plataforma web correlaciona un mejor rendimiento con un mayor compromiso, retención, satisfacción y un menor abandono. web.dev

Rendimiento transmite calidad

Los usuarios suelen interpretar la capacidad de respuesta como una señal de fiabilidad y confianza. Un producto que responde inmediatamente se siente cuidadosamente diseñado; Un producto congelado, atascado o dejado en espera se siente frágil, incluso si sus especificaciones son técnicamente correctas.

Es por eso que el rendimiento no se trata sólo de ingeniería u optimización; debe tratarse como un requisito del producto. Las opciones de diseño, la estrategia de contenido, la arquitectura JavaScript, el alojamiento y los efectos visuales dan forma a la experiencia percibida por el usuario.## Qué optimizar

Una estrategia de rendimiento centrada en el usuario debería plantear estas preguntas:

1. ¿Cuándo aparece el contenido significativo? Optimice la experiencia de espera, no solo el tiempo de carga final.
2. ¿Cuándo puede interactuar el usuario? Una página que parece lista pero ignora la entrada todavía se siente rota.
3. ¿Qué tan estable es la interfaz? Evite movimientos inesperados mientras carga contenido, anuncios, imágenes o fuentes.
4. ¿Qué tan fluidas son las interacciones? Desplazarse, escribir, abrir menús y navegar deben ser continuos, no entrecortados.

Core Web Vitals ayuda a medir partes clave de esta experiencia; Pero las métricas son valiosas en la medida en que representan la fricción real del usuario. El objetivo no es poner el tablero en verde; es hacer que el producto se sienta rápido, claro y confiable en condiciones reales.

Conceptos recurrentes en esta sección```text

📦 Kullanıcının algıladığı performans Deneyimin laboratuvar skorundan değil; kullanıcının hissettiği hız ve güvenilirlik.

📦 Algılanan bekleme süresi Gecikmenin duygusal süresi; çoğu zaman memnuniyeti saat süresinden daha çok etkiler.

📦 Core Web Vitals LCP, INP ve CLS—gerçek kullanıcıların 75. yüzdeliğinde ölçülen yükleme, yanıt ve görsel kararlılık.

📦 Saha verisi ile laboratuvar verisi Gerçek kullanıcı ölçümü ile kontrollü, tekrarlanabilir teşhis testleri.

📦 RAIL Response, Animation, Idle, Load—kullanıcı eylemlerine göre performans hedefleri.

📦 Performans bütçesi “Yeterince hızlı”yı tasarım kısıtı haline getiren ağırlık, gecikme ve kararlılık limitleri.

## El coste de la lentitud

Un sitio web lento genera costos antes de que los usuarios vean el contenido principal. El primer retraso se convierte en la primera impresión: los visitantes pueden interpretarlo como una señal de que el producto es antiguo, poco fiable o difícil. Por lo tanto, el desempeño no se trata sólo de quedarse o no; También da forma al juicio sobre la institución detrás del sitio.

Los usuarios esperan que el contenido aparezca rápidamente y que las interacciones respondan. A medida que aumenta la demora, disminuye la paciencia; Es posible que abandonen la página, repitan la acción o se vayan con menos confianza en el producto. MDN identifica el bajo rendimiento como una causa de abandono, baja retención, baja conversión y disminución de la satisfacción. [MDN](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/why_web_performance)

### La primera impresión se produce durante la instalación.

Incluso si la página no está técnicamente lista, la experiencia de carga es parte de la interfaz:

- La pantalla en blanco no muestra evidencia de progreso.
- Una página parcialmente renderizada puede hacer que el producto parezca incompleto.
- Un indicador de carga visible ayuda, pero no compensa la espera innecesariamente larga.
- Los cambios de diseño hacen que la interfaz parezca inestable y pueden provocar errores de clic.
- La respuesta inicial rápida proporciona seguridad de que el sistema está funcionando.

Esto es especialmente importante para quienes visitan el sitio por primera vez y aún no han acumulado confianza. La guía de rendimiento de Google señala que los sitios lentos son menos efectivos en cuanto a participación y retención, y los casos en los que el tiempo de carga adicional resulta en una pérdida de usuarios medible. [web.dev](https://web.dev/learn/performance/why-speed-matters)

### La satisfacción se acumula

Se puede tolerar un solo retraso; pero los retrasos recurrentes se acumulan a lo largo de la sesión. El producto del usuario espera primero la página, luego el menú y luego el resultado de la búsqueda no es un camino sencillo hacia el objetivo; vive como una serie de obstáculos.El rendimiento también afecta el estado emocional. La investigación resumida en web.dev vincula los retrasos en la velocidad de la página con un estrés elevado; es decir, la experiencia lenta puede parecer más pesada de lo que sugeriría su duración por sí sola. Con el tiempo, esta frustración reduce la confianza, el compromiso, la voluntad de regresar y la probabilidad de recomendar el producto. [web.dev](https://web.dev/learn/performance/why-speed-matters)

### Impacto empresarial

El “coste de la lentitud” aparece en formas interconectadas:

- Más visitas abandonadas y misiones sin terminar.
- Menor conversión e ingresos.
- Disminución del uso repetido y retención de clientes.
- Mayor demanda de apoyo cuando no está claro si la acción tiene éxito o no.
- Confianza más débil en la marca.
- Mayores costos de datos, batería y dispositivos para usuarios con conexiones lentas o limitadas.

La lección práctica es sencilla: la velocidad forma parte de la primera impresión del producto y de cada interacción posterior. Un sitio rápido no sólo ahorra tiempo: comunica respeto por la atención del usuario y hace que la experiencia parezca más confiable.

## Psicología de la espera

La espera no se experimenta como una medida neutral de segundos. La gente juzga la latencia a través de la emoción y la expectativa: dos segundos pueden parecer aceptables cuando la interfaz responde de inmediato; La misma cantidad de tiempo parece mucho más larga si la pantalla está en blanco, el resultado es incierto o no se sabe si la acción funcionó.

Las investigaciones sobre la experiencia de servicio muestran que el **tiempo de espera percibido** a menudo influye más en la satisfacción que la espera objetiva. Se siente peor si la espera es vacía, inexplicable, incierta o fuera del control del usuario; la interacción, el conocimiento y el progreso visible pueden hacer que el mismo período sea más manejable. [Investigación Erasmus](https://repub.eur.nl/pub/12176/)

### Por qué las esperas digitales son dolorosas

Varios efectos psicológicos hacen que los retrasos sean especialmente perjudiciales en la web y las aplicaciones:- **El tiempo sin estar ocupado parece más largo.** La pantalla en blanco no deja nada en qué concentrarse; La atención se centra en el paso del tiempo.
- **El tiempo de incertidumbre parece más largo.** Si no hay comentarios, no está claro si el sistema se está cargando, congelado o fallando.
- **El tiempo de ansiedad se siente más largo.** Si hay dinero, datos personales o una tarea importante en juego, el resultado genera ansiedad.
- **El tiempo injusto o incontrolado parece más largo.** Los usuarios que no entienden por qué están esperando o qué pueden hacer se frustran.
- **El tiempo interrumpido parece más largo.** Las pausas repetitivas interrumpen la concentración y hacen que la tarea parezca más difícil de lo que es.

La primera espera suele ser especialmente importante porque establece las expectativas para el resto de la experiencia. Si el producto es lento antes de que el usuario obtenga valor, la demora se siente como un obstáculo más que como un paso necesario.

### Diseñando mejores esperas

La mejor solución es un buen rendimiento; pero las esperas inevitables deben diseñarse deliberadamente:

- Mostrar respuesta inmediata cuando el usuario toca o envía.
- Reemplace la pantalla en blanco con una estructura significativa, como un diseño de esqueleto.
- Mostrar progreso si se puede medir el tiempo.
- Si el proceso es complejo, explique lo sucedido.
- Dar control como cancelar, reintentar o continuar en segundo plano.
- Confirmar el éxito claramente para que no se repita la acción.
- Utilice actualizaciones optimistas sólo si el error se puede manejar de forma segura.

El indicador de progreso no acelera objetivamente el proceso; Reduce la incertidumbre y señala que el sistema está funcionando. El objetivo es convertir la espera pasiva en progreso consciente: el usuario debe saber que algo está sucediendo, por qué está sucediendo y, si es posible, cuánto tiempo podría durar.

## Evaluar el rendimiento de UXEl rendimiento de UX debe medirse desde dos perspectivas: **cómo funciona el sistema** y **con qué éxito los usuarios completan sus objetivos**. Una página puede obtener excelentes puntuaciones técnicas, pero seguirá frustrando al usuario si la navegación es confusa, los errores son frecuentes o las tareas importantes toman demasiado tiempo.

### Elementos vitales web básicos

Core Web Vitals de Google se centra en tres dimensiones de cara al usuario: carga, capacidad de respuesta y estabilidad visual. Los umbrales "buenos" recomendados se miden en el percentil 75 de las experiencias reales del usuario. [Centro de búsqueda de Google](https://developers.google.com/search/docs/appearance/core-web-vitals)

| Métrica | Que medidas | Buen objetivo |
|---|---|---|
| Pintura con contenido más grande (LCP) | Cuando el contenido principal es visible | ≤ 2,5 segundos |
| Interacción con la siguiente pintura (INP) | Qué tan rápido responde visiblemente la interfaz a la entrada del usuario | ≤ 200 ms |
| Cambio de diseño acumulativo (CLS) | Cuánto se mueve la página inesperadamente | ≤ 0,1 |

Estas métricas responden a tres preguntas básicas: *¿Pueden ver contenido importante? ¿Pueden interactuar sin esperar? ¿La interfaz permanece en su lugar?*

### Métricas de producto y disponibilidad

Las métricas técnicas deben compararse con resultados reales de los usuarios:

- **Tasa de éxito de la tarea:** porcentaje de usuarios que completaron la tarea correctamente.
- **Duración de la tarea:** el tiempo necesario para lograr un objetivo.
- **Tasa de error:** frecuencia de error, acción repetitiva o falla.
- **Tasa de abandono:** frecuencia de abandono antes de completar el flujo.
- **Satisfacción:** CSAT, preguntas post-tarea o entrevistas.
- **Retención y conversión:** si un mejor rendimiento genera conversión, compra, suscripción u otra acción valiosa.Estas métricas muestran si las mejoras en el rendimiento simplemente producen mejores puntuaciones de diagnóstico o una mejora significativa de la experiencia de usuario. [Ejército UX](https://uxarmy.com/blog/how-to-measure-ux-rendimiento/)

### Datos de campo y datos de laboratorio

**Los datos de campo** provienen de dispositivos, navegadores, redes y ubicaciones reales de usuarios reales. Es la mejor manera de comprender la experiencia que realmente obtienen los usuarios; El informe Core Web Vitals también utiliza este tipo de datos del mundo real. [Ayuda de Google Search Console](https://support.google.com/webmasters/answer/9205520?hl=en)

**Los datos de laboratorio** provienen de instrumentos controlados y condiciones de prueba repetibles. Útil para extraer regresiones y comparar cambios; pero no puede representar todos los dispositivos o condiciones de red del mundo real.

Un proceso de medición sólido utiliza dos: el laboratorio para encontrar las causas, el campo para verificar el impacto y las métricas de resultados del usuario para verificar que la experiencia realmente ha mejorado.

### Mida los recorridos, no solo las páginas

Las puntuaciones a nivel de página son útiles; pero los usuarios experimentan **flujos**: buscar, iniciar sesión, pagar, cargar un archivo o completar un formulario. Mida el rendimiento de estos viajes desde la perspectiva del usuario:

1. Tiempo hasta que el usuario pueda comenzar.
2. Retraso después de cada interacción importante.
3. Errores y acciones repetitivas.
4. Terminación y abandono.
5. Satisfacción posterior a la tarea.

Por lo tanto, el objetivo de desempeño más significativo no es simplemente “reducir el LCP” o “mejorar el INP”. Se trata de: **ayudar a los usuarios a completar tareas importantes de forma rápida, segura y sin esfuerzos innecesarios.**

## Rendimiento para todosLa experiencia rápida no debería definirse por el teléfono más reciente, una computadora portátil potente o Wi‑Fi de alta velocidad. Los usuarios reales pueden tener hardware antiguo, un plan de datos limitado, una red móvil ocupada, una pantalla pequeña o dispositivos con mucho JavaScript y animación. El desempeño inclusivo significa hacer que la **experiencia principal** sea utilizable y responsiva en estas condiciones.

### Diseño según la línea base

En lugar de tratar a los usuarios lentos como un caso atípico, comience con la capacidad razonable más baja:

- Haga que el contenido y las acciones esenciales estén disponibles sin grandes descargas.
- Utilice diseños responsivos que se adapten al tamaño de la pantalla, la orientación y el método de entrada.
- Mantenga la navegación, los formularios y las interacciones principales simples en la pantalla pequeña.
- Utilice HTML semántico y mejoras progresivas para que la funcionalidad básica funcione sin instalar funciones avanzadas.
- No asuma que todos los dispositivos admiten un procesador rápido, una gran memoria y conectividad táctil o persistente.

El objetivo no es crear una versión móvil peor. Ofrecer el mismo valor fundamental; adaptando la presentación y características opcionales al contexto del usuario.

### Adaptar los recursos de forma inteligente

El navegador no debe recibir en el dispositivo más datos o cálculos de los necesarios. Las imágenes responsivas pueden seleccionar el tamaño apropiado con `srcset` y `sizes`; Las imágenes de la página inferior se pueden cargar de forma diferida para reservar el ancho de banda para el contenido visible. [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images)

La carga adaptativa puede brindarles a todos una experiencia central rápida y agregar medios de mayor calidad, animaciones complejas o scripts no esenciales cuando el dispositivo y la red lo admiten. Esta imagen y vídeo más pequeños en una conexión lenta; Podría significar menos animaciones y cálculos más baratos en hardware inferior. [web.dev](https://web.dev/articles/adaptive-loading-cds-2019)### Soporte de conexión defectuosa

Las redes no son estables. El usuario puede cambiar entre Wi-Fi y datos móviles, perder la conexión en el ascensor o experimentar una alta latencia mientras el ancho de banda parece adecuado. Una buena UX es la razón:

- Debe mostrar estados claros de carga, fuera de línea y reintento.
- Preservar la entrada del usuario en caso de errores.
- Debe almacenar en caché los activos subyacentes en la ubicación adecuada.
- Debería permitir que las acciones seguras se pongan en cola para sincronizarlas más tarde.
- No debería forzar el reinicio de toda la tarea después de un error temporal.
- Debe transmitir si la acción tuvo éxito, no tuvo éxito o aún está pendiente.

Una interfaz que maneja las interrupciones con elegancia sólo parece más confiable que una rápida en condiciones ideales.

### Prueba condiciones reales

Las pruebas de rendimiento deben incluir dispositivos reales de gama baja, diferentes navegadores, pantallas pequeñas, aceleración de la CPU y redes simuladas lentas o inestables. Mida Core Web Vitals tanto en pruebas de campo como controladas; Segmente los resultados por clase de dispositivo, tipo de conexión, geografía y recorridos clave.

El estándar "¿Funciona en mi máquina?" No lo es. Es: "¿Pueden los usuarios con dispositivos normales y conexiones difíciles ver, comprender y completar la tarea importante?" Un producto de rendimiento es aquel que no hace que la calidad del hardware o la velocidad de la red sean un requisito previo para la experiencia de uso.

## Diseño que prioriza el rendimiento

La velocidad, la capacidad de respuesta y la estabilidad del diseño que priorizan el rendimiento no son problemas técnicos que deban solucionarse después del lanzamiento; lo considera como requisitos del producto desde el principio. Pide a los diseñadores e ingenieros que consideren el impacto que cada elemento visual, interacción y característica tiene en el tiempo, la atención, la batería, los datos y los recursos del dispositivo del usuario.

### Comience con la experiencia principalComience por identificar el objetivo principal del usuario y diseñar el camino más corto y confiable hacia él:

- Mostrar primero el contenido más importante.
- Hacer que la acción primaria esté disponible lo antes posible.
- Eliminar elementos decorativos que compitan con el contenido principal.
- Retrasar las funciones avanzadas hasta que sean necesarias.
- Utilice la divulgación progresiva para mantener simples las pantallas iniciales.
- Diseñar estados útiles en blanco, carga, error y fuera de línea.

Una interfaz hermosa que tarda demasiado en resultar útil no es un diseño exitoso. La pantalla principal debería ofrecer valor rápidamente, incluso mientras el contenido secundario continúa cargándose.

### Tome decisiones visuales de manera responsable

Las decisiones de diseño afectan directamente el rendimiento. Los vídeos de héroes de gran tamaño, las imágenes no optimizadas, las fuentes personalizadas, las sombras complejas, la animación excesiva y los widgets de terceros pueden aumentar el tamaño de la descarga, el trabajo de renderizado y el retraso en la interacción.

Elija imágenes responsivas del tamaño adecuado, recursos livianos, animaciones restringidas y componentes renderizables progresivamente.

### Diseño para el rendimiento percibido

Los usuarios necesitan retroalimentación además de velocidad. Una interfaz responsiva:

- Debe confirmar la entrada inmediatamente.
- Pantalla protegida mientras se carga contenido nuevo.
- Si se conoce la estructura de la página, se debe utilizar un esqueleto.
- Se deben utilizar indicadores de progreso en operaciones con una duración significativa.
- Debe mantener constantes las dimensiones del diseño para evitar el movimiento visual.
- Explicar errores y ofrecer acciones de recuperación.

Los comentarios deben ser honestos: la animación de carga no debe ocultar una solicitud bloqueada; El esqueleto debe parecerse al contenido que representa y no debe crear falsas expectativas.

### Integrar el rendimiento en el proceso

El diseño que prioriza el rendimiento funciona mejor como un flujo de trabajo común:

1. Defina presupuestos de rendimiento para el peso de la página, la carga, la capacidad de respuesta y la estabilidad.2. Incluir dispositivos y redes más lentos en las revisiones de diseño.
3. No sólo la pantalla final ideal; Estados de carga, error y transición de prototipos.
4. Pruebe viajes de usuario realistas en condiciones de laboratorio y de campo.
5. Supervise Core Web Vitals y los resultados de las tareas después de la publicación.
6. Revise el diseño cuando las nuevas funciones consuman el presupuesto disponible.

El principio central es simple: **no sólo lo que aparece en el prototipo ideal; Diseñe la experiencia que los usuarios realmente pueden recibir.**

## modelo FERROVIARIO

RAIL define el rendimiento web no como un recuento de carga de una sola página; Es un marco centrado en el usuario para pensar en términos de una secuencia de acciones del usuario. Divide la experiencia en **Respuesta, Animación, Inactivo y Carga**; Le da a cada contexto un objetivo práctico basado en cómo las personas perciben el retraso. [web.dev](https://web.dev/articles/rail)

| Principio | Experiencia de usuario | Objetivo práctico |
|---|---|---|
| **Respuesta** | Confirmar hacer clic, tocar, escribir y otras entradas | Responder en 100 ms |
| **Animación** | Sigue deslizando, arrastrando y haciendo transiciones fluidas | Produzca cada cuadro en aproximadamente 16 ms |
| **Inactivo** | Utilice el tiempo en segundo plano sin bloquear la interacción futura | Trabaja en pequeños trozos, idealmente menos de 50 ms |
| **Cargar** | Haga que el contenido útil y la participación estén disponibles rápidamente | Carga contenido interactivo en unos 5 segundos |

###Respuesta

Cuando el usuario hace clic en un botón, la interfaz debería confirmar la acción casi de inmediato, incluso si el proceso completo lleva más tiempo. La primera respuesta podría ser presionar estado, control giratorio, actualización optimista o alternar navegación; Su propósito es brindar seguridad de que se han recibido los aportes.Las tareas largas de JavaScript pueden bloquear el hilo principal y retrasar esta retroalimentación. Dividir el trabajo costoso en partes más pequeñas permite que el navegador devuelva el control al usuario con mayor frecuencia. [MDN](https://developer.mozilla.org/en-US/docs/Glossary/RAIL)

### Animación

Deslizar, arrastrar y realizar transiciones son interacciones constantes. Si en el renderizado faltan fotogramas, el movimiento será entrecortado; La interfaz parece poco pulida y difícil de controlar.

El objetivo tradicional de RAIL es de aproximadamente 16 milisegundos por fotograma a 60 fps. En la práctica, los equipos deben priorizar la fluidez donde el movimiento ayuda a comprender la situación o manipular el contenido; Debe evitar animaciones innecesarias que consuman potencia de procesamiento.

### inactivo

El tiempo libre es la oportunidad para prepararse para futuras interacciones: precargar posibles contenidos, analizar datos aplazados o inicializar componentes no críticos. Sin embargo, el trabajo en segundo plano debe seguir siendo interrumpible; Una tarea que monopoliza el hilo principal hace que la página parezca lenta tan pronto como el usuario interactúa con ella.

RAIL recomienda dividir el trabajo en blanco en unidades cortas para que la interacción tenga prioridad. Esto es especialmente importante en dispositivos de bajo consumo donde el mismo cálculo lleva más tiempo. [web.dev](https://web.dev/articles/rail)

###Cargar

La descarga no finaliza cuando el navegador descarga cada recurso. El objetivo significativo es mostrar contenido útil, establecer estabilidad visual y hacer que las interacciones clave estén disponibles lo más rápido posible.

Por lo tanto, una estrategia de carga basada en RAIL prioriza:

- Contenidos y estilos críticos.
- Primera aparición significativa.
- Código de interacción básico.
- Tamaños de diseño estables.
- Imágenes, guiones y funciones retrasados ​​que no se necesitan de inmediato.

### Usando RAIL hoyRAIL se entiende mejor como un modelo de planificación y priorización que no reemplaza las métricas modernas. Combínelo con Core Web Vitals, datos de campo y resultados de tareas para ver qué latencias son más importantes para los usuarios.

Por ejemplo, un equipo de producto puede descubrir que la página de destino se carga aceptablemente pero el filtro de búsqueda tarda 600 ms. RAIL dirige la atención a esa interacción porque la verdadera fuente de fricción no es sólo la carga inicial; es la respuesta. El principio central es: **optimizar los momentos en que los usuarios actúan, esperan y descubren lo que está sucediendo.**

## Diseñar el rendimiento desde cero

El rendimiento se logra más fácilmente cuando se integra en la base del producto en lugar de como una tarea de limpieza posterior al lanzamiento. Las decisiones tempranas sobre contenido, diseño, imágenes, fuentes, JavaScript, API y arquitectura determinan qué tan rápido será útil la experiencia y qué tan receptiva será en dispositivos reales.

### Establecer objetivos con antelación

Antes de crear pantallas detalladas, defina qué significa "suficientemente rápido" para los viajes de usuario más importantes:

- ¿Cuándo debería aparecer contenido significativo?
- ¿Cuándo debería poder interactuar el usuario?
- ¿Con qué rapidez deberían responder las principales acciones?
- ¿Cuánto movimiento de pedidos es aceptable?
- ¿Qué dispositivos y condiciones de red deberían ser compatibles?

Convierta estas respuestas en presupuestos de rendimiento para el peso de la página, el tamaño de la imagen, JavaScript, la fuente, el código de terceros, el tiempo de carga y la latencia de interacción. El presupuesto hace que el rendimiento sea una restricción de diseño común y no sólo un problema del desarrollador.

### Primero, tome decisiones de alto impacto

Los mayores beneficios a menudo provienen de decisiones tomadas antes de la implementación:

- Priorizar los contenidos esenciales antes que los medios decorativos.
- Diseñar el camino crítico antes de los rasgos secundarios.- Elija imágenes responsivas y recursos del tamaño adecuado.
- Reducir la dependencia de fuentes personalizadas y secuencias de comandos de terceros.
- Mantenga los diseños estables mientras carga contenido.
- Utilice mejoras progresivas para capacidades avanzadas.
- Evite interacciones que requieran solicitudes de red innecesarias.

Una interfaz pequeña y enfocada generalmente es más fácil de acelerar que una interfaz con muchas funciones que luego necesita ser optimizada.

### Prototipo de la experiencia real

Un archivo de diseño estático representa el estado final; pero no indica espera, carga parcial, falla o recuperación. Los prototipos deben incluir:

- Carga inicial lenta.
- Respuestas API retrasadas.
- Estados vacíos y esqueléticos.
- Indicadores de progreso.
- Conexiones desconectadas o caídas.
- Comportamiento de error y reintento.
- Restricciones de dispositivos de gama baja.
- Interacciones de teclado, tacto y accesibilidad.

Esto introduce problemas de UX relacionados con el rendimiento, aunque aún se pueden reemplazar de forma económica.

### Medir constantemente

Pruebe el rendimiento en cada etapa: revisión del diseño, prototipo, solicitud de extracción, versión candidata y producción. Utilice el laboratorio para reproducir problemas, el campo para comprender a los usuarios reales y las métricas del producto, como la finalización de tareas, el abandono y la satisfacción, para verificar que las mejoras técnicas estén funcionando.

El principio rector es **mover el rendimiento hacia la izquierda**: tomar decisiones importantes sobre el rendimiento antes de escribir el código, protegerlas con presupuesto y pruebas, y considerarlas parte de la definición de una característica terminada. Un producto rápido no se produce en una única pasada de optimización final; Está formado por cientos de pequeñas decisiones tomadas desde el principio.

## Parejas que se confunden con más frecuencia```text
❌ Performans UX’ten ayrıdır
✓ Performans, UX’in en görünür boyutlarından biridir

❌ Yeşil Core Web Vitals panosu ürünün iyi hissettirdiği anlamına gelir
✓ Metrikler gerçek sürtünme ve görev sonuçlarını temsil ettiğinde işe yarar

❌ Bekleme yalnızca saat süresidir
✓ Algılanan bekleme; geri bildirim, kesinlik ve kontrolle şekillenir

❌ Geliştirici laptopunda hızlı olmak “yeterince hızlı”dır
✓ Kapsayıcı performans sıradan cihazlar ve zor ağlardan başlar

❌ Lansmandan sonra optimize edin
✓ Performansı sola kaydırın: bütçe, prototip ve “bitti” tanımı ilk günden

Lista de verificación: trate el rendimiento como UX del producto

1. Enumere los cinco recorridos de mayor valor (en el mercado: búsqueda, detalles del producto, agregar al carrito, finalizar compra, recuperación de cuenta).
2. Para cada viaje, escriba la sensación de “roto” en un lenguaje sencillo: pantalla en blanco, tacto silencioso, rebote del diseño, clics repetitivos.
3. Establezca objetivos de contenido significativo, preparación para la interacción, latencia de respuesta y estabilidad del diseño.
4. No sólo la pantalla ideal; Diseñe estados de espera, error, fuera de línea y de recuperación.
5. Asigne Core Web Vitals (campo + laboratorio) al éxito, permanencia, fracaso, abandono y satisfacción de la tarea.
6. Identifique los dispositivos y redes clave que deben migrar antes de que el lanzamiento se considere "realizado".
7. Aplique la lente RAIL: ¿qué retrasos perjudican más la respuesta, la animación, el inactivo o la carga?
8. Convertir las respuestas en un presupuesto de desempeño de propiedad conjunta del diseño y la ingeniería.

Si no puede responder estas ocho preguntas, el rendimiento sigue siendo una ocurrencia tardía; No es un requisito del producto.

Puntos clave de este episodio

1. El rendimiento es UX: los usuarios experimentan los productos a lo largo del tiempo: apariencia, capacidad de respuesta, estabilidad y fluidez.
2. La lentitud cuesta confianza, conversión, retención y energía emocional; La primera espera es la primera impresión.
3. La espera percibida suele ser más importante que los segundos objetivos; Diseñe la retroalimentación, el progreso y el control en retrasos inevitables.
4. Medir juntos el rendimiento del sistema y los resultados del usuario; Elija viajes en lugar de puntuaciones de vanidad de página.
5. El diseño inclusivo y que prioriza el rendimiento comienza desde el dispositivo base, las redes imperfectas y los presupuestos iniciales.
6. RAIL mantiene la atención en las acciones de los usuarios y los momentos de espera; Core Web Vitals digitaliza partes de esta historia.

El objetivo no es poner el tablero en verde. El objetivo es ayudar a los usuarios a completar tareas importantes de forma rápida, segura y sin esfuerzos innecesarios.

A continuación: separaremos lo que siente el usuario de lo que miden las herramientas, de modo que las métricas se conviertan en la herramienta de decisión, no en la hoja de tocador.