Por que recursos como o gzip não são ativados por padrão em muitos servidores da Web?

Question

Tendo jogado com vários servidores on-line, vi coisas como o goDaddy não ativar o gzip por padrão. Mesmo com algumas quedas do IIS, instalações padrão do apache e assim por diante.

Eu continuo executando em servidores que não possuem recursos básicos que melhoram a velocidade do seu website por padrão.

Isso me leva a duas opções: todos que fazem pacotes de webserves mal, ou eu simplesmente não entendo por que eles fizeram isso. É muito mais provável que eu não saiba por que eles não fazem isso.

Alguém poderia me explicar por que você enviaria servidores da Web com recursos desativados, como o gzip, e vários cabeçalhos de controle de cache?

Eu achei que os sites mais rápidos eram resultado disso, de acordo com o que o ySlow e o PageSpeed me dizem o tempo todo. Quais são as desvantagens?

    

Answer 1

"recursos" - leva ram & CPU para comprimir o seu conteúdo em tempo real ... muito pouco, mas recursos, no entanto, em um site ou dois é trivial, mas em 1000 ou mais ... as coisas podem ficar funky.  Também - o comentário do Falcon é válido - os fornecedores querem a configuração 'bare bones' à prova de falhas como padrão.

-sean

ATUALIZAÇÃO: Eu esqueci também: o tempo de execução extra em cada requisição para fazer a compressão real também - existe a memória extra usada carregando o mod_deflate [deflate_module] em primeiro lugar, então geralmente todo processo fica um pouco mais gordo e um pouco mais lento . ~ como eu digo, geralmente trivial, mas se você está precisando de recursos para começar ...

    

Answer 2

Um motivo pode ser a compatibilidade com o IE6. Enquanto o IE6 suporta gzip, ele só faz isso em 65535 bytes de tamanho comprimido.

Se a sua página for maior do que isso, o resto será cortado sem explicação. Mas aqui está a parte engraçada: só acontece se a página foi carregada do cache de arquivos, não se for recebida pela rede, tornando toda a bagunça difícil de depurar.

Ele pode ser contornado pelo processamento dos cabeçalhos da solicitação, mas às vezes haverá um proxy transparente usando o IE6, por exemplo. software de vírus. O proxy não altera nenhum cabeçalho User-Agent, então você está sem sorte. Ainda bem que o IE6 está quase erradicado.

Não tenho certeza se todas as versões foram afetadas ou apenas algumas, mas o motivo acima foi o motivo pelo qual o site em que trabalho teve gzip off por um longo tempo.

    

Answer 3

Você pode pensar que é porque o GZip não é suportado por todos os navegadores. Essa explicação está errada: um servidor pode ser compatível com versões anteriores com base no cabeçalho Accept-Encoding da solicitação, que indica se o navegador pode aceitar conteúdo compactado com GZip.

Uma possível explicação é que não há necessidade de compactar tudo. Por que você compactaria um arquivo ZIP ou uma imagem JPEG? Na melhor das hipóteses, o tamanho será o mesmo. Na pior das hipóteses, ele se tornará maior.

Outro fator é o desempenho do lado do servidor. É melhor deixar o desenvolvedor ativar a compactação quando esse desenvolvedor souber o impacto na CPU e os prós e contras do ZGip em relação a um conteúdo específico.

    

Answer 4

Eu acho que é por razões de compatibilidade. Alguns clientes não podem descompactá-lo e, em alguns casos raros, podem quebrar a funcionalidade do lado do servidor. Os fornecedores provavelmente querem uma configuração padrão à prova de falhas.

    

Answer 5

Quanto menos instruções um servidor da web precisar para executar, mais solicitações poderão ser exibidas.

A compactação gzip recebe instruções para executar, o que diminui a velocidade. Se você quiser, pode ligá-lo.

    

Answer 6

Minha resposta pode ser tola e controvertida, mas você pode imaginar o quanto de receita as empresas como a Amazon vão perder se a compactação HTTP estiver ativada por padrão? O tráfego é uma parte significativa da fatura mensal e todas essas APIs tranquilas transportam toneladas de dados.