Réparez votre site WordPress de membership lent : Un guide de reconstruction sans tête

J'ai perdu le compte du nombre de propriétaires de sites d'adhésion qui sont venus nous voir avec la même histoire : « Nous avons lancé sur WordPress, c'était bien pendant un temps, et maintenant c'est terriblement lent. » Ils ont tout essayé -- les plugins de cache, CDN, la mise à niveau de l'hébergement, la désactivation des plugins un par un. Certaines choses ont aidé. La plupart n'ont pas aidé. Et le vrai problème ? Leurs membres s'en vont. Non pas parce que le contenu est mauvais, mais parce que d'attendre 6 secondes pour qu'une page de leçon se charge fait que les gens se demandent si les 49 $/mois en valent la peine.

Si cela vous semble familier, cet article est pour vous. Je vais vous expliquer exactement pourquoi les sites WordPress de membership heurtent un mur de performance, ce que vous pouvez réalistes corriger sans une reconstruction, et quand (et comment) aller sans tête -- en utilisant WordPress comme votre backend de contenu avec un frontend moderne qui vole réellement.

Table des matières

Réparez votre site WordPress de membership lent : Un guide de reconstruction sans tête

Pourquoi les sites WordPress de membership deviennent lents

Soyons honnête à propos de ce qui se passe réellement sous le capot. Un site WordPress de membership typique n'est pas juste WordPress. C'est WordPress + MemberPress (ou Restrict Content Pro, ou WooCommerce Memberships) + un constructeur de pages + un plugin LMS + un plugin communautaire + un plugin de formulaires + l'analyse + probablement 15-25 autres plugins. Chacun ajoute des requêtes de base de données. Chacun charge des fichiers CSS et JavaScript. Et ils se composent.

Voici à quoi ressemble une requête typique sur un site de membership :

  1. L'utilisateur accède à la page
  2. PHP traite la requête (noyau WordPress)
  3. Le plugin de membership vérifie si l'utilisateur a accès (requête de base de données)
  4. Si l'accès est accordé, le contenu est récupéré (plus de requêtes de base de données)
  5. Le constructeur de pages assemble la mise en page (encore plus de requêtes)
  6. Le plugin LMS vérifie la progression, marque les achèvements (encore plus de requêtes)
  7. Tous les fichiers CSS/JS du plugin se chargent -- même ceux non nécessaires sur cette page
  8. Le HTML rendu arrive finalement au navigateur

Une seule page de leçon sur un site de membership que j'ai audité l'année dernière faisait 147 requêtes de base de données et chargeait 43 fichiers CSS/JS distincts. La page pesait 4,2 Mo. Sur un hébergement partagé, cette page a pris 7,8 secondes à charger.

La taxe des plugins

Chaque plugin WordPress est essentiellement un crochet dans le pipeline d'exécution. Même les plugins bien écrits ajoutent de la surcharge. Mais les plugins de membership sont particulièrement coûteux car ils s'exécutent sur chaque chargement de page pour vérifier les autorisations. MemberPress, par exemple, croche à template_redirect, the_content, et plusieurs autres filtres. Multipliez cela par un site avec 500+ pages protégées et des milliers de membres actifs, et votre serveur fait un travail sérieux sur chaque requête.

Le problème de la base de données

WordPress stocke tout dans une seule base de données. Les métadonnées utilisateur, les métadonnées de publication, les niveaux de membership, la progression des cours, l'historique des transactions -- tout cela vit dans wp_options, wp_usermeta, et wp_postmeta. Ces tables n'ont jamais été conçues pour le volume de données qu'un site de membership génère. Une fois que vous dépassez 10 000+ membres avec des données de progression de cours, ces tables s'agrandissent et les requêtes ralentissent à un rythme d'escargot.

J'ai vu des tables wp_usermeta avec 2 millions+ de lignes sur les sites de membership. Sans une indexation appropriée (et le schéma par défaut de WordPress n'indexe pas meta_value), même les recherches simples deviennent terriblement lentes.

Les vrais chiffres de performance

Mettez des données derrière cela. Voici une comparaison des Core Web Vitals des sites WordPress de membership que nous avons audités par rapport à ce que nous voyons après les reconstructions sans tête :

