criticalstaff2025

Duolingo Android

The 5-Second Wall

39% of Duolingo's entry-level Android users waited 5+ seconds to see the home screen. They weren't waiting for the server. They were waiting for an ad.

The Incident

Duolingo's 2025 Android performance audit revealed a stark split: flagship device users had an acceptable experience, but 39% of users on entry-level Android devices — the dominant hardware in Duolingo's emerging-market growth markets — experienced startup latency above 5 seconds. App-open conversion rate was only 91% on these devices, meaning 9% of users who opened the app gave up before the home screen loaded. Three independent blocking operations were responsible.

Evidence from the Scene

  • 39% of entry-level device users experienced 5+ second startup (flagship users: under 2 seconds)
  • App-open conversion rate was 91% on budget devices — 9% of opens abandoned before home screen
  • Android Profiler showed a WebView being created on the main thread during startup
  • A network call with a 1+ second P99 in India completed before the home screen rendered
  • Course data deserialization from a multi-megabyte JSON payload blocked the UI thread
  • Removing the startup network call in a local test cut startup by ~30% immediately

The Suspects

3 of these are the real root causes. The others are plausible-sounding distractors.

Ads SDK initializing a WebView on the main thread during app startup

Synchronous site availability HTTP request blocking home screen render

Multi-megabyte course data payload deserialized synchronously on the UI thread at startup

Missing Baseline Profiles causing JIT warmup overhead on new installs

Full-resolution character illustrations loaded synchronously before home screen displayed

The Verdict

Real Root Causes

  • Ads SDK initializing a WebView on the main thread during app startup

    WebView initialization is one of the most expensive operations on Android — it loads a Chromium instance. Running it on the main thread during startup added over 1.5 seconds to cold start on entry-level devices. Deferring ads SDK initialization until after the home screen rendered eliminated this entirely.

  • Synchronous site availability HTTP request blocking home screen render

    A network call to check service availability completed synchronously before the home screen rendered. In high-latency markets (India, Brazil), this added 1+ second to every startup. Making it non-blocking with caching removed it from the critical path.

  • Multi-megabyte course data payload deserialized synchronously on the UI thread at startup

    Duolingo's course data had grown to multi-megabyte JSON payloads. Deserializing this on the main thread at startup added hundreds of milliseconds on slow CPUs. The fix: split into on-demand chunks and deserialize off-thread.

Plausible But Wrong

  • Missing Baseline Profiles causing JIT warmup overhead on new installs

    Duolingo did add Baseline Profiles as part of the fix (achieving an additional 30% startup improvement in a separate initiative), but the 5-second wall on entry-level devices was caused by the three blocking main-thread operations, not JIT compilation.

  • Full-resolution character illustrations loaded synchronously before home screen displayed

    Image loading via Coil/Glide runs on background threads and does not block TTID. The blocking operations here are all explicitly on the main thread: WebView init, network call, and JSON deserialization.

Summary

Duolingo's entry-level Android users were stuck at a 5-second wall caused by three independent main-thread blocking operations: an ads SDK creating a WebView during startup, a synchronous network availability check, and multi-megabyte course data being deserialized inline. After running 200+ A/B tests to validate each fix, Duolingo cut the percentage of users experiencing 5+ second startup from 39% to 8% and improved app-open conversion from 91% to 94.7% on budget devices — recovering hundreds of thousands of daily active users. Published June 2025.

The Real Decision That Caused This

“Integrating an ads SDK without measuring its initialization cost on low-end hardware, and not establishing a policy that nothing blocking runs on the main thread before the home screen renders.”

Lesson Hint

Chapter 7 (Platform & Performance) covers startup optimization, StrictMode, and the App Startup library. Chapter 4 (Networking) covers async request patterns and caching strategies to remove network from the startup critical path.

Want to test yourself before reading the verdict?

Open Interactive Case in Autopsy Lab