Como servir mais de 100 mil páginas por dia em uma conexão doméstica lenta

Data original: 7-5-2020
Última atualização: 16-9-2020
Fonte: cheapskatesguide.org
Tradução: PT-BR

A forma mais barata de manter um site é usando a conexão de Internet doméstica que você já possui. O custo é essencialmente zero se você hospedar o site em um computador de baixíssimo consumo, como um Raspberry Pi. O problema dessa abordagem é que a largura de banda de upload costuma ser muito limitada em conexões domésticas; por isso, seu site pode ocasionalmente perder tráfego potencial durante períodos de “alto tráfego”. Por essa razão, e também pela dor de cabeça associada a hospedar um site em um computador fisicamente sob sua posse, a sabedoria convencional diz que você não deve hospedar um site em um servidor dentro de casa. No entanto, existem formas de absorver picos de tráfego mesmo em muitas conexões domésticas de baixa largura de banda.

Vamos olhar alguns números. O tipo de serviço de Internet disponível nos Estados Unidos varia muito de lugar para lugar. Assim, muita gente nos EUA fica presa a conexões domésticas menos adequadas para hospedar um servidor web em casa. Vamos supor que sua única opção seja o serviço DSL de 12 Mbit/s da AT&T, cuja velocidade de upload oscila de segundo a segundo entre 64 KBytes/s e 128 KBytes/s, isto é, entre 512 Kbits/s e 1 Mbit/s. Isso significa que, depois da sobrecarga associada à conexão, sua velocidade média real de upload é de apenas cerca de 90 KBytes/s. Agora, digamos que seu site seja um blog bastante comum, com cerca de 3.000 visitantes e 6.000 visualizações de página por mês. Em uma conexão de 90 KB/s, seu servidor web não deveria ter problema algum para lidar com esse tipo de tráfego em dias normais.

Em raras ocasiões, porém, você publica nas redes sociais aquele artigo de ouro que viraliza, e muito mais pessoas do que o normal querem lê-lo. Vamos supor que determinado artigo leve, em média, 2,16 segundos para ser acessado a partir do seu servidor por cada leitor. Isso significa que ele só poderia ser lido cerca de 40.000 vezes em um período de 24 horas. A situação é um pouco mais complicada por vários fatores, incluindo o fato de que os leitores não chegarão em um fluxo constante. Mas, para esse cenário hipotético, que é um caso ideal para você, digamos que os leitores realmente cheguem em um fluxo relativamente constante. Digamos que 70.000 pessoas tentem ler o artigo no primeiro dia após sua publicação. Isso significa que 30.000 leitores não conseguirão ler seu artigo durante esse pico de tráfego do primeiro dia. Como seu site normalmente recebe apenas cerca de 72.000 visualizações de página por ano, perder 30.000 visualizações durante um único pico de tráfego diário significa perder uma parte substancial de seus leitores potenciais do ano.

Mas ainda não perca a esperança. Há formas de capturar esses raros picos de tráfego. Considerando que você não consegue aumentar sua velocidade de upload e não pode dizer aos leitores para esperarem até amanhã para ler o artigo, geralmente você tem apenas duas opções viáveis para levar seu artigo a mais leitores em pouco tempo: 1) reduzir a quantidade de dados que precisa ser enviada, e 2) maximizar a porcentagem de tempo em que seu servidor está realmente transmitindo dados, em vez de fazer outras coisas, como conectar-se ao navegador do visitante, realizar o handshake SSL, esperar o navegador fazer a próxima requisição etc.

