🥇[Não] use CDN

Quase todos os artigos ou ferramentas para otimizar a velocidade do site têm uma cláusula modesta “use um CDN”. Em geral, CDN é uma rede de distribuição de conteúdo ou rede de distribuição de conteúdo. Nós do Method Lab frequentemente encontramos perguntas de clientes sobre esse assunto; alguns deles habilitam seu próprio CDN. O objetivo deste artigo é entender o que uma CDN pode proporcionar em termos de velocidade de carregamento do site, quais problemas podem surgir e em quais casos o uso de uma CDN se justifica.

Os atrasos circulados na imagem são causados pelo uso de um CDN.

Um pouco de história

Como muitas tecnologias, as CDNs surgiram por necessidade. Com o desenvolvimento dos canais da Internet entre os internautas, surgiram os serviços de vídeo online. Naturalmente, o conteúdo de vídeo requer muito mais largura de banda em comparação com o conteúdo normal de um site (imagens, texto e código CSS ou JS).

Ao tentar transmitir um fluxo de vídeo em paralelo para vários clientes de um servidor, o canal de Internet do servidor provavelmente se tornará o gargalo. Via de regra, alguns milhares de threads são suficientes para obstruir um canal de servidor típico. É claro que pode haver outras limitações de recursos, mas elas não são importantes neste momento. Também é importante que expandir o canal do servidor seja muito caro (e às vezes impossível) e também impraticável. A carga no canal durante as transmissões será cíclica.

O problema de limitar o canal de um servidor individual é perfeitamente resolvido pelo CDN. Os clientes não se conectam diretamente ao servidor, mas aos nós da rede CDN. Em uma situação ideal, o servidor envia um fluxo para o nó CDN e então a rede usa seus próprios recursos para entregar esse fluxo a muitos usuários. Do ponto de vista económico, pagamos apenas pelos recursos efetivamente consumidos (podem ser largura de banda ou tráfego) e obtemos uma excelente escalabilidade do nosso serviço. Usar um CDN para entregar conteúdo pesado é completamente justificado e lógico. Embora seja importante notar que os maiores players neste espaço (por exemplo, Netflix) estão construindo seus próprios CDNs em vez de usar grandes CDNs comerciais (Akamai, Cloudflare, Fastly, etc.)

À medida que a web evoluiu, os próprios aplicativos da web se tornaram cada vez mais complexos. O problema da velocidade de carregamento veio à tona. Os entusiastas da velocidade do site identificaram rapidamente vários problemas importantes que faziam com que os sites carregassem lentamente. Um deles foram os atrasos na rede (RTT - round trip time ou ping time). Os atrasos afetam muitos processos no carregamento do site: estabelecer uma conexão TCP, iniciar uma sessão TLS, carregar cada recurso individual (imagem, arquivo JS, documento HTML, etc.)

O problema foi agravado pelo fato de que ao usar o protocolo HTTP/1.1 (antes do advento do SPDY, QUIC e HTTP/2 esta era a única opção), os navegadores não abriam mais do que 6 conexões TCP para um host. Tudo isso levou ao tempo de inatividade da conexão e ao uso ineficiente da largura de banda do canal. O problema foi parcialmente resolvido pela fragmentação de domínio - a criação de hosts adicionais para superar o limite no número de conexões.

É aqui que aparece a segunda capacidade do CDN - redução da latência (RTT) devido ao grande número de pontos e à proximidade dos nós ao usuário. A distância desempenha aqui um papel decisivo: a velocidade da luz é limitada (cerca de 200 km/s em fibra óptica). Isso significa que cada 000 km de viagem adiciona 1000 ms de atraso ou 5 ms ao RTT. Este é o tempo mínimo necessário para transmissão, pois também há atrasos nos equipamentos intermediários. Como uma CDN geralmente sabe como armazenar objetos em cache em seus servidores, podemos nos beneficiar carregando tais objetos por meio de uma CDN. Condições necessárias para isso: a presença do objeto no cache, a proximidade do ponto CDN ao usuário em comparação com o servidor de aplicação web (servidor de origem). É importante compreender que a proximidade geográfica de um nó CDN não garante baixa latência. O roteamento entre o cliente e o CDN pode ser construído de forma que o cliente se conecte a um host em outro país e possivelmente em outro continente. É aqui que entram em jogo a relação entre os operadores de telecomunicações e o serviço CDN (peering, ligações, participação em IX, etc.) e a política de encaminhamento de tráfego do próprio CDN. Por exemplo, a Cloudflare, ao utilizar dois planos iniciais (gratuito e barato), não garante a entrega do conteúdo do host mais próximo – o host será selecionado para atingir o custo mínimo.

