🥇[Não] use CDN

Praticamente em qualquer artigo ou ferramenta para otimização da velocidade dos sites, existe uma modesta seção que menciona "utilize CDN". De fato, CDN é a rede de entrega de conteúdo, ou content delivery network. Na empresa "Método Lab", frequentemente nos deparamos com perguntas de clientes sobre esse assunto, e alguns deles ativam um CDN por conta própria. O objetivo deste artigo é entender o que um CDN pode oferecer em termos de velocidade de carregamento do site, quais problemas podem surgir e em quais casos a utilização de um CDN é justificada.

As latências destacadas na imagem são causadas pelo uso do CDN.

Um pouco de história

Assim como muitas tecnologias, os CDNs surgiram por necessidade. Com o desenvolvimento das conexões de internet dos usuários, surgiram serviços de vídeo online. É natural que o conteúdo em vídeo exija uma largura de banda significativamente maior do que o conteúdo comum dos sites (imagens, texto e códigos CSS ou JS).

Ao tentar transmitir um fluxo de vídeo para muitos clientes a partir de um único servidor, o gargalo mais provável será a largura de banda do canal do servidor. Normalmente, alguns milhares de fluxos são suficientes para saturar um canal típico de servidor. É claro que podem existir outras limitações de recursos, mas, no momento, isso não é importante. Também é relevante notar que ampliar o canal do servidor é muito caro (e, às vezes, impossível), além de ser ineficaz. A carga no canal durante as transmissões terá um caráter cíclico.

O problema da limitação do canal de um servidor individual é perfeitamente solucionado pelo CDN. Os clientes não se conectam diretamente ao servidor, mas sim aos nós da rede CDN. Na situação ideal, o servidor envia um fluxo para o nó CDN, que, a partir daí, utiliza seus próprios recursos para entregar esse fluxo a múltiplos usuários. Do ponto de vista econômico, pagamos apenas pelos recursos efetivamente consumidos (o que pode ser largura de banda ou tráfego) e obtemos uma excelente escalabilidade do nosso serviço. A utilização de CDN para a entrega de conteúdo pesado é totalmente justificada e lógica. No entanto, vale ressaltar que os maiores players nesta área (como a Netflix) constroem suas próprias CDNs em vez de utilizar grandes CDNs comerciais (Akamai, Cloudflare, Fastly, etc.).

À medida que a web evoluiu, os próprios aplicativos web tornaram-se mais complexos e pesados. O problema da velocidade de carregamento ganhou destaque. Entusiastas da velocidade de sites rapidamente identificaram alguns problemas principais que resultavam em carregamento lento de sites. Um deles eram os atrasos na rede (RTT — round trip time ou tempo de ping). Os atrasos afetam muitos processos no carregamento de um site: a configuração da conexão TCP, o início da sessão TLS, o carregamento de cada recurso individual (imagem, arquivo JavaScript, documento HTML, etc.)

O problema era agravado pelo fato de que, ao usar o protocolo HTTP/1.1 (até o surgimento do SPDY, QUIC e HTTP/2, essa era a única opção), os navegadores abrem no máximo 6 conexões TCP para um único host. Tudo isso resultava em inatividade na conexão e uso ineficaz da largura de banda disponível. O problema era parcialmente resolvido por meio de sharding de domínio – a criação de hosts adicionais para superar o limite no número de conexões.

Aqui surge a segunda capacidade do CDN – a redução de atrasos (RTT) devido ao grande número de pontos e à proximidade dos nós com o usuário. A distância desempenha um papel crucial: a velocidade da luz é limitada (cerca de 200.000 km/s em fibras ópticas). Isso significa que cada 1000 km de trajeto adiciona 5 ms de atraso ou 10 ms em RTT. Esses são os custos mínimos de tempo para a transmissão, pois ainda existem atrasos no equipamento intermediário. Como o CDN geralmente pode armazenar objetos em cache em seus servidores, podemos nos beneficiar do carregamento desses objetos através do CDN. As condições necessárias para isso são: a presença do objeto em cache e a proximidade do ponto CDN em comparação com o servidor da aplicação web (origin server). É importante entender: a proximidade geográfica de um nó do CDN não garante baixos atrasos. O roteamento entre o cliente e o CDN pode ser configurado de tal forma que o cliente se conecte a um host em outro país, possivelmente em outro continente. Aqui entram em ação as relações entre operadoras de telecomunicações e o serviço CDN (peering, existências de interconexões, participação em IX, etc.) e a política de roteamento de tráfego da própria CDN. Por exemplo, o Cloudflare, ao usar os dois planos iniciais (gratuito e barato), não garante a entrega de conteúdo a partir do nó mais próximo – a escolha do host será feita para alcançar o menor custo.

