# Cache statique complet : la parade d’urgence d’un domaine skiable saturé > Face aux pics de réservation des vacances scolaires, un domaine skiable a préféré générer tout son site en pages statiques plutôt que complexifier son CDN. Retour sur ce choix radical. - Auteur : Clément Hadrot - Publié le : 2020-07-06 - Mis à jour le : 2020-07-06 - Catégorie : Performance - URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/cache-statique-complet-domaine-skiable-pic/ ## L’essentiel - Générer tout le site en HTML statique évite la moindre exécution PHP au pic - Le choix a été préféré à une configuration CDN plus fine, jugée trop fragile à maintenir - Les pages nécessitant une interaction restent servies dynamiquement à part Trente-six heures avant l'ouverture des réservations d'une vacance scolaire, le trafic d'un domaine skiable peut être multiplié par vingt en quelques minutes. Face à ce pic prévisible mais bref, l'équipe technique a tranché pour une solution qui peut sembler brutale au premier abord : générer l'intégralité du site en pages HTML statiques, plutôt que d'affiner encore la configuration du CDN devant le serveur WordPress. Le choix méritait d'être posé clairement, car il implique une contrainte forte : plus aucune page ne reflète l'état de la base de données en temps réel tant que la génération n'a pas été relancée. ## Pourquoi ne pas complexifier le CDN plutôt La configuration existante s'appuyait déjà sur un CDN avec des règles de cache par type de page. Mais chaque affinage supplémentaire — exception pour telle page contenant un formulaire, règle spéciale pour telle section mise à jour plus souvent — ajoutait de la complexité à un système déjà difficile à auditer entièrement en cas d'incident. L'équipe a jugé qu'ajouter encore des règles fines, la veille d'un pic critique, augmentait le risque d'erreur au pire moment. La génération statique complète, elle, a l'avantage d'être un mécanisme unique et vérifiable : soit le fichier HTML existe et sert la page telle quelle, soit il n'existe pas et une régénération est déclenchée. Rien entre les deux. ## Mise en œuvre : génération programmée par WP-CLI Un script WP-CLI parcourt l'ensemble des pages publiques du site — informations pistes, hébergements, forfaits, actualités — et enregistre le rendu HTML de chacune dans un répertoire dédié, servi directement par le serveur web sans passer par PHP : > L'essentiel à retenir : Générer tout le site en HTML statique évite la moindre exécution PHP au pic ; Le choix a été préféré à une configuration CDN plus fine, jugée trop fragile à maintenir ; Les pages nécessitant une interaction restent servies dynamiquement à part ``` wp domaine-skiable generer-cache-statique --dossier=/var/www/cache-statique # Dans le script personnalisé : foreach ( $urls_publiques as $url ) { $reponse = wp_remote_get( $url, array( 'timeout' => 30 ) ); $html = wp_remote_retrieve_body( $reponse ); $chemin = domaine_url_vers_chemin_fichier( $url ); file_put_contents( $chemin, $html ); } ``` La configuration du serveur web priorise ensuite le fichier statique s'il existe, et ne retombe sur PHP que pour les chemins absents du cache ou pour les points d'entrée explicitement dynamiques, comme le moteur de réservation lui-même. ## Ce qui reste dynamique par nécessité Le moteur de réservation de forfaits, le compte client et le formulaire de contact restent servis normalement par WordPress, sans passer par la génération statique. Isoler ces points d'entrée a demandé un travail préalable de cartographie des URL du site, pour s'assurer qu'aucune page nécessitant une session utilisateur ne soit accidentellement figée. - Pages figées en statique : informations pistes, tarifs, hébergements, actualités, pages institutionnelles. - Restées dynamiques : moteur de réservation, espace client, formulaire de contact. - Fréquence de régénération : toutes les heures en période creuse, déclenchée manuellement juste avant un pic annoncé. ## Résultats pendant le pic Lors de l'ouverture des réservations de février, le pic de trafic a été absorbé presque entièrement par les pages statiques : 96 % des pages vues n'ont déclenché aucune exécution PHP, seul le passage effectif au moteur de réservation sollicitant le serveur applicatif. Le serveur, dimensionné pour un trafic courant, a tenu la charge sans dégradation perceptible, alors qu'une simulation préalable avec le seul CDN existant laissait apparaître des temps de réponse dégradés au-delà d'un certain seuil de connexions simultanées. > Face à un pic bref et prévisible, un mécanisme simple et vérifiable bat souvent une configuration fine mais fragile. ## Ce que cette approche ne règle pas La billetterie elle-même, avec sa gestion des stocks de forfaits et ses créneaux limités, reste un système à part entière, non couvert par cette génération statique. Sa propre montée en charge relève d'un chantier distinct. ## Notre verdict La génération statique complète n'est pas une solution universelle : elle impose de renoncer, sur les pages concernées, à toute personnalisation en temps réel. Mais pour un site à forte proportion de contenu public et stable, face à un pic de trafic ponctuel et anticipé, elle offre une garantie de robustesse qu'une configuration de cache plus fine, ajoutée dans l'urgence, ne peut pas toujours offrir avec la même certitude.