Open and Close Signalr connections and performance patterns

I want to minimize the amount of connections I’m using with SignalR to reduce server resources and browser connection limit issues. Would it be a bad practice to always post requests to my rest api, but if the task is known to be a long running task, or a task which will want to communicate status changes over time, return a command to the web client that it should listen on a signalr connection, and then establish a signalr connection until the task completes?

My signalr backend is associated to the rest api through connection id to session id mappings and I can have the client re-use the same signalr connection if ones spawns multiple tasks and hold open until the last task completes.

I understand the type of traffic that uses these services will dictate how many sessions need the signalr connection at the same time, but if I know that say, only 30-40% of my traffic is going to use the long running / reporting type tasks, and maybe for only 30% of their sessions, is it worth the design in terms of performance to use some sort of on demand open/close pattern signalr/sockets vs a rest polling pattern?