Antes de entrarmos nos detalhes, deixe-me falar de forma geral sobre o que acontece quando um visitante abre uma de suas páginas web no navegador. Vou tratar apenas de generalidades, porque estamos interessados principalmente na cadeia de eventos e em como aumentar a velocidade de cada um deles. Primeiro, o navegador do visitante consulta um servidor DNS para obter o endereço IP do seu site. Depois, o navegador se conecta ao seu servidor web, e ocorre uma conversa majoritariamente unidirecional sobre as características do navegador e do computador dele. Essa é a parte de conexão da transferência da página. Então, se seu site usa HTTPS, ocorre um handshake SSL, no qual são estabelecidos os protocolos TLS que serão usados, o servidor web entrega seu certificado SSL e o navegador verifica se ele é legítimo. Só o handshake SSL pode levar até um terço de segundo. Depois que o navegador confia no servidor web e uma conexão segura foi estabelecida, a transferência de dados está pronta para começar.

Os dados da sua página web são transmitidos em etapas, chamadas de requisições. Cada tipo de dado é solicitado em uma requisição diferente. Primeiro, o arquivo HTML da página é solicitado pelo navegador do visitante. Depois, os dados são enviados, uma requisição por vez, para cada arquivo referenciado dentro do código HTML. Exemplos de arquivos que podem ser referenciados em código HTML incluem arquivos CSS, imagens, vídeos, arquivos de som e favicons. Se sua página web contém 50 imagens, o navegador do visitante precisa fazer 50 requisições para obter todas elas.

Depois de cada requisição, o navegador espera que o servidor web receba a solicitação e comece a enviar os dados de volta. Sempre existe algum tempo de espera para que o início da transmissão de dados chegue ao navegador. Dependendo da distância entre o servidor web e o computador do visitante, o tempo de espera associado a cada requisição pode variar de alguns milissegundos a um quarto de segundo ou mais. Se uma página web tem 50 imagens e o visitante está do outro lado do mundo em relação ao servidor, é possível que transmitir essas 50 imagens uma por vez leve mais de 12,5 segundos, além do tempo necessário para transmitir os dados dos arquivos de imagem. Muitas vezes, várias requisições ocorrem em paralelo, então o tempo total decorrido para enviar 50 imagens pode ser significativamente menor do que 12,5 segundos. Mas não precisa ser.

As linhas do tempo também podem ficar ainda mais complicadas pelo fato de que um servidor web pode ter vários visitantes tentando baixar a mesma página ao mesmo tempo, e muitas das requisições feitas por diferentes visitantes podem ocorrer em paralelo. Essa é outra razão pela qual prever o tempo exato necessário para baixar uma página web pode ser difícil.

Agora que você tem uma compreensão básica do que acontece quando o navegador de um visitante baixa páginas web de um servidor, vamos falar sobre 7 formas de aumentar a quantidade de tráfego que seu servidor consegue suportar em uma conexão de baixa largura de banda.

1. Certifique-se de que você não tem problemas de carregamento de página

Você pode cometer muitos tipos de erro ao criar uma página web, então não vou listar todos aqui. O Google Web Console e testadores de velocidade de carregamento, como o Pingdom Website Speed Test, procurarão erros na sua página e mostrarão quaisquer problemas encontrados. A primeira coisa que você precisa fazer para aumentar a velocidade de carregamento das suas páginas é remover todos esses erros.

2. Crie páginas estáticas ou quase estáticas

Páginas web estáticas geralmente carregam muito mais rápido do que páginas dinâmicas e exigem menos largura de banda. Uma razão é que páginas estáticas não exigem que JavaScript seja enviado ao navegador do visitante. Se você precisa ter algum conteúdo dinâmico, considere usar código PHP executado no servidor, em vez de código executado no computador do visitante. Mas lembre-se: quanto mais código você roda no servidor, mais poderoso ele precisa ser; e mais potência significa maior custo de eletricidade. Se você tem uma conexão de Internet de baixa largura de banda e não quer ter altos custos de energia, esqueça coisas que devoram CPU, como animações nas suas páginas. Esqueça programas de banco de dados. Esqueça qualquer coisa além de código muito simples rodando dentro das suas páginas. A maior parte do enfeite visual que você vê na Internet hoje é servida por conexões de alta velocidade e por servidores que custam milhares de dólares cada, pertencentes a grandes empresas que podem pagar por eles e pela eletricidade para mantê-los. Infelizmente, quase todas as informações que você provavelmente encontrará sobre a melhor abordagem para desenvolver um site serão sobre esse tipo de site. Não caia na armadilha de pensar que esses são os únicos tipos de site que você pode construir.

