Guide complet Astro sur Cloudflare : configuration SSR et accès Chine ×3 plus rapide

La semaine dernière, j’ai aidé un ami à déployer son blog Astro. Après la mise en ligne sur Cloudflare Pages, j’ai testé depuis l’étranger : pages instantanées, expérience fluide. Ses amis en Chine ont attendu près de 5 secondes — gênant.

Cloudflare annonce plus de 300 datacenters et une bande passante gratuite illimitée. Pourquoi l’accès depuis la Chine est-il si lent ? Beaucoup de développeurs se posent la question. Vous avez sans doute entendu parler d’« IP optimisées », mais comment les configurer, y a-t-il un risque pour le compte, et quel est l’effet réel ?

Cet article couvre le déploiement Astro sur Cloudflare : site statique, configuration SSR, puis optimisation pour l’accès depuis la Chine. J’ai fait pas mal d’erreurs sur le chemin ; voici ce que j’en retiens pour vous faire gagner du temps.

Vous apprendrez :

• Mise en ligne de zéro en environ 20 minutes
• Les trois modes de l’adaptateur SSR, sans confusion
• Trois stratégies d’optimisation pour la Chine, avec une latence jusqu’à ×3 plus basse

C’est parti.

Pourquoi choisir Cloudflare Pages

Cloudflare vs Vercel : hébergement gratuit

On me demande souvent : Vercel ou Cloudflare ? Tout dépend de vos besoins.

Les limites de bande passante frappent tout de suite. Vercel gratuit : 100 Go/mois, puis facturation (40 $ par 100 Go). Un de mes projets a explosé en trafic ; la facture Vercel a fait mal. Cloudflare Pages ? Bande passante illimitée, gratuit — rassurant pour les indépendants.

Performances mondiales : Cloudflare compte plus de 300 datacenters. J’ai testé en Europe, Asie et Amériques : latences basses. Vercel est solide, mais avec moins de nœuds. Audience mondiale → avantage Cloudflare.

Protection DDoS : incluse en gratuit, sans config supplémentaire. Lors d’une attaque, Cloudflare a tout bloqué ; je n’ai même pas ouvert les logs. Vercel protège surtout son réseau en gratuit, moins en profondeur pour votre site.

Côté Vercel : cache de build excellent (2e build ~3-4 min). Pages reconstruit souvent entièrement (10+ min). Intégration Next.js : si vous êtes sur Next.js, Vercel reste le choix naturel.

Mes recommandations :

• Blog Astro statique → Cloudflare Pages
• Trafic imprévisible → Cloudflare Pages
• Utilisateur Next.js avancé → Vercel
• Builds très fréquents → Vercel

Cloudflare Pages vs Workers : évolution 2025

Pages et Workers déploient tous deux Astro — lequel prendre ?

Différence de fond : Workers = calcul serverless en périphérie. Pages = Workers + outillage de build et déploiement (Git, CI). Sous le capot, Pages tourne sur Workers.

En 2025, Cloudflare pousse les nouveaux projets vers Workers pour plus de flexibilité. Pour Astro, ce n’est pas une obligation.

Mon usage :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

• Pages : repo GitHub, push → build auto — idéal pour « déployer vite, sans complexité ».
• Workers : Wrangler CLI, wrangler.jsonc — variables, liaisons KV, etc.

Pour Astro :

• static : Pages + Dashboard GitHub
• server ou hybrid : les deux marchent ; je recommande Pages + Wrangler

Première fois ? Essayez Pages + Git : résultat en quelques minutes. Wrangler peut attendre.

Processus complet de déploiement Astro sur Cloudflare

Déploiement statique : 5 minutes

Blog, doc ou portfolio purement statiques : c’est simple.

Prérequis :

• Projet sur GitHub
• Compte Cloudflare (gratuit)

Étapes :

1. Dashboard Cloudflare — dash.cloudflare.com, menu Workers & Pages.
2. Nouveau projet — Create application → Pages → Connect to Git.
3. Dépôt GitHub — sélectionner le repo Astro ; autoriser l’accès si demandé.
4. Build — crucial :
   • Framework preset : Astro
   • Build command : npm run build
   • Build output directory : dist
   • Root directory : vide à la racine, sinon chemin du sous-dossier
