PHP ohne Framework: Warum unsere Apps schneller sind

Laravel kostet Sie 2.400 EUR/Jahr an Hosting-Kosten – und das ist nur der Anfang. Nach 25 Jahren PHP-Entwicklung kann ich sagen: Framework-freie Apps sind oft schneller, günstiger und langlebiger. Hier sind die Zahlen.

TL;DR – Die Kernpunkte

• Performance: 5–15 ms Median vs. 80–150 ms mit Framework-Overhead → 1 Server statt 3
• Architektur: DDD + PSR-Standards statt Vendor-Ordner-Diktat → Wartbar nach 15 Jahren
• Hosting: 2.400€/Jahr gespart (Real-World-Projekt mit 15.000 Usern)

Was bedeutet “framework-frei” konkret?

Nicht: Alles von Grund auf neu schreiben Sondern: Gezielt Composer-Packages nutzen, aber die Architektur selbst bestimmen

Der Unterschied in Zahlen:

Framework-freie App:

• ~15 gut gewählte Composer-Packages
• 150 Zeilen eigener Router-Code
• Volle Kontrolle über Performance & Security
• PHP-Version-Upgrades: 2-8h Aufwand

Laravel-App:

• 187+ Dependencies (incl. Transitive)
• Framework diktiert Architektur (MVC)
• Migrationen bei jedem Major-Release (Laravel 6 → 11 = 6 Breaking-Change-Zyklen)
• Framework-Upgrades: 20-60h Aufwand pro Major-Version

Wichtig: Ich arbeite mit PSR-Standards, nicht willkürlich. PSR-1/12 (Coding), PSR-7/17 (HTTP), Psalm/PhpStan Level 7+, Rector für automatisierte PHP-Upgrades.

Das Framework-Paradoxon

Frameworks versprechen Geschwindigkeit, Struktur und “Best Practices”. In der Realität bringen sie oft:

• Overhead: 80% der Framework-Features werden nie genutzt
• Update-Treadmill: Laravel 6 → 7 → 8 → 9 → 10… Jedes Major-Release bedeutet potenzielle Breaking Changes
• Performance-Kosten: Jeder Request durchläuft hunderte Dateien, bevor Ihre Logik überhaupt startet
• Vendor Lock-in: Ihre Architektur wird vom Framework diktiert, nicht von Ihren Geschäftsprozessen

Wann macht framework-freie Entwicklung Sinn?

✅ Perfekt für:

Business-Apps mit klarer Domäne Controlling-Systeme, Wächterkontrolle, Führerschein-Management – diese Apps haben klar definierte Prozesse. Sie brauchen keine Blog-Engine oder Social-Media-Features. Sie brauchen:

• Schnelle Datenverarbeitung
• Zuverlässige Background-Jobs
• Integration in bestehende Systeme
• Volle Kontrolle über Security

Langlebige Systeme Meine ältesten Produktiv-Apps laufen seit 15+ Jahren. Warum? Weil sie nicht von Framework-Releases abhängig sind. PHP 7.4 → 8.0 → 8.1 → 8.2 – alles ohne Code-Änderungen (vereinzelte Deprecations/Warnungen ausgenommen).

Performance-kritische Anwendungen Ein Framework-freies REST-API antwortet in 5-15ms. Mit Laravel? Gerne 80-150ms. Bei 10.000 Requests/Stunde macht das den Unterschied zwischen einem Server und fünf Servern.

Individualisierte Architektur Wenn Ihre Geschäftsprozesse nicht in MVC passen – und seien wir ehrlich, die wenigsten tun das wirklich –, kämpfen Sie gegen das Framework statt mit ihm zu arbeiten.

❌ Weniger geeignet für:

• Standard-CRUD-Apps: Wenn Sie nur ein Admin-Panel für eine Datenbank brauchen, nutzen Sie ein Framework
• Content-Management: Für Blogs, Marketing-Sites etc. gibt es bessere Tools (WordPress, Statamic, etc.)
• Teams ohne Senior-Entwickler: Framework-freie Entwicklung erfordert Erfahrung und Disziplin
• Rapid Prototyping: Für einen 2-Wochen-MVP ist Laravel schneller

📦 Wann Laravel/Symfony doch besser ist

Fairerweise: Es gibt Szenarien, in denen Frameworks die klügere Wahl sind:

• Fachlich dünne CRUD-Backoffices mit viel Boilerplate – Framework-Generatoren sparen Zeit
• Teams > 5 Devs mit gemischter Seniorität → standardisierte Conventions & Developer Experience
• Ecosystem-Features out-of-the-box: Policy/Queue/Observer/Scout – wenn Sie genau diese Features brauchen

