Por que os servidores HTTP não enviam um único arquivo de volta quando possível?

2

Eu estou querendo saber por que os servidores HTTP não empacotam uma solicitação de página da web em um único arquivo, que então seria lido pelo navegador?

Tanto quanto eu sei, a quantidade de solicitações feitas para cada página da Web (CSS / JSS / imagens + saída HTML) combinadas torna o carregamento de uma página da Web mais lento e também coloca carga no servidor da web. Existe um servidor que empacota todo o conteúdo (ou o máximo possível) e o envia para o cliente?

Para ilustrar a minha pergunta:

Situação normal widgets.js widgets.css picture1.png picture2.png widgets.html

Situação do pacote

widgets.pck

Claro que isso daria um pouco de sobrecarga no começo, mas com o cache inteligente eu diria que algumas melhorias deveriam ser possíveis?

    
por JanWillem 28.02.2011 / 17:23

5 respostas

8

Se todos os objetos em uma determinada página fossem atendidos pelo mesmo servidor, suponho que isso seria possível. Na maioria dos casos, porém (especialmente com sites de vários milhões de usuários), esse não é o caso. Muitos servidores diferentes estão envolvidos em atender diferentes partes de cada página e se você precisar de um servidor "front end" para reunir todos os recursos, empacotá-los e enviá-los, o desempenho seria drasticamente pior do que a maneira como as coisas funcionam agora é responsável por buscar todos os recursos da página.

    
por 28.02.2011 / 17:30
5

É realmente possível:

  • JS, inclua-os apenas no servidor lado inclui.
  • Objetos (imagens, flash, etc.) podem ser incorporados. Consulte: link e link

A vantagem de ter recursos separados é que eles são armazenados em cache separadamente por várias partes do aplicativo da Web de cadeia para o navegador da web: - cache no nível do sistema de arquivos no site - sites separados para arquivos estáticos (imagens, JS, etc.) - cache e rede de distribuição (como a Akamai) - cache no navegador da web.

Então, em vez de invalidar o cache para a página inteira porque você adicionou uma vírgula, o navegador recarregará apenas a página HTML.

Além disso, não esqueça que a maioria dos sites e navegadores estão usando o HTTP / 1.1 com o KeepAlive ativado. Isso significa que os objetos do mesmo site serão carregados na mesma conexão TCP.

    
por 28.02.2011 / 17:43
3

As técnicas padrão para reduzir o número de solicitações são:

  • colocando todo o código JS em um arquivo (e minimizando-o)
  • colocando todo o código CSS em um arquivo (e minimizando-o)
  • colocando todas as imagens pequenas e reutilizáveis em um sprite;

No entanto, colocar tudo isso como inline em HTML seria impraticável. JS / CSS / sprites são reutilizáveis em todo o site e eles permanecerão no cache do navegador quando você estiver solicitando outra página.

entre. Eu recomendo-lhe um livro sobre o assunto:

    
por 28.02.2011 / 18:16
1

Respostas de servidores da Web não são incluídas em um arquivo, mas duas coisas acontecem

  1. link
  2. compactação de respostas (módulo mod_deflate do módulo do Apache) negociado entre o servidor e o cliente

Acho que os dois juntos fazem o mesmo que você sugere, mas todos baseados na negociação entre cliente e servidor sobre recursos e desejos.

    
por 28.02.2011 / 19:44
1

Como outros já mencionaram, o protocolo HTTP atual fornece suporte limitado para isso.

Há o esquema DATA URI que permite codificar objetos binários como imagens em base64 e embutidos, combinando efetivamente o HTML e o objeto em um arquivo. Isso reduz a capacidade de cache, mas ainda pode valer a pena para pequenos objetos, reduzindo o número de conexões de curta duração e reduzindo a transferência de cabeçalhos não compactados. A extensão do Apache mod_pagespeed do Google realiza este truque, entre outros, automaticamente para objetos de 2k ou menos. Consulte o link

HTTP Pipelining / keepalives são úteis, mas, como Koos van den Hout menciona, só funcionam em objetos com tamanho conhecido. Além disso, o pipelining e a compactação gzip não fazem nada sobre a transferência não compactada de cabeçalhos e cookies.

Um desenvolvimento interessante é o projeto de pesquisa do Google chamado SPDY , que faz quase o que você sugere. Entre outros, ele intercala várias solicitações HTTP em uma única conexão TCP, intercalando e priorizando os recursos. Também comprime todo o fluxo, incluindo cabeçalhos e cookies. Testes mostraram cerca de 50% de redução nos tempos de carregamento de página, então eu definitivamente ficaria de olho neste projeto.

O navegador Google Chrome já está usando o protocolo SPDY ao se comunicar com sites do Google, como Gmail e Pesquisa. Você pode encontrar alguns diagnósticos internos digitando about: net-internals na barra de localização.

    
por 28.02.2011 / 21:45

Tags