DevCore.net

WebP: Das unterschätzte Bildformat

Das Problem: WebP spart ~30% Bandwidth gegenüber JPEG, sitzt aber auf der Sideline.

Warum nicht mehr Websites WebP nutzen:

1. Unwissenheit – Viele kennen WebP gar nicht
2. Kompatibilität-Angst – "Was wenn alte Browser nicht unterstützen?" (Fallback ist einfach!)
3. Workflow-Trägheit – Bestehendes Tooling müsste angepasst werden
4. 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.

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!

Formularverarbeitung mit Array-Namen vereinfachen

Komplizierte Formularverarbeitung? Nutze HTML-Arrays!

<!-- HTML -->
<input name="user[name]">
<input name="user[email]">
<input name="product[sku][]">
<input name="product[sku][]">

// PHP - automatisch strukturiert!
$_POST['user']['name']        // "John"
$_POST['user']['email']       // "john@test.de"
$_POST['product']['sku'][0]   // "SKU123"
$_POST['product']['sku'][1]   // "SKU456"

Vorteil: Automatische Strukturierung, kein manuelles Parsing, weniger Code.

Gold-Regel: Immer $_POST validieren bevor du es nutzt!

JSON direkt in MySQL: Flexibilität trifft Datenbank

MySQL hat Superkräfte mit JSON! Statt mühsame Normalisierung brauchst du nur:

-- Speichern
INSERT INTO users (profile) VALUES ('{"name":"John","age":30}');

-- Abfragen
SELECT profile->>'$.name' AS name FROM users;

-- Suchen
SELECT JSON_SEARCH(profile, 'one', 'John') FROM users;

-- Aktualisieren
UPDATE users SET profile = JSON_SET(profile, '$.age', 31) WHERE id = 1;

Vorteile: Kein Schema-Overhead, direkter Zugriff auf verschachtelte Daten, perfekt für halbstrukturierte Daten.

Tipp: Indexiere JSON-Pfade mit GENERATED COLUMNS für bessere Performance!

Hinweis zu MariaDB

⚠️ Achtung: Die moderne JSON-Syntax (-> und ->>) funktioniert in MariaDB noch nicht. Verwende stattdessen JSON_VALUE() für einen ähnlichen Effekt:

-- MariaDB: statt ->>
SELECT JSON_VALUE(profile, '$.name') AS name FROM users;

JSON_VALUE() ist zukunftssicher und wird auch in neueren MySQL-Versionen unterstützt.

Speicher sparen mit COMPRESS() und UNCOMPRESS()

Große Log-Dateien fressen Speicherkontingent? COMPRESS() ist dein Freund!

-- Speichern (komprimieren)
INSERT INTO logs (content) VALUES (COMPRESS('großer text hier...'));

-- Auslesen (dekomprimieren)
SELECT UNCOMPRESS(content) FROM logs WHERE id = 1;

Die Magie: zlib-Komprimierung reduziert Textdaten auf 20-30% der ursprünglichen Größe.

Idealfall: Logs, alte Artikel, Backup-Metadaten.

Achtung: Die CPU-Kosten für Komprimierung/Dekomprimierung lohnen sich vor allem bei größeren Datenmengen – bei kleinen Texten überwiegt der Overhead!