Reducción del tamaño de respuestas API para una UX móvil más rápida: pasos prácticos

Cómo se ven las “respuestas API hinchadas” en móvil

En móvil, las respuestas API hinchadas se traducen en pantallas lentas que se quedan en un spinner, incluso con Wi‑Fi decente. En conexiones más débiles la demora se nota: los toques se sienten lentos y el desplazamiento de listas puede dar tirones mientras la app espera los datos.

La causa es simple. La app descarga más datos de los que necesita para renderizar la pantalla. Ese JSON extra aún tiene que viajar por la red, ser parseado y ocupar memoria. Si la UI nunca muestra la mayor parte, el usuario paga un coste sin beneficio.

El bloat suele esconderse en unos pocos lugares:

• Objetos anidados profundos que pertenecen a otras pantallas (por ejemplo, perfiles de usuario completos dentro de cada comentario)
• Arrays grandes obtenidos “por si acaso” (500 ítems cuando la pantalla muestra 20)
• Campos repetidos copiados en muchos ítems (el mismo objeto de categoría dentro de cada producto)
• Campos pesados que suman rápido (descripciones largas, HTML, metadatos de imágenes, logs de auditoría)

Imagínate una pantalla de catálogo que muestra nombre del producto, precio, miniatura y “en stock”. Si la respuesta además incluye datos completos del vendedor, productos relacionados por ítem y reseñas, el primer pintado se vuelve más lento sin ningún beneficio visible.

El objetivo no es hacer respuestas diminutas a toda costa. Es enviar el payload más pequeño que todavía alimente la pantalla, y nada más. Si se hace de forma consistente, la UX móvil suele sentirse más rápida sin cambiar la UI.

Por qué payloads más pequeños suelen significar mejor UX móvil

En móvil, la velocidad suele estar limitada por la red, no por el teléfono. Una respuesta que va bien en la red de la oficina puede sentirse lenta en celular, donde el ancho de banda cae y la latencia sube cuando el usuario se mueve o pierde señal.

El tamaño te perjudica de varias formas. Respuestas más grandes tardan más en descargarse y sufren más cuando se pierden paquetes y hay reintentos. La pantalla espera más antes de poder mostrar algo útil.

También hay un coste en batería y CPU. Más bytes implican más tiempo de radio y más trabajo para decodificar y parsear JSON. En teléfonos de gama baja, parsear objetos anidados grandes puede volverse notable, especialmente si compite con trabajo de UI.

Síntomas típicos:

• Renderizado inicial más lento porque la app espera el payload completo
• Toques y desplazamiento retrasados si el parseo compite con la UI
• Más estados de “cargando” mientras la app transforma datos
• Más fallos y timeouts en conexiones pobres

El servidor también lo nota. Payloads mayores aumentan el coste de ancho de banda y reducen el throughput, ya que cada petición tarda más en construirse, serializarse y enviarse. Respuestas más ligeras suelen mejorar tanto el rendimiento cliente como la eficiencia del servidor.

Encuentra lo que tu app no usa (auditoría simple)

Elige una pantalla lenta o que consuma muchos datos. Una sola pantalla basta para revelar patrones que puedes aplicar en toda la API.

Primero, escribe literalmente lo que la pantalla muestra. Si muestra un título, precio, miniatura y una insignia “en stock”, esos son los campos que importan para esa vista.

Luego compara esa lista con la respuesta real que recibe la app (inspector de red, proxy o logs del servidor). Aquí es donde el bloat suele volverse obvio: vuelven objetos grandes “por si acaso”, aunque la pantalla nunca los use.

Una auditoría rápida que puedes hacer en 15 minutos:

• Captura una respuesta real para esa pantalla (no un mock).
• Resalta los campos que la pantalla usa ahora mismo.
• Marca los campos que no se usan en esta pantalla (especialmente objetos anidados).
• Señala las partes pesadas: arrays largos, includes profundos, blobs grandes de metadatos.
• Decide qué se queda ahora, qué pasa a una llamada posterior y qué se elimina.

