Otimizando o desempenho da aplicação web de visualização de dados

Estou reescrevendo uma ferramenta web de visualização de dados que foi escrita há 3 anos. Desde então, o mecanismo de JavaScript do navegador tornou-se muito mais rápido, então pensei em transferir parte do trabalho do servidor para o cliente.

Na página, os dados são visualizados em uma tabela e em um mapa (ou gráfico), ele está usando os mesmos dados, mas de uma maneira diferente para que os dois algoritmos para preparar os dados para exibição sejam diferentes.

Antes de cada interação do usuário com os seletores desdobráveis ​​de dados (3 principais + 2sub dependendo do 3 principais), 3 solicitação ajax foram enviadas, php fazendo todo o trabalho e enviando apenas dados necessários (em html para a tabela / xml para o gráfico) resposta muito pequena, nenhum problema de desempenho e javascript foi acrescentando resposta e não fazendo muito mais do que perseguir events de mudança.

Então, o desempenho foi bom, mas em cada mudança de critério, o usuário precisa aguardar a resposta do ajax: /

Agora, minha idéia é enviar de volta um object json em uma solicitação ajax, somente em todas as alterações da combinação principal de 3 critérios e, em seguida, ter javascript preenchendo os dados na tabela e o gráfico / mapa no ajaxsuccess e, em seguida, também na mudança do 2 sub critério.

Minha hesitação diz respeito à estrutura do json enviar pelo servidor, o saldo da carga útil.

Na verdade, se houvesse apenas um algoritmo necessário para criar a estrutura desejada do json para exibir os dados dos dados brutos, eu teria o php processando os dados nesse object pronto para o javascript para lidar com ele sem nenhum tratamento adicional; mas há 2.

assim

  • se eu fizer o processo PHP processar os dados para criar 2 objects (um para tabela / um para o gráfico), vou dobrar o tamanho da resposta do json e aumentar o uso da memory no lado do cliente; Eu não gosto dessa abordagem porque este object dois contém os mesmos dados, apenas estruturados de forma diferente e a redundância é o mal, não é?

  • se eu enviar o object em bruto e deixar o JavaScript procurar o que exibir e onde eu estou dando muito trabalho ao cliente – isso também em todas as alterações de subcritérios (ou eu poderia criar todos os objects json uma vez no ajaxsuccess para que estejam prontos em O caso desta mudança de subcritérios?) – aqui estou pouca preocupação para usuários com navegador antigo / ram pequeno …

(O object raw json não tratado, dependendo dos critérios variam entre 3kb e 12kb, entre 500 e 2000 registros)

Estou falhando em detectar a melhor abordagem …

Então, para esse trabalho simples de dados brutos para objects de objects estruturados múltiplos, você teria php (aumentando o tamanho da resposta e enviando dados redundantes) ou javascript (aumentando a carga útil do javascript) processando os dados brutos?

Obrigado por sua opinião

Encontrei uma solução adequada, então eu responderei a minha própria pergunta.

Segui o conselho de @ Daverandom:

  • O PHP envia dados brutos (juntamente com alguns parâmetros que dependem da combinação dos principais critérios)

  • O JavaScript processa os dados brutos e os torna na página

  • O JavaScript reprocessa os dados brutos se os sub-critérios forem alterados, pois ao testar o processo de looping parece ser muito rápido e não congelar o navegador, então não há necessidade de manter o object estruturado no escopo

  • Os headers de cache agressivos são enviados com a resposta JSON AJAX (esses dados nunca são alterados – apenas novos registros são adicionados todos os anos) caso o usuário re-consulte dados que já foram consultados: então os dados brutos não são mantidos no escopo JavaScript se ele for não sendo exibido

  • Além disso, as cadeias JSON ecoadas pelo php são armazenadas em cache no servidor (porque esses dados nunca mudam), então isso reduz as consultas do database e melhora o tempo de resposta

O código final é limpo, fácil de manter e o aplicativo funciona perfeitamente.

Graças a @Daverandom pela ajuda.