By default a page loads fresh every time it cycles back in the playlist. For most pages that is the whole answer: a page that builds its content on load picks up the latest data on every cycle without any setting.
When the playlist cycle is not enough
If a page holds the screen for a long time and its data can go stale while it sits there, the cycle is too slow. A logistics board on screen for twenty minutes, querying live data only on load, is showing twenty-minute-old numbers by the end.
The old trick for this was adding the same URL twice with a different query string. That still works and is occasionally useful, but the settings below are the direct route.
Pages that update themselves
Many dashboards refresh their own data over a websocket or a polling connection, and keep updating while they sit on screen. Those need nothing.
Forcing a reload on a self-updating page makes it worse. Every reload interrupts the live connection and restarts the page’s own update logic. If a dashboard refreshes itself, leave it alone and set the playlist duration to how long it should be visible.
Screenshot settings
These apply when a page is rendered on our side rather than on the device, which is the Screenly Anywhere path.
Screenshot cache timeout controls how long a captured screenshot is reused before a new one is taken, from 60 seconds to 24 hours. Raise it for content that rarely changes and lower it when the page needs to be current. Every capture costs time, so this is a real trade rather than a free dial.
Screenshot delay is how long we wait after the page loads before capturing. A page that assembles itself after the initial load, which is most dashboards, arrives half-empty without this. If a captured page is missing its charts, this is the setting to raise.
Choosing a duration instead
Often the right fix is neither. A page that should be current is a page that should be on screen briefly and come round often, rather than one held up for twenty minutes and refreshed behind the scenes. See How long things play.