PusherJS: Updates to improve reconnection and transport caching strategy

We recently deployed some small but significant updates to the PusherJS transport caching strategy. This enhancement is designed to improve reconnection times and provide a better experience for your end users.

What’s new?

In the 8.2.0 update we removed the retry limit for WebSockets allowing us to retry WebSocket indefinitely.

With the 8.3.0 update we’ve made changes to improve reconnection and transport caching strategies.

8.2.0 update - Removing the retry limit for WebSockets

By removing the retry limit for WebSockets, Pusher allows for indefinite WebSocket retries. 

The initial limit was introduced to improve re-connection time for clients with recurrent WebSocket issues. However, with these issues becoming less common, the limit was found to be unnecessary and could result in undesirable consequences—like forcing a modern web browser with a temporary poor internet connection to use slower fallback options for the rest of the session.

Enabling indefinite retries for WebSocket offers improved performance, a consistent end-user experience, increased resilience to temporary network problems, and optimization for modern infrastructure.

By allowing unlimited retry attempts, the system maintains a faster and more efficient transport method, reducing the risk of slower fallback options due to temporary connection issues. This ensures users experience have a more robust and reliable connection overall, aligning the system with stable and reliable modern internet infrastructure.

8.3.0 - Update to cached re-connect strategy to prioritize WebSocket

PusherJS has always used a caching mechanism to store the last successful transport, using it for subsequent connection attempts. This approach was initially implemented to cater to clients that did not support WebSockets, and it continues to be a sensible strategy for those still lacking WebSocket support.

However, we've identified a challenge with this caching strategy for clients that are forced to fallback to alternative transports. Not due to lack of WebSocket support but because of temporary connectivity issues.

To address this, we've made a simple yet impactful change. 

When the cached transport isn't WebSocket, the system will now retry WebSockets first before attempting the fallback transport. This ensures faster reconnection using WebSockets when possible.

We track these WebSocket attempts before fallback. If WebSocket fails more than three times, we assume the client prefers the fallback transport and continue to maintain the current cached strategy.

How does this affect you?

In response to evolving trends, such as Single Page Applications (SPAs) that have led to longer end user sessions, we've updated our SDK. Our primary objective is to prioritize user experience, ensuring that clients stay connected through WebSocket connections whenever possible. 

We have implemented measures to enable more clients to benefit from the advantages of low latency WebSocket connections, and we will only resort to alternative transports when WebSocket is not a viable option. 

This enhancement ensures a seamless and efficient experience for our users. By optimizing our SDK in this way, we aim to offer a more robust and reliable platform for all our clients.

We look forward to hearing your feedback on GitHub!