Patrones a cuestionar: un objeto user completo adjunto a cada elemento, includes profundos como order -> customer -> addresses -> ..., y objetos de “metadata” que crecen con el tiempo. Otra señal de alarma es enviar a la vez una versión resumen y una detallada del mismo contenido cuando la pantalla muestra solo una.

Escribe las decisiones. Esa nota corta se convierte en tu plan de cambios y reduce el riesgo de cortar algo que otra pantalla realmente necesita.

Victorias rápidas: recorta objetos anidados y listas pesadas

Los wins rápidos suelen venir de detener “cosas extra” en la fuente. Si una pantalla solo necesita un nombre y un estado, devolver un perfil anidado completo (configuraciones, permisos, logs de auditoría, timestamps) es un desperdicio en cada petición.

Una regla práctica: reemplaza includes profundos por identificadores más un pequeño resumen. En lugar de incrustar un customer completo en cada order, devuelve customerId y un par de campos que la UI realmente muestra (por ejemplo, customerName). Obtén los detalles completos cuando el usuario abra la página del cliente.

Los includes por defecto son otro problema común. Los objetos relacionados se añaden “temporalmente” y nunca se quitan. Si la pantalla no lo muestra, no lo envíes.

También elimina campos que no deberían salir del servidor, como cadenas de depuración, flags internos que el cliente no usa, valores computados duplicados, campos obsoletos tras un refactor y blobs grandes (HTML/markdown/base64) cuando un resumen corto basta.

Las listas pesadas suelen ser el mayor motor de payload. Limítalas y pagínalas. Un patrón común es “top N más un conteo”: devuelve topReviews (primeras 3) y reviewCount, y solo carga la lista completa en la pantalla de reseñas.

Paso a paso: añade selección de campos sin romper clientes

La selección de campos es una forma limpia de adelgazar respuestas sin forzar una gran reescritura. La regla principal es compatibilidad hacia atrás: las versiones antiguas de la app deben seguir funcionando.

Un patrón de despliegue seguro

Comienza con un enfoque:

• Allowlist de campos por endpoint (mejor cuando quieres control estricto)
• Un parámetro de consulta fields= (mejor cuando distintas pantallas necesitan formas distintas)

Luego despliega:

1. Mantén defaults seguros. Si un cliente no envía fields, devuelve la misma respuesta que devuelves hoy.
2. Haz fields opcional. Ejemplo: GET /products?fields=id,name,price,thumbnailUrl.
3. Proporciona varios conjuntos de campos nombrados para pantallas comunes. Aunque sigas usando fields=, documenta qué piden típicamente “home”, “list” y “details”.
4. Entrega soporte en el servidor primero y luego actualiza la app. Los clientes antiguos seguirán recibiendo el payload por defecto.
5. Mide, luego ajusta. Cuando la mayoría de usuarios estén en la nueva versión, considera reducir la respuesta por defecto (o mantenerla si debes soportar clientes antiguos).

Campos anidados: mantén reglas simples

La selección anidada es donde aparece la complejidad. Puedes mantener la selección plana (solo primer nivel) o permitir un pequeño formato anidado con reglas estrictas.

Un formato simple es: fields=id,name,price,category(id,name). Si eso es demasiado, usa include= para relaciones (ejemplo: include=category) y mantiene fields solo de primer nivel.

Añade validación para que la selección no exponga datos que nunca pretendiste devolver:

• Rechaza campos desconocidos con un error claro
• Bloquea campos sensibles (secretos, notas internas, tokens crudos)
• Limita la profundidad y el número de campos para prevenir consultas costosas
• Solo permite campos que explícitamente estén en la allowlist

Un setup práctico: las pantallas de lista piden id,name,price,thumbnailUrl y las de detalle añaden description,images,availability. Mismo recurso, payload más pequeño donde importa.

Da forma a tus endpoints para listas y vistas de detalle

Una razón común por la que las pantallas móviles van lentas es que los endpoints de lista actúan como “dame todo”. Un feed solo necesita datos suficientes para renderizar filas rápidamente. Deja los datos profundos para la pantalla que abre un ítem.

Un patrón simple es dos formas:

• Resumen para listas (pequeño, predecible, rápido)
• Detalle para un ítem (más grande, completo)

Haz intencionadamente pequeños los endpoints de lista

