Em um aplicativo da Web em que estou trabalhando, existem 3 tipos de scripts (o mesmo se aplica às folhas de estilo):
- Os necessários em todas as páginas (por exemplo, jquery)
- Os necessários em várias páginas, mas não em todas (por exemplo, uma biblioteca de caixas de luz usada em páginas que mostram imagens carregadas pelo usuário)
- Os necessários em uma única página (por exemplo, algo específico para a funcionalidade dessa página)
Cada página deve ter seu próprio pacote que agrupa todos os scripts necessários? Ou cada tipo de script deve ter seu próprio pacote (por exemplo, uma página pode carregar três pacotes - essentialScripts.js, mediaLibraries.js e pageSpecificScripts.js)? Ou existe uma abordagem melhor que eu não conheço?
Qual é a melhor prática para agrupar esses scripts e quais vantagens / desvantagens existem para diferentes abordagens?
(Não tenho certeza de quão relevante será isso, mas o projeto no qual estou trabalhando está usando o pacote ASP.NET MVC. Além disso, para simplificar, vamos supor que nenhum dos arquivos venha de uma CDN de terceiros, portanto todos estão sendo carregados no mesmo local e o cliente não pode acessar outros sites.)
Respostas:
Para aplicativos complexos, faz sentido fazer a divisão que você sugeriu. Seus bits comuns, especialmente as bibliotecas externas, mudarão com muito menos frequência do que o código do aplicativo. Portanto, eles são os principais candidatos ao cache. Agrupar tudo impede isso. Por outro lado, eles adicionam solicitações HTTP extras. O que tornaria a experiência inicial um pouco menos agradável. Um padrão comum é ter bibliotecas externas em um pacote e código de aplicativo em outro. Especialmente quando o último é menor e há muito compartilhamento entre páginas e visualizações, isso faz sentido.
Este é um alvo em movimento, no entanto. As melhores práticas de hoje são os antipadrões de amanhã. O conselho muda em um mundo em que o http / 2 é comum ou quando os módulos do lado do cliente são suportados por todos os principais navegadores.
fonte