@jsoules we already discussed this, but I just wanted to put this down in an issue.
In the case of webrtc=1, let's not wait for the webrtc connection to be established before starting up the page. API requests should only use webrtc if the connection has been established - otherwise they should fallback to http requests through the proxy. This is part of prioritizing successful page loads, even when webrtc connection cannot be established. The purpose of webrtc is to reduce load on our hosted proxy server.
One sub-optimal part of this is that even in the case where webrtc works, the first few requests that go through may be happening prior to the connection event. We can hope this is only a relatively small amount of data, since by default only one parameter is selected, and further selection requires user intervention - by the time those are selected, we can hope that we have a webrtc connection.
jsoules
commented
1 year ago
@jsoules we already discussed this, but I just wanted to put this down in an issue.
In the case of webrtc=1, let's not wait for the webrtc connection to be established before starting up the page. API requests should only use webrtc if the connection has been established - otherwise they should fallback to http requests through the proxy. This is part of prioritizing successful page loads, even when webrtc connection cannot be established. The purpose of webrtc is to reduce load on our hosted proxy server.
One sub-optimal part of this is that even in the case where webrtc works, the first few requests that go through may be happening prior to the connection event. We can hope this is only a relatively small amount of data, since by default only one parameter is selected, and further selection requires user intervention - by the time those are selected, we can hope that we have a webrtc connection.