Optimiser vos modules PrestaShop avec le lazy loading des services Symfony

Introduction

Depuis que PrestaShop repose sur Symfony (à partir de la version 1.7.6 et renforcé dans PrestaShop 8 et 9), nous avons accès à toute la puissance du conteneur de services. Pourtant, beaucoup de développeurs de modules continuent de charger leurs services « en eager »… même quand ceux-ci ne sont presque jamais utilisés.

Le résultat ? Plus de lenteur, plus de mémoire consommée pour rien. La solution : activer le lazy loading des services. Dans cet article, nous allons voir comment cette technique simple peut transformer les performances de vos modules PrestaShop.

Comprendre le lazy loading des services

Qu’est-ce que le lazy loading ?

Le principe est simple :

  • Sans lazy loading → Symfony instancie votre service immédiatement au démarrage
  • Avec lazy loading → Symfony place un proxy. Le service réel n’est créé qu’au premier appel

Pour bien comprendre, imaginons une métaphore : votre service est comme un camion de livraison 🚚.

  • Sans lazy : le camion démarre à chaque requête, même s’il est vide
  • Avec lazy : il ne démarre que quand vous avez effectivement un colis à livrer

Les bénéfices concrets

Cette approche apporte plusieurs avantages :

  • Réduction de la consommation mémoire : seuls les services utilisés sont instanciés
  • Temps de réponse plus rapides : moins d’objets à créer au démarrage
  • Meilleure scalabilité : votre module s’adapte mieux à la charge

Pourquoi c’est particulièrement utile dans PrestaShop

Les modules PrestaShop contiennent souvent des services lourds :

  • Clients API (Stripe, Amazon S3, ChatGPT, etc.)
  • Parsers Excel/CSV pour l’import/export
  • Générateurs PDF pour les factures
  • Clients de cache Redis ou Elasticsearch

Le problème ? La plupart des pages de votre boutique n’ont pas besoin de ces services. Sans lazy loading, vous gaspillez des ressources précieuses. Avec le lazy loading, ces services ne se chargent que quand ils sont réellement nécessaires.

Implémentation pratique dans un module

Exemple d’un service externe lourd

Commençons par créer un service qui simule un client API externe :

// src/Infra/External/ApiClient.php
namespace MyVendor\MyModule\Infra\External;

final class ApiClient 
{
    public function __construct(private string $apiKey) 
    {
        // Simulation d'une initialisation coûteuse
        // (connexion réseau, authentification, etc.)
    }
    
    public function fetchCatalog(): array 
    {
        // Appel API externe pour récupérer un catalogue
        // Opération potentiellement lente
        return [
            ['id' => 1, 'name' => 'Produit 1'],
            ['id' => 2, 'name' => 'Produit 2'],
        ];
    }
}

Configuration des services avec lazy loading

Voici comment configurer ce service dans votre fichier services.yml :

# modules/mymodule/config/services.yml
services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  MyVendor\MyModule\Infra\External\ApiClient:
    arguments:
      $apiKey: '%env(MYMODULE_API_KEY)%'
    lazy: true   # 💡 Le proxy est généré uniquement au besoin

Service applicatif utilisant le client API

Créons maintenant un service qui utilise notre client API :

// src/App/Catalog/SyncCatalog.php
namespace MyVendor\MyModule\App\Catalog;

use MyVendor\MyModule\Infra\External\ApiClient;

class SyncCatalog 
{
    public function __construct(private ApiClient $client) {}
    
    public function __invoke(): int 
    {
        $rows = $this->client->fetchCatalog();
        
        // Logique de synchronisation avec PrestaShop
        // (création/mise à jour des produits)
        
        return \count($rows);
    }
}

Controller Symfony pour déclencher la synchronisation

Enfin, un contrôleur qui utilise notre service :

// src/Ui/Controller/Admin/CatalogController.php
namespace MyVendor\MyModule\Ui\Controller\Admin;

use MyVendor\MyModule\App\Catalog\SyncCatalog;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;