5. Déployer — Save and Deploy ; Cloudflare pull, installe, build, déploie.

Vous obtenez votre-projet.pages.dev. Chaque push sur GitHub relance un build.

Problèmes courants :

• Version Node.js : ajouter .nvmrc ou .node-version avec 18 ou 20.
• 404 : vérifier que la sortie est dist (ou selon astro.config.mjs).
• Timeout : réessayer le déploiement.

Domaine personnalisé (optionnel) : Custom domains → Set up a custom domain → CNAME chez votre DNS (ou auto si le domaine est déjà sur Cloudflare DNS).

Déploiement SSR : adaptateur @astrojs/cloudflare

Quand avez-vous besoin du SSR ?

• Données temps réel (commentaires, stats, login)
• Logique serveur (API, BDD, auth)
• Rendu à la demande (gros volumes non pré-rendus)

Blog Markdown pur ? Le statique suffit.

Étape 1 — Installer l’adaptateur :

npx astro add cloudflare

Cela installe le paquet, met à jour astro.config.mjs et crée wrangler.jsonc.

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server',
  adapter: cloudflare(),
});

Étape 2 — Mode de rendu :

1. output: 'server' — tout en SSR ; apps data-driven ; chaque requête coûte un rendu.
2. output: 'hybrid' (recommandé) — statique par défaut, SSR page par page ; blog + quelques routes dynamiques.
3. output: 'static' — pas d’adaptateur ; déploiement statique ci-dessus.

Dans ~90 % des cas : hybrid.

export default defineConfig({
  output: 'hybrid',
  adapter: cloudflare(),
});

Page en SSR :

// src/pages/api/comments.js
export const prerender = false;

export async function GET() {
  const comments = await fetchComments();
  return new Response(JSON.stringify(comments));
}

Étape 3 — Liaisons Cloudflare (optionnel) — KV, D1, R2 dans wrangler.jsonc :

{
  "name": "my-astro-app",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    {
      "binding": "MY_KV",
      "id": "your-kv-namespace-id"
    }
  ]
}

export const prerender = false;

export async function GET({ locals }) {
  const { MY_KV } = locals.runtime.env;
  const sessionData = await MY_KV.get('user:123');
  return new Response(sessionData);
}

Étape 4 — Dev local :

npm install wrangler --save-dev
npm run build
npx wrangler pages dev ./dist

Étape 5 — Production :

npx wrangler login
npm run build
npx wrangler pages deploy ./dist

Ou Git intégré (liaisons KV parfois à configurer dans le Dashboard).

Erreurs fréquentes :

1. Hydration mismatches — désactiver Auto Minify (HTML/CSS/JS) : Dashboard → domaine → Speed → Optimization.
2. Cannot find module 'MY_KV' — vérifier le binding dans wrangler.jsonc.
3. 500 — Logs temps réel : Workers & Pages → projet → Logs.

Variables d’environnement et secrets

Local — fichier .dev.vars (à ignorer dans .gitignore) :

DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=your-secret-key-for-dev

export const prerender = false;

export async function GET({ locals }) {
  const apiKey = locals.runtime.env.API_KEY;
}

Production — Dashboard : Settings → Environment Variables (Production / Preview).

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Secrets :

npx wrangler secret put API_KEY

Clés API et BDD → Secrets ; config publique → variables classiques.

Optimisation de la vitesse d’accès depuis la Chine

Diagnostic : mesurer la vitesse réelle

Ne optimisez pas avant d’avoir mesuré. Audience surtout hors Chine ? La config Cloudflare par défaut peut suffire.

Outils en ligne :

1. 17ce.com — test multi-province / opérateur ; viser < 200 ms en temps de réponse.
2. tool.chinaz.com/speedtest — détails de routage.

En local : DevTools → Network → temps du premier chargement.

Repères :

• < 150 ms : très bien
• 150–250 ms : acceptable

• 250 ms ou chargement > 3 s : optimiser

Pourquoi c’est lent ? Anycast + routage ; trafic peut passer par Hong Kong, etc. Les IP/CNAME optimisés visent des nœuds plus directs.

Option 1 : IP optimisées (gratuit, effet maximal)

Latence typique : 280 ms → ~70 ms. Un peu technique ; risques à connaître.