Muitas empresas líderes de Internet atraem o interesse público (desenvolvedores web e proprietários de serviços) para o tema velocidade de carregamento e desempenho do site. Entre essas empresas estão Yahoo (ferramenta Yslow), AOL (WebPageTest) e Google (serviço Page Speed Insights), que estão desenvolvendo suas próprias recomendações para acelerar sites (principalmente relacionadas à otimização de clientes). Posteriormente, surgem novas ferramentas de teste de velocidade de sites, que também fornecem dicas sobre como aumentar a velocidade do site. Cada um desses serviços ou plug-ins tem uma recomendação consistente: “Use um CDN”. A redução na latência da rede é normalmente citada como explicação para o efeito do CDN. Infelizmente, nem todos estão preparados para compreender exatamente como o efeito de aceleração da CDN é alcançado e como pode ser medido, por isso a recomendação é tomada com fé e usada como postulado. Na verdade, nem todos os CDNs são criados iguais.

Usando um CDN hoje

Para avaliar a utilidade do uso de CDNs, elas precisam ser classificadas. O que pode ser encontrado agora na prática (os exemplos entre parênteses não são, obviamente, exaustivos):

CDN gratuito para distribuição de bibliotecas JS (MaxCDN, Google. Yandex).
CDN de serviços para otimização do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imagens).
CDN para otimização estática e de recursos em CMS (disponível em Bitrix, WordPress e outros).
CDN de uso geral (StackPath, CDNVideo, NGENIX, Megafon).
CDN para aceleração de sites (Cloudflare, Imperva, Airi).

A principal diferença entre esses tipos é quanto do tráfego passa pela CDN. Os tipos 1 a 3 são a entrega de apenas parte do conteúdo: de uma solicitação a várias dezenas (geralmente fotos). Os tipos 4 e 5 são proxy completo de tráfego por meio de um CDN.

Na prática, isso significa o número de conexões utilizadas para carregar o site. Com HTTP/2, usamos uma única conexão TCP com o host para processar qualquer número de solicitações. Se dividirmos os recursos em host principal (origem) e CDN, será necessário distribuir as solicitações em vários domínios e criar várias conexões TCP. O pior caso é: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Esta fórmula não leva em consideração atrasos nas redes móveis para ativação do canal de rádio do aparelho (caso não estivesse ativo) e atrasos na torre de celular.

Esta é a aparência da cascata de carregamento do site (as latências para conexão com o CDN são destacadas em RTT 150 ms):

Se o CDN cobrir todo o tráfego do site (exceto serviços de terceiros), poderemos usar uma única conexão TCP, evitando atrasos na conexão com hosts adicionais. Claro, isso se aplica a conexões HTTP/2.

Outras diferenças são determinadas pela funcionalidade de um CDN específico - para o primeiro tipo ele apenas hospeda um arquivo estático, para o quinto ele altera vários tipos de conteúdo do site para fins de otimização.

Capacidades de CDN para aceleração de sites

Vamos descrever toda a gama de recursos de CDN para acelerar sites, independentemente da funcionalidade de tipos individuais de CDN, e depois ver o que está implementado em cada um deles.

1. Compressão de recursos de texto

O recurso mais básico e compreensível, mas muitas vezes mal implementado. Todos os CDNs declaram a presença de compactação como recurso de aceleração. Mas se você olhar com mais detalhes, as deficiências ficam claras:

graus baixos para compactação dinâmica podem ser usados - 5-6 (por exemplo, para gzip o máximo é 9);
compactação estática (arquivos em cache) não usa recursos adicionais (por exemplo, zopfi ou brotli com grau 11)
não há suporte para compactação Brotli eficiente (economizando cerca de 20% em comparação com o gzip).

Se você usa uma CDN, vale a pena conferir alguns pontos: pegue o arquivo que veio da CDN, registre seu tamanho compactado e compacte manualmente para comparação (você pode usar algum serviço online com suporte para brotli, por exemplo vsszhat.rf).