Framework-freie Entwicklung ist kein Dogma. Es ist eine bewusste Entscheidung für spezifische Anforderungen.

Mein Standard-Stack im Detail

Composer-Packages (Auszug):

// composer.json
{
  "require": {
    "php": "^8.2",
    // Routing
    "nikic/fast-route": "^1.3",
    // PSR-7/17 HTTP
    "nyholm/psr7": "^1.8",
    "nyholm/psr7-server": "^1.1",
    "psr/http-server-middleware": "^1.0",
    // Database
    "ext-pgsql": "*",
    // Security
    "paragonie/sodium_compat": "^1.20",
    // Validation
    "respect/validation": "^2.2",
    // HTTP Client
    "guzzlehttp/guzzle": "^7.8",
    // Logging
    "monolog/monolog": "^3.5"
  }
}

Das sind ~15 gut gewählte Packages statt 187+ Dependencies bei Laravel – mit voller Kontrolle über Performance und Architektur.

Performance-Vergleich: Zahlen sprechen

Ich habe für einen Kunden eine Führerschein-Kontroll-App entwickelt – 15.000 Mitarbeiter, ~200.000 Prüfvorgänge/Jahr.

Anforderung: REST-API für mobile App + Admin-Interface

Benchmark (identische Funktionalität):

Metrik	Framework-frei	Laravel 10	Faktor
Response Time (Median)	8ms	95ms	11.9x
Memory per Request	2.5 MB	18 MB	7.2x
Requests/Sec (ab_bench)	4.200	580	7.2x
Dependencies	15	187	12.5x
Cold Start Time	45ms	380ms	8.4x

Mess-Setup: PHP 8.2-FPM, opcache aktiv (JIT disabled), gleiche Hardware (4 vCPU, 8GB RAM), identische Endpoints; Median über 10.000 Requests; Cold-Start separat gemessen.

Real-World Impact:

• Hosting: 1 Server statt 3 (2.400€/Jahr gespart)
• Mobile UX: Spürbar schnappiger
• Wartung: Kein “Laravel 11 Migration Project” nötig

Performance-Optimierungen

opcache & Preloading:

; php.ini (Production)
opcache.enable=1
opcache.validate_timestamps=0  ; Keine File-Checks im Live-Betrieb
opcache.preload=/var/www/preload.php  ; Router + Domain-Classes
opcache.preload_user=www-data

Composer Autoloader:

composer dump-autoload --optimize --classmap-authoritative

HTTP-Server-Alternative: RoadRunner oder Swoole bringen weitere +30–60% RPS, falls Ihr Use Case das rechtfertigt (z.B. Websockets, lange Polling-Requests).

Security: Kontrolle statt Konvention

Ein unterschätzter Vorteil: Volle Kontrolle über den Security-Stack.

Beispiel: Session-Management

Laravel nutzt standardmäßig Cookie-basierte Sessions. Für unsere Controlling-Systeme implementiere ich:

// Token-basiert, rotierend, mit Redis
// Krypto-Primitive: libsodium/Paragonie; keine Eigenkrypto.
class SecureSessionHandler implements SessionHandlerInterface {
    private Redis $redis;
    private int $tokenLifetime = 900; // 15min
    private int $maxLifetime = 28800;  // 8h

    public function read($sessionId): string|false {
        // Token-Rotation bei jedem Request
        $newToken = $this->rotateToken($sessionId);

        // Automatisches Logout bei Inaktivität
        if ($this->isExpired($sessionId)) {
            $this->destroy($sessionId);
            return false;
        }

        return $this->redis->get("session:$newToken");
    }

    // ... weitere Methoden
}

Security-Features, die ich standardmäßig implementiere:

• Token-Rotation: Jeder Request bekommt neuen Token
• Device-Fingerprinting: IP + User-Agent + Canvas-Hash
• Rate-Limiting: Pro User, pro IP, pro Endpoint
• SQL-Injection Prevention: PDO Prepared Statements, immer
• XSS-Protection: Context-aware Escaping (HTML, JS, URL, CSS)
• CSRF-Protection: Per-Form-Tokens mit Zeitlimit
• Password-Policy: Argon2id mit konfigurierbarem Aufwand

Security-Leitplanken:

• Secrets & Config: Keine Secrets im Code – env + Secret-Manager; Rotations-Intervall ≤ 90 Tage
• Security-Header: CSP/Frame-Options/Referrer-Policy/HSTS als Middleware; Strict-Transport-Security aktiviert

Mit Laravel müsste ich dafür Packages installieren, konfigurieren, hoffen, dass sie gepflegt werden. Bei mir: 150 Zeilen Code, vollständige Kontrolle.

Architektur: Domain-Driven statt Framework-Driven

Das Problem mit MVC