Principe : des centaines d’IP Cloudflare ; certaines sont bien plus rapides depuis la Chine.

Étape 1 — XIU2/CloudflareSpeedTest :

CloudflareST.exe

Exemple de sortie :

IP地址           延迟    下载速度
104.16.160.10   68ms    15.2MB/s

Étape 2 — DNS : le DNS ne doit pas être chez Cloudflare (DNSPod, Alibaba Cloud, etc.). Sinon l’enregistrement A ne change pas le routage Anycast.

Enregistrement A : @ ou www → IP testée, TTL 600.

Étape 3 — revérifier sur 17ce.com.

Risque (janv. 2025) : Cloudflare a durci les conditions sur les abus ; statut des IP optimisées non explicite.

• Blog perso : risque faible
• Site commercial / fort trafic : CNAME public ou résolution par opérateur
• Contrôle tous les 1–2 mois

Dépannage : cache navigateur, nslookup, retester et changer d’IP si dégradation régionale.

Option 2 : CNAME public optimisé (gratuit, plus stable)

Domaines maintenus par la communauté (exemples — à tester avant usage) :

• cdn.cloudflare.quest
• cf.xiu2.xyz

Enregistrement CNAME (DNS hors Cloudflare), TTL 600.

403 Forbidden : retirer le DNS du site chez Cloudflare, supprimer le site dans le Dashboard, attendre quelques minutes.

Vérifier avec nslookup puis 17ce.com.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Bon compromis si vous voulez de l’accélération sans mesurer les IP vous-même.

Option 3 : résolution par opérateur (DNS payant, meilleur résultat)

IPs différentes selon opérateur / région ; défaut pour l’international vers your-project.pages.dev.

Fournisseurs : DNSPod, Alibaba Cloud DNS (Cloudflare DNS ne gère pas le routage par opérateur chinois).

1. Tester par opérateur avec CloudflareSpeedTest (Telecom, Unicom, Mobile), ou plages courantes (à valider par vos propres tests) :

   • Telecom : 104.16.160.0/24
   • Unicom : 104.23.240.0/24
   • Mobile : 172.64.32.0/24

2. DNSPod — plusieurs enregistrements avec « type de ligne » différent :

   Enregistrement 1 :
   - Hôte : @
   - Type : A
   - Ligne : Telecom
   - Valeur : 104.16.160.10
   
   Enregistrement 2 :
   - Hôte : @
   - Type : A
   - Ligne : Unicom
   - Valeur : 104.23.240.5
   
   Enregistrement 3 :
   - Hôte : @
   - Type : A
   - Ligne : Mobile
   - Valeur : 172.64.32.8
   
   Enregistrement 4 (défaut, international) :
   - Hôte : @
   - Type : CNAME
   - Ligne : Défaut
   - Valeur : your-project.pages.dev

3. Enregistrer et attendre la propagation.

Résultat : chaque opérateur chinois vers un nœud rapide ; l’international vers Cloudflare natif.

Coût : DNSPod perso gratuit (basique) ; pro ~20 ¥/mois ; Alibaba selon requêtes.

Pour > 10 000 visites/mois, l’investissement vaut souvent le coup.

Comparaison et surveillance

Gain typique ×3 à ×5.

Surveillance : UptimeRobot, Analytics Cloudflare, Better Uptime. Rappel 1–2 mois : 17ce.com, si > 200 ms relancer CloudflareSpeedTest et mettre à jour le DNS.

Conclusion

Déploiement : Pages + Git pour le statique ; npx astro add cloudflare et hybrid ou server pour le SSR.

SSR : hybrid dans la majorité des cas ; liaisons dans wrangler.jsonc ; .dev.vars en local, Dashboard en prod ; couper Auto Minify si erreur d’hydratation.

Chine : IP optimisées (gratuit, maintenance) ; CNAME public (pratique) ; résolution par opérateur (meilleur, petit coût).

Recommandations : blog perso → 1 ou 2 ; trafic élevé → 3 ; commercial → prudence sur les IP optimisées.

Actions : compte Cloudflare, test 17ce.com, rappel de vérification des IP.

Suite : Workers KV, D1, R2, Pages Functions — à explorer avec Astro.

Si cet article vous a aidé, partagez votre expérience en commentaires.