2. Configurando cabeçalhos de cache do cliente

Também um recurso simples de aceleração: adicionar cabeçalhos para armazenamento em cache de conteúdo pelo cliente (navegador). O cabeçalho mais atual é o cache-control, o desatualizado expira. Além disso, Etag pode ser usado. O principal é que a idade máxima do controle de cache seja grande o suficiente (de um mês ou mais).Se você estiver pronto para armazenar o recurso em cache o máximo possível, poderá adicionar a opção imutável.

Os CDNs podem diminuir o valor máximo de idade, forçando o usuário a recarregar o conteúdo estático com mais frequência. Não está claro a que isso está relacionado: o desejo de aumentar o tráfego na rede ou aumentar a compatibilidade com sites que não sabem como redefinir o cache. Por exemplo, o tempo de cache de cabeçalho padrão da Cloudflare é de 1 hora, o que é muito baixo para dados estáticos imutáveis.

3. Otimização de imagem

Como o CDN assume as funções de armazenar em cache e servir imagens, seria lógico otimizá-las no lado do CDN e servi-las aos usuários desta forma. Vamos fazer uma reserva desde já que esse recurso está disponível apenas para CDN tipos 2, 3 e 5.

Você pode otimizar imagens de várias maneiras: usando formatos de compactação avançados (como WebP), codificadores mais eficientes (MozJPEG) ou simplesmente limpando metadados desnecessários.

Em geral, existem dois tipos de otimizações: com perda de qualidade e sem perda de qualidade. As CDNs geralmente se esforçam para usar a otimização sem perdas para evitar possíveis reclamações dos clientes sobre alterações na qualidade da imagem. Nessas condições, o ganho será mínimo. Na realidade, muitas vezes o nível de qualidade JPEG é muito superior ao necessário e você pode recomprimir com segurança com um nível de qualidade inferior sem comprometer a experiência do usuário. Por outro lado, é difícil determinar o nível de qualidade e configurações universalmente para todas as aplicações web possíveis, por isso as CDNs utilizam configurações mais conservadoras em comparação com aquelas que podem ser aplicadas levando em consideração o contexto (finalidade das imagens, tipo de aplicação web , etc.)

4. Otimizando a conexão TLS

A maior parte do tráfego hoje passa por conexões TLS, o que significa que gastamos mais tempo na negociação TLS. Recentemente, novas tecnologias foram desenvolvidas para acelerar esse processo. Por exemplo, trata-se de criptografia EC, TLS 1.3, cache de sessão e tickets, aceleração de criptografia de hardware (AES-NI), etc. A configuração correta do TLS pode reduzir o tempo de conexão para 0-1 RTT (sem contar DNS e TCP).

Com software moderno, não é difícil implementar tais práticas por conta própria.

Nem todos os CDNs implementam as melhores práticas de TLS; você pode verificar isso medindo o tempo de conexão TLS (por exemplo, no Webpagetest). Ideal para uma nova conexão - 1RTT, 2RTT - nível médio, 3RTT e mais - ruim.

Deve-se notar também que mesmo ao usar TLS no nível CDN, o servidor com nossa aplicação web também deve processar TLS, mas do lado CDN, porque o tráfego entre o servidor e o CDN passa pela rede pública. Na pior das hipóteses, teremos atrasos duplos na conexão TLS (o primeiro para o host CDN, o segundo entre ele e nosso servidor).

Para algumas aplicações, vale a pena prestar atenção às questões de segurança: o tráfego geralmente é descriptografado em nós CDN, e esta é uma oportunidade potencial para interceptação de tráfego. A opção de trabalhar sem divulgação de tráfego costuma ser oferecida nos planos tarifários de ponta mediante o pagamento de uma taxa adicional.

5. Reduza atrasos de conexão

O principal benefício do CDN de que todos falam: baixa latência (menos distância) entre o host do CDN e o usuário. Conseguido através da criação de uma arquitetura de rede distribuída geograficamente, na qual os hosts estão localizados em pontos de concentração de usuários (cidades, pontos de troca de tráfego, etc.)

