cdnjs повністю перейшов на платформу розробника Cloudflare

cdnjs тепер на платформі розробника Cloudflare

Станом на 23 червня 2026 року cdnjs, один з найактивніших CDN з відкритим кодом в Інтернеті, працює виключно на платформі розробника Cloudflare. Цей перехід не лише оптимізував роботу cdnjs, але й сприяв розвитку самої платформи Cloudflare, оскільки в процесі міграції були виявлені та усунені її обмеження.

Що таке cdnjs та чому він досі важливий

cdnjs — це безкоштовна, відкрита мережа доставки контенту для бібліотек JavaScript та CSS. Замість використання бандлера або самостійного розміщення бібліотек, таких як jQuery, Bootstrap або Lodash, розробники можуть просто додати тег <script>, що вказує на cdnjs.cloudflare.com. Бібліотека завантажується з периферії Cloudflare миттєво, в будь-якій точці світу, без реєстрації, ключів API та обмежень швидкості. Це інфраструктура, що лежить в основі значної частини навчальних посібників з JavaScript, демонстрацій CodePen та відповідей на Stack Overflow.

Керований спільнотою, cdnjs використовується приблизно на 12% всіх вебсайтів, займаючи 48,3% ринку JavaScript CDN. Він обслуговує в середньому 108 000 запитів на секунду, або 9 мільярдів на день, через понад 330 дата-центрів Cloudflare, з коефіцієнтом попадання в кеш 98,6%.

Проєкт cdnjs був створений у 2011 році Раяном Кіркманом та Томасом Девісом як безкоштовне, кероване спільнотою дзеркало популярних бібліотек з відкритим кодом. Cloudflare почав безкоштовно розміщувати його через кілька місяців, а у 2019 році взяв на себе підтримку проєкту. Тоді Cloudflare не мав зрілої платформи розробника, здатної повністю підтримувати всю екосистему cdnjs. П'ятнадцять років та багато розробок пізніше, платформа стала достатньо зрілою, щоб повністю забезпечити роботу cdnjs на Workers, Workflows, D1, Queues, Workers Cache, R2, KV та Containers.

Незважаючи на зміни у веб-розробці, cdnjs продовжує обробляти мільярди запитів щодня. Однією з причин є те, що великі мовні моделі (LLM), такі як ChatGPT, Claude або Cursor, часто використовують cdnjs при створенні швидких HTML-демо, оскільки їхні навчальні дані містять безліч посилань на нього. URL-шаблон є послідовним, а версії незмінними, що ідеально підходить для надійного відтворення моделями. Крім того, кожен файл на cdnjs має хеш SRI, дзеркала піддаються аудиту, а весь проєкт є відкритим кодом, що робить його незамінним у світі, де зростає занепокоєння щодо атак на ланцюги поставок. Він також залишається безкоштовним для всіх, без ключів API, обмежень швидкості або вимог до реєстрації.

Чому знадобилася міграція

Міграція cdnjs відбулася не через повільну роботу старої системи, а через бажання її постійно вдосконалювати. Попередня архітектура добре обслуговувала користувачів, забезпечуючи 98% попадання в кеш, мільярди запитів та відсутність збоїв. Однак внутрішньо, впровадження нових функцій або виправлення існуючих проблем у процесі обробки пакетів ставало все складніше. Будь-яка зміна вимагала координації розгортань між GCP Functions, віртуальною машиною та Cloudflare, а моніторинг був ускладнений.

У 2020 році cdnjs частково перейшов на безсерверну архітектуру, перемістивши обслуговування файлів на Cloudflare Workers та KV, з резервним bare-metal джерелом. Це значно покращило стійкість та масштабованість, а також дозволило попередньо стискати кожен ресурс за допомогою Brotli та gzip. Проте, сторона публікації — конвеєр, що відстежує npm та GitHub на наявність нових версій бібліотек, завантажує їх, обробляє та записує результати — залишалася на Google Cloud Platform (GCP). На той час Cloudflare Workers були розроблені для швидких, короткочасних HTTP-запитів і не мали необхідних компонентів для довготривалого, багатоетапного конвеєра.

Проблеми старої архітектури

Стара архітектура мала п'ять основних проблемних точок:

1. Відсутність спільного трасування: Оновлення пакета могло проходити через Cloud Functions, події об'єктів Google Cloud Storage (GCS), теми Pub/Sub, віртуальну машину git-sync та Workers KV, перш ніж файл досягав користувача. Жодна з цих систем не мала спільного ідентифікатора кореляції, що ускладнювало налагодження.
2. Розділене сховище: Файли зберігалися у двох місцях одночасно: Workers KV на периферії та репозиторій GitHub як джерело правди. Жодне з них не було авторитетним, і при розбіжностях не було чистого способу їх узгодження.
3. Конвеєр, склеєний подіями об'єктів: Конвеєр прийому даних був ланцюгом невеликих GCP Cloud Functions, кожна з яких виконувала один крок і передавала дані наступній через спільне сховище. Сховище виконувало подвійну функцію черги повідомлень, без черги мертвих листів, видимості беклогу та чистого повторного відтворення у разі збою.
4. 26 функцій для 26 літер: Перевірка оновлень npm вимагала 26 Cloud Functions, по одній на кожну літеру алфавіту. Кожен шард мав власне розгортання та власні журнали.
5. Репозиторій GitHub не міг обслуговувати: Окрема віртуальна машина git-sync дзеркалювала кожен оброблений файл у cdnjs/cdnjs. Роки випусків збільшили його обсяг до понад 1,1 ТБ упакованого сховища, що призвело до відмови сервісу архівування GitHub генерувати tar-архіви або zip-завантаження. Форкування стало непрактичним, клонування повільним.

