A podcast home screen often combines several tasks: continue an episode, find updates from followed shows, and discover something new. Loading them as one all-or-nothing request can leave the page blank when only a secondary section is slow.
Start by ranking the listener's immediate jobs. “Continue listening” may matter more than a large recommendation grid when someone has a few minutes before leaving home.
Give sections independent states
Show a section's loading, empty, error, and ready states separately where your architecture permits it. A failed discovery request should not hide a successfully loaded saved episode.
Keep private and public data sources distinct. A cached public catalog record can provide a title or image, but the fact that a listener followed or played it belongs to that account. Make sure shared caches cannot return personalized rows to another person.
Avoid duplicating the same episode across several sections without a reason. If a followed episode is already in the continue row, you may choose to keep it out of a lower “new for you” group. Use stable episode IDs for that rule.
Check the first useful screen
Test an account with no follows, one with a paused episode, and one with many subscriptions. Delay a nonessential request and confirm that the most useful action still appears.
A fresh account needs a different empty state from a returning listener whose data failed to load. Explain the difference through the next available action rather than showing the same generic illustration.
Measure time to a meaningful action, not only time until every card finishes loading. A smaller, reliable first screen can serve listeners better than a complete page that arrives too late.