Métrique WordPress + plugins de membership Reconstruction sans tête (Next.js) Cible Google
Largest Contentful Paint (LCP) 4.2 - 8.1s 0.8 - 1.4s < 2.5s
Interaction to Next Paint (INP) 280 - 450ms 40 - 90ms < 200ms
Cumulative Layout Shift (CLS) 0.15 - 0.38 0.01 - 0.04 < 0.1
Time to First Byte (TTFB) 1.2 - 3.8s 50 - 200ms < 0.8s
Poids total de la page 2.8 - 5.2MB 180 - 400KB < 2MB
Requêtes HTTP 45 - 90+ 8 - 15 < 60

Ce ne sont pas des chiffres théoriques. Ils proviennent de vrais projets. La différence est flagrante, et elle affecte directement votre résultat net.

La recherche d'Elementor montre que seulement 40,5% des sites WordPress réussissent les trois Core Web Vitals. Pour les sites de membership avec leur charge supplémentaire de plugins ? Ce nombre baisse considérablement. Pendant ce temps, les sites Next.js réussissent à environ 55% de taux dès la sortie de la boîte -- et avec une optimisation appropriée, vous pouvez aller beaucoup plus haut.

Et voici l'argument commercial qui compte vraiment : une amélioration de vitesse de 0,1 seconde sur mobile augmente les taux de conversion au détail de 8,4% selon la recherche de Deloitte. Pour un site de membership facturant 49 $/mois, même une légère réduction du taux d'attrition grâce à des chargements de pages plus rapides paie la reconstruction en quelques mois.

Pouvez-vous corriger cela sans une reconstruction ?

Question juste. Et la réponse honnête est : parfois, oui. Avant de vous engager dans une reconstruction sans tête complète, voici ce qu'il faut essayer :

Des victoires rapides qui aident vraiment

Mettez à niveau PHP vers 8.3+. Cela seul peut améliorer les performances de 20-30%. Vérifiez votre version à Tableau de bord → Outils → Santé du site → Info → Serveur. Si vous êtes toujours sur PHP 7.4, vous laissez des performances gratuites sur la table.

Passez à un hébergement de qualité. Si vous êtes sur un hébergement partagé, passez à l'hébergement WordPress géré (Cloudways, Kinsta, WP Engine). Budget 50-150 $/mois au lieu de 10 $. C'est l'amélioration unique la plus importante que la plupart des gens puissent faire.

Installez un cache d'objet. Redis ou Memcached. Cela cache les résultats de requête de base de données en mémoire, ce qui est énorme pour les sites de membership qui martelent la base de données à chaque requête.

// wp-config.php - Activez le cache d'objet Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);

Supprimez les plugins inutilisés et désactivez les scripts par page. Utilisez Asset CleanUp ou Perfmatters pour désactiver le CSS/JS des plugins sur les pages où ils ne sont pas nécessaires. Cela seul peut éliminer 10-20 requêtes HTTP par page.

Optimisez votre base de données. Supprimez les éléments temporaires expirés, nettoyez les révisions de publication, optimisez les options préchargées :

-- Vérifiez la taille des données préchargées (doit être inférieure à 1 Mo)
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- Trouvez les plus grands contrevenants
SELECT option_name, LENGTH(option_value) as size 
FROM wp_options 
WHERE autoload = 'yes' 
ORDER BY size DESC 
LIMIT 20;

Quand ces correctifs ne suffisent pas

Voici la chose : toutes ces optimisations sont des pansements sur un problème architectural fondamental. Vous exécutez toujours PHP à chaque requête. Vous interrogez toujours une base de données MySQL pour vérifier les autorisations. Vous chargez toujours le noyau WordPress -- tous les 70 000+ lignes de celui-ci -- avant qu'un seul octet de votre contenu réel ne soit servi.

Si votre site de membership a moins de 1 000 membres et moins de 200 contenus, les optimisations ci-dessus pourraient vous faire atteindre des performances acceptables. Mais si vous grandissez -- et la croissance est supposément le point -- vous allez heurter le même mur à nouveau.

Réparez votre site WordPress de membership lent : Un guide de reconstruction sans tête - architecture

Quand une reconstruction sans tête a du sens

