Performances et surveillance

Configurer le CDN QUIC.cloud dans WordPress avec LiteSpeed Cache

Vérifié le 7 min de lecture wordpress cdn cache

QUIC.cloud peut distribuer les ressources statiques et les pages compatibles de WordPress depuis son réseau CDN, en coordination avec LiteSpeed Cache. Son intérêt dépend de l'endroit où se trouvent vos visiteurs, du contenu qui peut être mis en cache et du coût du service.

Connecter les services QUIC.cloud et activer son CDN sont deux étapes distinctes. Vous pouvez utiliser des services d'optimisation sans faire passer le trafic du site par le CDN.

Avant de commencer

Mettez à jour WordPress et LiteSpeed Cache en disposant d'une sauvegarde récupérable. Vérifiez que le site fonctionne en HTTPS sur l'hébergement et notez son IP d'origine, le domaine principal et les enregistrements DNS actuels. Gardez l'accès au fournisseur DNS et au registraire.

Pour une boutique, repérez le panier, le paiement, le compte client et le contenu personnalisé. L'intégration ne justifie pas de forcer un cache public pour toutes les pages ni pour tous les utilisateurs connectés.

Connecter WordPress à QUIC.cloud

  1. Dans WordPress, ouvrez LiteSpeed Cache > General > Online Services — services en ligne, selon la traduction —.
  2. Cliquez sur Enable QUIC.cloud services et suivez l'assistant pour associer le domaine à votre compte QUIC.cloud.
  3. Vérifiez que le bon domaine a été associé, y compris sa variante avec ou sans www.
  4. Si vous voulez distribuer le trafic, poursuivez avec l'activation du CDN. Si vous cherchiez seulement l'optimisation des images ou du CSS, ne changez pas les DNS pour autant.

Les anciens guides montraient Request Domain Key. La procédure actuelle commence dans les services en ligne ; consultez l'assistant officiel d'association si votre écran est différent.

Choisir comment connecter le domaine

L'assistant propose différentes options selon le domaine et le fournisseur DNS. Ne copiez pas la cible CNAME d'une autre installation : utilisez celle attribuée à votre site.

Conserver votre fournisseur DNS

Pour un sous-domaine comme www.tudominio.com, configurez le CNAME fourni par QUIC.cloud chez le fournisseur DNS faisant autorité. Ce sera l'éditeur de zone de cPanel uniquement si c'est là qu'est gérée la zone utilisée par le domaine.

Sur le domaine racine, un CNAME classique ne peut pas coexister avec les autres enregistrements nécessaires. Certains fournisseurs permettent une solution équivalente grâce à l'aplatissement de CNAME. Vérifiez la compatibilité de la méthode DNS avant de le modifier.

Si vous utilisez Cloudflare comme DNS, suivez l'intégration spécifique de QUIC.cloud. N'enchaînez pas deux proxys en activant les options des deux fournisseurs sans vérifier que cette architecture est prise en charge.

Utiliser les DNS de QUIC.cloud

Avant de changer les serveurs DNS du domaine, reproduisez la zone complète dans QUIC.cloud. La détection automatique peut oublier des enregistrements.

Comparez le site et les sous-domaines, MX, adresses des serveurs de messagerie, SPF, DKIM, DMARC, vérifications et CAA. La messagerie doit continuer à pointer vers son service, pas vers le CDN web. Si vous utilisez DNSSEC, coordonnez aussi avec les fournisseurs le changement de signatures et d'enregistrements DS ; une délégation avec un DS incorrect peut rendre le domaine impossible à résoudre.

Remplacez ensuite les serveurs DNS par ceux attribués au domaine. Conservez l'ancienne zone pendant la transition et vérifiez la propagation ; sa durée dépend des caches DNS, pas d'un délai fixe indiqué dans ce guide.

Vérifier la mise en service

Vérifiez dans QUIC.cloud que le domaine, son origine et le HTTPS sont corrects. Ouvrez le site dans une session privée et testez plusieurs pages publiques, les ressources, un formulaire et, le cas échéant, le processus d'achat sans effectuer de paiement réel.

Vérifiez aussi la messagerie et les sous-domaines. Si quelque chose ne fonctionne plus après le changement de DNS, comparez d'abord la zone et l'IP d'origine ; ne désactivez pas les protections du serveur à l'aveugle.

Une erreur d'accès aux endpoints REST peut venir de restrictions de l'application ou du pare-feu. Comparez avec les IP et les exigences de communication publiées par QUIC.cloud et indiquez à l'assistance le domaine, l'heure et l'erreur, sans partager de clés.

Purges, consommation et retour à l'origine

Après avoir modifié un modèle ou du contenu, il peut être nécessaire de purger le cache de l'extension et celui du CDN. Commencez par les pages concernées : une purge totale oblige à régénérer de nombreuses réponses et peut augmenter temporairement la charge de l'hébergement.

Consultez dans le panneau les formules, le quota, le crédit et les conditions en vigueur avant d'activer des services payants. Mesurez la consommation et les temps de réponse depuis les régions où se trouvent vos visiteurs ; ne choisissez pas une formule uniquement d'après le nombre d'emplacements annoncé.

Si vous décidez de retirer le CDN, préparez d'abord les enregistrements qui ramèneront le site vers l'hébergement et vérifiez le certificat de l'origine. Si vous avez changé les serveurs DNS, reproduisez aussi toute la zone chez le fournisseur de destination. Gardez le CDN opérationnel pendant la transition pour ne pas laisser sans service les visiteurs qui ont encore les anciens DNS.

Cela peut aussi vous aider

Quelque chose cloche ou a changé ? Racontez-nous et nous le vérifions.