A note on Push and WebSocket
kael opened this issue · comments
cc @gauntface
Type of Issue
Precision on the dual use of Push and WebSocket
Details....
In the FAQ, Push is described as a better protocol than WebSocket. But in my experience that's not true, WebSocket appears as complementary protocol to be used in dual-mode.
In Paris metro, the mobile connection is a bit prehistorical, mostly on EDGE, even more with one carrier that is using roaming and which connection rate is limited and is to be decreased due to telecom regulator injunction. Adding to that, this ISP/carrier had had long time peering problems with Google, like YouTube or Google Play being very slow, although I'm more speculating on that point since these peering issues are supposed to be solved now.
In my experience, I get better reconnection with WebSocket than with Push, being underground or even on aerial lines. For some reason, the Push socket doesn't reconnect easily in these constraint conditions.
It can take more than 10 minutes to get the Push socket reconnected. Whereas a PWA using WebSocket with auto-reconnection get fast reconnection and much better success rates even when being connected on 2G - I've configured Nginx with all the possible options to get the fastest reconnection and even using TCP-FastOpen (although not sure TCP-FO is still working with Chrome).
So I believe the best approach is a dual use of Push and WebSocket . When the - ping'ed - WebSocket connection is alive, the push payload is sent over that socket, and as soon as the WebSocket connection is off, the push payload is re-routed to the Push socket. And so on. A more brute force approach is to use dual-connection but it increases battery consumption.
One last parameter to take into account is that the server onto which the PWA is running is hosted by a subsidiary of that ISP, so technically it's the same sub-network, and it might be a factor of that good WebSocket reconnection rate over 2G.
The whole point of web push is that it works when the page is not open. You cannot expect the page to be open (or workers to be running) when the page is open compared to service workers.
because of this (regardless of preference or additional apps from mobile devices) it's not a good idea to expect the behavior to be comparable.