MVC ist ein Pattern aus den 70ern für Desktop-GUIs. Für moderne Business-Apps oft suboptimal:

Laravel-Struktur:
app/
  Models/        # Anämische Datencontainer
  Controllers/   # Fat Controllers mit Business-Logik
  Views/         # Templates

Das Problem: Geschäftslogik ist über Models und Controllers verstreut. Bei komplexen Domänen wird das schnell chaotisch.

Meine Struktur: Domain-Driven Design (DDD)

src/
  Domain/
    Mitarbeiter/
      Entity/
        Mitarbeiter.php
        Führerschein.php
      Service/
        FührerscheinPrüfung.php
        BenachrichtigungService.php
      Repository/
        MitarbeiterRepository.php
      Exception/
        FührerscheinAbgelaufen.php

  Infrastructure/
    Persistence/
      PostgresAdapter.php
    Http/
      Router.php
      Middleware/

  Application/
    UseCase/
      MitarbeiterAnlegen.php
      FührerscheinPrüfen.php

Vorteile:

1. Geschäftslogik isoliert: Domain-Layer hat keine Abhängigkeiten zu Framework oder Infrastruktur
2. Testbar: Domain-Logik kann ohne Datenbank getestet werden
3. Wartbar: Neue Entwickler finden sich schnell zurecht – die Ordnerstruktur spiegelt die Domäne
4. Erweiterbar: Neue Features = neue Use Cases, bestehende Logik bleibt unangetastet

DDD & Boundaries konkret

Domain-Layer kennt weder HTTP noch SQL – Ports/Adapter kapseln Infrastruktur (PSR-Interfaces).

Beispiel Use Case (6 Zeilen, nur Domain-Calls):

class FührerscheinPrüfenHandler {
    public function handle(FührerscheinPrüfenCommand $cmd): void {
        $mitarbeiter = $this->repo->find($cmd->mitarbeiterId);
        $führerschein = $mitarbeiter->führerschein();

        if ($führerschein->istAbgelaufen()) {
            throw new FührerscheinAbgelaufen($mitarbeiter);
        }

        $this->eventBus->dispatch(new FührerscheinGeprüft($mitarbeiter));
    }
}

Keine SQL-Queries, keine HTTP-Header, keine Framework-Magic. Nur Business-Logik.

Wartbarkeit: Der 10-Jahres-Test

Frage: Wird Ihre App in 10 Jahren noch wartbar sein?

Framework-Szenarien:

Laravel 5 (2015) → Laravel 6 (2019): Breaking Changes → Laravel 7 (2020): Breaking Changes → Laravel 8 (2020): Breaking Changes → Laravel 9 (2022): Breaking Changes → Laravel 10 (2023): Breaking Changes → Laravel 11 (2024): Breaking Changes

Jedes Major-Release: 20-60 Stunden Migration für mittelgroße App (Erfahrungswert aus 5 Laravel-9/10-Projekten, mid-size, 50–150 Routen).

Framework-freie Szenarien:

PHP 5.6 (2014) → PHP 7.0 (2015): Meist kompatibel → PHP 7.4 (2019): Deprecations, aber läuft → PHP 8.0 (2020): Meist kompatibel mit 7.4-Code → PHP 8.2 (2023): Warnings, aber funktioniert

Pro PHP-Version: 2-8 Stunden Anpassungen für mittelgroße App.

Real-World Beispiel:

Ich betreue eine Wächterkontroll-App aus 2009:

• 2009-2015: PHP 5.3, zero changes
• 2015-2020: PHP 7.0, Migrationsaufwand: 4h (E_STRICT Warnings beheben)
• 2020-2024: PHP 8.1, Migrationsaufwand: 6h (Typed Properties hinzufügen)

Gesamt-Migrationsaufwand über 15 Jahre: 10 Stunden

Vergleichbare Laravel-App hätte ~200-400 Stunden benötigt.

”Aber man muss alles selbst bauen!”

Das stimmt – und das ist ein Feature, kein Bug.

Was ich “selbst baue”:

Router (150 Zeilen eigener Code statt 5.000+ in Laravel Router)

// Zero Magic. Was du schreibst, wird ausgeführt.
$router = new Router();
$router->get('/api/mitarbeiter/{id}', MitarbeiterController::class, 'show');
$router->post('/api/führerschein/prüfen', FührerscheinController::class, 'prüfen');

// Vorteil: Keine versteckten Middleware-Chains, kein Route-Caching-Drama
// Nachteil: Keine automatische Middleware-Injection (aber braucht man das?)

Kein Re-Inventing: PSR-7-kompatibel, nur dünne Komposition statt Magic. Funktioniert seit 2015 ohne Breaking Changes.

