La documentation de la plateforme a tendance à décrire chaque produit isolément, sous le meilleur angle possible. Cela crée une lecture dans laquelle Workers semble plus puissant que Pages et Pages semble plus simple que Workers. Aucune des deux lectures n’est correcte. Ils ont des capacités véritablement uniques dans chaque direction – et une large zone de chevauchement où la différence réside uniquement dans le modèle de déploiement.
Ce que seuls les travailleurs ont
Les déclencheurs Cron sont la primitive la plus pertinente qui n'existe pas dans Pages. En wrangler.toml :
[triggers] crons = ["0 3 * * *", "*/15 * * * *"]
Celui-ci enregistre deux crons : un à 3h du matin tous les jours, un autre toutes les 15 minutes. Le gestionnaire correspondant est la méthode scheduled de l'objet exporté par le Worker. Pages n'a pas cette primitive. Il ne s'agit pas d'une limitation d'exécution, mais d'une décision relative au produit. Si vous avez besoin d'une exécution périodique, c'est un travailleur indépendant.
Les consommateurs de file d'attente fonctionnent de la même manière. Cloudflare Queues vous permet de mettre les messages en file d'attente et de les traiter de manière asynchrone. Le consommateur — le Worker qui lit dans la file d'attente — est configuré en wrangler.toml avec [[queues.consumers]]. Les fonctions Pages ne peuvent pas être des consommateurs de file d'attente ; ne peut publier des messages dans des files d'attente que via une liaison.
Les Email Workers reçoivent des e-mails directement. Vous configurez un itinéraire d'e-mail dans Cloudflare pour qu'il pointe vers un Worker, et celui-ci reçoit l'e-mail en tant qu'objet avec un expéditeur, un destinataire, des en-têtes et un corps. Cela vous permet de traiter les rebonds, d'analyser les reçus de facture ou d'acheminer les e-mails vers différentes files d'attente, le tout sans votre propre serveur de messagerie. Pages ne prend pas en charge ce déclencheur.
Workers for Platforms est le mécanisme multi-tenant où les utilisateurs SaaS peuvent déployer leurs propres Workers au sein du compte de l'opérateur. L'opérateur utilise un Dispatch Worker qui reçoit les demandes et les transmet au script de locataire approprié. Il s'agit d'une primitive d'infrastructure pour les plates-formes qui doivent exécuter du code utilisateur arbitraire avec une isolation garantie. Exclusif aux travailleurs.
Les sockets TCP (en version bêta) permettent des connexions TCP directes à partir d'un Worker – utiles pour se connecter à des bases de données qui ne disposent pas d'API HTTP, telles que PostgreSQL ou Redis sans Upstash. Toujours en évolution, mais sans équivalent dans Pages.
Les alarmes d’objets durables méritent une mention distincte des objets durables en général. Les DO fonctionnent dans les deux cas, mais les alarmes – des minuteries qui réveillent un DO spécifique à une heure définie – sont une primitive de planification qui complète les déclencheurs cron pour les cas avec état par entité (planification d'un rappel par utilisateur, par exemple). Disponible dans les deux environnements d'exécution, mais l'orchestration démarre normalement à partir d'un Worker avec un déclencheur cron ou de file d'attente.
Ce que seul Pages a
L’hébergement d’actifs statiques à un coût nul par requête est la fonctionnalité la plus sous-estimée de Pages et la plus coûteuse à répliquer en dehors de Pages. Lorsque vous déployez un projet Pages, les fichiers statiques (HTML, CSS, JavaScript, images, polices) sont distribués via le CDN global de Cloudflare. Les requêtes pour ces actifs ne passent pas par le runtime Workers : elles sont servies directement depuis le CDN Edge, sans déclencher aucune logique informatique, sans compter comme un invocation, sans coût par requête au-delà du plan Pages.
Le forfait gratuit de Pages comprend des requêtes CDN illimitées. Le forfait payant coûte 20 $/mois et ajoute 5 000 builds/mois et jusqu'à 5 builds simultanées. Pour un site avec des dizaines de millions de pages vues mensuellement, cette absence de coût par requête statique constitue un avantage de facturation significatif par rapport à toute architecture basée sur de purs Workers.
Les déploiements automatiques en aperçu par branche constituent la deuxième différence. Chaque poussée vers une branche non principale génère une URL unique au format hash-branch.seuprojeto.pages.dev, avec des actifs et des fonctions fonctionnant ensemble. Aucune configuration supplémentaire, aucun script CI à écrire. Workers ne réplique pas cela de manière native : vous devez configurer manuellement le flux de « déploiement de succursale » dans votre CI.
Le pipeline de build intégré est également unique. Pages détecte le framework (Next.js, Astro, SvelteKit, Nuxt, Hugo, Gatsby), configure les valeurs par défaut de construction et exécute le processus de construction dans un environnement isolé à chaque poussée. Pour Workers, la construction relève de la responsabilité de votre CI, ce qui est plus flexible, mais signifie plus de configuration à maintenir.
Les conventions _redirects et _headers vous permettent de configurer des redirections et des en-têtes HTTP pour les ressources statiques via des fichiers texte brut à la racine du projet, sans code. Utile pour les migrations d'URL, HSTS, de politique de sécurité du contenu et d'en-tête de cache. Les travailleurs peuvent implémenter la même chose avec du code, mais c'est plus verbeux.
Qu'est-ce que les deux ont en commun
Le runtime du V8 est identique. Les limites sont les mêmes : 128 Mo de mémoire (dure), 10 Mo de script compressé sur le forfait payant, 30 secondes de CPU par requête, 1 000 sous-requêtes par invocation. Tout code exécuté dans Workers s'exécute dans Pages Functions sans modification.
Les liaisons de données sont partagées : D1 (SQLite en périphérie), KV (valeur-clé distribuée), R2 (stockage d'objets), Objets durables (état cohérent avec la coordination), AI (inférence de modèle en périphérie). Vous pouvez avoir une base de données D1 accessible à la fois par Pages Functions et par un Worker autonome configuré sur le même wrangler.toml avec la liaison pointant vers le même ID de base de données.
Les liaisons de service fonctionnent dans les deux sens : une fonction Pages peut appeler un Worker autonome directement via une liaison interne, sans latence du réseau public. Un travailleur peut appeler un autre travailleur. L'appel est un fetch() normal contre la liaison, mais acheminé en interne sur le réseau Cloudflare.
L'architecture qui utilise chacun au bon endroit
Le modèle qui émerge des projets qui utilisent correctement Workers et Pages comporte trois couches. Le premier est le projet Pages : il sert le SPA ou le site Web généré par le build, avec des actifs statiques sur le CDN sans frais par requête. Les routes API sont en /functions/api/ — Fonctions Pages colocalisées avec le frontend, avec aperçu de branche inclus, accédant à D1 et KV pour les données d'application.
La deuxième couche est celle des Workers pour les tâches asynchrones : des scripts autonomes avec des déclencheurs cron pour le traitement planifié, des consommateurs de file d'attente pour le travail asynchrone découplés du chemin critique HTTP, et des Email Workers pour le traitement des e-mails. Ces Workers accèdent aux mêmes liaisons de données que le projet Pages : la même base de données D1, le même espace de noms KV.
La troisième couche est la communication entre eux via les liaisons de service. Une Fonction Pages nécessitant un traitement lourd appelle directement le Worker spécialisé, sans HTTP externe. Le Cron Worker qui doit déclencher une notification peut appeler la fonction Pages d'envoi via la liaison de service.
Cette architecture n'est pas théorique. C'est ce qui se produit lorsque vous utilisez chaque primitive où elle résout le problème avec un coût opérationnel inférieur : Pages CDN gratuit pour les actifs, même temps d'exécution pour l'API colocalisée, Workers autonomes pour les déclencheurs que Pages ne prend pas en charge.
La carte de décision
La question qui organise la décision est : qu’est-ce qui déclenche ce code ? S'il s'agit d'une requête HTTP et que le code cohabite avec une interface, Pages Functions. S'il s'agit d'une requête HTTP mais que le projet n'a pas de frontend — service API pur — Workers avec configuration en wrangler.toml. S'il s'agit d'autre chose que HTTP (heure planifiée, message de file d'attente, courrier électronique entrant), les travailleurs n'ont pas d'alternative.
Les deux côtés de la table disposent de capacités que l’autre ne peut pas reproduire sans coût ni complexité supplémentaires. Une décision qui ignore cela – en utilisant uniquement Workers parce que vous pensez que c'est plus « sérieux », ou simplement Pages parce que vous pensez que c'est plus simple – atteindra une limite qui nécessitera une refactorisation plus tôt que nécessaire.
A lire aussi
- Cloudflare Workers vs Pages : la différence qui compte avant de choisir
- Migrer de Pages vers Workers : quand cela a du sens et le coût réel du changement -Workers et Pages : déploiement, routage et ce que cache chaque modèle
- Fonctions Pages : quand utiliser à la place de purs Workers
- KV pour la limitation de débit, les indicateurs de fonctionnalités et la configuration distribuée : où ça marche et où ça ne marche pas
- Cloudflare KV : Que signifie une distribution mondiale lorsque vous devez écrire