Quando devo usar in-line vs. JavaScript externo?

https://stackoverflow.com/questions/138884

02-07-2019
|

Pergunta

Gostaria de saber quando devo incluir scripts externos ou escrevê-los em linha com o código html, em termos de desempenho e facilidade de manutenção.

O que é a prática geral para isso?

em cenários do mundo real - Eu tenho várias páginas HTML que validação de formulário do lado do cliente necessidade. Por isso eu uso um plugin jQuery que eu incluir em todas essas páginas. Mas a pergunta é, I:

escrever os bits de código que configure esse script embutido?
incluem todos os bits em um arquivo que é share entre todas estas páginas html?
incluir cada bit em um arquivo externo separado, uma para cada página html?

Graças.

Solução

No momento esta resposta foi originalmente publicado (2008), a regra era simples: Todos script deve ser externo. Tanto para a manutenção e desempenho.

(Por que o desempenho? Porque se o código é separada, pode mais fácil ser armazenado em cache por navegadores.)

JavaScript não pertence no código HTML e se ele contiver caracteres especiais (tais como <, >) ainda cria problemas.

Hoje em dia, web escalabilidade mudou. Reduzir o número de pedidos tornou-se uma consideração válida devido à latência de fazer várias solicitações HTTP. Isso faz com que a resposta mais complexa: na maioria dos casos, tendo JavaScript externo é ainda recomendado. Mas, para certos casos, especialmente muito pequenos pedaços de código, inlining-los em HTML do site faz sentido.

Outras dicas

Maintainability é definitivamente uma razão para mantê-los externo, mas se a configuração é um one-liner (ou, em geral, menor do que o HTTP sobrecarga você teria para fazer esses arquivos externo) é em termos de performance melhor mantê-los em linha. Lembre-se sempre, que cada solicitação HTTP gera alguma sobrecarga em termos de tempo de execução e de tráfego.

Naturalmente, isso tudo se torna irrelevante o momento em que seu código é mais do que um par de linhas e não é realmente específico para uma única página. No momento em que você quer ser capaz de reutilizar esse código, torná-lo externo. Se você não fizer isso, olhar para o seu tamanho e decidir então.

Externalização javascript é uma das regras de desempenho yahoo: http://developer.yahoo.com/performance/rules.html#external

Enquanto a regra dura e rápida que você deve sempre externar roteiros será geralmente uma boa aposta, em alguns casos, você pode querer para inline alguns dos scripts e estilos. Você deve coisas no entanto, apenas em linha que você sabe que vai melhorar o desempenho (porque você mediu isso).

Se você só se preocupam com o desempenho, a maioria dos conselhos neste segmento é algo totalmente errado, e está se tornando mais e mais errado na era SPA, onde podemos supor que a página é inútil sem o código JS. Passei incontáveis ??horas otimizando tempos de carregamento da página SPA, e verificando os resultados obtidos com diferentes navegadores. Através da placa o aumento de desempenho por re-orquestrar o seu html, pode ser bastante dramática.

Para obter o melhor desempenho, você tem que pensar em páginas como foguetes de dois estágios. Estas duas etapas correspondem aproximadamente às fases <head> e <body>, mas acho que eles em vez como <static> e <dynamic>. A parte estática é basicamente uma constante de cadeia que você empurrar para baixo o tubo de resposta o mais rápido que puder. Isso pode ser um pouco complicado se você usar um monte de middleware que define os cookies (estes necessidade de ser definido antes de enviar conteúdo http), mas, em princípio, é só liberar o buffer de resposta, espero que antes de saltar para algum código de templates (navalha, php, etc) no servidor. Isso pode parecer difícil, mas então eu só estou explicando tudo errado, pois fica próximo ao trivial. Como você deve ter adivinhado, esta parte estática deve conter todas javascript inline e minified. Seria algo parecido

<!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>

Uma vez que não lhe custa quase nada para enviar esta parte pelo fio, você pode esperar que o cliente começará a receber este algo em torno de 5 ms + latência após a conexão com o servidor. Supondo que o servidor é razoavelmente perto esta latência poderia ser entre 20ms a 60ms. Browsers iniciará o processamento desta seção, logo que eles obtê-lo, e o tempo de processamento será tempo de transferência normalmente dominam pelo fator 20 ou mais, que agora é sua janela amortizado para o processamento do lado do servidor da porção <dynamic>.

Demora cerca de 50ms para o navegador (Chrome, descansar talvez 20% mais lento) para processar em linha jquery + signalr + angular + ng animado + ng toque + ng rotas + lodash. Isso é bastante surpreendente em si. A maioria das aplicações web têm menos código do que todos aqueles bibliotecas populares juntos, mas vamos dizer que você tem tanto, de modo que iria ganhar a latência de 100ms + de processamento no cliente (esta vitória latência vem do segundo pedaço de transferência). No momento em que o segundo pedaço chega, temos processados ??todo o código js e modelos e podemos começar a executar as transformações dom.

Você pode objetar que este método é ortogonal ao conceito inlining, mas não é. Se você, em vez de inlining, link para cdns ou seus próprios servidores do navegador teria que abrir outra conexão (s) e execução de atraso. Desde esta execução é basicamente livre (como o lado do servidor está conversando com o banco de dados) deve ficar claro que todos esses saltos custaria mais do que fazer sem saltos em tudo. Se houvesse uma peculiaridade navegador que disse js externos executa mais rapidamente pudéssemos medir domina qual fator. Minhas medidas indicam que os pedidos extras matar desempenho nesta fase.