Se você absolutamente precisa de algum conteúdo dinâmico, pense com muito cuidado em formas de minimizá-lo. Por exemplo, em vez de um pacote completo de analytics, escreva seu próprio código PHP que não faça nada além de contar o número de vezes que uma página foi visitada. Em vez de usar algum código comercial de comentários de visitantes que também exige que você rode um programa de banco de dados, escreva seu próprio código menor e mais rápido. Ou use o Babbleweb para comentários de visitantes. E considere desativar comentários depois que 20 ou 30 tiverem se acumulado em determinado artigo.

3. Reduza a quantidade de dados em cada página web

Reduzir a quantidade de dados por página que seu servidor precisa enviar pode aumentar significativamente a velocidade de carregamento. Por exemplo, passar de três imagens de 500 KB em uma página para uma imagem de 50 KB pode economizar mais de 16 segundos em uma conexão de 90 KBytes/s. Até reduzir a quantidade de texto HTML escrevendo de forma mais sucinta ou dividindo um artigo longo em dois ou mais artigos menores pode ajudar. E, se seu código CSS estiver em um arquivo separado do código HTML, você deve limpar o CSS para se livrar de tudo que não é mais usado e minimizar o número de comentários. Nem é preciso dizer que um arquivo de texto leva muito menos tempo para ser enviado do que a mesma informação apresentada em formato de áudio ou vídeo.

Não se esqueça de usar formatos de imagem que minimizem o tamanho dos seus arquivos. Você deve experimentar sites como Picresize e Compress.io para ver quanta compressão consegue aplicar sem que as imagens prejudiquem a aparência geral do seu site.

4. Reduza o número de requisições por página

Como a introdução deste artigo observou, o número de requisições que o navegador de um visitante precisa fazer para obter todo o conteúdo de uma página web pode ter um grande efeito no tempo de carregamento. Portanto, vale a pena minimizar o número de imagens desnecessárias e outros tipos de dados incluídos nas suas páginas. Considere também colocar o código CSS dentro dos arquivos HTML, em vez de deixá-lo em arquivos separados. Colocar CSS em um arquivo separado usado por vários arquivos HTML permite alterar mais facilmente a aparência do site, mas também significa que uma requisição adicional precisa ser feita para cada página que inclui esse arquivo CSS.

Qualquer visitante que tente acessar uma página do seu site via HTTP e precise ser transferido para a página HTTPS consome uma requisição adicional. Pense em formas de minimizar quantas vezes isso acontece. Falando em HTTP versus HTTPS, ninguém parece mencionar que o preço pago pela segurança adicional do HTTPS é o aumento de largura de banda e de requisitos de CPU. Só o handshake SSL pode aumentar o tempo de carregamento da página em mais de um quarto de segundo.

5. Comprima suas páginas web

A maioria dos servidores web consegue comprimir conteúdo automaticamente antes de enviá-lo aos navegadores dos visitantes. Isso pode reduzir a quantidade de dados que precisa ser enviada para código HTML e CSS em 50% a 70%. Até onde consigo perceber, a compressão não exige muita CPU. Também notei que, quando uma página dinâmica está recebendo muito tráfego, o servidor web Lighttpd parece manter essa página comprimida dinamicamente na RAM por algum tempo, para não precisar recomprimi-la antes de cada envio. Páginas estáticas são comprimidas apenas uma vez, não importa quantas vezes sejam enviadas.

Você deve comprimir seus arquivos de imagem antes de incluí-los nas páginas. Como resultado, pedir ao servidor para comprimir imagens novamente não reduz significativamente o tamanho delas. Isso apenas aumenta seus requisitos de CPU. Portanto, você deve configurar seu servidor web para não comprimir imagens.

6. Não use software de desenvolvimento de sites para criar seu site

