Kapitel 45 cachte einen BERECHNETEN Wert INNERHALB von PHP – jetzt gehen wir eine Ebene HÖHER: die GESAMTE HTTP-Response cachen, sodass manche Anfragen PHP GAR NICHT mehr erreichen.

Der Cache-Control-Header

JEDE HTTP-Response KANN einen Cache-Control-Header tragen, der Browsern UND zwischengeschalteten Proxies mitteilt, OB und WIE LANGE die Antwort gecached werden darf:

use Symfony\Component\HttpFoundation\Response;

#[Route('/projects/{id}', name: 'project_show', requirements: ['id' => '\d+'])]
public function show(int $id, ProjectRepository $projectRepository): Response
{
    $projekt = $projectRepository->find($id);

    $response = $this->render('project/show.html.twig', ['projekt' => $projekt]);
    $response->setPublic();
    $response->setMaxAge(60);

    return $response;
}

setPublic() erlaubt das Cachen NICHT NUR im Browser, sondern auch in GEMEINSAM genutzten Caches (Reverse Proxies, CDNs) – Standard ist private (NUR der individuelle Browser darf cachen). setMaxAge(60) erlaubt Caching für 60 Sekunden.

Symfonys eingebauter HTTP-Cache

Für lokale Entwicklung/kleine Deployments bringt Symfony einen EINGEBAUTEN Reverse-Proxy in PHP mit – KEIN separater Infrastruktur-Baustein nötig:

// Ausschnitt, NUR relevant für Kapitel 46 - normalerweise unverändert
use Symfony\Component\HttpKernel\HttpCache\HttpCache;

$kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);

if ('prod' === $_SERVER['APP_ENV']) {
    $kernel = new HttpCache($kernel);
}

$response = $kernel->handle(Request::createFromGlobals());
$response->send();
$kernel->terminate($request, $response);

HttpCache UMHÜLLT den eigentlichen Kernel – Anfragen, für die eine GÜLTIGE gecachte Response existiert, werden bereits HIER beantwortet, OHNE dass der restliche Symfony-Code (Routing, Controller, Doctrine) überhaupt ausgeführt wird.

Für echte Produktion: Varnish oder Nginx

Symfonys PHP-basierter HTTP-Cache ist praktisch für den Einstieg, aber ECHTE Hochlast-Produktionssysteme setzen typischerweise auf einen DEDIZIERTEN Reverse Proxy wie Varnish oder Nginx – VOR PHP geschaltet, beantwortet er gecachte Anfragen, OHNE dass überhaupt ein PHP-Prozess gestartet werden muss (deutlich schneller als selbst der schnellste PHP-Code).

ESI: teilweise dynamische Seiten cachen

Was, wenn NUR ein TEIL einer Seite gecacht werden soll (z. B. die statische Projektbeschreibung), ein ANDERER Teil aber IMMER nutzerspezifisch bleiben muss (z. B. "Angemeldet als ...")? Edge Side Includes (ESI) lösen das:

{% render_esi controller('App\\Controller\\NavigationController::benutzerBox') %}

Der EINGEBETTETE Teil wird als EIGENE Sub-Anfrage behandelt, mit EIGENEM Cache-Control-Header – die restliche Seite kann öffentlich gecacht werden, während GENAU dieser eine Baustein NIE gecacht wird. Ein fortgeschrittenes Werkzeug, dessen vollständige Einrichtung (ESI-fähiger Reverse Proxy) über den Rahmen dieser Schulung hinausgeht.