Une reconstruction sans tête n'est pas la bonne décision pour tout le monde. Voici quand cela a du sens :

  • Vous avez 1 000+ membres actifs et les performances se dégradent à mesure que vous grandissez
  • Votre équipe de contenu est heureuse avec WordPress pour la gestion de contenu (elle déteste juste la lenteur du site)
  • Vous avez besoin que le site fonctionne sur plusieurs plates-formes -- web, application mobile, peut-être une API pour les partenaires
  • Vos Core Web Vitals échouent et cela affecte le SEO et les conversions
  • Vous avez déjà essayé les étapes d'optimisation ci-dessus et avez atteint les rendements décroissants
  • Vous passez plus de temps à combattre WordPress qu'à construire votre activité

Et voici quand cela n'a pas du sens :

  • Vous êtes un créateur solo avec un petit site et un budget limité
  • Votre équipe de contenu ne peut pas travailler sans un constructeur de pages visuel pour chaque page
  • Vous n'avez pas de développeur (ou d'agence) qui peut maintenir une architecture découplée
  • Vos problèmes de performance sont réellement juste un mauvais hébergement

Architecture d'un site de membership sans tête

Plongeons dans l'architecture réelle. Voici à quoi ressemble un site de membership sans tête :

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   WordPress     │     │    Next.js        │     │     CDN         │
│   (Backend)     │────▶│    (Frontend)     │────▶│   (Vercel/CF)   │
│                 │ API │                   │     │                 │
│ - Contenu       │     │ - Pages SSR/SSG   │     │ - Cache edge    │
│ - Données user  │     │ - Gestion auth    │     │ - Dist. globale │
│ - Memberships   │     │ - Contrôle accès  │     │                 │
│ - WP REST API   │     │ - Progression     │     │                 │
│   ou WPGraphQL  │     │   des cours       │     │                 │
└─────────────────┘     └──────────────────┘     └─────────────────┘

La couche de contenu

WordPress reste votre CMS. Votre équipe de contenu continue d'utiliser l'éditeur qu'elle connaît. Vous exposez le contenu via l'API WP REST (intégrée) ou WPGraphQL (beaucoup mieux pour ce cas d'utilisation). Je recommande fortement WPGraphQL -- cela vous permet de récupérer exactement les données dont vous avez besoin en une seule requête au lieu de faire plusieurs appels REST.

# Récupérez une leçon avec son cours et ses exigences d'accès
query GetLesson($slug: String!) {
  lessonBy(slug: $slug) {
    title
    content
    lessonFields {
      duration
      videoUrl
      requiredMembershipLevel
    }
    course {
      node {
        title
        slug
        lessons {
          nodes {
            title
            slug
          }
        }
      }
    }
  }
}

La couche d'authentification

C'est là que cela devient intéressant. Sur un site de membership WordPress traditionnel, l'authentification est gérée par les cookies et wp_get_current_user(). Dans une configuration sans tête, vous avez besoin d'un système d'authentification approprié basé sur les jetons.

Nous utilisons généralement l'une de deux approches :

  1. Authentification JWT -- WordPress émet un JWT lors de la connexion, le frontend le stocke et l'envoie avec les requêtes API
  2. NextAuth.js avec WordPress comme fournisseur -- plus flexible, supporte la connexion sociale, meilleure gestion des sessions

Pour la plupart des sites de membership, l'option 2 est meilleure :

// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import CredentialsProvider from 'next-auth/providers/credentials'

export const authOptions = {
  providers: [
    CredentialsProvider({
      name: 'WordPress',
      credentials: {
        username: { label: 'Email', type: 'email' },
        password: { label: 'Password', type: 'password' },
      },
      async authorize(credentials) {
        const res = await fetch(
          `${process.env.WP_URL}/wp-json/jwt-auth/v1/token`,
          {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
              username: credentials?.username,
              password: credentials?.password,
            }),
          }
        )
        const user = await res.json()
        if (res.ok && user) {
          return {
            id: user.user_id,
            name: user.user_display_name,
            email: user.user_email,
            token: user.token,
          }
        }
        return null
      },
    }),
  ],
}

La couche de contrôle d'accès

Le contrôle d'accès dans une configuration sans tête se fait au niveau du frontend. Le frontend vérifie le niveau de membership de l'utilisateur avant de rendre le contenu protégé. C'est en fait plus sûr que le WordPress traditionnel car même si quelqu'un affiche la source de la page, le contenu protégé n'a jamais été envoyé au navigateur -- il est fermé au niveau du serveur pendant SSR.

