Framework-Tuning: Next.js 15, Laravel, Symfony & Rust in WSL 2

Hast du schon einmal versucht, mit einem stumpfen Messer Tomaten zu schneiden? Es funktioniert irgendwie, aber es macht keinen Spaß. Genauso fühlt sich Webentwicklung an, wenn die Framework-Performance in WSL 2 zwar läuft, aber noch im "Schongang" konfiguriert ist. In Teil 8 haben wir das Fundament gelegt – jetzt schleifen wir das Messer und holen das Maximum aus Next.js, PHP und Rust heraus.

In Teil 8 haben wir das Fundament gelegt und dem Betriebssystem Beine gemacht. Jetzt schleifen wir das Messer. Wir tauchen tief in die Konfiguration von Next.js 15, Laravel, Symfony und Rust ein. Wir nutzen Tools, die exklusiv unter Linux (und damit in WSL 2) glänzen, und verwandeln deine Umgebung von "ganz okay" in "verdammt schnell".

Next.js 15: Den Turbo zünden (wortwörtlich)

Next.js ist großartig, aber wir kennen alle diese Sekunden des Schweigens, wenn wir npm run dev eingeben. In einer Windows-Umgebung kämpft das Dateisystem oft mit den tausenden kleinen Dateien. In WSL 2 sind wir im Linux-Dateisystem (ext4) zu Hause, aber das reicht noch nicht.

Mit Next.js 15 haben wir Zugriff auf Turbopack.

Warum Turbopack in WSL 2 anders ist

Turbopack ist der in Rust geschriebene Nachfolger von Webpack. Unter reinem Windows gibt es hier oft noch Pfad-Probleme oder Virenscanner, die dazwischenfunken. In WSL 2 läuft Turbopack in seiner natürlichen Umgebung.

Praxis-Tipp: Aktiviere Turbopack nicht nur testweise, sondern mach es zu deinem Standard.

1. Öffne deine package.json.

2. Ändere das Start-Skript:

   bash

   "scripts": {
     "dev": "next dev --turbo"
   }

Der Effekt? Ich habe kürzlich ein Projekt mit über 50 Routen migriert. Der lokale Server-Start ging von 4,5 Sekunden auf 1,2 Sekunden runter. Das klingt nach wenig, aber wenn du das 50 Mal am Tag machst, gewinnst du Lebenszeit zurück.

Wichtig: Solltest du noch eine .babelrc Datei im Projekt haben: Weg damit! Sobald Next.js diese Datei sieht, deaktiviert es den superschnellen SWC-Compiler und fällt auf das langsame Babel zurück. Das ist wie Handbremse fahren.

PHP-Performance: Laravel & Symfony entfesseln

"PHP muss für jeden Request neu starten." Das war gestern. In der modernen PHP-Welt gibt es Technologien, die deine Anwendung dauerhaft im Arbeitsspeicher halten – ähnlich wie einen Node.js-Server. Unter Windows ist die Einrichtung oft ein Krampf aus DLL-Dateien und Pfad-Hacks. In WSL 2 ist es ein Heimspiel.

Laravel Octane: Hochgeschwindigkeits-PHP

Laravel Octane lädt dein Framework einmal in den RAM und bedient Anfragen daraus. Kein Bootstrapping bei jedem Klick.

So installierst du es in WSL 2: Nutze den Swoole Server, da er unter Linux extrem performant ist (besser als RoadRunner in vielen Benchmarks).

# In deinem WSL 2 Terminal
composer require laravel/octane
php artisan octane:install --server=swoole

Wenn du jetzt php artisan octane:start --watch ausführst, wirst du Reaktionszeiten sehen, die du bei PHP nicht für möglich gehalten hättest. Wir sprechen von unter 15ms.

Symfony: Runtime & APCu

Auch Symfony bietet enorme Tuning-Möglichkeiten. Da WSL 2 den Linux-Kernel nutzt, können wir den APCu (User Cache) sehr aggressiv nutzen, ohne Angst vor den typischen Windows-File-Locking-Problemen zu haben.

Frage: Warum ist mein Symfony in WSL 2 trotzdem langsam? Antwort: Oft liegt es am Realpath Cache. Symfony prüft ständig, ob Dateien noch da sind.

Die Lösung: Erhöhe in deiner php.ini (innerhalb von WSL 2) die Puffergrößen massiv.

realpath_cache_size = 4096K
realpath_cache_ttl = 600
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000

Das reduziert die Festplattenzugriffe (I/O) drastisch. Dein Symfony-Projekt "fliegt" jetzt, weil es fast nur noch aus dem RAM operiert.

Rust: Wenn der Linker bremst

Ich liebe Rust. Aber ich hasse das Warten auf cargo build. Besonders frustrierend ist, wenn der Code fertig kompiliert ist, aber der Linker (das Tool, das alles zusammenklebt) noch ewig braucht.

Hier kommt mein absoluter Geheimtipp für Rust-Entwickler in WSL 2: Mold.

Mold – Der Usain Bolt unter den Linkern

Mold ist ein moderner Linker, der multithreaded arbeitet. Er ist so schnell, dass der Link-Vorgang fast unmerklich wird. Unter nativem Windows ist er kaum nutzbar. In WSL 2? Ein Einzeiler.

Ein persönliches Beispiel: An einem trüben Dienstag arbeitete ich an einem CLI-Tool. Jedes kleine cargo run dauerte 8 Sekunden. 7 davon waren Linking. Ich war genervt. Nach der Installation von Mold sank die Zeit auf 1,5 Sekunden. Es fühlte sich an, als hätte ich einen neuen Computer gekauft.

Die Anleitung:

1. Installiere Mold in WSL 2 (Ubuntu/Debian):

   bash

   sudo apt-get update && sudo apt-get install mold clang

2. Konfiguriere dein Projekt: Erstelle eine .cargo/config.toml in deinem Projektordner:

   bash

   [target.x86_64-unknown-linux-gnu]
   linker = "clang"
   rustflags = ["-C", "link-arg=-fuse-ld=mold"]

Probiere es aus. Du wirst den Unterschied nicht nur messen, du wirst ihn fühlen.

Fazit: Es geht um den "Flow"

Warum machen wir uns diese Mühe? Warum reicht "gut genug" nicht aus? Weil langsame Tools uns aus dem "Flow" reißen. Jede Sekunde Wartezeit gibt deinem Gehirn die Chance, abzuschweifen ("Hab ich neue Mails?").

Framework-Tuning in WSL 2 bedeutet, die Fesseln zu lösen.

• Next.js reagiert sofort.

• Laravel/Symfony antworten in Millisekunden.

• Rust baut, bevor du blinzeln kannst.

Du hast jetzt die Werkzeuge. Dein Windows-Rechner ist dank WSL 2 eine High-Performance-Linux-Maschine. Es ist an der Zeit, dass sich deine Projekte auch so anfühlen.