Muitas das principais empresas de internet atraem o interesse do público (desenvolvedores web e proprietários de serviços) para o tema da velocidade de carregamento e funcionamento de sites. Entre essas empresas estão Yahoo (ferramenta Yslow), AOL (WebPageTest) e Google (serviço Page Speed Insights), que desenvolvem suas próprias recomendações para acelerar sites (sobretudo focando na otimização do cliente). Mais tarde, surgem novas ferramentas de teste de velocidade de sites que também oferecem conselhos sobre como aumentar a velocidade. Em cada um desses serviços ou plugins, há uma recomendação constante: 'Use CDN'. Como explicação para o efeito da CDN, geralmente é citada a redução das latências de rede. Infelizmente, nem todos estão dispostos a entender como exatamente esse efeito de aceleração é alcançado através da CDN e como pode ser medido, portanto, a recomendação é aceita como um dado e utilizada como um postulado. Na realidade, nem todas as CDNs são igualmente úteis.

Uso de CDN hoje

Para avaliar a utilidade da aplicação de CDNs, é necessário classificá-las. O que pode ser encontrado atualmente na prática (os exemplos entre parênteses, é claro, não são exaustivos):

CDNs gratuitas para distribuição de bibliotecas JS (MaxCDN, Google, Yandex).
CDNs de serviços de otimização do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imagens).
CDNs para estáticos e otimização de recursos em CMS (disponíveis no Bitrix, WordPress e outros).
CDNs de propósito geral (StackPath, CDNVideo, NGENIX, Megafon).
CDNs para aceleração de sites (Cloudflare, Imperva, Airi).

A chave para a distinção desses tipos reside no seguinte: que parte do tráfego passa pela CDN. Tipos 1-3 envolvem a entrega apenas de parte do conteúdo: desde uma até várias dezenas de requisições (normalmente imagens). Tipos 4 e 5 envolvem o proxy completo do tráfego através da CDN.

Na prática, isso significa a quantidade de conexões que são utilizadas para carregar o site. Ao usar HTTP/2, utilizamos uma única conexão TCP com o host para processar qualquer número de requisições. Se dividimos os recursos entre o host principal (origin) e a CDN, é necessário distribuir as requisições por vários domínios e criar várias conexões TCP. No pior cenário, isso resulta em: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Nesta fórmula, não são consideradas as latências em redes móveis para ativação do canal de rádio do dispositivo (se não estiver ativo) e as latências na torre de celular.

Veja como isso aparece na queda de carga do site (destaques para latências na conexão com o CDN em RTT de 150 ms):

Se o CDN cobre todo o tráfego do site (exceto serviços de terceiros), podemos usar uma única conexão TCP, economizando latências ao conectar a hosts adicionais. Claro, isso se aplica a conexões HTTP/2.

As diferenças adicionais são determinadas pela funcionalidade do CDN específico – para o primeiro tipo, trata-se apenas de para PrestaShop um arquivo estático, para o quinto, isso envolve a modificação de vários tipos de conteúdo do site visando a otimização.

Capacidades do CDN para acelerar o site

Vamos descrever o espectro completo de capacidades do CDN para acelerar sites, sem nos preocupar com a funcionalidade de tipos específicos de CDN, e depois veremos o que está implementado em cada um deles.

1. Compressão de recursos de texto

A capacidade mais básica e intuitiva, no entanto, muitas vezes é implementada de forma deficiente. Todos os CDNs declaram a compressão como um recurso de aceleração. Mas, ao olhar mais de perto, surgem falhas:

podem usar graus baixos de compressão dinâmica – 5-6 (por exemplo, para gzip, o máximo é 9);
na compressão estática (arquivos em cache), não são utilizadas capacidades adicionais (como zopfi ou brotli com grau 11)
não há suporte para compressão eficiente brotli (economia de aproximadamente 20% em relação ao gzip).

Se você está usando um CDN, vale a pena verificar estes pontos: pegue um arquivo que veio do CDN, registre seu tamanho em formato comprimido e descompacte manualmente para comparação (pode usar algum serviço online com suporte a brotli, como всёсжать.рф).

2. Definição de cabeçalhos de cache do cliente

Outra função simples de aceleração: definir cabeçalhos para o cache do conteúdo pelo cliente (navegador). O cabeçalho mais relevante é o cache-control, o obsoleto é o expires. O Etag pode ser usado adicionalmente. O principal é que o max-age do cache-control seja suficientemente longo (de um mês ou mais), se você estiver disposto a armazenar o recurso de forma mais rigorosa, pode adicionar a opção immutable.

Os CDNs podem diminuir o valor de max-age, forçando o usuário a recarregar estáticas com mais frequência. Não está claro se isso se deve ao desejo de aumentar o tráfego na rede ou à necessidade de melhorar a compatibilidade com sites que não conseguem limpar o cache. Por exemplo, o valor do tempo de armazenamento em cache nos cabeçalhos do Cloudflare é, por padrão, de 1 hora, o que é muito baixo para estáticas imutáveis.

3. Otimização de imagens

Como o CDN assume as funções de cache e entrega de imagens, faz sentido otimizá-las do lado do CDN e entregá-las aos usuários dessa forma. Vale ressaltar que essa possibilidade está disponível apenas para CDNs dos tipos 2, 3 e 5.

As imagens podem ser otimizadas de várias maneiras: utilizando formatos avançados de compressão (como WebP), codificadores mais eficientes (MozJPEG) ou simplesmente limpando metadados desnecessários.

De modo geral, existem dois tipos de otimizações: com perda de qualidade e sem perda de qualidade. Normalmente, os CDNs buscam utilizar otimizações sem perdas – para evitar possíveis reclamações dos clientes sobre a alteração na qualidade das imagens. Nessas condições, o ganho será mínimo. Na prática, muitas vezes o nível de qualidade do JPEG excede significativamente o necessário, permitindo a recompressão com uma taxa de qualidade mais baixa, sem prejudicar a percepção dos usuários. Por outro lado, definir um nível de qualidade e configurações universais para todas as aplicações web possíveis é difícil, portanto os CDNs utilizam configurações mais conservadoras em comparação com aquelas que podem ser aplicadas de acordo com o contexto (propósito das imagens, tipo de aplicação web, etc.)

4. Otimização da conexão TLS

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

Com software moderno, implementar essas práticas não é difícil em suas próprias capacidades.

Nem todas as CDN implementam as melhores práticas de TLS, e isso pode ser verificado medindo o tempo de conexão TLS (por exemplo, no Webpagetest). O ideal para uma nova conexão é 1RTT, 2RTT é um nível médio, 3RTT ou mais – é ruim.

Também é importante notar que, mesmo ao usar TLS no nível da CDN, o servidor com nosso aplicativo da web também deve lidar com TLS, mas do lado da CDN, porque o tráfego entre o servidor e a CDN passa por uma rede pública. No pior cenário, teremos duplicações de latência na conexão TLS (a primeira com o host da CDN, a segunda entre ele e nosso servidor).

Para algumas aplicações, vale a pena considerar questões de segurança: geralmente, o tráfego é descriptografado nos nós da CDN, o que representa uma oportunidade potencial para interceptar o tráfego. A opção de operar sem revelar o tráfego é normalmente oferecida em planos de alto nível mediante uma taxa adicional.

5. Redução de latências de conexão