// middleware.ts - Protégez les itinéraires de membership au edge
import { withAuth } from 'next-auth/middleware'

export default withAuth({
  callbacks: {
    authorized: ({ token, req }) => {
      const path = req.nextUrl.pathname
      if (path.startsWith('/courses/')) {
        return token?.membershipLevel === 'premium' || 
               token?.membershipLevel === 'lifetime'
      }
      if (path.startsWith('/community/')) {
        return !!token
      }
      return true
    },
  },
})

export const config = {
  matcher: ['/courses/:path*', '/community/:path*', '/dashboard/:path*'],
}

Choisir votre framework frontend

Pour les sites de membership spécifiquement, voici comment les principales options se comparent :

Framework Meilleur pour Support SSR Story Auth Courbe d'apprentissage
Next.js (App Router) Sites de membership dynamiques avec mises à jour fréquentes du contenu Excellent NextAuth.js est mature Modérée
Astro Sites lourds en contenu avec une interaction minimale Bon (hybride) Nécessite plus de DIY Inférieure
Remix Interactions utilisateur complexes, sites lourds en formulaires Excellent Modèles intégrés Modérée
SvelteKit Équipes qui veulent des tailles de bundle plus petites Excellent Écosystème croissant Modérée

Pour la plupart des sites de membership, Next.js est le bon choix. Il gère mieux le mélange de contenu statique (pages marketing, articles de blog) et de contenu dynamique (tableaux de bord, progression des cours, fonctionnalités communautaires) que n'importe quoi d'autre en ce moment. L'App Router avec React Server Components vous permet de récupérer les données sur le serveur sans envoyer le code de récupération des données au navigateur.

Nous faisons beaucoup de développement Next.js spécifiquement pour ce type de projet. Si votre site est plus lourd en contenu avec moins d'interaction dynamique -- pensez à une bibliothèque de contenu d'adhésion sans fonctionnalités communautaires -- Astro peut être encore plus rapide car il ne libère zéro JavaScript par défaut.

Authentification et contrôle d'accès

Gestion des tiers de membership

La plupart des sites de membership ont plusieurs tiers. Gratuit, basique, premium, peut-être un tier lifetime. Dans une architecture sans tête, vous stockez les données de membership dans WordPress et les synchronisez avec la session de votre frontend.

Le flux ressemble à ceci :

  1. L'utilisateur se connecte → le frontend s'authentifie auprès de WordPress → un JWT est émis
  2. JWT inclut les réclamations de niveau de membership
  3. Le middleware frontend vérifie ces réclamations sur chaque route protégée
  4. Le contenu est récupéré de l'API WordPress seulement si l'utilisateur a le bon niveau d'accès
  5. La session s'actualise périodiquement pour attraper les modifications de membership (mises à niveau, expirations, annulations)

Intégration des paiements

Stripe est la norme ici. Vous avez deux options :

  • Garder l'intégration Stripe dans WordPress en utilisant MemberPress ou WooCommerce Subscriptions, et synchroniser le statut vers le frontend
  • Déplacer Stripe vers le frontend en utilisant Stripe Checkout et les webhooks, WordPress servant de magasin de données

L'option 2 est plus propre à long terme. Stripe Checkout gère la conformité PCI, et vous pouvez traiter les webhooks dans les itinéraires API Next.js :

// app/api/webhooks/stripe/route.ts
import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: Request) {
  const body = await req.text()
  const sig = req.headers.get('stripe-signature')!
  
  const event = stripe.webhooks.constructEvent(
    body,
    sig,
    process.env.STRIPE_WEBHOOK_SECRET!
  )

  switch (event.type) {
    case 'customer.subscription.created':
    case 'customer.subscription.updated':
      // Mettez à jour le niveau de membership dans WordPress via l'API REST
      await updateWordPressMembership(event.data.object)
      break
    case 'customer.subscription.deleted':
      // Rétrogradez au tier gratuit
      await revokeMembership(event.data.object)
      break
  }

  return new Response('OK', { status: 200 })
}

Le processus de migration étape par étape

Voici le processus de migration réel que nous suivons. Ce n'est pas théorique -- c'est le livret que nous utilisons pour les reconstructions CMS sans tête.

