A player can update its on-screen timer many times a second. That does not mean each update should become a network request. Progress saving needs a smaller set of useful checkpoints.
Think about the moments when someone expects their place to be safe: pausing, changing episodes, seeking, leaving the player, and listening for a meaningful interval.
Separate display time from saved time
Update the local display smoothly. Keep a local pending position for recovery. Send a bounded progress update on your chosen schedule and at important player events. Use the documented API fields and units rather than copying a formatted time label into a request.
Coalesce nearby changes. If a listener seeks three times in two seconds, the final stable position is usually more useful than three competing writes. Keep requests ordered or carry enough local state to prevent an older response from replacing newer state in your interface.
Do not rely only on a page-close event. Browsers and operating systems can stop a process without giving it enough time to complete a final request. Regular checkpoints reduce the amount of progress at risk.
Measure the tradeoff
A shorter interval can preserve a more recent position but creates more writes and battery work. A longer interval reduces traffic but can lose more progress after an interruption. Choose deliberately and check the actual request budget.
Test pause, app suspension, an airplane-mode transition, and a force-close in a controlled environment. Record the maximum lost interval you observe rather than claiming perfect continuity.
The best schedule is the simplest one that meets your listener's expectations and the API's limits. Keep it configurable in one place so the team can improve it without editing every player screen.