Query Builder (nutze ich gar nicht) Stattdessen: Plain SQL + PDO

// Kein Query Builder, kein Eloquent – nur SQL + Prepared Statements
$stmt = $pdo->prepare("
    SELECT m.*, f.gültig_bis
    FROM mitarbeiter m
    JOIN führerscheine f ON m.id = f.mitarbeiter_id
    WHERE m.abteilung_id = :abteilung
      AND f.gültig_bis < :stichtag
    ORDER BY f.gültig_bis ASC
");
$stmt->execute([
    'abteilung' => $abteilungId,
    'stichtag' => $stichtag
]);

// Vorteil: EXPLAIN ANALYZE sagt dir exakt, was PostgreSQL tut
// Nachteil: Kein "automatic eager loading" (aber das ist oft ein Bug, nicht ein Feature)

Warum Plain SQL + PDO:

• Volle PostgreSQL-Power: CTEs, Window Functions, GIN/BRIN Indexes, Partial Indexes, Array-Operationen
• Kein Eloquent N+1 Problem: Joins sind explizit, nicht lazy-loaded
• EXPLAIN ANALYZE Pflicht: Queries sind optimierbar, Performance-Regression sofort sichtbar
• Guardrails: SET LOCAL statement_timeout='250ms' verhindert Runaway-Queries
• Keine “Magic”: Was ich schreibe, wird ausgeführt – keine versteckten Subqueries

Was ich nicht selbst baue:

• Mailer: SwiftMailer/Symfony Mailer
• HTTP-Client: Guzzle
• Validation: Respect/Validation
• Logging: Monolog
• Testing: PHPUnit

Strategie: Nutze Composer-Packages für Querschnitts-Concerns, aber kontrolliere die Architektur.

Migration von Framework zu framework-frei?

Nicht empfohlen. Wenn Sie eine funktionierende Laravel-App haben: Lassen Sie sie in Ruhe.

Framework-freie Entwicklung macht Sinn für:

• Neue Projekte mit klarer Domäne
• Langlebige Systeme (10+ Jahre Laufzeit)
• Performance-kritische Apps
• Legacy-Modernisierung (alte App neu schreiben)

Fazit: Wann ist framework-frei die richtige Wahl?

✅ Nutzen Sie framework-freies PHP wenn:

• Sie Senior-Entwickler im Team haben
• Langlebigkeit wichtiger ist als Speed-to-Market
• Performance kritisch ist
• Individuelle Architektur gefordert ist
• Volle Kontrolle über Security benötigt wird
• Wartungsbudget langfristig optimiert werden soll

❌ Nutzen Sie ein Framework wenn:

• Junior-Entwickler die Mehrheit stellen
• Rapid Prototyping gefragt ist
• Standard-CRUD die Hauptanforderung ist
• Community-Packages kritisch sind (Auth, CMS, etc.)
• Team-Erfahrung mit dem Framework vorhanden ist

Mein Angebot

Ich entwickle seit 1998 framework-freie PHP-Apps für Business-Kunden:

• Controlling-Systeme
• Wächterkontrolle
• Führerschein-Management
• Workflow-Portale
• ERP/CRM-Integrationen

Mein Versprechen:

• Performance: < 20ms Response Time
• Langlebigkeit: 10+ Jahre ohne Major-Refactoring
• Security: Production-ready, penetration-tested
• Wartbarkeit: Clean Architecture, testbar, dokumentiert

Kostenlose Erstberatung

Sie überlegen, ob framework-freie Entwicklung für Ihr Projekt sinnvoll ist?

Buchen Sie ein kostenloses 30-Minuten-Gespräch:

→ Termin vereinbaren

Ich analysiere Ihre Anforderungen und gebe Ihnen eine ehrliche Einschätzung – auch wenn die Antwort “Nutzen Sie Laravel” lautet.

---

Über die Autorin: Carola Schulte ist Software-Architektin und entwickelt seit 1998 Business-Apps. Schwerpunkte: PHP/PostgreSQL, Security-by-Design, DSGVO-konforme Systeme. 1,8M+ Lines of Code in Produktion.

Kontakt: 📧 die@entwicklerin.net 🌐 www.entwicklerin.net 📍 Lüneburg & Remote

---

Hat Ihnen dieser Artikel geholfen? Teilen Sie ihn mit Kollegen, die vor ähnlichen Architektur-Entscheidungen stehen.

Weitere Artikel in dieser Serie:

• Controlling-Systeme entwickeln: Von der Idee zum Produktivsystem (erscheint 20.01.2025)
• PostgreSQL Performance-Tuning für Business-Apps (erscheint 03.02.2025)
• Security-by-Design: DSGVO-konforme PHP-Apps (erscheint 17.02.2025)