PERFORMANCE

Early Hints: Kritische Assets vor der eigentlichen Antwort laden

103 Early Hints ist ein HTTP-Status, mit dem der Server dem Browser schon vor der eigentlichen Response wichtige Hinweise schicken kann, z. B. welche CSS- oder Font-Dateien direkt geladen werden sollen.

HTTP/1.1 103 Early Hints
Link: </assets/css/main.css>; rel=preload; as=style
Link: </assets/fonts/ibm-plex-sans.woff2>; rel=preload; as=font; type="font/woff2"; crossorigin

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Wo hilft das? Vor allem bei SSR, langsamen Datenbankabfragen oder generell hohem TTFB. Der Browser kann kritische Assets schon anfordern, während das Backend noch an der finalen HTML-Antwort arbeitet.

Wichtig: Early Hints bringt vor allem etwas für Assets, die du sehr sicher brauchst. Für wechselnde oder unklare Ressourcen ist der Effekt gering oder du preloadest unnötig.

performance dev-tricks

Server-Timing: Performance-Daten direkt in den DevTools

Mit dem Server-Timing HTTP-Header verschickst du Performance-Metriken direkt an den Browser. Diese tauchen sofort im DevTools unter Network → Timings auf.

Format:

Server-Timing: db;dur=123;desc="Query"

In PHP:

$start = microtime(true);
// ... Datenbankabfrage oder andere Operation ...
$duration = (microtime(true) - $start) * 1000; // Dauer
header("Server-Timing: db;dur=$duration;desc=\"Database\"", true);

Live Demo: https://server-timing-hono.deno.dev/ – öffne DevTools, schau in Network → Timing

php performance dev-tricks

Große Datenmengen in PHP: Speicher sparen mit Generatoren

Statt erst ein riesiges Array aufzubauen, kannst du Werte mit yield einzeln erzeugen und direkt weiterverarbeiten.

function userIds(PDO $db): Generator {
    $stmt = $db->query('SELECT id FROM users');

    while (($id = $stmt->fetchColumn()) !== false) {
        yield (int) $id;
    }
}

foreach (userIds($db) as $id) {
    processUser($id);
}

Ohne Generatoren landet oft alles zuerst in einem Array, etwa per fetchAll() oder durch manuelles Sammeln. Das kostet bei vielen Datensätzen schnell unnötig viel RAM.

Vorteile: Weniger Speicherverbrauch, schnellerer Start der Verarbeitung, sauberere Trennung zwischen Datenquelle und Verarbeitung.

Wichtig: Generatoren sind ideal für sequentielle Verarbeitung. Wenn du alle Werte mehrfach brauchst oder zufällig darauf zugreifen willst, ist ein echtes Array oft immer noch die richtige Wahl.

php performance resource-saving

VIRTUAL Columns in MySQL: Berechnete Spalten ohne Speicher

Statt berechnete Werte im Code vorzubereiten oder redundant in der DB zu speichern, übernimmt MariaDB/MySQL das selbst:

-- Nachträglich zu einer bestehenden Tabelle hinzufügen
ALTER TABLE orders
  ADD COLUMN gross DECIMAL(10,2) AS (net * (1 + tax_rate)) VIRTUAL;

VIRTUAL bedeutet: kein eigener Speicherplatz – der Wert wird beim Lesen berechnet. Die Alternative STORED schreibt ihn physisch in die Tabelle.

Vorteil: Kein Trigger, kein App-Code, keine Synchronisations-Fehler – die Spalte ist immer korrekt.

Index: Nutzt du die VIRTUAL Column in einer WHERE-Bedingung, lohnt sich ein Index darauf – sonst muss MariaDB/MySQL den Ausdruck für jede Zeile im Scan berechnen:

ALTER TABLE orders ADD INDEX idx_gross (gross);

Der Unterschied ist dramatisch: Abfragen auf großen Tabellen fallen damit von mehreren Sekunden auf wenige Millisekunden – bei mir von 4 Sekunden auf 80 ms. Verwendest du die Spalte hingegen nur im SELECT, ist kein Index nötig: Der Ausdruck wird erst nach dem Filtern berechnet, also nur für die Zeilen, die bereits alle anderen Bedingungen passiert haben.

sql performance simplify

Eleventy: schlankes SSG bei voller Kontrolle

Eleventy ist das perfekte SSG, wenn du mit Markdown, Nunjucks oder HTML schreiben willst und dir der Build nicht im Weg stehen soll. Du legst ein paar Markdown-Dateien, packst deine Assets daneben und lässt Eleventy rendern. Layouts oder Includes kannst du dazuschalten, aber sie sind optional der ganze Ablauf bleibt minimal.

Probiere es in 2 Schritten aus:

echo "Hello World" > index.md

npx @11ty/eleventy

ssg simplify performance

WebP: Das unterschätzte Bildformat

Das Problem: WebP spart ~30% Bandbreite gegenüber JPEG, findet aber wenig Anwendung.

Warum nicht mehr Websites WebP nutzen:

Unwissenheit – Viele kennen WebP gar nicht
Kompatibilität-Angst – "Was wenn alte Browser nicht unterstützen?" (Fallback ist einfach!)
Workflow-Trägheit – Bestehendes Tooling müsste angepasst werden
Wahrnehmung – Mythos: PNG/JPEG hätten bessere Qualität (stimmt nicht!)

<!-- So easy: Fallback für alte Browser -->
<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Fallback">
</picture>

Browser-Support: 97%+ der modernen Browser. Kein Grund mehr zu warten!

Meine Faustregel: WebP für neue Projekte, schrittweise Migration für bestehende.

html ssg performance

If-Bedingungen optimieren: Richtige Reihenfolge spart Zeit

Die Idee: Wenn du mehrere Bedingungen mit || kombiniertst, stoppt PHP sobald eine wahr ist (Short-Circuit-Evaluation). Ordne deine Checks strategisch:

// ❌ Schlecht: Teure DB-Abfrage zuerst
if ($this->expensiveDbQuery() || $variable === '123') { }

// ✅ Gut: Schnelle Variablenprüfung zuerst
if ($variable === '123' || $this->expensiveDbQuery()) { }

Erspart dir eine ganze DB-Abfrage, wenn die erste Bedingung passt. Mit && funktioniert es genauso – auch hier sollten billige Checks zuerst kommen.

Faustregel: Billige Operationen zuerst, teure Operationen zuletzt – das gilt für beide || und &&. So einfach ist Leistungsoptimierung!

php performance