Direkt zum Hauptinhalt

Performance-Tipps

Ein Overlay läuft als Chromium-Instanz innerhalb von OBS. Wenn die CPU- oder GPU-Last steigt, ist das Overlay oft mit Schuld - aber meistens lässt sich das mit ein paar Settings runterdrücken.

CPU vs. GPU

Im Windows-Task-Manager (nicht der OBS-eigene Log-Viewer): die obs-browser-page.exe ist die Browser-Quelle. Wenn die konstant > 15 % CPU braucht, ist etwas im Overlay teurer als nötig.

Hardware-Beschleunigung an lassen

Wenn dein System nicht flackert (siehe BrowserSource flackert), Hardware-Beschleunigung an lassen. Das verschiebt das Compositing von CPU auf GPU. Moderne GPUs schaffen ein Overlay nebenher locker - die CPU dankt es dir.

Anzahl Browser-Quellen reduzieren

Jede zusätzliche Browser-Source ist ein eigener Chromium-Prozess mit eigenem Speicher und eigenem Render-Loop. Faustregel:

SetupOK?
Eine Browser-Source pro Szene mit allen Widgetsja
Eine Browser-Source pro Widget (Alerts, Chat, Counter separat)nein, lieber zusammenfassen
Eine "Globale" Browser-Source die in mehreren Szenen referenziert wirdja, OBS macht das richtig
Einzelnes Widget gezielt als Single-Element-URL (/overlay/element) ausgelagertnur wenn es einen konkreten Grund gibt (z. B. separates Layering in einer Szene), nicht als Standard

Im Pro Editor und im Builder kannst du beliebig viele Widgets in ein Overlay packen. Das ist praktisch immer effizienter als mehrere Overlays parallel. Details zu den Editoren: Overlay Pro Editor vs Builder, zur Single-Element-URL: Browser Source Grundlagen.

Animationen sparsam einsetzen

Die Widget-Paletten in Builder und Pro Editor haben Alert-Animationen, Hype-Train-Effekte, Konfetti. Schön, aber:

  • Konstant laufende Animationen (Hintergrund-Loops, Partikel) sind teuer.
  • Alerts und Hype-Train sind nur während des Events animiert - das ist fast immer unkritisch.
  • Eigene Background-Loops (z. B. ein animiertes GIF als Box-Background) belasten konstant.

Mehr zu den einzelnen Widget-Typen: Overlay Builder → Wichtige Widgets.

Bilder vorab optimieren

Wenn du PNGs hochlädst (Logo, Cam-Frame, Avatar): vorher auf Stream-Auflösung skalieren. Ein 4096×4096-Logo als 200×200-Element gerendert verschwendet Speicher. Tools wie squoosh.app oder tinypng.com reichen.

Chat-Box mit Limit

Das Chat-Widget hat eine Einstellung « Max Nachrichten » (intern max_messages). Standard ist 50. Höher (z. B. 200) heißt: bei Spike-Traffic muss der Browser 200 DOM-Knoten rendern und im Layout halten. Auf schwachen Systemen oder bei sehr aktivem Chat ggf. auf 20-30 runter - das kostet dich keine Nachrichten aus dem echten Chat, es limitiert nur, wie viele gleichzeitig im Overlay sichtbar bleiben.

Refresh wenn nötig

Langläufer-Streams (12+ h): einmal pro Stream-Pause die Browser-Source per Refresh cache of current page neu laden. Browser-Memory-Leaks gibt's immer, das ist Standard-Chromium-Verhalten und kein Chatlix-Bug.

Debug-Modus

Anders als man vermuten könnte, ist der Debug-Modus kein Schalter im Editor, sondern ein Query-Parameter direkt in der Browser-Source-URL: häng &debug=1 an. Das zeigt oben links ein Banner mit canvas (Layout-Sollgröße), viewport (tatsächliche OBS-Größe) und scale (Verhältnis der beiden) - gedacht, um "Editor sieht anders aus als OBS"-Probleme zu diagnostizieren, siehe Empfohlene Settings. Es ist kein FPS-Zähler und keine generelle Performance-Anzeige. Das Banner verschwindet nach 30 Sekunden von selbst, kostet also im Normalbetrieb nichts - für einen echten CPU/GPU-Lasttest ist trotzdem der Windows-Task-Manager (siehe oben) die verlässlichere Quelle, nicht dieses Banner. Entferne &debug=1 wieder aus der URL, wenn du fertig getestet hast, damit es beim nächsten Szenen-Wechsel nicht unnötig neu aufploppt.

Weiterführend