Optimize Your PrestaShop Modules with Symfony Service Lazy Loading

Introduction

Since PrestaShop relies on Symfony (from version 1.7.6 and reinforced in PrestaShop 8 and 9), we have access to the full power of the service container. Yet, many module developers continue to load their services “eagerly”… even when they’re almost never used.

The result? More slowness, more memory consumed for nothing. The solution: enable lazy loading of services. In this article, we’ll see how this simple technique can transform your PrestaShop module performance.

Understanding Service Lazy Loading

What is Lazy Loading?

The principle is simple:

  • Without lazy loading → Symfony instantiates your service immediately at startup
  • With lazy loading → Symfony places a proxy. The actual service is only created on first call

To understand well, let’s imagine a metaphor: your service is like a delivery truck 🚚.

  • Without lazy: the truck starts at every request, even if it’s empty
  • With lazy: it only starts when you actually have a package to deliver

Concrete Benefits

This approach brings several advantages:

  • Reduced memory consumption: only used services are instantiated
  • Faster response times: fewer objects to create at startup
  • Better scalability: your module adapts better to load

Why This is Particularly Useful in PrestaShop

PrestaShop modules often contain heavy services:

  • API clients (Stripe, Amazon S3, ChatGPT, etc.)
  • Excel/CSV parsers for import/export
  • PDF generators for invoices
  • Redis or Elasticsearch cache clients

The problem? Most pages in your store don’t need these services. Without lazy loading, you waste precious resources. With lazy loading, these services only load when actually necessary.

Practical Implementation in a Module

Example of a Heavy External Service

Let’s start by creating a service that simulates an external API client:

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

final class ApiClient
{
    public function __construct(private string $apiKey)
    {
        // Simulation of expensive initialization
        // (network connection, authentication, etc.)
    }

    public function fetchCatalog(): array
    {
        // External API call to retrieve a catalog
        // Potentially slow operation
        return [
            ['id' => 1, 'name' => 'Product 1'],
            ['id' => 2, 'name' => 'Product 2'],
        ];
    }
}

Service Configuration with Lazy Loading

Here’s how to configure this service in your services.yml file:

# 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   # 💡 Proxy is generated only when needed

Application Service Using the API Client

Let’s now create a service that uses our API client:

// 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();

        // Synchronization logic with PrestaShop
        // (product creation/update)

        return \count($rows);
    }
}

Symfony Controller to Trigger Synchronization

Finally, a controller that uses our 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
    {
        // Only here will ApiClient be actually instantiated
        $count = $useCase();

        $this->addFlash('success', "$count products synchronized!");
        return $this->redirectToRoute('mymodule_catalog_index');
    }
}

Best Practices and Use Cases

When to Enable Lazy Loading

Lazy loading is particularly beneficial for:

  • External API clients: Stripe, PayPal, delivery services
  • Heavy processing services: Excel manipulation, PDF generation, image processing
  • Export/import features: rarely used but expensive
  • Cache clients: Redis, Memcached when not always necessary

When to Avoid Lazy Loading

Conversely, avoid lazy loading for:

  • Simple helpers: lightweight services used everywhere
  • Critical services: used in every request
  • Logging services: must be immediately available

Pitfalls to Avoid and Best Practices

Beware of Final Classes

If your service is a final class, Symfony cannot create a proxy. Prefer an interface:

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

final class ApiClient implements ApiClientInterface
{
    // Implementation...
}

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

Avoid Serializing Proxies

Lazy proxies should not be serialized. If you need to persist a service’s state, extract the necessary data first.

Test Performance

Use tools like Blackfire or the Symfony profiler to measure real impact:

# Debug services and their proxies
bin/console debug:container --show-private

Advanced Technique: Service Subscriber

For even finer control, use the ServiceSubscriberInterface pattern:

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
    {
        // Service is only retrieved when needed
        $useCase = $this->locator->get('syncCatalog');
        $count = $useCase();

        $this->addFlash('success', "$count products synchronized!");
        return $this->redirectToRoute('mymodule_catalog_index');
    }
}

Measuring Performance Impact

To evaluate lazy loading effectiveness in your context, here are some metrics to monitor:

Memory Consumed

// Before and after lazy loading activation
echo "Memory used: " . memory_get_peak_usage(true) / 1024 / 1024 . " MB\n";

Page Loading Times

Use the Symfony profiler or external tools to measure response time for pages that don’t use your heavy services.

Conclusion

Service lazy loading is a small configuration tweak that can have a considerable impact on your PrestaShop module performance:

  • Significant reduction in memory consumption
  • Faster response times for unaffected pages
  • More scalable and professional modules

Next time you develop a module with heavy services, think about adding that simple lazy: true line in your configuration. Your users and your server will thank you!

Don’t hesitate to test this technique on your existing projects and share your results with the PrestaShop community.

Article published on October 2, 2025 by Nicolas Dabène - PHP & PrestaShop Expert with 15+ years of experience