Quarante mégaoctets de mémoire PHP en plus par requête : c’est l’écart mesuré avec memory_get_peak_usage() entre l’ancien thème, qui affichait ses contenus avec des appels PHP classiques dans des fichiers .php, et le même site après adoption de Timber pour structurer ses gabarits avec Twig. Sur un serveur dédié, cette différence passe souvent inaperçue. Sur un mutualisé dont le plafond mémoire par processus PHP est fixé bas par l’hébergeur, elle peut suffire à déclencher des erreurs de dépassement.
Timber, la bibliothèque qui permet d’écrire les gabarits WordPress en Twig plutôt qu’en PHP mêlé de HTML, apporte un vrai bénéfice de lisibilité et de séparation entre logique et présentation. Ce bénéfice a cependant un coût d’exécution réel, qu’il vaut mieux connaître avant de l’adopter sur une infrastructure aux ressources comptées.
Ce que Twig fait réellement à l’exécution
Twig ne se contente pas d’interpréter un gabarit ligne par ligne à chaque requête. Il le compile d’abord en une classe PHP native, mise en cache sur disque, puis exécute cette classe compilée. La première visite après une modification d’un gabarit déclenche donc une phase de compilation, plus coûteuse en mémoire et en temps CPU que les visites suivantes qui réutilisent le fichier compilé déjà présent sur disque.
$twig = new \Twig\Environment( $loader, [
'cache' => WP_CONTENT_DIR . '/cache/twig',
'debug' => WP_DEBUG,
]);
Sur un mutualisé, ce dossier de cache doit être surveillé au même titre que n’importe quel autre cache disque : il grossit avec chaque variante de gabarit rencontrée, et un quota d’espace disque serré peut se retrouver saturé par des fichiers de compilation Twig accumulés sans jamais être purgés.
Où part réellement la mémoire supplémentaire
La consommation mémoire additionnelle observée avec Timber ne vient pas uniquement de Twig, mais aussi de la couche d’objets que Timber construit autour des données WordPress. Une boucle de gabarit qui affiche une liste d’articles instancie, pour chaque article, un objet Timber\Post complet, avec ses méthodes d’accès aux champs personnalisés, ses relations et son cache interne, là où un thème classique se contentait d’un objet WP_Post plus léger manipulé directement.
$posts = Timber::get_posts([
'post_type' => 'article',
'posts_per_page' => 50,
]);
// Chaque élément de $posts est un objet Timber\Post,
// plus lourd qu'un simple WP_Post.
Sur une page qui affiche cinquante articles en boucle, comme une page d’archive complète, cette différence de poids par objet se multiplie et peut représenter l’essentiel de l’écart mesuré.
Réduire le coût sans abandonner Twig
La correction retenue n’a pas été de renoncer à Timber, dont les bénéfices de maintenabilité restaient réels pour l’équipe, mais de réduire la taille des boucles et de limiter les champs chargés à ceux réellement affichés :
- pagination plus agressive des archives, avec des lots de dix articles plutôt que cinquante ;
- utilisation de
Timber::get_posts()avec un tableau de champs restreints plutôt que le chargement systématique de l’objet complet ; - purge régulière du dossier de cache Twig via une tâche cron, plutôt qu’une accumulation indéfinie.
Adapter le plafond mémoire, en dernier recours
Sur ce mutualisé, une marge de manœuvre existait aussi du côté de la configuration PHP elle-même, avec une élévation ciblée de memory_limit dans un fichier .user.ini propre au site concerné, sans affecter les autres sites du même serveur :
memory_limit = 192M
Cette solution reste un correctif, pas une réponse au problème de fond : augmenter la limite mémoire masque un coût réel plutôt que de le réduire, et un mutualisé qui plafonne ce paramètre par contrat ne laisse d’ailleurs pas toujours cette possibilité.
Un moteur de gabarits plus expressif se paie toujours quelque part : en mémoire, en temps de compilation, ou en espace disque de cache. Le choisir sans le mesurer revient à découvrir la facture après coup.
Mesurer avant d’adopter, pas après
La leçon retenue par l’équipe n’a pas été de conclure que Timber convient mal à un mutualisé en général, mais qu’un changement de moteur de rendu mérite une mesure préalable sur un environnement représentatif des contraintes réelles de production, avec les mêmes plafonds de mémoire et d’espace disque que ceux fixés par l’hébergeur final. Cette mesure aurait permis d’anticiper l’ajustement du plafond mémoire avant la mise en production, plutôt que de le découvrir via des erreurs remontées par les visiteurs.
Ce qu’on retient
Timber et Twig apportent un vrai gain de lisibilité pour une équipe qui maintient des gabarits complexes, mais ce gain a un coût mesurable en mémoire et en usage disque qu’un mutualisé aux plafonds serrés révèle plus vite qu’un serveur dédié généreux. Adopter ce type d’outil sur ce genre d’infrastructure suppose de mesurer le coût réel avant la mise en production, et de limiter la taille des boucles de gabarits plutôt que de compter sur une simple élévation du plafond mémoire.
