Por que não incorporar estilos / scripts em HTML em vez de vincular?

40

Concatenamos arquivos CSS e JavaScript para reduzir o número de solicitações HTTP, o que melhora o desempenho. O resultado é HTML assim:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Se tivermos lógica do lado do servidor / construção para fazer tudo isso por nós, por que não dar um passo além e incorporar esses estilos e scripts concatenados no HTML?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Isso é menos duas solicitações HTTP, mas ainda não vi essa técnica na prática. Porque não?

    
por GladstoneKeep 27.12.2013 / 00:04
fonte

6 respostas

96

Porque salvar solicitações HTTP é de pouca utilidade quando você o faz quebrando o cache. Se as folhas de estilo e os scripts forem exibidos separadamente, eles poderão ser armazenados em cache muito bem e serão amortizados em muitas solicitações para páginas muito diferentes. Se eles estão na mesma página HTML, eles precisam ser retransmitidos com todos. Solteiro. Pedido.

O HTML desta página, por exemplo, tem 13 KB no momento. Os 180 KB de CSS atingiram o cache e o mesmo aconteceu com os 360 KB do JS. Os dois hits de cache consumiram quantidades mínimas de tempo e praticamente não consumiram largura de banda. Elimine o profiler de rede do seu navegador e tente em outros sites.

    
por 27.12.2013 / 00:26
fonte
18

Simplesmente porque o desempenho da Web realmente importa! 99% vezes ele vai te dar tempos de resposta do usuário final mais rápidos.

Aqui estão alguns exemplos da Velocity Conf.

  • Bing : uma página 2 segundos mais lenta resultou em uma queda de 4,3% na receita / usuário.
  • Google : um atraso de 400 milissegundos causou uma queda de 0,59% nas pesquisas / usuário.
  • Yahoo ! - Uma desaceleração de 400 milissegundos resultou em uma queda de 5 a 9% no tráfego de página inteira.
  • Shopzilla - Acelerar o site em 5 segundos aumentou a taxa de conversão de 7 a 12%, dobrou o número de sessões do marketing do mecanismo de pesquisa e reduziu o número de servidores necessários pela metade.
  • Mozilla - A redução de 2,2 segundos em suas páginas de destino aumentou as conversões de download em 15,4%, o que eles estimam resultará em 60 milhões de downloads do Firefox por ano.
  • Netflix - Adotando uma otimização única, a compactação gzip, resultou em uma aceleração de 13-25% e reduziu o tráfego de rede de saída em 50%.

De Steve Souders, pioneiro em otimização de desempenho da Web,

80-90% of the end-user response time is spent on the frontend - Start here first.

O uso de arquivos externos produz páginas mais rápidas porque os arquivos JavaScript e CSS são armazenados em cache pelo navegador / redes / proxies (conforme definido no protocolo HTTP com cabeçalhos de Cache). JavaScript e CSS que estão embutidos em documentos HTML são baixados toda vez que o documento HTML é solicitado. Isso reduz o número de solicitações HTTP necessárias, mas aumenta o tamanho do documento HTML. Se você estiver usando scripts semelhantes ao Jquery, é fácil incluir 300 KB de scripts e não acreditar que todos tenham uma largura de banda de 100 MBits / s com baixa latência, executando um único aplicativo - o navegador - aberto em seu site. 99% vezes ele vai te dar tempos de resposta do usuário final mais rápidos.

A frequência com que componentes JavaScript e CSS externos são armazenados em cache em relação ao número de documentos HTML solicitados também é importante. Se os usuários em seu site tiverem várias visualizações de página por sessão e muitas de suas páginas reutilizarem os mesmos scripts e folhas de estilo (bundles), haverá um benefício potencial maior dos arquivos externos armazenados em cache.

Mas o in-line é, às vezes, preferível para aplicativos de página única ou sites da Web com uma única visualização de página por sessão. Não existe uma regra de ouro e, geralmente, esquece-a, uma vez que se trata principalmente de sites muito específicos, realmente envolvidos no desempenho do usuário final.

Você pode ler aqui porque o desempenho é importante ( Disclaimer: Eu sou o autor)

    
por 27.12.2013 / 10:22
fonte
3

A versão mais recente do HTTP foi criada em 1999. Em 1999, todos conectaram-se à Internet com discagem. A Internet estava muito lenta. 16 anos depois, as coisas mudaram muito, mas os protocolos que usamos não mudaram.

