Se você se preocupa apenas com desempenho, a maioria dos conselhos deste segmento é totalmente errada e está se tornando cada vez mais errada na era do SPA, onde podemos assumir que a página é inútil sem o código JS. Passei inúmeras horas otimizando o tempo de carregamento da página do SPA e verificando esses resultados com diferentes navegadores. Em geral, o aumento de desempenho re-orquestrando seu html pode ser bastante dramático.
Para obter o melhor desempenho, você deve pensar nas páginas como foguetes de dois estágios. Estas duas etapas correspondem aproximadamente a <head>e <body>fases, mas acho que eles em vez como <static>e <dynamic>. A porção estática é basicamente uma constante de seqüência de caracteres que você desliza no tubo de resposta o mais rápido possível. Isso pode ser um pouco complicado se você usar muito middleware que define cookies (eles precisam ser configurados antes de enviar conteúdo http), mas, em princípio, está apenas liberando o buffer de resposta, antes de saltar para algum código de modelo (razor, php, etc) no servidor Pode parecer difícil, mas só estou explicando errado, porque é quase trivial. Como você deve ter adivinhado, essa parte estática deve conter todo o javascript embutido e minificado. Seria algo como
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
Como não custa quase nada enviar essa parte pelo fio, você pode esperar que o cliente comece a receber algo em torno de 5ms + latência após conectar-se ao seu servidor. Supondo que o servidor esteja razoavelmente próximo, essa latência pode estar entre 20ms e 60ms. Os navegadores começarão a processar esta seção assim que a receberem, e o tempo de processamento normalmente dominará o tempo de transferência pelo fator 20 ou mais, que agora é sua janela amortizada para o processamento da <dynamic>parte do servidor .
Demora cerca de 50ms para o navegador (chrome, descanse talvez 20% mais lento) para processar jquery + sinalr + angular + animação + toque + rotas + lodash. Isso é incrível por si só. A maioria dos aplicativos da Web possui menos código do que todas as bibliotecas populares reunidas, mas digamos que você tenha o mesmo, por isso ganharíamos latência + 100ms de processamento no cliente (essa conquista de latência vem do segundo bloco de transferência). Quando o segundo pedaço chega, processamos todo o código js e modelos e podemos começar a executar transformações dom.
Você pode objetar que esse método é ortogonal ao conceito embutido, mas não é. Se você, em vez de inlining, vincular a cdns ou seus próprios servidores, o navegador precisará abrir outra conexão (s) e atrasar a execução. Como essa execução é basicamente gratuita (como o servidor está conversando com o banco de dados), deve ficar claro que todos esses saltos custariam mais do que não fazer nenhum salto. Se houvesse uma peculiaridade de navegador que dissesse js externos executados mais rapidamente, poderíamos medir qual fator domina. Minhas medidas indicam que solicitações extras reduzem o desempenho nesse estágio.
Eu trabalho muito com a otimização de aplicativos SPA. É comum as pessoas pensarem que o volume de dados é muito importante, enquanto na verdade a latência e a execução geralmente dominam. As bibliotecas minificadas listadas adicionam até 300kb de dados, e são apenas 68 kb gzipados, ou 200ms de download em um telefone de 2mbit 3g / 4g, que é exatamente a latência que seria necessária no mesmo telefone para verificar se ele possuía os mesmos dados já em seu cache, mesmo que fosse proxy em cache, porque o imposto de latência móvel (latência do telefone à torre) ainda se aplica. Enquanto isso, as conexões de área de trabalho com menor latência de primeiro salto geralmente têm maior largura de banda.
Em resumo, agora (2014), é melhor incorporar todos os scripts, estilos e modelos.
EDITAR (MAIO DE 2016)
À medida que os aplicativos JS continuam a crescer, e algumas das minhas cargas agora empilham mais de 3 megabytes de código minificado, torna-se óbvio que pelo menos as bibliotecas comuns não devem mais ser incorporadas.