Descarregar sites que utilizam Slick

Sobre Slick

Um carrossel que fica anos sem mudar é normalmente um problema. Aqui é precisamente esse o objetivo. Cópias do código foram colocadas em modelos uma vez e deixadas em paz, a continuar a fazer o trabalho para que foram escritas em páginas construídas há muito tempo, o que faz de Slick um mau assunto para um roteiro de produto e um assunto muito bom para datar um website.

Lançada em 2014 com licença MIT, a extensão resolvia um problema que todos os sites de apresentação tinham na altura. O conteúdo tinha de rodar, tinha de funcionar tanto sob um dedo como sob um rato, e tinha de encaixar numa base de código que já dependia de jQuery. Os carrosséis desta geração foram adotados pelos autores de temas e não pelos donos dos sites, o que explica que a biblioteca apareça em sites cujos operadores nunca ouviram o nome.

Em outubro de 2026 detetamos a biblioteca em 1 006 949 sites, dos quais 322 070 nos Estados Unidos, sendo .com o sufixo mais comum. Resolvemos também 87 cadeias de versão distintas, e 1.8.1 é a leitura que registamos com mais frequência. Uma concentração apertada numa versão, dispersa de forma ténue por muitas outras, é o aspeto que uma biblioteca distribuída dentro de temas tem visto de fora. A maioria das instalações nunca sai da versão com que o seu modelo veio, por isso os números de versão dizem pouco sobre o cuidado com que um site é mantido.

O sinal de datação tem antes de vir do contexto, e o contexto é exatamente aquilo que um perfil tecnológico completo fornece. Um site que transporta esta biblioteca juntamente com uma compilação antiga de jQuery, um construtor de páginas da mesma era e uma estrutura de folhas de estilo de época semelhante é um site cujo front-end não é reconstruído há muito tempo. A mesma biblioteca dentro de uma pilha de resto moderna significa normalmente que um único modelo legado sobreviveu a uma remodelação. Distinguir entre esses dois casos é impossível a partir de uma deteção isolada e é simples a partir de uma linha inteira.

Quem precisa dessa distinção? As agências que vendem reconstruções e precisam de uma lista de alvos defensável em vez de abordagem a frio. Os fornecedores de desempenho cujo argumento inteiro é o código do lado do cliente que carrega em todas as páginas sem ser usado. Os profissionais de acessibilidade, uma vez que o conteúdo rotativo e a navegação por teclado nunca se deram bem e o trabalho de correção tem de ser dimensionado antes de poder ser orçamentado. As equipas de segurança que inventariam dependências envelhecidas de front-end, onde a pergunta não é se um site concreto é vulnerável mas quanto do parque precisaria de ser mexido. Cada um destes é uma questão de população.

Os limites da deteção apontam num só sentido. Identificamos a biblioteca a partir de assinaturas de ficheiro e de marcação característica, por isso qualquer site que concatene os seus scripts num único pacote, mude o nome do ficheiro, o coloque em linha ou o carregue de forma condicional pode passar-nos despercebido. A contagem é, por isso, um limite inferior e não um recenseamento, e os sites que nos escapam pendem para aqueles que têm uma cadeia de compilação, o que significa que os sites mais bem mantidos ficam sub-representados. O enviesamento é suficientemente consistente para que as comparações entre países, sufixos e tecnologias vizinhas se mantenham sólidas mesmo onde o total absoluto não se mantém.

O que uma lista descarregável muda é a direção da pergunta. Verificar um domínio diz o que esse domínio carrega, o que sempre se poderia ver no código-fonte da página. Uma exportação diz quantos sites transportam a biblioteca, em que mercados, sob que sufixos e o que mais corre a acompanhá-la, e essa é a única forma de responder à pergunta antes da resposta deixar de importar. Ordenado pelos sistemas de gestão de conteúdos que o acompanham, este carrossel deixa de ser um widget e passa a ser um marcador de toda uma época de construção, e uma época é algo a que se pode vender, que se pode proteger ou que se pode migrar.