Más rápido y elegante: una importante actualización de la aplicación revela una revisión de la interfaz de usuario y un aumento de la velocidad del backend del 200%
Por DeHub Team — 2024-10-28
En el tercer trimestre de 2024 revisamos la interfaz de usuario y mejoramos la velocidad del backend en un 200%.
Por qué enviaron juntos
Porque por separado ambos son malos lanzamientos.
Un rediseño en un backend lento es una aplicación más lenta que se ve diferente, y los usuarios la experimentan como una degradación sin importar qué tan bueno sea el diseño: el cambio visual llama la atención sobre cada espera. Una mejora de backend sin cambios visibles es invisible: los usuarios no notan tres veces más rápido si lo que están esperando se ve exactamente igual.
Juntos son una sola mejora perceptible. Todo se ve diferente y todo responde de inmediato, y eso se refuerza en lugar de socavarse mutuamente. Es por eso que el mismo lanzamiento obtuvo un 95% de comentarios positivos.
Qué significa "200% más rápido"
Tres veces el rendimiento anterior, a través de las rutas que importan: cargas de alimentación, inicios de transmisión, operaciones de billetera, lanzamientos de arcade.
El detalle honesto es que esta no fue una optimización inteligente. Era el coste acumulado de cuatro años de envío, pagado. Consultas escritas cuando el conjunto de datos era pequeño y nunca se volvieron a visitar. Llamadas secuenciales que siempre podrían haber sido paralelas. El almacenamiento en caché se aplicó donde fue fácil en lugar de donde ayudó. Cada uno de ellos era individualmente razonable en ese momento y colectivamente caro.
No hay una versión glamorosa de este trabajo. Se trata de medir, luego desempaquetar y luego volver a medir.
Lo que realmente cambió la revisión
Menos de lo que sugiere una comparación de captura de pantalla y más de lo que los usuarios podrían articular.
Las 50 entrevistas a usuarios de 2021 habían producido dos hallazgos que se mantuvieron tres años después: la configuración de la billetera era donde las personas se daban por vencidas, y cualquier cosa que requiriera un modelo mental para comprender su valor se trataba con sospecha. La revisión fue en gran medida esos dos hallazgos aplicados en toda la superficie.
Menos pasos entre abrir la aplicación y hacer algo. Declaraciones más claras de lo que vale una acción antes de tomarla. Menos de la aplicación, suponiendo que ya supieras cómo funcionaba.
Lo que no arregló
Incorporación, por completo. Mejoró y siguió siendo el lugar más común donde la gente se detiene, que es el hallazgo más persistente en la historia de DeHub.
Discovery también se mantuvo débil, y eso alimentó el feed renovado con respuestas de audio y espacios de conversación en vivo al año siguiente.
## Por qué el trabajo rápido era lo más importante
Porque todo después dependía del espacio para la cabeza. La integración de Livepeer para más de 50.000 espectadores simultáneos, el CDN personalizado y el 99,99% de tiempo de actividad en el primer trimestre de 2025, todos ellos son compatibles. llegó en dos trimestres, y ninguno de ellos habría podido sobrevivir en el backend tal como estaba a mediados de 2024.
Cómo se acumuló la deuda
No por descuido, que es la explicación reconfortante y la equivocada.
Cada consulta lenta en esa base de código fue escrita por alguien competente, bajo una fecha límite, contra un conjunto de datos en el que se desempeñó bien. Cada llamada secuencial que debería haber sido paralela era secuencial porque esa era la versión correcta más simple en ese momento. Nada de eso fue un error cuando se cometió.
El error fue estructural: nada en nuestro proceso revisó una decisión después de que las condiciones que la justificaban hubieran cambiado. El código se revisó cuando se escribió y nunca más.
La solución no fue mejores ingenieros. Estaba haciendo del rendimiento una medida permanente en lugar de una respuesta a incidentes, de modo que la degradación aparece como una tendencia en lugar de como una queja.