bfBuster 1.0.0

Threads a member has just read still show as unread when they press Back.​

Noticeable on desktop, constant on a phone.

Why it happens​

The page is never re-requested. Browsers keep the previous page in the back/forward cache, a snapshot of the live page, DOM and JavaScript heap intact, and restore it when you press Back.

This is deliberate. It is why Back feels instant, and it happens regardless of Cache-Control. A page can be fully dynamic, private, and never touched by a CDN, and still come back exactly as it was. The only response header that prevents it is no-store.

XenForo has nothing watching for it. It registers two pageshow handlers, one that resets a timing value and one that hides the PWA loading indicator. Neither touches unread markers.

So a restored page keeps whatever it was showing when the member left it.

Nothing has gone wrong. Nobody asked.

What it does​

Listens for pageshow with event.persisted set to true, which only happens for a back/forward cache restore, and refreshes the page.

Two conditions must both hold:

The page has to be one where read state is visible.

The page type comes from the data-template attribute XenForo already puts on <body>, so no markup is added and nothing needs modifying to carry it.

Out of the box, that is the forum list, a forum's thread list, What's New, watched threads and search results.

Threads, profiles, conversations and add-on pages are untouched and keep their instant Back.

Something has to have been read while the page was away.

Opening a thread bumps a counter in sessionStorage. Each page records the counter as it loads, and the back/forward cache restores that value along with everything else.

On the way back, the two are compared. If nothing was read, the restore is left alone.

A Back from a profile, a search or another list stays instant.

Members only. Guests have no read state to go stale.

The trade-off​

You cannot have both an instant Back and guaranteed-fresh read state on the same page.

The back/forward cache is fast precisely because it does not ask the server, so anything that fixes staleness spends some of that.

This spends it as narrowly as it can: only on pages that show read state, and only after the member has actually read something.

Everything else keeps the cache.

If a full load on those returns is still worse for you than a stale unread marker, this add-on is not what you want.

A blanket Cache-Control: no-store, which turns the cache off board-wide, is very much not what you want.

Cost​

Measured on a live-sized board:

• +330 bytes gzipped on member pages. Nothing on guest pages.
• 0.003 ms of server render time per page.
• No database queries, no tables, no scheduled tasks.

The cost that matters is the refreshes themselves: each one is a page load that used to be free.

The sessionStorage check exists to keep that proportional to how much members actually read, rather than to how often they press Back.

Installing​

Upload, install, then switch it on:

Setup → Options → RaGEZONE bfBuster

It ships off, so installing changes nothing until you decide.

Options​

Refresh restored pages
The on/off switch.

Pages to refresh
One template name per line, matched against data-template.

Add the template name of any add-on page that shows unread markers.

Pages that mark content read
One template name per line. Visiting one of these is what makes a list behind it out of date.

Leave empty to refresh on every return, at the cost of some unnecessary loads.

If it does not seem to fire​

Read data-template off <body> on the page that stayed stale and check it is in the list.

Add-ons and custom pages often use their own template names.

If Back produces a network request rather than an instant restore, the page was never in the back/forward cache to begin with and something else is serving it.

Look at Cache-Control on the response instead.

Requirements​

XenForo 2.3.0+.

One template, one template modification, three options.

No PHP classes, no schema changes, and uninstalling leaves nothing behind.