Repensar a interface
Em primeiro lugar, um design de interface de usuário que mostra 50-100k linhas em um cliente provavelmente não é a melhor interface de usuário em primeiro lugar. Não é apenas uma grande quantidade de dados para enviar ao cliente e para o cliente gerenciar e talvez seja impraticável em alguns dispositivos móveis, mas obviamente há muito mais linhas do que qualquer usuário realmente lerá em qualquer interação com a página. Então, a primeira ordem pode ser repensar o design da interface do usuário e criar algum tipo de interface mais orientada para a demanda (paginada, rolagem virtual, digitada por letra, etc...). Existem muitas possibilidades diferentes para um design de interface de usuário diferente (e espero que melhor) que diminua a quantidade de transferência de dados. Qual design seria melhor depende inteiramente dos dados e dos modelos de uso prováveis do usuário.
Enviar dados em pedaços
Dito isso, se você for transferir tantos dados para o cliente, provavelmente desejará enviá-los em partes (grupos de linhas por vez). A ideia com os blocos é que você envie uma quantidade consumível de dados em um bloco para que o cliente possa analisá-lo, processá-lo, mostrar os resultados e então estar pronto para o próximo bloco. O cliente pode permanecer ativo o tempo todo, pois possui ciclos disponíveis entre os blocos para processar outros eventos do usuário. Mas, enviá-lo em partes reduz a sobrecarga de enviar uma mensagem separada para cada linha. Se o seu servidor estiver usando compactação, os pedaços também oferecem uma chance maior de eficiência de compactação. O tamanho de um bloco (por exemplo, quantas linhas de dados devem conter) depende de vários fatores e provavelmente é melhor determinado por meio de experimentação com clientes prováveis ou com o cliente esperado com menor consumo de energia. Por exemplo, você pode querer enviar 100 linhas por mensagem.
Use um formato de transferência eficiente para os dados
E, se você estiver usando socket.io para transferir grandes quantidades de dados, convém rever como você usa o formato JSON. Por exemplo, enviar 100.000 objetos que repetem exatamente os mesmos nomes de propriedade não é muito eficiente. Muitas vezes você pode inventar suas próprias otimizações que evitam a repetição de nomes de propriedades que são exatamente os mesmos em todos os objetos. Por exemplo, em vez de enviar 100.000 destes:
{"firstname": "John", "lastname": "Bundy", "state": "Az", "country": "US"}
se todos os objetos tiverem exatamente as mesmas propriedades, você poderá codificar os nomes das propriedades em seu próprio código ou enviar os nomes das propriedades uma vez e enviar uma lista de valores separados por vírgula em uma matriz que o código de recebimento pode colocar em um objeto com os nomes de propriedade apropriados:
["John", "Bundy", "Az", "US"]
O tamanho dos dados às vezes pode ser reduzido em 2-3x simplesmente removendo informações redundantes.