Na prática, as prioridades para diferentes redes podem estar em regiões específicas. Por exemplo, os CDNs russos terão mais pontos de presença na Rússia. Os americanos desenvolverão primeiro a rede nos EUA. Por exemplo, um dos maiores CDN Cloudflare tem apenas 2 pontos na Rússia - Moscou e São Petersburgo. Ou seja, podemos economizar no máximo cerca de 10 ms de latência em comparação com a colocação direta em Moscou.

A maioria dos CDNs ocidentais não possui nenhum ponto na Rússia. Ao conectar-se a eles, você só pode aumentar os atrasos para o seu público russo.

6. Otimização de conteúdo (minificação, mudanças estruturais)

O ponto mais complexo e tecnologicamente avançado. Alterar o conteúdo durante a entrega pode ser muito arriscado. Mesmo se considerarmos a minificação: reduzir o código-fonte (devido a espaços extras, estruturas sem importância, etc.) pode afetar seu desempenho. Se falamos de mudanças mais sérias - mover o código JS para o final do HTML, mesclar arquivos, etc. - o risco de atrapalhar a funcionalidade do site é ainda maior.

Portanto, apenas alguns CDNs do tipo 5 fazem isso. É claro que não será possível automatizar todas as alterações necessárias para acelerar as coisas – são necessárias análise e otimização manuais. Por exemplo, remover código não utilizado ou duplicado é uma tarefa manual.

Via de regra, todas essas otimizações são controladas pelas configurações e as mais perigosas são desabilitadas por padrão.

Suporte para recursos de aceleração por tipo de CDN

Então, vamos dar uma olhada nas oportunidades potenciais de aceleração que os diferentes tipos de CDNs oferecem.

Por conveniência, repetimos a classificação.

CDN gratuito para distribuição de bibliotecas JS (MaxCDN, Google. Yandex).
CDN de serviços para otimização do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imagens).
CDN para otimização estática e de recursos em CMS (disponível em Bitrix, WordPress e outros).
CDN de uso geral (StackPath, CDNVideo, NGENIX, Megafon).
CDN para aceleração de sites (Cloudflare, Imperva, Airi).

Agora vamos comparar os recursos e tipos de CDN.

Oportunidade
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compressão de texto
+–
-
+–
+–
+

Cabeçalhos de cache
+
+
+
+
+

Fotos
-
+–
+–
-
+

TLS
-
-
-
+–
+

Atrasos
-
-
-
+
+

Conteúdo
-
-
-
-
+

Nesta tabela, “+” é usado para indicar apoio total, “–” significa nenhum apoio e “+–” é apoio parcial. É claro que pode haver desvios desta tabela na realidade (por exemplo, alguns CDN de uso geral implementarão recursos para otimização de imagens), mas para uma ideia geral ela é útil.

Resultados de

Esperançosamente, depois de ler este artigo você terá uma ideia mais clara sobre a recomendação “use um CDN” para acelerar seus sites.

Como em qualquer negócio, você não pode acreditar nas promessas de marketing de qualquer serviço. O efeito precisa ser medido e testado em condições reais. Se você já usa um CDN, verifique a eficácia usando os critérios descritos no artigo.

É possível que o uso de um CDN agora esteja retardando o tempo de carregamento do seu site.

Como recomendação geral, podemos focar no seguinte: estudar o seu público, determinar a sua abrangência geográfica. Se o seu público principal estiver concentrado em um raio de 1 a 2 mil quilômetros, você não precisará de um CDN para seu objetivo principal - reduzir a latência. Em vez disso, você pode colocar seu servidor mais próximo de seus usuários e configurá-lo adequadamente, obtendo a maioria das otimizações descritas no artigo (gratuitas e permanentes).

Caso o seu público esteja verdadeiramente distribuído geograficamente (raio superior a 3000 quilômetros), usar um CDN de qualidade será realmente útil. No entanto, você precisa entender com antecedência o que exatamente seu CDN pode acelerar (veja a tabela de capacidades e sua descrição). No entanto, a aceleração de sites ainda continua sendo uma tarefa complexa que não pode ser resolvida conectando-se um CDN. Além das otimizações acima, os meios de aceleração mais eficazes permanecem atrás do CDN: otimização da parte do servidor, alterações avançadas na parte do cliente (remoção de código não utilizado, otimização do processo de renderização, trabalho com conteúdo, fontes, adaptabilidade, etc. )

Fonte: habr.com

[Não] use um CDN