Plus rapide et plus lisse : une mise à niveau majeure de l'application révèle une révision de l'interface utilisateur et une augmentation de la vitesse du backend de 200 %

Par DeHub Team — 2024-10-28

Au troisième trimestre 2024, nous avons révisé l'interface utilisateur et amélioré la vitesse du backend de 200 %.

Pourquoi ils ont expédié ensemble

Parce que séparément, ce sont tous les deux de mauvaises versions.

Une refonte sur un backend lent est une application plus lente qui a l'air différente, et les utilisateurs la perçoivent comme un déclassement, quelle que soit la qualité de la conception. Le changement visuel attire l'attention sur chaque attente. Une amélioration du backend sans changement visible est invisible : les utilisateurs ne remarquent pas trois fois plus vite si la chose qu'ils attendent est exactement la même.

Ensemble, ils constituent une seule amélioration perceptible. Tout semble différent et tout répond immédiatement, et ceux-ci se renforcent plutôt que de se saper mutuellement. C'est pourquoi la même version a suscité 95 % de commentaires positifs.

## Ce que « 200 % plus rapide » signifie

Trois fois le débit précédent, sur les chemins qui comptent — charges d'alimentation, démarrages de flux, opérations de portefeuille, lancements d'arcade.

Le détail honnête est que ce n'était pas une optimisation intelligente. C'était le coût cumulé de quatre années d'expédition, remboursé. Requêtes écrites lorsque l'ensemble de données était petit et n'a jamais été revisité. Appels séquentiels qui auraient toujours pu être parallèles. La mise en cache s'appliquait là où c'était facile plutôt que là où cela aidait. Chacun d'entre eux était individuellement raisonnable à l'époque et collectivement coûteux.

Il n'existe pas de version glamour de ce travail. Il s'agit de mesurer, puis de décocher, puis de mesurer à nouveau.

Ce que la refonte a réellement changé

Moins qu'une comparaison de capture d'écran ne le suggère, et plus que ce que les utilisateurs pourraient articuler.

Les 50 entretiens avec les utilisateurs de 2021 avaient produit deux conclusions qui sont restées vraies trois ans plus tard : la configuration du portefeuille était l'endroit où les gens abandonnaient, et tout ce qui nécessitait un modèle mental pour comprendre sa valeur était traité avec suspicion. La refonte était en grande partie ces deux résultats appliqués sur toute la surface.

Moins d'étapes entre l'ouverture de l'application et l'action. Des énoncés plus clairs de la valeur d'une action avant de la prendre. Moins de l'application en supposant que vous saviez déjà comment cela fonctionnait.

Ce qu'il n'a pas corrigé

Intégration, entièrement. Elle s'est améliorée et est restée l'endroit le plus fréquenté par les gens, ce qui est la découverte la plus persistante de l'histoire de DeHub.

La découverte est également restée faible, et cela a alimenté la refonte du flux avec des réponses audio et des espaces de discussion en direct l'année suivante.

Pourquoi le travail rapide comptait le plus

Parce que tout après dépendait de la marge de manœuvre. L 'intégration Livepeer pour plus de 50000 spectateurs simultanés, le CDN personnalisé et le temps de disponibilité de 99,99 % au premier trimestre 2025 tous sont arrivés dans les deux trimestres, et aucun d'entre eux n'aurait pu survivre sur le backend tel qu'il était à la mi-2024.

Comment la dette s'est accumulée

Pas par négligence, ce qui est l'explication réconfortante et la mauvaise.

Chaque requête lente dans cette base de code a été écrite par une personne compétente, dans les délais impartis, en fonction d'un ensemble de données où elle s'est bien déroulée. Chaque appel séquentiel qui aurait dû être parallèle était séquentiel parce que c'était la version correcte la plus simple à l'époque. Rien de tout cela n'était une erreur quand il a été fait.

L'erreur était structurelle : rien dans notre processus n'a jamais revu une décision après que les conditions qui la justifiaient aient changé. Le code a été révisé lorsqu'il a été écrit et plus jamais.

La solution n'était pas de meilleurs ingénieurs. Il s'agissait de faire de la performance une mesure permanente plutôt qu'une réponse à un incident, de sorte que la dégradation apparaît comme une tendance plutôt que comme une plainte.