Melhore o desempenho usando uma rede de fornecimento de conteúdo.
As redes de fornecimento de conteúdo (CDNs) melhoram o desempenho do site usando uma rede distribuída de servidores para fornecer recursos aos usuários. Como as CDNs reduzem a carga do servidor, elas reduzem os custos com servidores e são adequadas para lidar com picos de tráfego. Este artigo discute como as CDNs funcionam e fornece orientação independente de plataforma sobre como escolher, configurar e otimizar uma configuração de CDN.
Visão geral
Uma rede de fornecimento de conteúdo consiste em uma rede de servidores otimizados para entregar conteúdo rapidamente aos usuários. Embora as CDNs sejam provavelmente mais conhecidas por disponibilizar conteúdo em cache, as CDNs também podem melhorar a entrega de conteúdo que não pode ser armazenado em cache. De modo geral, quanto mais conteúdo do seu site for disponibilizado pela CDN, melhor.
De modo geral, os benefícios de desempenho das CDNs são resultado de vários princípios: os servidores CDN estão localizados mais perto dos usuários do que os servidores de origem e, portanto, têm uma latência de tempo de retorno (RTT) menor. As otimizações de rede permitem que as CDNs forneçam conteúdo mais rapidamente do que se o conteúdo fosse carregado "diretamente" do servidor de origem. Por fim, a CDN armazena em cache a necessidade de uma solicitação ir até o servidor de origem.
Entrega de recursos
Embora possa parecer não intuitivo, usar uma CDN para fornecer recursos (mesmo os que não podem ser armazenados em cache) normalmente será mais rápido do que fazer com que o usuário carregue o recurso "diretamente" de seus servidores.
Quando uma CDN é usada para entregar recursos da origem, uma nova conexão é estabelecida entre o cliente e um servidor CDN próximo. O restante da jornada (ou seja, a transferência de dados entre o servidor e a origem da CDN) ocorre pela rede da CDN, que geralmente inclui conexões persistentes existentes com a origem. Os benefícios são duplos: encerrar a nova conexão o mais próximo possível do usuário elimina custos desnecessários de configuração da conexão (estabelecer uma nova conexão é caro e requer várias idas e voltas). O uso de uma conexão pré-aquecida permite que os dados sejam transferidos imediatamente com a maior capacidade de processamento possível.
Algumas CDNs melhoram isso ainda mais, roteando o tráfego para a origem por meio de vários servidores CDN espalhados pela Internet. As conexões entre servidores CDN ocorrem em rotas confiáveis e altamente otimizadas, em vez de rotas determinadas pelo Border Gateway Protocol (BGP). Embora o BGP seja o protocolo de roteamento de fato da Internet, suas decisões de roteamento nem sempre são voltadas para o desempenho. Portanto, as rotas determinadas pelo BGP provavelmente terão menos desempenho do que as rotas ajustadas entre os servidores de CDN.
Armazenamento em cache
Armazenar recursos em cache nos servidores de uma CDN elimina a necessidade de uma solicitação viajar até a origem para ser disponibilizada. Como resultado, o recurso é entregue mais rapidamente e também reduz a carga no servidor de origem.
Adicionar recursos ao cache
O método mais comumente usado para preencher os caches da CDN é solicitar que os recursos do CDN sejam necessários. Isso é conhecido como "extração da origem". Na primeira vez que um recurso específico for solicitado do cache, a CDN o solicitará do servidor de origem e armazenará a resposta em cache. Dessa forma, o conteúdo do cache é construído ao longo do tempo à medida que recursos sem cache adicionais são solicitados.
Como remover recursos do cache
As CDNs usam a remoção de cache para remover periodicamente recursos menos úteis do cache. Além disso, os proprietários de sites podem usar a limpeza para remover explicitamente os recursos.
Remoção de cache
Os caches têm capacidade de armazenamento finita. Quando um cache se aproxima da capacidade dele, ele libera espaço para novos recursos, removendo aqueles que não foram acessados recentemente ou que ocupam muito espaço. Esse processo é conhecido como remoção de cache. Um recurso removido de um cache não significa necessariamente que ele foi removido de todos os caches em uma rede CDN.
Limpeza
A limpeza (também conhecida como "invalidação de cache") é um mecanismo para remover um recurso dos caches de uma CDN sem ter que esperar que ele expire ou seja removido. Geralmente, ela é executada usando uma API. A limpeza é fundamental em situações em que o conteúdo precisa ser retirado. Por exemplo, para corrigir erros de digitação, preços ou matérias jornalísticas incorretas. Além disso, ela também pode desempenhar um papel crucial na estratégia de armazenamento em cache de um site.
Se uma CDN for compatível com a limpeza quase instantânea, ela poderá ser usada como um mecanismo para gerenciar o armazenamento em cache do conteúdo dinâmico: armazene o conteúdo dinâmico em cache usando um TTL longo e limpe o recurso sempre que ele for atualizado. Dessa forma, é possível maximizar a duração do armazenamento em cache de um recurso dinâmico, mesmo sem saber antecipadamente quando o recurso será alterado. Essa técnica às vezes é chamada de "armazenamento em cache sem aviso prévio".
Quando a limpeza é usada em escala, ela normalmente é utilizada em conjunto com um conceito conhecido como "tags de cache" ou "chaves de cache substitutas". Esse mecanismo permite que os proprietários de sites associem um ou mais identificadores adicionais (às vezes chamados de "tags") a um recurso armazenado em cache. Essas tags podem ser usadas para realizar uma limpeza altamente granular. Por exemplo, é possível adicionar uma tag de "rodapé" a todos os recursos (por exemplo,
/about,/blog) que contêm o rodapé do site. Quando o rodapé for atualizado, instrua a CDN a limpar todos os recursos associados à tag "footer".
Recursos armazenáveis em cache
Se e como um recurso deve ser armazenado em cache depende se ele é público ou privado, estático ou dinâmico.
Recursos privados e públicos
Recursos particulares
Os recursos privados contêm dados destinados a um único usuário e, portanto, não devem ser armazenados em cache por uma CDN. Recursos particulares são indicados pelo cabeçalho
Cache-Control: private.Recursos públicos
Os recursos públicos não contêm informações específicas do usuário e, portanto, podem ser armazenados em cache por uma CDN. Um recurso pode ser considerado armazenável em cache por uma CDN se não tiver um cabeçalho
Cache-Control: no-storeouCache-Control: private. O período pelo qual um recurso público pode ser armazenado em cache depende da frequência com que o recurso é alterado.
Conteúdo dinâmico e estático
Conteúdo dinâmico
O conteúdo dinâmico é alterado com frequência. Uma resposta de API e uma página inicial da loja são exemplos desse tipo de conteúdo. No entanto, o fato de esse conteúdo mudar com frequência não o impede necessariamente de ser armazenado em cache. Durante períodos de tráfego intenso, armazenar essas respostas em cache por períodos muito curtos (por exemplo, cinco segundos) pode reduzir significativamente a carga no servidor de origem, tendo impacto mínimo na atualização de dados.
Conteúdo estático
O conteúdo estático muda com pouca frequência, se for o caso. Imagens, vídeos e bibliotecas com controle de versões geralmente são exemplos desse tipo de conteúdo. Como o conteúdo estático não muda, ele deve ser armazenado em cache por um longo time to live (TTL), por exemplo, seis meses ou um ano.
Como escolher uma CDN
Geralmente, o desempenho é uma das principais considerações ao escolher uma CDN. No entanto, é importante considerar os outros recursos oferecidos por uma CDN (por exemplo, recursos de segurança e análise), assim como os preços, o suporte e a integração da CDN.
Desempenho
De modo geral, a estratégia de desempenho de uma CDN pode ser considerada em termos de equilíbrio entre minimizar a latência e maximizar a taxa de ocorrência em cache. CDNs com muitos pontos de presença (PoPs) podem oferecer latência menor, mas podem ter proporções de ocorrência em cache mais baixas devido à divisão do tráfego em mais caches. Por outro lado, CDNs com menos PoPs podem estar localizadas geograficamente mais distantes dos usuários, mas podem alcançar proporções de ocorrência em cache mais altas.
Como resultado dessa compensação, algumas CDNs usam uma abordagem em camadas para o armazenamento em cache: os PoPs localizados perto dos usuários (também conhecidos como "caches de borda") são complementados com PoPs centrais com maiores proporções de ocorrência em cache. Quando um armazenamento em cache de borda não encontra um recurso, ele procura um PoP central para o recurso. Essa abordagem troca uma latência um pouco maior por uma probabilidade maior de que o recurso possa ser disponibilizado de um cache de CDN, embora não necessariamente de um cache de borda.
A compensação entre minimizar a latência e maximizar a proporção de ocorrência em cache é um espectro. Nenhuma abordagem específica é universalmente melhor. No entanto, dependendo da natureza do seu site e da base de usuários, você poderá descobrir que uma dessas abordagens oferece um desempenho significativamente melhor do que a outra.
Também é importante notar que o desempenho da CDN pode variar significativamente, dependendo da região geográfica, da hora do dia e até mesmo dos eventos atuais. Embora seja sempre uma boa ideia fazer sua própria pesquisa sobre o desempenho de uma CDN, pode ser difícil prever o desempenho exato que você obterá de uma CDN.
Efeitos na Maior exibição de conteúdo (LCP, na sigla em inglês)
Conforme descrito anteriormente neste artigo, o objetivo principal de uma CDN é reduzir a latência, distribuindo recursos para servidores geograficamente mais próximos dos usuários. Por isso, o principal benefício da CDN é que ela melhora o desempenho de carregamento. Em particular, o Tempo até o primeiro byte (TTFB, na sigla em inglês) de um recurso pode ser melhorado significativamente ao introduzir uma CDN na arquitetura do lado do servidor do seu site.
Embora a TTFB não seja uma métrica de desempenho centrada no usuário, ela é uma métrica importante para diagnosticar problemas com a Maior exibição de conteúdo (LCP), que é uma métrica centrada no usuário.
As CDNs são particularmente eficazes para melhorar a LCP, já que podem melhorar a entrega de documentos (reduzindo o TTFB na configuração da conexão e no armazenamento em cache do documento) e na melhoria da entrega de quaisquer recursos estáticos necessários para renderizar o elemento da LCP.
Mais recursos
Normalmente, as CDNs oferecem uma ampla variedade de recursos além de sua oferta principal de CDN. Os recursos oferecidos com frequência incluem: balanceamento de carga, otimização de imagens, streaming de vídeo, computação de borda e produtos de segurança.
Como criar e configurar uma CDN
O ideal é usar uma CDN para exibir todo o site. De modo geral, o processo de configuração consiste em se inscrever em um provedor de CDN e atualizar o registro DNS CNAME para apontar para o provedor de CDN. Por exemplo, o registro CNAME de www.example.com pode apontar para example.my-cdn.com. Como resultado dessa mudança no DNS, o tráfego para seu site será roteado pela CDN.
Se o uso de uma CDN para exibir todos os recursos não for uma opção, configure uma CDN para exibir somente um subconjunto de recursos, por exemplo, apenas recursos estáticos. Para isso, crie um registro CNAME separado que será usado somente para os recursos que devem ser exibidos pela CDN. Por exemplo, é possível criar um registro CNAME static.example.com que aponte para example.my-cdn.com. Também seria necessário reescrever os URLs dos recursos veiculados pela CDN para apontar para o subdomínio static.example.com que você criou.
Mesmo que sua CDN já esteja configurada, é provável que sua configuração não seja eficiente. As próximas duas seções deste artigo explicarão como aproveitar ao máximo sua CDN aumentando a proporção de ocorrências em cache e ativando recursos de desempenho.
Melhoria na proporção de ocorrência em cache
Uma configuração de CDN eficaz disponibilizará o máximo de recursos possível do cache. Isso geralmente é medido pela proporção de ocorrência em cache (CHR). A proporção de ocorrência em cache é definida como o número de ocorrências em cache dividido pelo número total de solicitações durante um determinado intervalo de tempo.
Um cache recém-inicializado terá um CHR de 0, mas isso aumenta à medida que o cache é preenchido com recursos. Uma CHR de 90% é uma boa meta para a maioria dos sites. Seu provedor de CDN deve fornecer análises e relatórios sobre seu CHR.
Ao otimizar o CHR, a primeira coisa a ser verificada é se todos os recursos armazenáveis em cache estão sendo armazenados em cache pelo período correto. Esta é uma avaliação simples que deve ser realizada por todos os sites.
O próximo nível de otimização do CHR, em termos gerais, é ajustar suas configurações de CDN para garantir que respostas logicamente equivalentes do servidor não sejam armazenadas em cache separadamente. Essa é uma ineficiência comum devido ao impacto de fatores como parâmetros de consulta, cookies e cabeçalhos de solicitação no armazenamento em cache.
Auditoria inicial
A maioria das CDNs fornece análises de cache. Além disso, ferramentas como WebPageTest e Lighthouse também podem ser usadas para verificar rapidamente se todos os recursos estáticos de uma página estão sendo armazenados em cache pelo período correto. Isso é feito verificando os cabeçalhos do Cache HTTP de cada recurso. O armazenamento em cache de um recurso usando o time to live (TTL) máximo evita buscas de origem desnecessárias no futuro e, portanto, aumenta o CHR.
No mínimo, um destes cabeçalhos normalmente precisa ser definido para que um recurso seja armazenado em cache por uma CDN:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
Além disso, embora isso não afete se ou como um recurso é armazenado em cache por uma CDN, é uma prática recomendada definir a diretiva Cache-Control: immutable também.Cache-Control: immutable indica que um recurso "não será atualizado durante o ciclo de vida de atualização". Como resultado, o navegador não revalidará o recurso ao disponibilizá-lo do cache do navegador, eliminando uma solicitação desnecessária do servidor. Essa diretiva só é compatível com Firefox e Safari. Não é compatível com navegadores baseados no Chromium. Este problema monitora a compatibilidade do Chromium com o Cache-Control: immutable. Marcar o problema com uma estrela pode incentivar o suporte a esse recurso.
Para uma explicação mais detalhada sobre o armazenamento em cache HTTP, consulte Evitar solicitações de rede desnecessárias com o cache HTTP.
Ajuste de detalhes
Uma explicação um pouco simplificada de como os caches de CDN funcionam é que o URL de um recurso é usado como a chave para o armazenamento em cache e a recuperação do recurso do cache. Na prática, isso ainda é demais, mas é um pouco complicado pelo impacto de itens como cabeçalhos de solicitação e parâmetros de consulta. Como resultado, reescrever os URLs de solicitação é uma técnica importante para maximizar a CHR e garantir que o conteúdo correto seja exibido aos usuários. Uma instância CDN configurada corretamente atinge o equilíbrio correto entre armazenamento em cache excessivamente granular (o que prejudica o CHR) e armazenamento em cache insuficientemente granular (o que resulta em respostas incorretas exibidas aos usuários).
Parâmetros de consulta
Por padrão, as CDNs consideram os parâmetros de consulta ao armazenar um recurso em cache. No entanto, pequenos ajustes no processamento de parâmetros de consulta podem ter um impacto significativo na CHR. Exemplo:
Parâmetros de consulta desnecessários
Por padrão, uma CDN armazenaria em cache
example.com/blogeexample.com/blog?referral_id=2zjkseparadamente, mesmo que eles sejam provavelmente o mesmo recurso subjacente. Isso é corrigido com o ajuste da configuração de uma CDN para ignorar o parâmetro de consultareferral\_id.Ordem do parâmetro de consulta
Uma CDN armazenará
example.com/blog?id=123&query=dogsem cache separadamente deexample.com/blog?query=dogs&id=123. Para a maioria dos sites, a ordem dos parâmetros de consulta não importa. Portanto, configurar a CDN para classificar os parâmetros de consulta (com a normalização do URL usado para armazenar a resposta do servidor em cache) aumentará a CHR.
Alterar
O cabeçalho de resposta Varia informa aos caches que a resposta do servidor correspondente a um URL específico pode variar, dependendo dos cabeçalhos definidos na solicitação (por exemplo, os cabeçalhos de solicitação Accept-Language ou Accept-Encoding). Como resultado, ele instrui um CDN a armazenar essas respostas em cache separadamente. O cabeçalho Var não é amplamente aceito por CDNs e pode resultar em um recurso armazenável em cache que não seja exibido a partir de um cache.
Embora o cabeçalho Variant possa ser uma ferramenta útil, o uso inadequado prejudica a CHR. Além disso, se você usar Vary, a normalização dos cabeçalhos de solicitação ajudará a melhorar a CHR. Por exemplo, sem a normalização, os cabeçalhos da solicitação Accept-Language: en-US e Accept-Language: en-US,en;q=0.9 resultariam em duas entradas de cache separadas, mesmo que seu conteúdo provavelmente fosse idêntico.
Cookies
Os cookies são definidos nas solicitações pelo cabeçalho Cookie. Eles são definidos nas respostas pelo cabeçalho Set-Cookie. Evite o uso desnecessário do cabeçalho Set-Cookie, já que os caches normalmente não armazenam em cache as respostas do servidor que contêm esse cabeçalho.
Recursos de desempenho
Esta seção discute os recursos de desempenho que normalmente são oferecidos pelas CDNs como parte da oferta principal do produto. Muitos sites se esquecem de ativar esses recursos, o que resulta em ganhos fáceis de desempenho.
Compactação
Todas as respostas baseadas em texto precisam ser compactadas com gzip ou Brotli. Se tiver, escolha Brotli em vez de gzip. O Brotli é um algoritmo de compactação mais novo e, comparado ao gzip, ele pode atingir taxas de compactação mais altas.
Há dois tipos de suporte a CDN para compactação Brotli: "Brotli da origem" e "Compactação Brotli automática".
Brotli na origem
O Brotli começa quando uma CDN disponibiliza recursos que foram compactados pela origem. Embora pareça ser um recurso que todas as CDNs devem oferecer suporte imediato, isso exige que uma CDN seja capaz de armazenar em cache várias versões (em outras palavras, versões compactadas com gzip e com Brotli) do recurso que correspondem a um determinado URL.
Compactação Brotli automática
A compactação Brotli automática ocorre quando os recursos são compactados com o Brotli pela CDN. Os CDNs podem compactar tanto recursos armazenáveis em cache quanto os não armazenados em cache.
Na primeira vez que um recurso é solicitado, ele é veiculado com a compactação "boa o suficiente", por exemplo, Brotli-5. Esse tipo de compactação é aplicável a recursos armazenáveis e não armazenáveis em cache.
Enquanto isso, se um recurso pode ser armazenado em cache, o CDN usa o processamento off-line para compactar o recurso em um nível de compactação mais poderoso, mas muito mais lento, por exemplo, o Brotli-11. Após a conclusão da compactação, a versão mais compactada será armazenada em cache e usada para solicitações subsequentes.
Práticas recomendadas de compactação
Os sites que querem maximizar o desempenho precisam aplicar a compactação Brotli no servidor de origem e na CDN. A compactação com Brotli na origem minimiza o tamanho da transferência de recursos que não podem ser disponibilizados no cache. Para evitar atrasos na disponibilização de solicitações, a origem precisa compactar os recursos dinâmicos usando um nível de compactação razoavelmente conservador, como o Brotli-4. Os recursos estáticos podem ser compactados usando o Brotli-11. Se uma origem não oferecer suporte ao Brotli, use gzip-6 para compactar recursos dinâmicos, e o gzip-9 poderá ser usado para compactar recursos estáticos.
TLS 1.3
O TLS 1.3 é a versão mais recente do Transport Layer Security (TLS), o protocolo criptográfico usado por HTTPS. O TLS 1.3 oferece melhor privacidade e desempenho em comparação com o TLS 1.2.
O TLS 1.3 reduz o handshake de TLS de duas idas e voltas para uma. Para conexões que usam HTTP/1 ou HTTP/2, reduzir o handshake de TLS para uma ida e volta reduz o tempo de configuração da conexão em 33%.
HTTP/2 e HTTP/3
O HTTP/2 e o HTTP/3 oferecem benefícios de desempenho em relação ao HTTP/1. Dos dois, o HTTP/3 oferece maiores benefícios de desempenho em potencial. O HTTP/3 ainda não está totalmente padronizado, mas terá suporte amplo quando isso ocorrer.
HTTP/2
Caso sua CDN ainda não tenha ativado o HTTP/2 por padrão, recomendamos que você o ative. O HTTP/2 oferece vários benefícios de desempenho em relação ao HTTP/1 e tem suporte de todos os principais navegadores. Os recursos de desempenho do HTTP/2 incluem: multiplexação, priorização de stream e compactação de cabeçalho.
Multiplexação
A multiplexação é sem dúvida o recurso mais importante do HTTP/2. A multiplexação permite que uma única conexão TCP atenda a vários pares de solicitação e resposta ao mesmo tempo. Isso elimina a sobrecarga de configurações de conexão desnecessárias. Considerando que o número de conexões que um navegador pode abrir em um determinado momento é limitado, isso também implica que o navegador agora pode solicitar mais recursos de uma página em paralelo. Teoricamente, a multiplexação elimina a necessidade de otimizações HTTP/1, como concatenação e folhas de sprite. No entanto, na prática, essas técnicas permanecerão relevantes, já que arquivos maiores são melhor compactados.
Priorização de stream
A multiplexação permite vários streams simultâneos. A priorização de stream fornece uma interface para comunicar a prioridade relativa de cada um desses streams. Isso ajuda o servidor a enviar os recursos mais importantes primeiro, mesmo que eles não tenham sido solicitados primeiro.
A priorização de streams é expressa pelo navegador por meio de uma árvore de dependências e é meramente uma declaração de preferência: em outras palavras, o servidor não é obrigado a atender (nem considerar) as prioridades fornecidas pelo navegador. A priorização de streams se torna mais eficaz quando mais partes de um site são veiculadas por meio de uma CDN.
As implementações de CDN de priorização de recursos HTTP/2 variam muito. Para identificar se a CDN oferece suporte total e adequado à priorização de recursos HTTP/2, confira O HTTP/2 é rápido ainda?.
Embora mudar a instância do CDN para HTTP/2 seja basicamente uma questão de ativar uma chave, é importante testar completamente essa alteração antes de ativá-la na produção. HTTP/1 e HTTP/2 usam as mesmas convenções para cabeçalhos de solicitação e resposta, mas o HTTP/2 é bem menos permissivo quando essas convenções não são respeitadas. Como resultado, práticas não específicas, como a inclusão de caracteres não ASCII ou maiúsculos nos cabeçalhos, podem começar a causar erros quando o HTTP/2 é ativado. Se isso ocorrer, as tentativas do navegador de fazer o download do recurso vão falhar. A tentativa de download com falha ficará visível na guia "Rede" do DevTools. Além disso, a mensagem de erro "ERR_HTTP2_PROTOCOL_ERROR" será exibida no console.
HTTP/3
HTTP/3 é o sucessor do HTTP/2. Desde setembro de 2020, todos os principais navegadores têm suporte experimental para HTTP/3, e algumas CDNs são compatíveis com ele. O desempenho é o principal benefício do HTTP/3 em relação ao HTTP/2. Especificamente, o HTTP/3 elimina o bloqueio "head-of-line" no nível da conexão e reduz o tempo de configuração da conexão.
Eliminação do bloqueio "head-of-line"
O HTTP/2 introduziu a multiplexação, um recurso que permite usar uma única conexão para transmitir diversos fluxos de dados simultaneamente. No entanto, com o HTTP/2, um único pacote descartado bloqueia todos os fluxos de uma conexão (um fenômeno conhecido como bloqueio "head-of-line"). Com o HTTP/3, um pacote descartado bloqueia apenas um único stream. Essa melhoria é, em grande parte, resultado do uso de HTTP/3 com UDP (o HTTP/3 usa UDP via QUIC) em vez de TCP. Isso torna o HTTP/3 particularmente útil para a transferência de dados em redes congestionadas ou com perdas.
Tempo de configuração da conexão reduzido
O HTTP/3 usa o TLS 1.3 e, portanto, compartilha os benefícios de desempenho: para estabelecer uma nova conexão, é necessário fazer uma única viagem de ida e volta e retomar uma conexão existente.
O HTTP/3 terá o maior impacto sobre os usuários com conexões de rede ruins, não apenas porque o HTTP/3 lida com a perda de pacotes melhor do que os anteriores, mas também porque a economia absoluta de tempo resultante de uma configuração de conexão 0-RTT ou 1-RTT será maior em redes com alta latência.
Otimização de imagens
Os serviços de otimização de imagens da CDN geralmente se concentram em otimizações de imagem que podem ser aplicadas automaticamente para reduzir o tamanho da transferência de imagem. Por exemplo: remover dados EXIF, aplicar compactação sem perdas e converter imagens para formatos de arquivo mais recentes (por exemplo, WebP). As imagens compõem aproximadamente 50% dos bytes de transferência na página da Web média. Portanto, otimizar imagens pode reduzir significativamente o tamanho da página.
Minificação
A minificação remove caracteres desnecessários de JavaScript, CSS e HTML. É preferível fazer a minificação no servidor de origem, em vez de no CDN. Os proprietários de sites têm mais contexto sobre o código a ser minimizado e, portanto, geralmente podem usar técnicas de minificação mais agressivas do que as empregadas por CDNs. No entanto, se a redução de código na origem não for uma opção, a minificação pela CDN será uma boa alternativa.
Conclusão
- Use uma CDN:as CDNs fornecem recursos rapidamente, reduzem a carga no servidor de origem e são úteis para lidar com picos de tráfego.
- Armazene o conteúdo em cache da maneira mais agressiva possível:tanto conteúdos estáticos quanto dinâmicos podem e precisam ser armazenados em cache, embora por durações variadas. Audite periodicamente seu site para garantir que o conteúdo está sendo armazenado em cache da maneira ideal.
- Ative os recursos de desempenho da CDN:recursos como Brotli, TLS 1.3, HTTP/2 e HTTP/3 melhoram ainda mais o desempenho.