final class CatalogController extends AbstractController 
{
    public function sync(SyncCatalog $useCase): Response 
    {
        // C'est seulement ici que ApiClient sera réellement instancié
        $count = $useCase();
        
        $this->addFlash('success', "$count produits synchronisés !");
        return $this->redirectToRoute('mymodule_catalog_index');
    }
}

Bonnes pratiques et cas d’usage

Quand activer le lazy loading

Le lazy loading est particulièrement bénéfique pour :

  • Clients API externes : Stripe, PayPal, services de livraison
  • Services de traitement lourd : manipulation Excel, génération PDF, traitement d’images
  • Fonctionnalités d’export/import : utilisées rarement mais coûteuses
  • Clients de cache : Redis, Memcached quand ils ne sont pas toujours nécessaires

Quand éviter le lazy loading

À l’inverse, évitez le lazy loading pour :

  • Helpers simples : services légers utilisés partout
  • Services critiques : utilisés dans chaque requête
  • Services de logging : doivent être disponibles immédiatement

Pièges à éviter et bonnes pratiques

Attention aux classes finales

Si votre service est une classe final, Symfony ne peut pas créer de proxy. Préférez une interface :

interface ApiClientInterface 
{
    public function fetchCatalog(): array;
}

final class ApiClient implements ApiClientInterface 
{
    // Implémentation...
}

# Configuration avec interface
services:
  MyVendor\MyModule\Infra\External\ApiClientInterface:
    class: MyVendor\MyModule\Infra\External\ApiClient
    arguments:
      $apiKey: '%env(MYMODULE_API_KEY)%'
    lazy: true

Évitez la sérialisation des proxies

Les proxies lazy ne doivent pas être sérialisés. Si vous devez persister l’état d’un service, extrayez d’abord les données nécessaires.

Testez les performances

Utilisez des outils comme Blackfire ou le profiler Symfony pour mesurer l’impact réel :

# Débugger les services et leurs proxies
bin/console debug:container --show-private

Technique avancée : Service Subscriber

Pour un contrôle encore plus fin, utilisez le pattern ServiceSubscriberInterface :

use Symfony\Contracts\Service\ServiceSubscriberInterface;
use Psr\Container\ContainerInterface;

final class MyController extends AbstractController implements ServiceSubscriberInterface 
{
    public static function getSubscribedServices(): array 
    {
        return [
            'syncCatalog' => SyncCatalog::class,
            'apiClient' => ApiClientInterface::class,
        ];
    }
    
    public function __construct(private ContainerInterface $locator) {}
    
    public function sync(): Response 
    {
        // Le service n'est récupéré que quand on en a besoin
        $useCase = $this->locator->get('syncCatalog');
        $count = $useCase();
        
        $this->addFlash('success', "$count produits synchronisés !");
        return $this->redirectToRoute('mymodule_catalog_index');
    }
}

Mesurer l’impact sur les performances

Pour évaluer l’efficacité du lazy loading dans votre contexte, voici quelques métriques à surveiller :

Mémoire consommée

// Avant et après activation du lazy loading
echo "Mémoire utilisée : " . memory_get_peak_usage(true) / 1024 / 1024 . " MB\n";

Temps de chargement des pages

Utilisez le profiler Symfony ou des outils externes pour mesurer le temps de réponse des pages qui n’utilisent pas vos services lourds.

Conclusion

Le lazy loading des services est un petit réglage de configuration qui peut avoir un impact considérable sur les performances de vos modules PrestaShop :

  • Réduction significative de la consommation mémoire
  • Temps de réponse plus rapides pour les pages non concernées
  • Modules plus scalables et professionnels

La prochaine fois que vous développez un module avec des services lourds, pensez à ajouter cette simple ligne lazy: true dans votre configuration. Vos utilisateurs et votre serveur vous remercieront !

N’hésitez pas à tester cette technique sur vos projets existants et à partager vos résultats avec la communauté PrestaShop.

Article publié le 2 octobre 2025 par Nicolas Dabène - Expert PHP & PrestaShop avec 15+ ans d’expérience