Oluwafemi Obajuluwa › FastChow
Performance
Render work, not network speed
Performance
The biggest focus of the rebuild was performance, and most of it came down to render work rather than network speed.
The home feed was janky at first. The images were a big part of the cause and the app was repeating work it did not need to. Every card on screen was being rebuilt while you scrolled, because of how the list was wired together. Once each card only redrew when its own content changed, the scrolling smoothed out. That was most of the fix, before any library got swapped.
The rest is the same idea in different places. Screens show what they already have and refresh underneath, so going back somewhere is instant instead of a spinner. Cards reuse the same views as you scroll instead of building new ones. Tabs load when you first swipe to them and stay loaded, with the next one warmed up in the background, so swiping between search tabs does not stall.
The bag works this way too. It lives on your phone first. Tapping plus updates the screen straight away and the server catches up a moment later, in one batch, instead of a request per tap. You are never waiting on the network to find out whether your own tap counted, and rapid taps cannot fight with a stale reply.
The difference is most noticeable on lower-end Android devices, where a poorly optimised interface turns sluggish quickly. The objective was not to make the app technically faster. It was to make it feel faster.