Feature Request: Improve LC Widget and site performance by making WebSocket API compatible with BFCache

[gilbertococchi]

Hello everyone, I wanted to take an opportunity to share an important opportunity that would affect the LC Widget performance and more importantly will speed up Sites performance when LC Widget is embedded.

While browsing HTTP Archive public dataset with performance metrics I've noticed that the LiveChat Widget JS SDK is currently preventing modern browsers to cache and restore back/forward navigation as back/forward-cache (https://web.dev/articles/bfcache).

Chrome for example cannot cache pages that handle WebSocket connections without some prerequisites that are explained here: https://web.dev/articles/bfcache#close-open-connections

All sites embedding the LiveChat Widget JS SDK may already have a negative user experience impact because of that, the entity of the impact depends by the amount of back/forward traffic each site has and whether the WebSocket usage from LC is the only BFCache blocking reason left.

In order to make the implementation BFCache compatible the following thins should happen:

1. the WebSocket connection should be closed when the pagehide event handler would trigger.
2. when the page is restored via BFCache (intercepted by pageshow event.persisted case), restart the WebSocket connection.

window.addEventListener('pagehide', () => {
  socket.close();
  ...
})

window.addEventListener('pageshow', (event) => { 
    if(event.persisted) {  
     // restart WebSocket connection when page is restored from BFCache  
     socket = new WebSocket('...');
     ...
   }
});

Making BFCache working on sites with LC widget being used is not only positive to overall site user experience but also towards the performance of the LC Chat widget itself.

Now users who didn't interact with the LC Chat widget would still be unable to benefit of BFCache.

Scenario of user using LC Chat widget without BFCache:

• user going to page A
• user opening and interacting with LC Chat Widget
• user going to Page B
• user clicks the back button
• page A has to reload interely from Network, including running all the JS, if user would like to resume LC Chat conversion they would need to wait all of that.

Scenario of user using LC Chat widget with BFCache:

• user going to page A
• user opening and interacting with LC Chat Widget
• user going to Page B
• user clicks the back button (page A restored via BFCache if under the cache limit)
• page A will be immediately restored, pageshow event would trigger, LC Chat connection could be established again and if there is a change in the history it could be synched.

How do developers measure the impact?
with RUM or CrUX, below a snapshot of a site homepage where 20% of the CrUX Mobile traffic is Back/Forward (slow) and 0% BFCache (fast) where the only blocking reason is the WebSocket API usage even if the widget is not opened.

Hope you appreciate this suggestion, happy to share more details and guidance if necessary.

[gilbertococchi]

Updated the suggestion with more clear guideline, up to 38K sites will benefit of this change by having BFCache eligible and users getting a way faster page load time when clicking "back" or "forward" buttons.

Also, the LC Widget will not need to be redownloaded, executing the JS from zero etc, so for users interacting with the widget the UX with the widget should improve as a result of this change.