As respostas que não devemos incorporar 'porque interfere no cache' são um pouco enganosas, particularmente na era da Internet super rápida. Quando você realmente faz os cálculos, muitas vezes há uma diferença insignificante entre os tempos de carregamento com os usuários cache-warm e cache-cold se você tiver inlined. O fato de que é uma pequena diferença não é inerentemente porque você tem embutido, mas por causa do design inflexível do HTTP / 1.1.

O protocolo SPDY implementa algo chamado push do servidor . Isso essencialmente leva inlining fora do documento HTML em si e no protocolo. Um servidor inteligente saberá quais recursos o cliente já possui. Um servidor burro enviará tudo de qualquer maneira - isso ainda será um benefício de desempenho, mas pode custar em termos de largura de banda. Se o navegador tiver o conteúdo em seu cache, ele pode simplesmente descartar as cópias recebidas. O servidor aguarda até que o HTML seja carregado antes de enviar os recursos adicionais - em teoria, o navegador pode enviar um sinal para cancelar o envio do servidor.

O HTTP / 2.0 é baseado no SPDY e provavelmente implementará o push do servidor, mas você pode, em teoria, começar a usar o SPDY hoje. Portanto, a verdadeira razão de não estarmos embutidos é um dos legados - os protocolos que existem atualmente são antigos e não são flexíveis o suficiente para alcançar o 'inline em nível de protocolo'.

    
por 27.12.2013 / 23:00
fonte
3

Além das preocupações de armazenamento em cache e de recuperação que as outras respostas geram, gostaria de destacar outro problema mais obscuro: análise .

JavaScript aparecendo em HTML pode apresentar problemas de análise, como neste exemplo:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... o que significa que você terá que transformar seu script para escapar de alguns caracteres que são acionados em HTML. Esse problema desaparece quando você fornece CSS e JavaScript como recursos externos, porque eles não precisam mais considerar o contexto de análise 'pai'.

Se você veicular seu conteúdo como XML, você terá uma parte disso usando as seções CDATA. CDATA, no entanto, vem com um problema semelhante:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Inliners, cuidado.

    
por 21.05.2014 / 18:04
fonte
1

A separação do conteúdo do estilo de sua apresentação geralmente é uma vantagem maior do que menos solicitações http.

Separar todo o estilo ativa e incentiva a reutilização e os arquivos compartilhados.

O conteúdo dos arquivos também será mais estático e disponível para armazenamento em cache em servidores e clientes para essa página e outras páginas visitadas.

Para sua pergunta específica ... Se o servidor foi feito para fazer a minificação em si, isso torna os ativos mais difíceis de manter e depurar problemas. No entanto, muitas estruturas agora fazem isso no nível do arquivo, por exemplo, todos cs e todos os js. Por exemplo, o framework ruby on rails agora reduz seus ativos para produção. 5-10 solicitações extras de HTTP geralmente não são o gargalo, são mais se houver mais de 100 solicitações http (que você geralmente obtém com imagens).

O passo extra de realmente incluir o código nas páginas em si teria a desvantagem de páginas maiores que você teria que gerenciar a seqüência de download com cuidado e a página não sendo capaz de exibir o conteúdo com frequência sem o restante (agora grande) página sendo baixada.

    
por 27.12.2013 / 00:26
fonte
1
  1. Minimize a codificação duplicada. para economizar tempo (você pode reutilizar o estilo e a função JS codificada para uma página).
  2. Minimize o esforço de mudança. (Se o seu cliente lhe pedir para mudar a cor do botão do site, você precisa ir uma página por uma).
  3. Reduza o tempo de carregamento (se o CSS e JS duplicarem, significa que o tamanho de páginas individuais aumenta e consome tempo para fazer o download. mas o CSS comum JS não precisa ser baixado várias vezes).
  4. Uso remoto. (você pode colocar o seu JS comum JS JS em um lugar remoto. não é o mesmo servidor hospedado)
  5. Reduza o tempo de correção de erros. Se houver um bug em uma função, você precisa ir página por página para corrigir os erros no JS e CSS incorporado.
  6. Para aumentar o SEO (simplesmente separe o conteúdo com metadados)
  7. Limpo e compreensivelmente de código (Se você incorporar tudo em uma depuração de arquivo e a clareza do código desapareceu. e cada página será uma página muito longa).
  8. Além disso, isso ajudará você a reduzir o tamanho do produto.
  9. Mas ainda assim você pode considerar incorporar a coisa mais original na mesma página.
por 27.12.2013 / 10:30
fonte