Ferramentas

Uma migração que ninguém devia notar

A 30 de julho de 2026, a Cloudflare publicou o relato da reconstrução do cdnjs, o CDN público que opera para bibliotecas JavaScript e CSS, na sua própria plataforma de desenvolvimento; a InfoQ retomou-o a 14 de agosto. Os números dados pela Cloudflare devem ser apresentados tal como são: o cdnjs serve cerca de 9 mil milhões de pedidos por dia, quase 108 000 pedidos por segundo distribuídos por mais de 330 centros de dados, com uma taxa de acerto de cache de 98,6 %, e é usado por cerca de 12 % dos sites.

Por baixo, a arquitetura mudou. O R2 passou a ser a fonte de verdade dos ficheiros publicados, o KV guarda os metadados dos pacotes, as versões e os hashes Subresource Integrity, e um Worker trata os pedidos com o Workers Cache à frente. O que não mudou é exatamente o que importa a quem alguma vez colou uma etiqueta script numa página: a Cloudflare indica que o conteúdo dos pacotes, os URL e os hashes SRI foram todos preservados. A migração foi pensada para ser invisível.

Essa invisibilidade é o verdadeiro produto. Um CDN público faz uma única promessa que conta: que o URL que colou no seu <head> há cinco anos responda hoje com os mesmos bytes. Tudo o resto, o número de pontos de presença, a taxa de cache, o runtime em que assenta, é pormenor de implementação. Estes serviços avaliam-se pela capacidade de mudar tudo por baixo sem mudar nada daquilo de que depende.

Três CDN, três promessas diferentes

Os três candidatos habituais não são da mesma natureza, e confundi-los é o erro mais comum. O cdnjs serve um catálogo de bibliotecas curado: um processo humano decide o que entra. O jsDelivr serve pacotes npm, repositórios GitHub e builds ESM, e funciona como multi-CDN, repartindo os pedidos entre a Cloudflare e a Fastly. O unpkg é o mais simples dos três: um espelho direto do npm, onde tudo o que é publicado fica imediatamente acessível por URL.

O argumento que deixou de ser verdade em 2020

Agora o argumento de que é preciso desistir. Durante anos, a justificação habitual de um CDN público foi a cache partilhada: use o CDN que toda a gente usa, e o seu visitante já terá o jQuery em cache de outro site, por isso não custa nada. Isso deixou de ser verdade há muito. Os browsers particionam agora a cache HTTP por site visitado: o Safari desde 2013, o Chrome desde a versão 86 em 2020, o Firefox desde a versão 85 em 2021.

• cdnjs: catálogo curado, operado pela Cloudflare; a reconstrução de 2026 preservou os URL, o conteúdo dos pacotes e os hashes SRI
• jsDelivr: npm, GitHub e ESM; multi-CDN entre Cloudflare e Fastly; os ficheiros já servidos mantêm-se mesmo que o pacote desapareça
• unpkg: um espelho direto do npm, o mais simples dos três e o mais exposto às mudanças a montante
• A cache partilhada entre sites já não existe: Safari 2013, Chrome 86 em 2020, Firefox 85 em 2021; o argumento histórico dos CDN públicos caducou
• Acrescente sempre integrity e crossorigin a uma etiqueta de terceiros; com um bundler moderno, o alojamento próprio é muitas vezes mais rápido e mais seguro do que os três

Esta partição significa que um ficheiro descarregado no site A volta a ser descarregado no site B, mesmo com o mesmo URL no mesmo CDN. A mudança foi feita pela privacidade: uma cache partilhada revela o histórico de navegação, porque um site pode cronometrar um pedido e deduzir se esteve noutro lado. O ganho de desempenho era real, foi abandonado deliberadamente, e qualquer conselho que ainda se apoie nele descreve a web de antes de 2020.

O que realmente os separa hoje

Sem esse argumento, a comparação fica mais estreita e mais honesta. Restam a disponibilidade, a imutabilidade e a quantidade de superfície de terceiros que aceita prender à sua página. Quanto à imutabilidade, o jsDelivr indica que um ficheiro já servido fica guardado de forma permanente: um pacote retirado do npm continua assim a responder em vez de partir os sites que o referiam. O unpkg, sendo um espelho, segue o npm mais de perto. Quem se lembra do desaparecimento do left-pad do npm em 2016 sabe que não é um caso teórico.

Quanto à disponibilidade, o desenho multi-CDN do jsDelivr faz com que um fornecedor em dificuldades não arraste o serviço consigo. O cdnjs depende inteiramente da Cloudflare, e a migração de 2026 tornou-o mais homogéneo, não mais redundante. É um compromisso e não um defeito: um único operador muito grande com mais de 330 localizações, contra vários operadores com modos de falha independentes. Escolha a falha que prefere explicar.

O atributo integrity não é opcional

Seja qual for a escolha, use Subresource Integrity. Um atributo integrity acompanhado de crossorigin="anonymous" pede ao browser que recuse um ficheiro cujo hash não corresponde, e faz toda a diferença entre confiar num URL e confiar em quem o controla. Sem ele, concede a um terceiro um direito de execução incondicional em todas as páginas do seu site. A etiqueta da fotografia acima não tem atributo integrity, e é a regra e não a exceção.

A opção que a maioria das comparações salta

Resta a opção que a maioria das comparações salta: não usar CDN público nenhum. Sirva o ficheiro da biblioteca a partir da sua própria origem, com o resto dos recursos. Como a cache está particionada, já não ganhava nada com a cache partilhada, e o alojamento próprio elimina uma resolução DNS, uma negociação TLS e uma ligação a um anfitrião que não controla. O seu bundler já faz isso. Para a maioria dos sites em 2026, é ao mesmo tempo a escolha mais rápida e a mais segura.

Uma última honestidade sobre os três: são fornecidos na medida do possível, sem compromisso contratual de disponibilidade. São infraestruturas públicas generosas, não um serviço que lhe seja devido. Se a sua página fica inutilizável quando uma biblioteca não carrega, essa dependência não pertence à oferta gratuita de um terceiro, por muitos centros de dados que tenha.