Não usar software comercial de desenvolvimento de sites contraria praticamente tudo que todo mundo na Internet diz a você. Mesmo assim, é a coisa certa a fazer em conexões de Internet de baixa largura de banda. Para ilustrar meu ponto, escolhi esta página do blog de Matt Mullenweg, que roda em WordPress. Escolhi essa página porque ela é majoritariamente texto, com apenas algumas imagens e sem publicidade. A página tem 9.669 bytes de texto visível ao leitor, mas o arquivo HTML contém 144.591 bytes de código HTML, graças ao WordPress! Para comparação, escolhi este artigo do meu site, que escrevi manualmente em HTML. Ele tem uma imagem e nenhuma publicidade. O leitor vê 9.698 bytes de texto, e o arquivo HTML contém apenas 15.074 bytes de código. Isso é cerca de um décimo do código do artigo de Matt! Eu provavelmente poderia ter reduzido isso para menos de 12.000 bytes se realmente quisesse. A propósito, também tenho um arquivo CSS de 3.105 bytes incluído no meu arquivo HTML. O HTML de Matt inclui três arquivos CSS cujos tamanhos nem me dei ao trabalho de verificar.

Agora, vejamos o custo de deixar o WordPress criar seu código HTML. O tempo necessário para enviar os 15.074 bytes de HTML do meu artigo por uma conexão de 90 KB/s seria de 0,167 segundo. O tempo para enviar o código HTML do artigo de Matt Mullenweg pela mesma conexão seria de 1,607 segundo. O código HTML geralmente é comprimido antes de ser enviado ao leitor, então a diferença de tempo não seria tão grande assim, mas ainda seria significativa.

O tempo médio para carregar apenas a parte HTML comprimida do meu artigo, o arquivo CSS comprimido associado e um pequeno favicon, de acordo com https://tools.pingdom.com, com um pequeno ajuste para simular uma conexão de 90 KB/s, é de 0,496 segundo; desses, 0,076 segundo são devidos ao envio do meu arquivo HTML comprimido para 6,8 KB. Supondo que o artigo de Matt seja comprimido na mesma proporção, apenas o código HTML dele levaria cerca de (0,496 - 0,076 + (6,8/15,1)*144,6/90) = 1,144 segundo para aparecer no navegador do leitor. Isso significa que, sem considerar imagens embutidas, cerca de 2,3 dos meus artigos (1,144/0,496 = 2,31) podem ser enviados aos leitores no mesmo tempo que o artigo de Matt. Assim, em uma conexão capaz de enviar 90 KBytes/s, os leitores poderiam visualizar a parte apenas textual do artigo de Matt cerca de 76.000 vezes por dia, e a parte textual do meu artigo cerca de 174.000 vezes por dia. Em outras palavras, o texto do meu artigo pode ser visto cerca de 98.000 vezes a mais por dia do que o de Matt. Essas 98.000 visualizações adicionais poderiam representar uma parte significativa do tráfego anual de um site pequeno. Portanto, mesmo com compressão de código HTML, ainda vale a pena escrever seu próprio código HTML.

Observe que simplifiquei minha análise ao não levar em conta a leve melhoria que muitos visitantes solicitando páginas ao mesmo tempo poderiam obter devido a alguma entrega paralela de páginas. No entanto, o fato básico de que minha página pode ser lida por várias dezenas de milhares de visitantes a mais por dia do que a de Matt ainda está correto.

7. Use um serviço gratuito de CDN para hospedar temporariamente imagens em artigos novos