Виведення з експлуатації старої архітектури також принесло користь у вигляді зменшення кількості рухомих частин, які потрібно було захищати, що дозволило закрити всі нещодавно виявлені вразливості cdnjs.

Як відбудували cdnjs

Нова архітектура cdnjs повністю працює на платформі розробника Cloudflare.

R2 став єдиним джерелом правди для файлового контенту. Він не має практичних обмежень за розміром, тому файли, які раніше не могли поміститися в KV, тепер зберігаються разом з усім іншим. Крім того, API S3 робить весь каталог cdnjs доступним для будь-якого S3-клієнта.

KV тепер зберігає лише метадані: інформацію про пакети, списки версій, хеші SRI. KV розроблений для великого обсягу читань з нечастими записами, що ідеально підходить для доступу до метаданих.

Перед Worker знаходиться Workers Cache, багаторівневий кеш, запущений Cloudflare цього року. Це замінило окремий внутрішній рівень кешування, зменшивши кількість рухомих частин.

Нова архітектура також розширює давнє партнерство з DigitalOcean. DigitalOcean роками розміщував вебсайт cdnjs як спонсор, а тепер також розміщує сховище. Кожен файл, опублікований в R2, дзеркалюється в DigitalOcean Spaces, слугуючи копією для аварійного відновлення та живим резервом. Обслуговуючий Worker читає дані через кеш → R2 → DigitalOcean.

Конвеєр прийому даних побудований на Cloudflare Workflows. Кожні десять хвилин cron-завдання запускає PackageUpdatesWorkflow, який перевіряє npm та GitHub на наявність нових версій. Для кожної знайденої нової версії він запускає DownloadPackageWorkflow, який завантажує tar-архів в R2, потім ProcessingWorkflow для кожного файлу, який витягує, мінімізує та стискає. Нарешті, PublishingWorkflow записує результати в R2 та KV та оновлює пошуковий індекс Algolia. Завдяки Workflows, стан кожного кроку зберігається, і у разі збою робочий процес відновлюється з останнього успішного кроку.

Складніша частина — це зв'язок Workflows із зовнішнім контейнером для стиснення. Стиснення є надто інтенсивним для Worker, тому воно передається Cloudflare Containers, де відбувається стиснення, а потім робочий процес продовжується. Для координації між файлами та пакетами використовуються Queues та Durable Objects.

Розширення можливостей платформи

Розробка нової архітектури була одним викликом, а міграція існуючого каталогу без порушення роботи файлів — іншим. Попередня спроба міграції була невдалою, оскільки повторна обробка старих пакетів призвела до відмінностей у хешах SRI, що могло б порушити роботу користувачів. Тому поточна міграція полягала в копіюванні існуючого контенту з KV в R2 «як є».

Під час міграції були виявлені два обмеження платформи:

1. Ліміт підзапитів Workers: Обмеження в 1000 підзапитів на виклик Worker. Це було вирішено шляхом шардування міграції за назвою пакета та розподілу роботи через Queues.
2. Ліміт кроків Workflows: Обмеження в 1024 кроки.

Ці обмеження були підвищені командами Workers та Workflows. Тепер підзапити можуть досягати 10 мільйонів на платних планах, а Workflows за замовчуванням мають 10 000 кроків, з можливістю конфігурації до 25 000. Це означає, що конвеєр cdnjs працює на тих самих будівельних блоках, які доступні будь-якому розробнику, а виявлені та підвищені ліміти стали доступними для всіх користувачів платформи Cloudflare.

Наступні кроки

Наступним питанням є можливість обслуговування cdnjs сучасних, нативних для браузера модулів ES. Архітектура не виключає цього, і шаблон Workflows-плюс-Containers, який сьогодні попередньо стискає файли, так само добре працюватиме для їх трансформації. Хоча це ще не зобов'язання, така можливість тепер розглядається, що було неможливо рік тому.

Що це означає для розробників

Міграція cdnjs на платформу розробника Cloudflare призвела до значного розширення можливостей самої платформи. Зокрема, були підвищені ліміти на кількість підзапитів Workers та кроків Workflows, що надає розробникам доступ до більш потужних та масштабованих інструментів для їхніх проєктів.

Ключові факти

• cdnjs повністю перейшов на платформу розробника Cloudflare 23 червня 2026 року.

• cdnjs є одним з найактивніших CDN з відкритим кодом, що використовується приблизно на 12% вебсайтів та обробляє 9 мільярдів запитів на день.

• Міграція була викликана потребою в покращенні внутрішньої архітектури та вирішенні проблем з моніторингом та розгортанням старої системи.

• Нова архітектура cdnjs повністю працює на платформі розробника Cloudflare, використовуючи R2 як єдине джерело правди, KV для метаданих, Workflows для конвеєра прийому даних та Containers для інтенсивного стиснення.

• Під час міграції були виявлені та підвищені ліміти на кількість підзапитів Workers (до 10 мільйонів) та кроків Workflows (до 25 000), що розширило можливості платформи для всіх користувачів.

Джерела

• Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform