How live updating works
Three gates, four rate tiers, and one shared cache.
Live starts updating by itself when the page has live data to show — a competition running today, or a favourite out on a course — and stops the rest of the time. Browsing finished results makes no requests.
There is no control to start or stop it.
The three gates
A request only goes out when all three of these are open:
| Gate | Open when | Why it exists |
|---|---|---|
| Armed | The page has live data — a race running today, or a favourite on a course | Browsing history should cost nothing |
| Visible | The tab is in front | A phone in a pocket costs nothing, whatever else is true |
| Online | The device has a connection | Failing requests help nobody |
Switching tabs or locking the phone stops polling immediately. Coming back returns every class to full rate at once, so what you see first is current.
A tab left open stops updating after two hours. Returning to it resets that cut-off.
The interval, and how it stretches
The base interval is yours to pick — 15, 30 or 60 seconds in Settings. Each class then multiplies that base by how busy it is:
| Class state | Multiplier | At a 15 s base |
|---|---|---|
| Something changed in the last 90 s | 1× | every 15 s |
| Quiet for 90 s to 6 min | 2× | every 30 s |
| Quiet for over 6 min | 4× | every 60 s |
| Settled — everyone finished or terminal | 6× | every 90 s |
"Changed" is measured against a hash the feed stamps on each class, so it tracks real changes in the data. A class taking punches keeps full rate while quiet ones back off, which is what makes a club page watching thirty classes inexpensive to leave open. A class Live has not seen before starts at full rate.
Why 15 seconds is the floor
The cache, and why viewer count does not matter
The browser never calls the timing feed directly. Every request goes through Live's own API, behind a shared cache:
| What | Cached for | Then served stale for | Why |
|---|---|---|---|
| Competition list | 120 s | 900 s | Changes hourly at most |
| Class list | 120 s | 900 s | Fixed once a race is set up |
| Results, running class | 8 s | 30 s | Fast enough to feel live |
| Results, settled class | 60 s | 600 s | Nothing can change |
| Passings | 8 s | 30 s | The live ticker |
| Entry index | 600 s | 3600 s | Entry lists are static once a race is running |
| Any error | not cached | — | A blip must not stick to the cache |
Every view of a class shares one cache entry, so load on the timing feed depends on how many classes are live rather than how many people are watching. Ten thousand viewers of one class produce the same upstream traffic as one.
On a cache miss the previous copy is served immediately and refreshed in the background, so a request rarely waits on the timing feed.
The class ceiling
A single screen watches at most 40 classes live. A large club at a big competition, or a long favourites list spread across several races, can exceed that; where it does, Live reports how many classes it left out.
If updating seems to have stopped