É uma boa prática ter um pacote por visualização no Asp Net MVC

Como empacotamento e minificação têm tudo a ver com otimização e carregamento de páginas mais rápido, parece-me lógico criar um pacote para scripts e um pacote para estilos por visualização, de modo que, para carregar todos os scripts e estilos, o navegador precisará para fazer 2 pedidos no máximo. Então, digamos que eu tenho um _Layout.cshtmlonde eu preciso 3 js bootstrap.js, jquery.jse alguns custom1.jseu posso criar um pacote, algo como isto:

bundles.Add(new ScriptBundle("~/bundles/layout").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom1.js"));

Então, digamos que eu tenho uma outra visão User.cshtmlonde eu preciso bootstrap.js, jquery.jse custom2.js, mais uma vez eu criar um pacote:

bundles.Add(new ScriptBundle("~/bundles/user").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom2.js"));

A mesma abordagem pode ser usada para pacotes configuráveis ​​de estilo. Mas, pelo que vejo, não é uma prática comum fazê-lo dessa maneira, geralmente os pacotes são criados com base no tipo, por exemplo, um para bootstrap, outro para jquery, outro para arquivos js / css personalizados etc. Mas isso não aumentaria o tempo de carregamento da página, porque ter mais pacotes significa mais solicitação ao servidor. Além disso, qual é o problema de fazer as coisas da maneira que descrevi no começo?

Eu acho que pode até ser contraproducente usar um único pacote por página.

Existe uma sobrecarga para a criação do pacote configurável ... embora essa sobrecarga ocorra uma vez por instância do aplicativo (é armazenada em cache pelo aplicativo após a primeira chamada), mas se você tiver um novo pacote configurável para cada página, isso significa para cada página distinta na sua visita, é necessário criar um novo pacote antes de poder ser veiculado. Isso deixaria o objetivo dos pacotes consideravelmente, eu acho.

Em vez disso, geralmente tenho dois pacotes: um pacote principal que cada página deve exigir e dificilmente mudará depois que o projeto inicial for configurado. Isso inclui estilos principais, jQuery / knockout e outras bibliotecas de fornecedores de base.

O segundo pacote configurável é geralmente o contexto por aplicativo (por exemplo, o pacote configurável Usuários pode ter itens modulares relacionados aos usuários em geral, mas não necessariamente a uma página específica).

Qualquer coisa específica da página nem sempre entra em um pacote.

O efeito prático do desempenho do empacotamento (pelo menos para aplicativos de negócios que eu costumo escrever) não é tão bom assim, considerando que quando o cliente chama pela primeira vez, ele fica lá até que ele mude novamente.

Se você tem um site público em que espera um número maior de visitantes pela primeira vez, pode adotar uma abordagem um pouco diferente.

Não.

Devido ao cache do navegador, você obtém os melhores resultados gerais usando o mesmo pacote ou pacotes em todas as páginas. Isso significa que o usuário baixará todos os css e js quando chegarem à primeira página e reutilizará esse arquivo nas páginas subseqüentes.

Dado que a maior parte do pacote configurável será composta por estruturas javascript, como jquery e bootstrap. Seus poucos bytes extras de código personalizado têm um efeito insignificante na velocidade geral de carregamento da página.

A desvantagem de um pacote configurável por página é que o pacote armazenado em cache de uma página não pode ser usado em outra página, o que você normalmente deseja é que a maior parte dos seus scripts (por exemplo, inicialização do jQuery, etc ...) seja baixada uma vez e armazenada em cache para todas as páginas em o site.

A solução "ideal" de uma perspectiva de armazenamento em cache seria ter um único pacote contendo todos os .js para todas as páginas em todo o site, a desvantagem dessa abordagem é que o pacote acaba sendo muito grande, o que significa que o carregamento inicial da página é mais lento , o que pode não ser desejável para sites voltados para o cliente em que as impressões iniciais são tudo.

A "melhor" solução provavelmente será uma mistura de técnicas, por exemplo

• Um pacote principal (material como jQuery e Bootstrap, usado em quase todas as páginas), além de um pacote por página
• Um único pacote para todo o site, talvez excluindo uma página pesada em javascript que adicione muito ao tamanho do pacote