Para listas y feeds, devuelve solo lo que la UI puede mostrar en la lista: id, título, URL de miniatura pequeña, estado corto y uno o dos atributos clave.

Mantén las listas acotadas y pagínalas por defecto, aunque los datasets “normalmente” sean pequeños. Usa paginación por página+límite o cursor e incluye un puntero claro al siguiente.

Ten cuidado con los totales. Un conteo total puede ser caro si fuerza trabajo extra. Si la UI solo necesita “cargar más”, hasNext suele ser suficiente.

Finalmente, no devuelvas historiales completos por defecto. Logs, mensajes, eventos y auditorías crecen para siempre. Devuelve la página más reciente y pagínala.

Reserva datos pesados para endpoints de detalle

Los endpoints de detalle pueden incluir objetos anidados, descripciones largas y registros relacionados porque se llaman con menos frecuencia.

Ejemplo: GET /products devuelve campos de resumen solo. Cuando el usuario toca un producto, GET /products/{id} devuelve variantes, imágenes completas, reseñas y reglas de inventario. Si luego necesitas más flexibilidad, añade selección opcional de campos, pero mantén los defaults de lista pequeños y estables.

Conceptos básicos de compresión y caché (manténlo simple)

La compresión y la caché son buenas mejoras “después”. La compresión hace cada viaje más pequeño. La caché evita el viaje.

Compresión: cuándo ayuda (y cuándo no)

Activa gzip o brotli para respuestas JSON. La compresión ayuda más cuando las respuestas son textuales y repetitivas (común con claves JSON y valores repetidos). En redes móviles lentas puede reducir mucho el tiempo de transferencia.

La compresión ayuda menos cuando las respuestas ya son diminutas, ya están comprimidas (imágenes, PDFs) o cuando tu servidor está limitado por CPU. Si la respuesta promedio es 2–5 KB, la compresión rara vez es el cuello de botella principal.

Una regla simple: comprime JSON por defecto y manténlo aburrido.

Caché: evita re-descargar lo que no cambió

La caché puede ser una gran ganancia porque muchas pantallas reutilizan los mismos datos (categorías, feature flags, ajustes de usuario, países de envío). Cachea datos estables de forma agresiva y refréscalos solo cuando cambien.

Mantén reglas de caché predecibles:

• Cachea datos de referencia con un disparador de refresco claro (actualización de la app, refresco manual o un número de versión)
• Cachea ajustes de usuario hasta que el usuario los cambie
• No caches feeds muy personales o que cambian rápido a menos que tengas un plan claro de invalidación

Para evitar re-descargar datos sin cambios, soporta requests condicionales (por ejemplo, ETags). El servidor devuelve un ETag; el cliente lo envía la próxima vez. Si nada cambió, el servidor responde con 304 Not Modified y sin body.

Si trabajas con un backend generado por IA, la caché y la compresión suelen ser más seguras una vez que hayas eliminado el overfetching accidental y las formas de respuesta inconsistentes.

Un ejemplo realista: adelgazar la respuesta de una pantalla de catálogo

Imagínate una pantalla de lista de productos. Cada fila muestra nombre, precio, una miniatura pequeña y una insignia de stock. Eso es todo. Pero la API devuelve el objeto de producto completo de todos modos, más datos relacionados que la pantalla nunca toca.

Antes (bloat común): el endpoint de lista devuelve descripciones completas, todas las imágenes en múltiples tamaños, perfiles de vendedores, cuerpos de reseñas y metadata extra. En un teléfono eso significa más bytes para descargar, más JSON para parsear y más tiempo antes de que la lista se sienta responsiva.

{
  "products": [
    {
      "id": "p_123",
      "name": "Trail Running Shoes",
      "price": 89.99,
      "thumbnail": {"url": "...", "w": 200, "h": 200},
      "stock": {"status": "in_stock", "count": 42},
      "description": "...long text...",
      "images": [{"url": "..."}, {"url": "..."}],
      "seller": {"id": "s_9", "name": "...", "bio": "...", "payout_settings": "..."},
      "reviews": {"avg": 4.7, "items": [{"body": "..."}]}
    }
  ]
}

