Descarregar sites que utilizam core-js

Sobre core-js

Quase ninguém decide instalar o core-js. Enquanto biblioteca modular de polyfills, chega dentro de um pacote de JavaScript, arrastada como dependência transitiva de uma predefinição de transpilador ou de um modelo inicial de framework, e quem é responsável pelo site muitas vezes nunca ouviu falar dela. Quem rastreia a web à procura do core-js não está, portanto, a medir adoção no sentido habitual de uma preferência ou de uma compra. O que o rastreio mede é o resíduo dos pipelines de compilação, e assim que se aceita esse enquadramento os dados tornam-se mais úteis e não menos.

Um polyfill existe para que funcionalidades mais recentes da linguagem continuem a funcionar em motores antigos. Um site que serve o core-js é um site cuja cadeia de ferramentas foi configurada, a certa altura, para suportar navegadores que os seus visitantes podem ter abandonado há muito, e essa configuração raramente é revista. O peso do frontend, os orçamentos de velocidade de página e a degradação lenta dos endereços sem manutenção decorrem todos do mesmo facto. Publicada pela primeira vez em 2014 e distribuída com licença MIT, a biblioteca sobreviveu a várias gerações de políticas de suporte a navegadores, o que explica que um pacote servido hoje ainda possa transportar camadas de compatibilidade para motores que quase ninguém usa.

A escala dá forma ao padrão. Em outubro de 2026 detetamos o core-js em 6 146 481 sites, 2 890 140 deles nos Estados Unidos e com o conjunto muito inclinado para .com. A geografia diz aqui pouco sobre onde a biblioteca é escrita e muito sobre onde se concentra o desenvolvimento web comercial e assente em frameworks, porque o código viaja com as ferramentas que as agências e as equipas de produto padronizam.

A deteção é inferencial e conta a menos. As impressões digitais sobrevivem à minificação de forma desigual, os empacotadores renomeiam e podam o código, e uma construção que integra apenas um punhado de polyfills pode não deixar nada reconhecível de todo. O nosso registo para esta entrada também não traz uma repartição de versões utilizável, por isso o conjunto de dados diz onde a biblioteca está presente mas não que versão está a ser servida. Quem planeia trabalho que dependa de uma versão concreta tem de tratar a lista como um conjunto de candidatos e confirmar nos endereços que interessam.

Quem nos pede esta lista divide-se em alguns grupos. As equipas de segurança e de cadeia de fornecimento querem o alcance de um pacote em que se confia largamente e que é mantido por muito pouca gente, porque é o alcance que torna uma dependência digna de ataque. Os fornecedores de desempenho querem endereços que servem código de compatibilidade antigo de que já não precisam. Quem mantém frameworks e navegadores quer provas antes de deixar cair o suporte a algo antigo. Verificar um domínio concreto não responde a nenhuma dessas perguntas, e verificar um domínio concreto é fácil de qualquer forma, porque um painel de programador do navegador trata disso num instante.

O que uma lista para descarregar acrescenta é a consulta inversa. Em vez de perguntar o que executa um site que já se conhece, pergunta-se que endereços de um país, sob um sufixo, numa dada plataforma de comércio eletrónico ou por trás de uma dada rede de distribuição transportam também esta dependência, e recebe-se a população inteira em linhas que se podem juntar aos dados das suas próprias contas. Reconstruir isso a partir de consultas domínio a domínio significa rastrear por conta própria o espaço de nomes registado, que é o trabalho que nós já fizemos.