Phase 1 : Audit et architecture (Semaine 1-2)

  • Auditez les performances du site actuel (Lighthouse, WebPageTest, métriques d'utilisateurs réels)
  • Cartographiez tous les types de contenu, les tiers de membership, et les flux utilisateur
  • Documentez chaque intégration (processeur de paiement, service d'email, analyse, etc.)
  • Concevez l'architecture sans tête
  • Configurez WPGraphQL et les types personnalisés

Phase 2 : Préparation du backend (Semaine 2-3)

  • Installez et configurez WPGraphQL
  • Créez des champs GraphQL personnalisés pour les données de membership
  • Construisez des points de terminaison REST personnalisés pour l'authentification
  • Configurez l'authentification JWT
  • Testez tous les points de terminaison API à fond

Phase 3 : Construction du frontend (Semaine 3-6)

  • Échafaudez le projet Next.js avec App Router
  • Implémentez le flux d'authentification
  • Construisez les modèles de page (pages marketing, pages de cours, pages de leçon, tableau de bord)
  • Implémentez le middleware de contrôle d'accès
  • Connectez l'intégration Stripe
  • Construisez le tableau de bord des membres

Phase 4 : Test et migration (Semaine 6-8)

  • Test de performance et optimisation
  • Test multi-navigateur et multi-appareils
  • Test d'acceptation par les utilisateurs avec de vrais membres
  • Migration DNS et lancement
  • Surveillez les performances pendant les 2 premières semaines après le lancement

Résultats de performance : avant et après

Voici un exemple réel d'un site de membership que nous avons reconstruit au début de 2026. Le site avait environ 8 000 membres actifs, 400+ leçons sur 12 cours, et un forum communautaire.

Métrique Avant (WordPress + MemberPress + LearnDash) Après (Next.js + WordPress sans tête)
LCP (mobile) 6.2s 1.1s
INP 380ms 65ms
CLS 0.24 0.02
TTFB 2.8s 85ms
Performance Lighthouse 28 96
Poids de la page (page de leçon) 3.8MB 290KB
Taux de churn mensuel 8.2% 5.1% (3 mois après reconstruction)

Cette seule réduction de churn -- de 8,2% à 5,1% -- représentait environ 14 000 $/mois en revenus retenus pour ce site particulier. La reconstruction s'est rentabilisée en moins de 3 mois.

Attentes en matière de coûts et de délais

Soyons transparents à propos des coûts. Une reconstruction sans tête n'est pas bon marché, mais ce n'est pas aussi cher que la plupart des gens l'assumant quand vous tenez compte du ROI.

Portée du projet Délai Fourchette budgétaire
Membership simple (1-2 tiers, bibliothèque de contenu seulement) 6-8 semaines 15 000 $ - 30 000 $
Membership moyen (plusieurs tiers, cours, suivi de la progression) 8-12 semaines 30 000 $ - 60 000 $
Membership complexe (cours, communauté, gamification, mobile) 12-20 semaines 60 000 $ - 120 000 $+

Pour comparaison, l'approche WordPress traditionnelle avec les plugins premium coûte 3 000 $-10 000 $ initialement mais accumule les coûts permanents dans les mises à niveau d'hébergement, les licences de plugins (500 $-1 500 $/an), et la bataille constante contre la dégradation des performances.

Si vous voulez discuter de ce qu'une reconstruction sans tête ressemblerait pour votre site spécifique, nous offrons des consultations architecturales gratuites. Pas de pitch deck, juste une conversation honnête sur la question de savoir si cela a du sens pour votre situation.

Vous pouvez également consulter notre page de tarification pour les structures d'engagement générales.

FAQ

Mon équipe de contenu devra-t-elle apprendre un nouveau CMS ?

Non, et c'est un des plus grands avantages de l'approche WordPress sans tête. Votre équipe de contenu continue d'utiliser WordPress exactement comme elle le fait aujourd'hui. Ils se connectent au même panneau d'admin, utilisent le même éditeur, et gèrent le contenu de la même manière. La seule différence est que le frontend -- ce que les visiteurs voient -- est construit avec un framework moderne. Votre équipe ne remarquera aucun changement dans leur workflow.

Comment le SEO fonctionne-t-il sur un site de membership sans tête ?

Avec Next.js et le rendu côté serveur, les moteurs de recherche reçoivent du HTML complètement rendu tout comme ils le feraient sur un site WordPress traditionnel. En fait, c'est mieux -- car les pages se chargent plus rapidement, vos Core Web Vitals s'améliorent, et Google utilise ceux-ci comme signaux de classement. Vous devrez gérer la génération de votre sitemap et les métabalises dans la couche Next.js, mais les frameworks comme next-seo rendent cela simple. Nous voyons généralement les sites s'améliorer dans les classements de recherche dans les 4-6 semaines suivant une migration sans tête.

Puis-je continuer à utiliser MemberPress ou WooCommerce pour les paiements ?

Vous pouvez, mais nous recommandons généralement de déplacer le traitement des paiements à Stripe directement sur le frontend. C'est plus propre, plus maintenable, et vous donne un meilleur contrôle sur l'expérience de paiement. Si vous êtes profondément intégré avec MemberPress et que vous ne voulez pas changer votre configuration de facturation, vous pouvez le garder du côté WordPress et synchroniser le statut de membership vers le frontend via API. Cela fonctionne, c'est juste une couche supplémentaire à maintenir.

Que se passe-t-il si le backend WordPress s'arrête ?

C'est en fait l'un des avantages de devenir sans tête. Si vous utilisez une génération statique pour les pages publiques, ces pages sont mises en cache sur un CDN et continueront à être servies même si WordPress s'arrête complètement. Les pages dynamiques (tableau de bord, progression des cours) seront affectées, mais vous pouvez implémenter une gestion d'erreur gracieuse qui affiche le contenu en cache ou un message de maintenance. Dans une configuration WordPress traditionnelle, si WordPress s'arrête, tout s'arrête.

Comment je gère le contenu réservé aux membres afin qu'il ne soit pas exposé dans l'API ?

C'est une préoccupation critique en matière de sécurité. Vous n'exposez jamais le contenu protégé dans les points de terminaison API publics. Le contenu protégé ne doit être accessible que via les requêtes API authentifiées. Dans WPGraphQL, vous pouvez utiliser des règles de contrôle d'accès qui vérifient le niveau de membership de l'utilisateur demandeur avant de retourner le contenu. Le frontend utilise ensuite le JWT de l'utilisateur authentifié pour faire ces requêtes côté serveur, donc le contenu ne frappe jamais le navigateur à moins que l'utilisateur soit autorisé.

L'hébergement WordPress sans tête est-il plus coûteux ?

Le backend WordPress devient réellement moins cher à héberger car il fait moins de travail -- il serve simplement les réponses API au lieu de rendre les pages complètes. Vous ajouterez un coût d'hébergement pour le frontend (le plan Pro de Vercel est 20 $/mois par membre de l'équipe, ou vous pouvez auto-héberger sur un VPS). Les coûts d'hébergement totaux sont généralement similaires ou légèrement plus élevés, mais l'amélioration des performances est dramatique. De nombreuses équipes trouvent qu'elles peuvent réduire leur hébergement WordPress car il ne gère plus le trafic direct.

Puis-je migrer graduellement au lieu de faire une reconstruction complète ?

Oui, et nous recommandons parfois cette approche. Vous pouvez commencer par construire simplement les pages publiques (marketing, blog) en tant que frontend sans tête tout en gardant la zone membre sur WordPress traditionnel. Puis migrez le tableau de bord des membres, puis les cours, puis la communauté. Cela réduit le risque et vous permet de valider l'approche avant de vous lancer complètement. Le middleware Next.js rend facile de proxier certains chemins de retour à votre installation WordPress pendant la transition.

Combien de temps prend la migration sans aucun temps d'arrêt ?

La migration sans aucun temps d'arrêt est une pratique standard. Vous construisez l'intégralité du nouveau frontend tandis que le site existant continue de fonctionner. Quand tout est testé et prêt, vous mettez à jour les enregistrements DNS pour pointer vers le nouveau frontend. Le changement prend quelques minutes, et si quelque chose ne va pas, vous pouvez immédiatement faire un rollback DNS. Nous gardons généralement le frontend WordPress ancien en cours d'exécution en parallèle pendant 2-4 semaines comme un filet de sécurité.