Después (respuesta de lista reducida): devuelve solo lo que la lista necesita, más un id estable para la llamada de detalle.

{
  "products": [
    {
      "product_id": "p_123",
      "name": "Trail Running Shoes",
      "price": 89.99,
      "thumbnail_url": "...",
      "stock_badge": "in_stock"
    }
  ]
}

Cuando el usuario toca un ítem, la pantalla de detalle obtiene el resto (imágenes completas, descripción, perfil del vendedor, reseñas). La lista carga antes y tiende a desplazarse con más suavidad porque la app pasa menos tiempo esperando y parseando.

Errores comunes y trampas a evitar

La forma más rápida de perder los beneficios es lanzarlo sin guardrails. La mayoría de problemas aparecen en producción, donde versiones antiguas de la app y datos reales chocan.

Un error común es añadir selección de campos y, por accidente, hacer seleccionables datos privados. Trata la selección como una allowlist, no como un espejo de las columnas de la base de datos. Si un campo es sensible (tokens, notas internas, precio de coste, flags de admin), nunca debe ser seleccionable.

Otra trampa es romper builds móviles antiguas cambiando defaults demasiado agresivamente. Si ayer la respuesta siempre incluía name y price, no exijas de repente fields=name,price para seguir teniéndolos.

El recorte excesivo también puede provocar un patrón N+1. Si una pantalla muestra 20 ítems y cada ítem ahora necesita una llamada adicional para obtener info básica, el tiempo total puede empeorar en móvil. Busca “una llamada por pantalla” cuando sea práctico: un payload de lista pequeño que aún contenga todo lo necesario para renderizar.

Finalmente, no olvides el tamaño de los payloads de error. Trazas de stack gigantes, detalles de validación repetidos y cuerpos de request reflejados pueden ser más grandes que tus respuestas exitosas. Mantén los errores cortos, consistentes y seguros.

Guardrails que funcionan:

• Usa una allowlist para campos seleccionables
• Mantén defaults compatibles hacia atrás
• Mide el número de llamadas además del tamaño del payload
• Separa formas de lista y detalle
• Limita y sanea las respuestas de error

Lista de comprobación rápida antes de publicar cambios

Antes de cortar campos o cambiar formas, deja claro qué necesita realmente cada pantalla. Un pequeño desajuste puede convertirse en texto faltante, ordenación rota o un crash que solo aparece en redes lentas.

Comprobaciones prácticas previas al envío:

• Para cada pantalla, confirma que la app lee cada campo que planeas mantener
• Elimina campos que ningún código usa, pero no cambies el significado de campos existentes
• Pon límites estrictos en listas grandes (paginación y un tamaño máximo razonable)
• Evita objetos anidados profundos por defecto; devuelve IDs o pequeños resúmenes a menos que el cliente lo pida explícitamente
• Si soportas selección de campos, usa una allowlist y nunca pases nombres de campo crudos a consultas de base de datos

Luego mide el impacto. Registra tamaño del payload y tiempo de respuesta antes y después en un dispositivo real, idealmente con una conexión lenta. Observa el tracking de errores tras el lanzamiento.

Siguientes pasos: convierte el slimming de payloads en rutina de release

La optimización de respuestas API funciona mejor como hábito. Empieza con una pantalla de alto tráfico donde las cargas lentas sean más obvias (feed de inicio, resultados de búsqueda, lista de catálogo), reduce ese endpoint, mide el impacto y repite.

Define objetivos simples para que quede claro qué es “bueno”:

• Pantallas de lista: respuestas pequeñas que carguen rápido en celular
• Pantallas de detalle: más datos, pero solo lo que la UI realmente necesita
• Respuestas de error: pequeñas y consistentes

Cuando necesites flexibilidad, mantiene la selección de campos predecible: un único parámetro y un pequeño conjunto de campos conocidos o presets nombrados.

Si heredaste un backend generado por IA, ten cuidado: los cambios de respuesta suelen convivir con lógica enmarañada o peligros de seguridad (como secretos expuestos o inyección SQL). FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar codebases generados por IA y puede validar las formas de respuesta, la autenticación y el endurecimiento de seguridad antes de que publiques cambios.