Le vrai problème avec un WordPress auto-géré
Un site WordPress en production n'est jamais uniquement WordPress. Il lui faut une base de données, un cache objet, un cache de page, un pipeline d'image, des certificats TLS, un DNS et un pare-feu — et sur un hébergement mutualisé, chacun de ces éléments est un plugin, un add-on payant ou un service que vous assemblez vous-même. Les incompatibilités de versions entre le runtime PHP, le serveur MySQL et un plugin de cache sont une source constante d'écrans blancs. cdn.com.tr remplace ce rafistolage par une seule pile managée où le runtime, la base de données, Redis et l'edge sont déjà compatibles et provisionnés ensemble.
Un cache objet Redis qui réduit vraiment la charge de la base de données
La lenteur de WordPress sous charge vient le plus souvent de requêtes de base de données répétées et identiques pour les options, les menus et les métadonnées d'article. L'add-on Redis managé se branche comme un drop-in de cache objet WordPress, si bien que ces requêtes sont répondues depuis la mémoire plutôt que depuis MySQL. Pour les sites WooCommerce et d'adhésion où les pages sont personnalisées et ne peuvent pas être entièrement mises en cache de page, c'est ce qui garde le panier et les pages de compte rapides. Comme Redis est managé, les identifiants sont injectés dans le runtime et pivotés pour vous plutôt que de rester dans un écran de réglages de plugin.
Cache CDN edge et optimisation d'image intégrés
Les assets statiques et le HTML cacheable sont servis depuis l'edge de cdn.com.tr près du visiteur, réduisant les allers-retours vers l'origine et absorbant les pics de trafic pendant les campagnes. L'optimisation d'image réencode les fichiers téléversés vers des formats modernes et sert des variantes correctement dimensionnées, ce qui supprime le besoin d'un plugin d'optimisation lourd qui entrerait en concurrence avec votre site pour les workers PHP. Les règles de cache comprennent les cookies de connexion WordPress et de panier WooCommerce, si bien que les utilisateurs connectés et les acheteurs contournent correctement le cache partagé tandis que les visiteurs anonymes reçoivent des pages mises en cache.
Auto SSL, DNS et WAF devant wp-admin
Les URL les plus attaquées sur toute installation WordPress sont wp-login.php et xmlrpc.php. Comme le trafic atteint l'edge de cdn.com.tr avant l'origine, le WAF filtre les schémas de brute-force et d'exploitation courants avant qu'ils ne touchent PHP. Auto SSL garde le HTTPS valide à la fois sur l'apex et le www sans tâches cron ni certbot, et le DNS est géré dans le même panel afin qu'un déplacement de domaine ne nécessite pas de jongler entre trois tableaux de bord.
Migrer un site existant sans reconstruction
Vous n'avez pas besoin de reconstruire le site pour le déplacer. Apportez les fichiers existants et un export de base de données, restaurez-les sur la plateforme managée, et validez sur une URL name.cdn.com.tr avant de basculer le DNS. La base de données managée gère l'import et les questions de jeu de caractères, Redis et le cache edge sont activés une fois le contenu vérifié, et la bascule du domaine se produit en dernier, si bien qu'il n'y a jamais de fenêtre où le site est inaccessible.
Un seul panel pour les agences qui gèrent de nombreux sites
Les agences souffrent le plus de l'incohérence : chaque site client finit sur un hébergement légèrement différent avec des plugins différents pour le cache et la sécurité. Standardiser sur la plateforme WordPress managée signifie le même runtime, le même modèle Redis et edge, et le même profil WAF sur chaque projet. La purge, les logs et le statut de déploiement sont visibles par site dans le même compte, si bien que confier un site à un autre membre de l'équipe ne veut pas dire réapprendre une configuration sur-mesure.
Comment déployer, étape par étape
Créez l'application WordPress
Dans le panel, ouvrez Platform, choisissez WordPress, et sélectionnez le runtime PHP 8 et la taille de plan. La plateforme provisionne le runtime, un volume persistant pour wp-content, et une base de données MySQL managée, si bien que vous n'avez jamais à modifier manuellement les constantes de base de données de wp-config.php — elles sont injectées pour vous.
Attachez votre domaine et émettez le SSL
Pointez le domaine vers cdn.com.tr, ou ajoutez-le d'abord comme sous-domaine name.cdn.com.tr pour tester. Auto SSL émet et renouvelle le certificat, et l'apex comme le www sont validés séparément afin qu'une boucle de redirection ne puisse pas laisser une variante non couverte.
Activez le cache objet Redis
Activez l'add-on Redis managé et déposez le drop-in object-cache depuis le panel. WordPress stocke alors les résultats de requêtes coûteuses, les options et les transients dans Redis plutôt que de solliciter MySQL à chaque requête, ce qui constitue le plus gros gain pour le trafic connecté et WooCommerce.
Activez le cache CDN edge et l'optimisation d'image
Publiez le site à travers l'edge afin que les fichiers statiques — images, CSS, JS, polices — soient servis depuis le cache près du visiteur. L'optimisation d'image réencode et redimensionne les médias à la volée, si bien que vous n'avez pas besoin d'un plugin d'optimisation séparé qui ralentirait wp-admin.
Définissez les règles de WAF et de purge
Appliquez le profil WAF devant wp-login.php, xmlrpc.php et wp-admin, et définissez des règles de contournement de cache pour les cookies de connexion et le panier. Configurez la purge automatique afin que la publication d'un article ou la mise à jour d'un produit efface le cache edge concerné sans purge manuelle.
Exemples de scénarios
Un site d'actualités ou un blog absorbe les pics de campagne grâce au cache de page à l'edge tandis que Redis garde le tableau de bord éditorial réactif.
Les pages produit et catégorie sont mises en cache à l'edge, le panier et le checkout contournent correctement le cache, et Redis garde les pages personnalisées rapides sous charge.
Des dizaines de sites clients tournent sur une pile standardisée unique avec le même modèle de SSL, de WAF et de cache, géré depuis un seul compte.
Questions fréquentes
Le cache objet Redis va-t-il casser les plugins de cache de page que j'utilise déjà ?
Le cache objet Redis et le cache de page à l'edge résolvent des problèmes différents et fonctionnent ensemble. Le cache objet sert les résultats de base de données depuis la mémoire pour les pages non cacheables et connectées ; le cache edge sert des réponses statiques entières pour les visiteurs anonymes. Vous pouvez généralement retirer une couche de cache de page basée sur un plugin une fois que l'edge la prend en charge, et garder le cache objet Redis managé pour les parties dynamiques.
Comment le checkout WooCommerce est-il tenu hors du cache partagé ?
Les règles de cache détectent les cookies WordPress et WooCommerce — le cookie de connexion et les cookies de panier/session — et contournent le cache edge pour ces requêtes, si bien qu'aucun client ne voit jamais le panier d'un autre client. Les pages produit et catégorie anonymes restent mises en cache, ce qui est là où se trouvent réellement le trafic et le gain de vitesse.
Ai-je toujours besoin de Wordfence, d'un plugin de cache et d'un plugin d'image ?
La pile couvre ce que ces plugins font habituellement : le WAF remplace le pare-feu d'un plugin de sécurité devant wp-admin, l'edge et Redis remplacent les plugins de cache, et l'optimisation d'image intégrée remplace un plugin d'image. Les retirer libère des workers PHP, car ces plugins tournent sinon à l'intérieur de chaque requête.
Publier un article efface-t-il automatiquement le cache CDN ?
Oui. La purge automatique est liée aux événements de contenu, si bien que publier ou mettre à jour un article, une page ou un produit efface les entrées de cache edge concernées. Vous pouvez également purger manuellement depuis le panel pour des changements ponctuels comme un ajustement de thème ou une image corrigée.
Puis-je garder ma version PHP et mes plugins actuels pendant la migration ?
Vous migrez vers le runtime PHP 8 managé ; la plupart des thèmes et plugins maintenus tournent sur PHP 8 sans modification. Vous validez le site sur une URL temporaire name.cdn.com.tr avant de basculer le DNS, si bien que tout plugin nécessitant une mise à jour est repéré avant que de vrais visiteurs ne le voient.
Qu'advient-il des identifiants de base de données de wp-config.php ?
La connexion à la base de données managée est injectée dans le runtime, si bien que vous ne collez pas manuellement l'hôte, le nom, l'utilisateur ou le mot de passe de la base de données dans wp-config.php. Les identifiants peuvent être pivotés depuis le panel sans modifier le fichier, ce qui est plus sûr que de les stocker en clair dans le dépôt ou sur disque.