Com a adoção do SPDY e o progresso do HTTP 2.0, ouvi algumas pessoas se referirem a domain sharding como um anti-pattern de desempenho. Eu discordo. Fragmentar recursos entre múltiplos domínios oferece um ganho expressivo de desempenho para muitos websites. Entretanto, há espaço para debate. Domain sharding não é apropriado para todo mundo. Essa técnica pode impactar negativamente o desempenho se feita de maneira incorreta e sua utilidade pode ser de curto prazo. Vale a pena fazer domain sharding? Vamos ver.

Compilando os dados

O HTTP Archive possui um campo chamado de “maxDomainReqs”. A explicação necessita de algumas linhas: websites requisitam recursos de vários domínios. Um website hoje acessa, em média, 16 diferentes domínios, conforme mostra o gráfico abaixo. Esse número subiu de 12.5 há um ano. Isso não é surpresa, dado o aumento do conteúdo de terceiros (anúncios, widgets, analytics).

O HTTP Archive contabiliza o número de requisições feitas a cada domínio. O domínio com a maior parte das requisições é o “max domain”, e o número de requisições naquele domínio é o “maxDomainReqs”. O valor médio do maxDomainReqs subiu de 47 para 50 no último ano. Não se trata de um aumento enorme, mas o fato de o número médio de requisições em um domínio ser tão grande é assustador.

50 é a média de maxDomainReqs entre a lista dos primeiros 300 mil sites do Reino Unido. Mas média não conta a história toda. Usando os dados do HTTP Archive no BigQuery e o bigqueri.es, ambos criados pelo Ilya Grigorik, é fácil encontrar a porcentagem para maxDomainReqs: nos primeiros 50% é 39, já em 90% é 97, e em 95% são 127 requisições em um único domínio.

Esses dados mostram que a maioria dos sites possui 39 ou mais recursos sendo baixados de um único domínio. A maior parte dos navegadores faz seis requisições por hostname. Se distribuirmos igualmente esses 39 recursos entre as conexões, cada conexão precisa fazer seis ou mais requisições sequenciais. Tempos de resposta por requisição variam muito, mas eu uso 500 ms como uma estimativa otimista. Se usarmos 500 ms como um tempo de resposta típico, isso introduz um entrave de 3000 ms no tempo de resposta. Na realidade, requisições são atribuídas a qualquer conexão disponíve,l e 500 ms talvez não seja o tempo de resposta típico para suas requisições. Mas dado o limite de seis conexões por hostname, 39 requisições em um domínio é um número muito grande.

Fragmentação errada

Há custos em domain sharding. Você precisará modificar seu website. É provável que se trate de um custo único; a infraestrutura tem que ser configurada uma única vez. Em termos de desempenho, o maior custo é a resolução de DNS extra para cada novo domínio. Outro custo de desempenho é o “overhead” de estabelecer cada conexão TCP e reforçar o congestionamento das janelas de conexões.

Apesar desses custos, domain sharding tem grandes benefícios para sites que precisam disso e que executam essa estratégia de forma correta. A primeira parte é importante – não faz sentido fazer domain sharding se o seu site tem um baixo número de “maxDomainReqs”. Por exemplo, se o número máximo de recursos baixáveis em um único domínio é 6, então você não deve executar a fragmentação. Com apenas 6 requisições em um único domínio, a maioria dos navegadores é capaz de baixar todos os 6 em paralelo. Por outro lado, se você tiver 39 requisições em um único domínio, fragmentar é provavelmente uma boa opção. Portanto, onde está o corte entre 6 e 39? Não tenho dados para responder a essa pergunta, mas eu diria que 20 é uma boa medida. Outros aspectos da página afetam essa decisão. Por exemplo, se sua página tem muitas outras requisições, então esses 20 recursos podem não se sustentar.

O sucesso de domain sharding pode ser diminuído se feito incorretamente. É importante manter estas dicas em mente.

• É melhor fragmentar em apenas dois domínios. Você pode testar valores maiores, mas testes anteriores demonstraram que dois é o valor ideal.
• Certifique-se de que a lógica de fragmentação está consistente para cada recurso. Você não quer que um só elemento, digamos main.js, fique alternando entre o domínio1 e domínio2.
• Você não precisa configurar diferentes servidores para cada domínio – apenas crie CNAMESs. O navegador não se preocupa com o endereço IP final – ele se importa apenas com diferentes domínios.

Essas e outras questões estão explicadas em mais detalhes no capítulo 11 do Even Faster Web Sites.

Solução de curto prazo?

Talvez o único forte argumento contra domain sharding seja o de que ele é desnecessário no mundo do SPDY (assim como no HTTP 2.0). Na verdade, domain sharding provavelmente prejudica o desempenho sob o SPDY, pois este suporta requisições concorrentes (envie todos os cabeçalhos de requisições antes), assim como a priorização de requisições. Fragmentação entre múltiplos domínios diminui esse benefício. O SPDY é suportado por Chrome, Firefox, Opera e IE11. Se o seu tráfego é dominado por esses navegadores, você talvez queira pular essa alternativa. Por outro lado, IE6 e 7 ainda são populares e suportam apenas duas conexões por hostname, portanto a fragmentação oferece um ganho ainda maior nesses navegadores.

Uma solução intermediária é alterar para domain sharding dependendo do cliente: 1 domínio para navegadores que suportam SPDY, 2 domínios para navegadores não-SPDY modernos, 3-4 domínios para o IE6-7. Isso torna a fragmentação mais difícil de implementar. Isso também torna menor a taxa de hits de cache em proxies intermediários.

Não há necessidade de fragmentação no mundo do HTTP 2.0 em todos os navegadores populares. Até lá, não há “bala de prata”. Mas se você está em um site com 39 ou mais recursos em um único hostname, talvez valha a pena explorar domain sharding.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/