Eu trabalho muito com a otimização de aplicativos SPA. É comum as pessoas a pensar que o volume de dados é um grande negócio, enquanto na latência verdade, e execução, muitas vezes dominam. As bibliotecas minified I listados adicionar até 300kb de dados, e isso é apenas 68 kb compactado, ou 200ms download em um 2Mbit 3G / 4G telefone, que é exatamente a latência levaria no mesmo telefone para verificar se ele tinha os mesmos dados em seu cache já, mesmo que fosse em cache proxy, porque o imposto latência móvel (telefone-a-torre latência) ainda se aplica. Enquanto isso, conexões de desktop que têm menor primeiro-hop latência normalmente têm maior largura de banda de qualquer maneira.

Em suma, agora (2014), é melhor para inline todos os scripts, estilos e modelos.

EDIT (MAY 2016)

aplicações como JS continuar a crescer, e alguns dos meus payloads agora empilhar até 3+ megabytes de código minified, está se tornando óbvio que a libra muito menos comumries não deve mais ser embutido.

eu acho que o específico para uma página, caso roteiro curto é (apenas) caso defensável para script embutido

Na verdade, há um caso bastante sólido para usar javascript embutido. Se os js é pequeno o suficiente (one-liner), que tendem a preferir a linha javascript por causa de dois fatores:

Localidade . Não há necessidade de navegar um arquivo externo para validar o comportamento de alguns javascript
AJAX . Se você está atualizando alguma seção da página via AJAX, você pode perder todos os seus manipuladores Dom (onclick, etc) para essa seção, dependendo de como você binded-los. Por exemplo, usando jQuery você pode usar o live ou métodos delegate de contornar isso, mas acho que se os js é pequeno o suficiente, é preferível apenas para colocá-lo em linha.

Outra razão pela qual você deve sempre usar scripts externos é para a transição mais fácil Content Security Policy (CSP) . defaults CSP proibir toda script embutido, tornando seu site mais resistente a ataques XSS.

Gostaria de ter um olhar para o código necessário e dividi-lo em tantos arquivos separados, conforme necessário. Cada arquivo js só iria segurar um "conjunto lógico" das funções etc. eg. um arquivo para todas as funções relacionadas login.

Então, durante desenvolvimento do site em cada página html só incluem aqueles que são necessários. Quando você vai ao vivo com seu site, você pode otimizar combinando arquivo a cada js uma página necessidades em um único arquivo.

A única defesa que posso oferecer para javascript inline é que, ao usar vistas rigidez com .NET MVC você pode se referir ao C # variáveis ??meados javascript que eu encontrei útil.

considerações Três:

Quanto código que você precisa (por vezes bibliotecas é um consumidor de primeira classe)?
Especificidade: é este código só funciona no contexto deste documento ou elemento específico
Cada código dentro do documento tende a torná-lo mais tempo e, portanto, mais lento. Além de que as considerações de SEO tornar óbvio, que você minimizar scripting interna ...

scripts externos também mais fácil é para depurar usando o Firebug. Eu gosto de Teste Unidade meu JavaScript e tê-lo ajuda a todos externo. Odeio ver JavaScript em código PHP e HTML se parece com uma grande bagunça para mim.

Por questão de manter JavaScript externo:

ASP.NET 3.5SP1 recentemente introduzido funcionalidade para criar um recurso de script Composite (mesclar um monte de arquivos js em um). Outro benefício para isso é quando a compressão de Webserver é ligado, o download de um arquivo um pouco maior terá uma taxa de compressão melhor então muitos arquivos menores (também menos http em cima, ida e volta etc ...). Eu acho que isso poupa sobre o carregamento da página inicial, então o cache do navegador entra em ação como mencionado acima.

ASP.NET lado, este screencast explica os benefícios em mais detalhes: http://www.asp.net/learn/3.5-SP1/ video-296.aspx

Outro benefício oculto de scripts externos é que você pode facilmente executá-los através de um verificador de sintaxe como JSLint . Isso pode salvar você de um monte de doloroso, difícil de encontrar, erros do IE6.

Em seu cenário soa como escrever o material externo em um arquivo compartilhado entre as páginas seriam bons para você. Concordo com tudo o que disse acima.

Durante prototipagem cedo manter sua linha de código para o benefício de iteração rápido, mas não se esqueça de fazer tudo externo pelo tempo que você atingir a produção.

Eu até se atrevem a dizer que, se você não pode colocar todo o seu Javascript externamente, então você tem um design ruim em suas mãos, e você deve refatorar seus dados e scripts

O Google incluiu tempos de carregamento nele é página medições do ranking, se você in-line muito, levará mais tempo para que as aranhas para rastejar através de sua página, isso pode ser influenciar o seu ranking da página se você tiver que muito incluído. em qualquer caso, diferentes estratégias podem ter influência na sua classificação.

bem, eu acho que você deve usar em linha ao fazer sites de página única como scripts não precisará ser compartilhados entre várias páginas

Sempre tente usar Js externo como js em linha é sempre difícil de manter.

Além disso, é profissionalmente necessário que você use um js externos, pois a maioria dos desenvolvedores recomendam usando js externamente.

Eu mesmo uso js externos.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow