O que é necessário para se ter um milhão de acessos?

[su_heading size=”26″ align=”left” margin=”0″]Do ponto de vista técnico, um servidor rápido, uma página leve e muito, muito suor.
Do ponto de vista estratégico, entender o que quem acessa quer, e entregar em menos de 3 ou 4 segundos.[/su_heading]

No começo deste ano, um cliente chegou até a mim porque tinha um site que não aguentava picos de 30 mil acessos em um único dia – ele queria que eu simplesmente ajustasse o servidor.

O site estava hospedado na Amazon, e tudo o que eu posso dizer, é que o custo era altíssimo (algo em torno de US$ 700/mês), e não era condizente com a performance.

Depois de analisar o servidor de cabo a rabo, chegamos a uma conclusão: Todo o produto dele estava errado.

E tudo foi refeito. Do logo ao servidor.

Menos de 15 dias depois do novo site entrar no ar (é um site de viralização de conteúdo) um de seus posts viralizou, e em um único dia o site conseguiu 920 mil sessões – mais de 1 milhão de pageviews.

O mais impressionante é que o servidor que ele roda agora, custa cerca de US$ 40.

Mas como?

Como isso é possível?

Como um servidor tão barato consegue ter uma performance tão superior a um que chegava custar quase 20 vezes mais?

No nosso caso, tudo começou com um bom servidor (digitalocean.com), e uma porta de entrada capaz de receber todo esse fluxo – Nginx.

Depois disso, uma aplicação que consuma pouca memória, e é capaz de entregar o conteúdo na mesma velocidade – Go (golang).

O consumo de memória, mesmo nos momentos de picos, chega a ser irrisório – de 30 a 70 MB, e o consumo de CPU, de 3 a 5%. Não chegamos nem sequer implementar Memcached, por exemplo, de tão boa a resposta do Go.

Isso é simplesmente como se o processo não existisse, e permite que o servidor consiga se concentrar nas outras tarefas – direcionar o fluxo, e buscar o conteúdo.

Aliás, a base de dados usada é PostgreSQL – estável, confiável e rápida.

Outra característica é o site usa um CMS próprio (são duas aplicações separadas, o CMS e o Site), e isso permite ter um controle total sobre a qualidade (técnica) do que é postado, e impede erros na entrada de dados (conteúdo vindo do Word, por exemplo, com um monte de tag’s que ‘sujam’ o html) – também faz com que o conteúdo possa ser indexado de forma mais eficiente.

Além disso, este CMS consegue distribuir ações ‘caras’, que normalmente acontecem no browser do usuário, como por exemplo buscar o número de vezes que o post foi compartilhado, etc, no próprio servido, ao invés de fazê-lo em tempo real, usando o tempo e o 3G do usuário – o CMS trabalha pesado, para que a aplicação do site se concentre somente em servir o conteúdo.

Mas isso só resolve metade do problema.

Esse site tem cerca de 70% de seu acesso via mobile, e com mobile, você tem que ser leve, ter performance, porque se demorar mais do que dois ou três segundos pra carregar, seu usuário simplesmente desiste.

Isso significa um html simples, bem elaborado, imagens bem comprimidas, um css enxuto e uma versão específica pra mobile, e outra pra desktop.

O site é responsivo, mas ele tem uma versão exclusiva pra mobile.

Isso liberta o primeiro load do ‘peso’ que somos obrigados a carregar pra sermos compatíveis com browsers antigos, além, é claro, do html que nem sequer é mostrado (e que acaba somando alguns k’s preciosos).

A versão mobile do site nem sequer usa jQuery (que pesa mais de 100k). O site também não carrega os ‘widgets’ sociais, que parecem inofensivos, mas que juntos custam muito mais de 1 MB no peso total.

As imagens usam uma compressão JPG mais moderna (Mozilla – 95% das imagens do site são JPG’s, e essa compressão acontece automaticamente no servidor), que consegue tirar quase 30% do peso original sem perda de qualidade.

O site tem todos seus scripts sendo carregados depois do conteúdo (async), e não depende deles para funcionar.

Isso nos fez tirar nota A em todos os quesitos nos testes de performance do Google (PageSpeed), entre outros, mas mais importante, fez com que o usuário tenha aquilo que ele tanto quer – ver o post que todos estão comentando na sua timeline, sem ter que esperar, e sem torrar seu plano de 3G.

Num site como esse, a interface, a arte, etc, tem que ficar em 2º plano – primeiro matamos a sede do usuário, e só depois o conquistamos com o sabor e serviços – é isso que vai fazer ele compartilhar o link, e voltar ao site.

Hoje, pouco mais de 4 meses depois, o site tem uma média superior a 5 milhões de sessões/mês, e estamos felizes em tê-los ajudado a começar a atingir seu potencial.

Mas tenho que admitir que o servidor hoje tem o dobro do tamanho (e do custo) – nos dias de muito acesso, o tamanho do arquivo de log acabava estourando o limite do HD (mais de 30 GB).