Wie sieht deine Seite auf iPhone SE, iPad und 4K-Monitor aus?
URL einfuegen, "Load" druecken, einen Viewport-Preset aus der Chip-Leiste waehlen (iPhone SE 375x667, iPhone 14 Pro 393x852, iPad 768x1024, Laptop 1280x800, FullHD 1920x1080) oder die zwei Slider ziehen, um jede exakte Pixelgroesse einzustellen (320-2560 breit, 480-1440 hoch). Die Seite rendert in einem iframe mit genau dieser Breite und Hoehe.
Das ist eine browser-gerenderte Vorschau, kein Geraet-Emulator. Die Engine deines Browsers (Chrome, Firefox, Safari) rendert, CSS, Fonts und Layouts verhalten sich also wie auf einem echten Screen dieser Groesse. Du bekommst keine Touch-Events, simulierst kein Handy-RAM-Limit, kannst `window.matchMedia('(hover: none)')` nicht triggern, fuer diese Faelle Chrome-DevTools oder Firefox-Responsive-Mode nutzen.
Ideal zum schnellen Pruefen von Breakpoints im Code-Review, fuer Demos am Kunden mit drei Groessen nebeneinander oder zum Verifizieren, dass der neue Hero im Design-System bei 375 px nicht bricht.
So benutzt du es
- Die volle URL der Seite oben einfuegen (z. B. `https://deine-site.de/landing`). `https://` kannst du weglassen, wir ergaenzen es.
- "Load" klicken oder Enter druecken. Die Seite laedt direkt vom Zielserver in den iframe, ohne Proxy dazwischen.
- Ein Geraet-Preset aus der Chip-Leiste waehlen (iPhone SE / iPhone 14 / iPad / Desktop / FullHD) oder die zwei Slider fuer eine Custom-Groesse nutzen.
- Die aktuellen Dimensionen erscheinen live oben rechts (z. B. `390 x 844`). "Rotate" klicken, um Breite und Hoehe zu tauschen (Hoch- vs Querformat).
- "Refresh" erzwingt einen Reload des iframes (nuetzlich nach einem neuen Build). "Open in new tab" oeffnet die Seite in voller Groesse.
- "Copy link" legt eine Preview-URL mit `?url=...&w=...&h=...` in die Zwischenablage, an einen Kollegen geschickt sieht er exakt dieselbe Vorschau.
- Erscheint die rote Karte "Site blocks embedding", hat der Zielserver `X-Frame-Options: DENY/SAMEORIGIN` oder `Content-Security-Policy: frame-ancestors` gesendet. In einem neuen Tab oeffnen, dort rendert der Browser normal.
Wann das nuetzlich ist
Sieben typische Situationen, in denen ein schneller Responsive-Check besser ist als nach den DevTools zu greifen:
- Review eines neuen Component-PR. Ein Junior pusht einen neuen Hero, du pruefst in 30 Sekunden, ob er auf iPhone SE (das kleinste noch genutzte Phone), iPad und Laptop funktioniert. Kein Repo-Clone noetig.
- Demo am Kunden. Zoom-Call, du oeffnest drei Tabs dieses Tools mit unterschiedlichen Presets und zeigst die gleiche Seite auf Desktop, Tablet und Handy gleichzeitig. Der Kunde sieht, dass alles funktioniert.
- QA-Bug-Repro. Ein Tester meldet "das Menue bricht bei 412 px Breite". Du stellst genau 412 am Slider ein, reproduzierst den Bug, machst einen Screenshot, haengst ihn ans Jira-Ticket.
- Wettbewerb pruefen. Ein Designer will sehen, wie eine Wettbewerber-Seite auf 4K (1920x1080) und auf einem Galaxy S22 (360x800) aussieht. URL einfuegen, Preset klicken, fertig.
- Validierung einer Landingpage vor einer Google-Ads-Kampagne. Die Ad-Freigabe verlangt "mobile-friendly". Du verifizierst bei 375 px, dass der CTA ohne Scrollen sichtbar ist und Fonts nicht kleiner als 16 px sind.
- Eine Seite aus der Handy-Sicht pruefen, waehrend du am Rechner sitzt. Die 375x667-Vorschau ohne Handy in die Hand zu nehmen und ohne Staging-Deploy.
- Post-Deploy-Sanity-Check. Du hast 2.3.0 in Prod ausgespielt, drei Groessen pruefen, dass nichts kaputt ist. "Refresh" laedt die frische Version (HTML-Cache invalidiert, CDN-Assets koennen bleiben).
Nach dem Layout-Check auch pruefen, wie der Link in Social Media aussieht: OpenGraph-Vorschau. Und SSL (SSL-Zertifikats-Pruefer) und DNS (DNS-Lookup pruefen, wenn eine Seite langsam oder gar nicht laedt, liegt das Problem meist dort.