Em páginas web típicas, arquivos de imagem geralmente contêm mais dados do que arquivos HTML; portanto, pode ser muito benéfico em termos de largura de banda hospedar imagens em algum lugar diferente do seu servidor web. Um lugar para onde você pode mover suas imagens é uma CDN, ou Content Delivery Network. O arquivo HTML da sua página passará então a ter um link para a imagem na CDN, em vez de um link para a imagem no seu servidor web. Para aqueles que não querem depender de uma CDN para hospedar permanentemente parte do conteúdo, existe outra forma. A maioria dos picos de tráfego ocorre na primeira semana após publicar um novo artigo nas redes sociais. Assim, você provavelmente só precisará hospedar as imagens dos artigos novos em uma CDN durante a primeira semana após publicá-los. Depois disso, pode colocar as imagens no seu próprio servidor web. Para sites pequenos, CDNs podem cobrar pela quantidade de conteúdo hospedado, em vez de pelo número de downloads; portanto, hospedar apenas algumas imagens por vez pode significar pagar pouco ou nada pelo uso do serviço de CDN.

Se você não quiser usar uma CDN para hospedar suas imagens, nem mesmo durante picos de tráfego, considere reduzir temporariamente o tamanho das imagens. Reduzir uma imagem de 640x480 pixels para 320x240 pode reduzir a quantidade de dados que você precisa transmitir para um terço ou um quarto do tamanho original. A imagem pode não ficar tão boa para seus leitores, mas pelo menos eles ainda conseguirão vê-la. E, em um ou dois dias, quando o pico de tráfego tiver passado, você pode recolocá-la em 640x480.

Resumo

Aqui estão as sete formas que sugeri para capturar aqueles picos de tráfego que ocasionalmente podem ocorrer no seu servidor web:

7 dicas para hospedar um site em uma conexão de Internet de baixa largura de banda

1. Certifique-se de que você não tem problemas de carregamento de página.
2. Crie páginas web estáticas ou quase estáticas.
3. Reduza a quantidade de dados em cada página web.
4. Reduza o número de requisições por página.
5. Comprima suas páginas web.
6. Não use software de desenvolvimento de sites para criar suas páginas web.
7. Use um serviço gratuito de CDN para hospedar temporariamente imagens em artigos novos.

Usando esses métodos, talvez você consiga aumentar o pico de tráfego que seu servidor web suporta em uma conexão doméstica de baixa largura de banda por um fator de quatro, cinco ou até mais. Isso pode permitir que você continue hospedando seu site em casa virtualmente de graça, mesmo quando ele receber picos ocasionais de tráfego muito acima de cem mil visualizações de página por dia.

Se você achou este artigo útil, compartilhe-o na sua rede social favorita. Você encontrará links de compartilhamento no topo da página.

Atualização de 8-5-20 às 18h

Como Jamie gentilmente apontou em seu comentário abaixo, meu provedor de CDN parou de servir a imagem no topo deste artigo por volta das 9h desta manhã. Isso aconteceu cerca de 7 horas depois que o artigo começou a receber uma grande quantidade de tráfego, aproximadamente 15.000 visualizações de página nas primeiras 5 ou 6 horas. Quando entrei na minha conta no CDN77.com, vi um banner no topo da página dizendo: “Sua conta foi suspensa. Seu site não está acelerado pela CDN.” Nenhuma explicação foi fornecida. Depois de investigar um pouco, parece que cometi o erro clássico de ver apenas parte da estrutura de cobrança deles e presumir que nenhuma outra cobrança se aplicava. Em resumo: o que eu estava supondo ser um plano gratuito, na verdade, não era gratuito. Então, claramente, preciso encontrar outra CDN “gratuita”, e desta vez preciso garantir que ela realmente seja gratuita.

Atualização de 16-9-20

Hoje recebi uma grande quantidade de tráfego em outro site. O tráfego foi todo para um artigo específico que publiquei em redes sociais. Durante um período de 646 segundos perto do pico de tráfego, meu script PHP contador de visualizações registrou 1.763 visualizações de página. Isso equivale a 2,73 visualizações por segundo, ou o equivalente a mais de 235.000 visualizações de página por dia. O HTML comprimido, o CSS comprimido e a imagem totalizavam 21.094 bytes de dados enviados pelo servidor Raspberry Pi 3 por visualização de página. Até onde pude perceber, ele pareceu lidar com o tráfego sem qualquer problema perceptível.