Integrate Speculation Rules API

[briansol]

As a Forum User,
I need a speedy experience from page to page
so that I don't have unnecessary load times as I navigate the website.


Google has recommended integrating the Speculation Rules API to pre-load the anticipated next logical navigation move a user might take to reduce time to load the next anticipated page

Suggested implementation (first wrong answer):

Forum Home
-> New posts / what's new
-> top record in the first sidebar (trending content?)

- Forum view
-> First non-sticky thread
-> page of last new post in first non-sticky thread
-> New Posts

Thread view
-> page 1, next page
-> page 2+, next page, previous page
-> Forum view
-> New Posts

 

[Kirby]

Google often recommends things that sound ike a good idea on the surface, but actually are not that great (for a forum)

Here is what Google (Gemini) thinks about this suggestion:

Short Answer: No, it is generally a bad idea for XenForo unless you heavily modify the backend to handle it.

Using Speculation Rules (especially prerender) on a state-heavy application like XenForo will likely break user experience and trash your server performance.

Here are the specific reasons why you should avoid it for a forum:

1. The "False Read" Problem (State Mutation)​

XenForo handles "Marking as Read" on the server-side (PHP) when the controller is loaded.

• Scenario: A user is scrolling through a forum list. The Speculation API prerenders the top 5 threads.
• Result: All 5 threads are instantly marked as "Read" in the database because the server received the request.
• User UX: The user never clicked them. Next time they refresh, everything looks read, and they miss new content.

2. The "View Count" Inflation​

Thread view counts are incremented when the controller action fires.

• Prerendering/Prefetching triggers the PHP controller.
• Your view counts will inflate massively with "ghost views" from users who hovered but never clicked.

3. Database "Thundering Herd"​

Forums are database-intensive. Rendering a thread involves:

• Checking permissions (Node, User Group, User).
• Fetching posts, user entities, signatures, avatars.
• Calculating unread status.
• Updating session activity.
• Writing to the xf_thread_view table.

If you prerender links on a forum list, you are effectively forcing every user to load multiple heavy pages simultaneously in the background. This allows a single user to unintentionally DDoS your MySQL database just by moving their mouse.

4. Security Tokens (CSRF)​

XenForo pages generate unique CSRF tokens (_xfToken) embedded in the HTML.

• If a page is prerendered and sits in the background for a while, the token might become stale or desynchronized from the user's current session state, causing "Security error occurred" messages when they finally try to reply or like a post.

5. Ad Impressions & Analytics​

If you run ads (AdSense, etc.) or Google Analytics:

• Prerender: Executes JavaScript. Ad impressions will register even if the user never sees the page. This violates most ad network policies (generating fake impressions) and can get your account banned.
• Prefetch: Usually doesn't execute JS, so Analytics are safe, but server-side stats (Awstats/GoAccess) will still be wrong.

---

How to do it safely (if you really want to)​

If you are determined to use it, you must restrict it strictly to prefetching static assets or modify XenForo's core.

Most of those points (except CSRF which will change with 2.4) are valid.
So in order to properly support speculation rules multiple core concepts / functcionality wuld have to be changed:

• Read marking (for threads, etc.) can't be done as it is right now, eg. triggered when the resource is requested, instead this would have to be triggered from the client when the page is actually viewed. This would be a breaking change for XenForo core and all Add-ons.
• Same for view counting
• There would be a high chance for users to see outdated data

Furthermore it may be quite difficult to select appropriate targets as forums usually have a lot of long-tail traffic.
If there isn't a candidate that will be accessed with high confidence (significant) resources would be wasted for both client and server.

Last but not least this would (currenly) only work for Chomium-based browsers.

So IMHO it doesn't make much sense as of now to consider implementing this.

 

[vbresults]

As a Forum User,
I need a speedy experience from page to page
so that I don't have unnecessary load times as I navigate the website.


Google has recommended integrating the Speculation Rules API to pre-load the anticipated next logical navigation move a user might take to reduce time to load the next anticipated page

Suggested implementation (first wrong answer):

Forum Home
-> New posts / what's new
-> top record in the first sidebar (trending content?)

- Forum view
-> First non-sticky thread
-> page of last new post in first non-sticky thread
-> New Posts

Thread view
-> page 1, next page
-> page 2+, next page, previous page
-> Forum view
-> New Posts

What you’re looking for is a native app. That is where I implement things like this.

On the web this is not feasible, particularly for complex sites like forums.