How to generate business value through performance optimizations

Performance is the most overlooked problem in mobile engineering — not because engineers don't care, but because it's invisible. When something crashes, there's a log. When servers cost too much, there's a bill. When an app is slow, users just leave. No alert fires, no ticket gets filed. That invisibility is the whole problem, and the talk is a systematic answer to it. The framework it introduces — Performance, Reliability, Efficiency — exists to show that these three things are connected and pull against each other. Making one screen faster can make the whole system more expensive. Understanding the trade-offs is what separates reactive firefighting from deliberate engineering. The core of the talk is a cycle: instrument the app, collect the right data, analyze it, prioritize what to fix, implement, and validate. The instrumentation piece is more nuanced than it sounds — what you measure and where you start the timer matters. The rule is to measure what the system does, not what the user does, because user behavior introduces noise that makes the data useless. Once you have data, averages mislead. Percentiles tell the truth. A small number of metrics — median latency, tail latency, success rate, failure rate, abandonment rate — gives a complete picture of any screen. Abandonment is the one most teams ignore, and it's the most honest signal: a user who left before the page loaded is a direct conversion loss that shows up nowhere in traditional monitoring. The abandonment curve is where engineering data becomes a business argument. It shows exactly how increasing load time drives users away, with a clear inflection point above which every additional millisecond has an outsized cost. That curve, combined with traffic volume, tells you where to focus: a small improvement on the screen every user sees daily is worth more than a large improvement on a screen almost nobody visits.