A principal vantagem da CDN, sobre a qual todos falam: baixas latências (menor distância) entre o host da CDN e o usuário. Isso é alcançado pela criação de uma arquitetura de rede geograficamente distribuída, onde os hosts sã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, as CDN russas terão mais pontos de presença na Rússia. As americanas, principalmente, desenvolverão a rede nos EUA. Por exemplo, uma das maiores CDN, a Cloudflare, possui apenas 2 pontos na Rússia – Moscovo e São Petersburgo. Ou seja, no máximo, podemos economizar cerca de 10 ms de latência em comparação com a hospedagem direta em Moscovo.

A maioria das CDN ocidentais não possui pontos na Rússia. Ao se conectar a elas, você pode apenas aumentar a latência para seu público russo.

6. Otimização de conteúdo (minificação, alterações estruturais)

O ponto mais difícil e técnico. Alterar o conteúdo durante a entrega pode ser muito arriscado. Mesmo ao considerar a minificação: a redução do código-fonte (eliminando espaços em branco, construções irrelevantes etc.) pode afetar sua funcionalidade. Em relação a mudanças mais sérias – como mover o código JS para o final do HTML, a combinação de arquivos e similares – o risco de comprometer a funcionalidade do site é ainda maior.

Portanto, apenas alguns CDNs do tipo 5 lidam com isso. Claro, automatizar todas as alterações necessárias para aceleração não será possível – é necessário análise e otimização manuais. Por exemplo, a remoção de código não utilizado ou duplicado é uma tarefa manual.

Em geral, todas essas otimizações são gerenciadas por configurações e as mais perigosas estão desativadas por padrão.

Suporte às capacidades de aceleração por tipos de CDN

Então, vamos ver quais das capacidades potenciais de aceleração são oferecidas pelos diferentes tipos de CDN.

Para facilitar, vamos repetir a classificação.

CDNs gratuitas para distribuição de bibliotecas JS (MaxCDN, Google, Yandex).
CDNs de serviços de otimização do cliente (por exemplo, Google Fonts para fontes, Cloudinary, Cloudimage para imagens).
CDNs para estáticos e otimização de recursos em CMS (disponíveis no Bitrix, WordPress e outros).
CDNs de propósito geral (StackPath, CDNVideo, NGENIX, Megafon).
CDNs para aceleração de sites (Cloudflare, Imperva, Airi).

Agora, vamos correlacionar os recursos e os tipos de CDN.

Possibilidade
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

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

Cabeçalhos de cache
+
+
+
+
+

Imagens
–
+–
+–
–
+

TLS
–
–
–
+–
+

Latências
–
–
–
+
+

Conteúdo
–
–
–
–
+

Nesta tabela, o '+' é usado para indicar suporte total, '–' para ausência, '±' para suporte parcial. Claro, podem haver desvios dessa tabela na realidade (por exemplo, algum CDN de uso geral implementará recursos de otimização de imagens), mas ela é útil para uma visão geral.

Resultados

Espero que, ao ler este artigo, você tenha uma visão mais clara sobre a recomendação 'use CDN' para acelerar sites.

Como em qualquer situação, não se deve acreditar nas promessas de marketing de qualquer serviço. O efeito precisa ser medido e verificado em condições reais. Se você já está usando algum CDN, verifique sua eficácia de acordo com os critérios descritos no artigo.

É possível que o uso de CDN neste momento esteja retardando o carregamento do seu site.

Como recomendação geral, considere o seguinte: estude seu público, determine suas fronteiras geográficas. Se seu público principal está concentrado em um raio de 1 a 2 mil quilômetros, você não precisa de um CDN para sua finalidade principal – a redução de latências. Em vez disso, você pode colocar seu servidor mais perto dos usuários e configurá-lo adequadamente, obtendo a maioria das otimizações descritas no artigo (gratuitamente e continuamente).

Se a sua audiência realmente está distribuída geograficamente (com um raio superior a 3000 quilômetros), usar uma CDN de qualidade pode ser realmente benéfico. No entanto, é necessário entender antecipadamente o que exatamente sua CDN pode acelerar (veja a tabela de recursos e suas descrições). A aceleração do site ainda é uma tarefa complexa, que não é resolvida apenas ao conectar uma CDN. Além das otimizações mencionadas, algumas das ferramentas mais eficazes para acelerar são: otimização do lado do servidor, ajustes avançados do lado 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