Skip to main content
Beim Start von Laravel werden registrierte Service Provider auch dann geladen, wenn deren Funktionalität während einer Anfrage nie genutzt wird. Deferred Service Provider lösen dieses Problem, indem sie das Laden bis zur tatsächlichen Nutzung des Services aufschieben.
Diese Seite setzt Wissen aus Grundlagen der Paketentwicklung voraus. Es empfiehlt sich, zunächst die grundlegende Funktionsweise von Service Providern zu verstehen.

Warum Deferred Provider nötig sind

Ein gewöhnlicher Service Provider ruft bei jeder Anfrage register() und boot() auf. Es ist Verschwendung, Funktionen wie Mail-Versand, Queue oder Cache jedes Mal zu initialisieren, obwohl sie auf vielen Seiten gar nicht gebraucht werden.
Wenn Sie diesen Provider deferren, wird er nur bei Anfragen initialisiert, die tatsächlich einen Report erzeugen.

Das Interface DeferrableProvider

Illuminate\Contracts\Support\DeferrableProvider ist ein schlichtes Interface mit einer einzigen Methode provides().
Sobald Sie dieses Interface implementieren, arbeitet Ihr Provider im Deferred-Modus.

Grundlegende Implementierung

Die Implementierung erfolgt in drei Schritten.
1

DeferrableProvider implementieren

2

Services in register() binden

Bindungen tragen Sie wie in einem normalen Provider in register() ein.
3

Aus provides() die registrierten Services zurückgeben

provides() muss alle Services zurückgeben, die Sie in register() gebunden haben. Laravel bestimmt anhand dieser Liste, „bei welchem Service dieser Provider zu laden ist”.

Funktionsweise des Service-Manifests

Beim Start erzeugt Laravel eine Manifest-Datei bootstrap/cache/services.php. Dort ist die Liste der Services aller Deferred Provider hinterlegt.
Anhand dieses Manifests weiß Laravel, „welcher Provider einen Service anbietet”, ohne die Dateien selbst zu laden. Der tatsächliche Provider wird erst dann geladen, wenn der Service zum ersten Mal aufgelöst wird.
Nach dem Hinzufügen oder Ändern eines Providers regenerieren Sie das Manifest.

Ablauf der internen Verarbeitung


Bedeutung der Methode provides()

Vergessen Sie einen Eintrag in provides(), wird der betroffene Service nie aufgelöst.
Auch wenn Sie die Properties $bindings / $singletons verwenden, listen Sie sie in provides() auf.

Grenzen von Deferred Providern

Deferred Provider eignen sich für Provider, die ausschließlich Bindings im Container registrieren. Provider, die in boot() z. B. Folgendes machen, dürfen nicht deferred werden.
Sie dürfen bei Deferred Providern zwar eine boot()-Methode schreiben, aber deren Inhalt läuft erst, wenn der Service aufgelöst wird. Erledigen Sie in boot() „stets erforderliche” Aufgaben wie Routen oder Middleware, kommt es zu unerwartetem Verhalten.

when() — Registrierung per Event-Trigger

Mit der Methode when() können Sie den Provider laden lassen, sobald ein bestimmtes Event feuert. Praktisch für Provider, die nur in bestimmten Kontexten (z. B. Job-Verarbeitung) benötigt werden.
Feuert eines der zurückgegebenen Events, wird der Provider geladen — auch wenn der Service noch nicht aufgelöst wurde.

Nutzen in der Paketentwicklung

Auch bei Drittanbieter-Paketen tragen Deferred Provider zur Performance der Nutzer-Anwendung bei.

Empfohlenes Muster

mergeConfigFrom() prüft intern, ob die Konfiguration gecacht ist. Der Aufruf innerhalb von register() eines Deferred Providers ist daher sicher. Bei gecachter Konfiguration passiert allerdings nichts.

Artisan-Commands mit runningInConsole() abtrennen

Command-Registrierung ist nur beim Artisan-Start nötig — trennen Sie sie mit runningInConsole(). Wenn Sie einen Provider deferren, der Commands anbietet, listen Sie die Command-Klassen auch in provides() oder stellen Sie einen separaten Command-Provider bereit.

Verwendung im Laravel-Kern

Viele der Kern-Provider von Laravel sind Deferred Provider. So werden Services, die nicht bei jedem Request gebraucht werden, nicht sofort geladen. In reinen API-Anwendungen kommt es vor, dass MailServiceProvider oder BroadcastServiceProvider während eines Requests nie geladen werden.

Entscheidungskriterien für Deferring

  • Services, die nicht in jedem Request genutzt werden (Mail, Reports, externe API-Clients)
  • Services, deren Initialisierung externe Verbindungen oder Dateizugriffe erfordert
  • Services mit schweren Objekt-Graphen
  • Provider, die nur in der CLI verwendete Commands liefern
  • Provider, die Routen registrieren (loadRoutesFrom usw.)
  • Provider, die dauerhaft aktive Middleware oder Exception-Handler registrieren
  • Provider, die globale Eloquent-Scopes oder Observer registrieren
  • Leichte Services, die in den meisten Requests genutzt werden (Overhead des Deferrings überwiegt)

Verwandte Seiten

Grundlagen der Paketentwicklung

Erläutert die Entwicklung von Laravel-Paketen rund um Service Provider.

Versionskompatibilität von Paketen verwalten

Erläutert Wartungsstrategien für Pakete bei Major-Upgrades von Laravel und PHP.
Zuletzt geändert am 13. Juli 2026