Descargar sitios web que utilizan core-js

Acerca de core-js

Casi nadie decide instalar core-js. Como biblioteca modular de polyfills, llega dentro de un paquete de JavaScript, arrastrada como dependencia transitiva de un preajuste de transpilador o de una plantilla inicial de framework, y en muchos casos la persona responsable de la web no habrá oído hablar de ella nunca. Quien rastrea la web en busca de core-js no está midiendo, por tanto, la adopción en el sentido habitual de una preferencia o una compra. Lo que el rastreo mide es el residuo de los flujos de compilación, y en cuanto se acepta ese encuadre los datos resultan más útiles, no menos.

Un polyfill existe para que las funciones más nuevas del lenguaje sigan funcionando en motores antiguos. Un sitio que sirve core-js es un sitio cuya cadena de herramientas se configuró, en algún momento, para dar soporte a navegadores que sus visitantes quizá abandonaron hace mucho, y esa configuración casi nunca se revisa. El peso del frontal, los presupuestos de velocidad de página y el lento deterioro de las webs sin mantenimiento se derivan todos del mismo hecho. Publicada por primera vez en 2014 y con licencia MIT, la biblioteca ha sobrevivido a varias generaciones de políticas de soporte de navegadores, y por eso un paquete servido hoy puede seguir llevando parches de compatibilidad para motores que casi nadie usa.

La escala da forma al patrón. En octubre de 2026 detectamos core-js en 6.146.481 sitios, de los cuales 2.890.140 están en Estados Unidos, y el conjunto se inclina con fuerza hacia .com. La geografía dice aquí poco sobre dónde se escribe la biblioteca y mucho sobre dónde se concentra el desarrollo web comercial y cargado de frameworks, porque el código viaja con las herramientas que agencias y equipos de producto adoptan como estándar.

La detección es inferencial y se queda corta. Las huellas sobreviven de forma desigual a la minificación, los empaquetadores renombran y podan código, y una compilación que incorpora en línea solo un puñado de polyfills puede no dejar nada reconocible siquiera. Nuestro registro para esta entrada tampoco incluye un desglose de versiones utilizable, así que el conjunto de datos puede decirle dónde está presente la biblioteca, pero no qué versión se sirve. Quien planifique un trabajo que dependa de una versión concreta debe tratar la lista como un conjunto de candidatos y confirmarlo en los sitios que le importen.

Quienes nos piden esta lista se agrupan en unos pocos perfiles. Los equipos de seguridad y de cadena de suministro quieren el alcance de un paquete de confianza generalizada con una base de mantenedores pequeña, porque el alcance es lo que hace que atacar una dependencia merezca la pena. Los proveedores de rendimiento quieren sitios que sirvan código de compatibilidad heredado que ya no necesitan. Los mantenedores de frameworks y de navegadores quieren pruebas antes de retirar el soporte de algo antiguo. Comprobar un solo dominio no responde a ninguna de esas preguntas, y además comprobar un solo dominio es fácil, porque el panel de desarrollo de un navegador lo resuelve en un momento.

Lo que aporta una lista descargable es la consulta inversa. En lugar de preguntar qué usa un sitio conocido, se pregunta qué sitios de un país, bajo un sufijo, en una plataforma de comercio electrónico concreta o detrás de una red de distribución concreta llevan también esta dependencia, y se obtiene la población entera en forma de filas que puede cruzar con los datos de sus propias cuentas. Reconstruir eso a partir de consultas dominio a dominio significa rastrear por su cuenta el espacio de nombres registrado, y ese es el trabajo que nosotros ya hemos hecho.