Kernpunkte
- Über 75 % der mobilen Nutzer und ein wachsender Anteil der Desktop-Nutzer surfen auf Retina- oder HiDPI-Bildschirmen (Quelle: StatCounter, 2025)
- Ein in 1x-Auflösung ausgeliefertes Bild erscheint auf einem 2x-Bildschirm unscharf — ein Mangel, der auf dem Nicht-Retina-Bildschirm des Entwicklers unsichtbar ist
- Unit- und funktionale Tests prüfen nicht die Auflösung der an den Browser ausgelieferten Bilder
- Visuelles Testen auf HiDPI-Viewports erfasst das Rendering so, wie der Nutzer es tatsächlich sieht, und erkennt unterdimensionierte Bilder
Visuelles Testen bezeichnet laut der Definition des ISTQB (International Software Testing Qualifications Board) "die Verifikation, dass die Benutzeroberfläche einer Software den erwarteten visuellen Spezifikationen entsprechend dargestellt wird, indem Referenz-Screenshots mit dem aktuellen Zustand der Anwendung verglichen werden" (ISTQB Glossary, Visual Testing).
Hier ist ein Problem, das nahezu alle Webentwicklungsteams ignorieren: Ihre Website sieht für die Mehrheit Ihrer Nutzer wahrscheinlich unscharf aus, und Sie wissen es nicht.
Das ist keine Übertreibung. Als Apple 2010 Retina-Bildschirme mit dem iPhone 4 einführte, stieg das Pixelverhältnis von 1x auf 2x. Jeder CSS-Pixel wird durch vier physische Pixel gerendert. Seitdem hat sich dieser Trend verallgemeinert. Aktuelle iPhones zeigen in 3x an. MacBook Pro, iPad, Samsung-Bildschirme, Google Pixel — alle verwenden Verhältnisse von 2x oder mehr. Laut StatCounter-Daten für 2025 stammen über 75 % der mobilen Sitzungen von Geräten mit hoher Pixeldichte, und dieser Anteil wächst auch auf dem Desktop mit der Verbreitung von 4K- und 5K-Bildschirmen stetig.
Das Ergebnis: Wenn Sie ein Bild von 400x300 Pixeln für einen Anzeigebereich von 400x300 CSS-Pixeln ausliefern, ist dieses Bild auf einem 1x-Bildschirm scharf. Aber auf einem 2x-Bildschirm muss der Browser diese 400x300 physischen Pixel auf 800x600 physische Pixel strecken. Das Bild wird unscharf. Nicht katastrophal unscharf — subtil unscharf. Gerade unscharf genug, dass Ihr Logo seine Schärfe verliert, Ihre Produktfotos "unprofessionell" wirken, Ihre Icons pixelig erscheinen.
Und das Schlimmste: Sie sehen es nicht, weil Sie vielleicht auf einem Nicht-Retina-Bildschirm entwickeln, oder weil Ihr Entwicklungsbrowser das tatsächliche Pixelverhältnis nicht emuliert.
Dieser Artikel vertritt eine unmissverständliche Position: Wenn Sie Ihre Website nicht visuell in HiDPI-Auflösung testen, testen Sie Ihre Website nicht so, wie Ihre Nutzer sie sehen. Und automatisiertes visuelles Testen ist die einzige zuverlässige Methode, um diese Probleme im großen Maßstab zu erkennen.
Das Retina-Problem: Eine Unschärfe, die Entwickler nicht sehen
Um zu verstehen, warum Retina-Bilder ein so verbreitetes Problem sind, muss man den Mechanismus des Device Pixel Ratio (DPR) und seine Auswirkungen auf das Bildrendering verstehen.
Das Device Pixel Ratio erklärt
Das Device Pixel Ratio (DPR) ist das Verhältnis zwischen den physischen Bildschirmpixeln und den vom Browser verwendeten CSS-Pixeln. Ein Bildschirm mit DPR 1 zeigt ein physisches Pixel pro CSS-Pixel. Ein Bildschirm mit DPR 2 (Retina) zeigt vier physische Pixel pro CSS-Pixel (2x2). Ein Bildschirm mit DPR 3 zeigt neun physische Pixel pro CSS-Pixel (3x3).
Wenn der Browser ein 200x200-Pixel-Bild in einem 200x200-CSS-Pixel-Container auf einem 2x-Bildschirm anzeigen muss, benötigt er 400x400 physische Pixel, um diesen Raum zu füllen. Wenn das Quellbild nur 200x200 Pixel hat, verwendet der Browser einen Interpolationsalgorithmus, um die fehlenden Pixel zu erfinden. Das Ergebnis: eine charakteristische Unschärfe, besonders sichtbar bei Bildern mit Text, feinen Linien, Logos oder Icons.
Warum Entwickler es nicht sehen
Hier ist das Paradox: Der Entwickler, der das Problem verursacht, sieht es oft nicht. Mehrere Gründe dafür.
Wenn Sie auf einem Nicht-Retina-Bildschirm entwickeln (einem externen 1080p-Monitor zum Beispiel), wird ein 1x-Bild auf Ihrem Bildschirm perfekt angezeigt. Es ist scharf, die Pixel stimmen eins zu eins überein. Sie haben keinen Grund, ein Problem zu vermuten.
Wenn Sie auf einem MacBook mit Retina-Bildschirm entwickeln, aber mit den Chrome DevTools im Responsive-Modus testen, hängt das emulierte DPR von Ihrer Konfiguration ab. Standardmäßig verwendet Chrome ein DPR von 1 für die gängigsten emulierten Geräte in der Device-Leiste. Sie können manuell ein DPR von 2 oder 3 konfigurieren, aber wie viele Entwickler tun das systematisch?
Und selbst wenn Sie auf einem Retina-Bildschirm entwickeln und die Unschärfe sehen, bemerken Sie sie vielleicht nicht. Die Unschärfe von 1x-Bildern auf einem 2x-Bildschirm ist subtil. Das Auge passt sich an. Sie müssen aktiv ein 1x- und ein 2x-Bild nebeneinander vergleichen, um den Unterschied wahrzunehmen — und wer macht das regelmäßig?
Die Auswirkung auf die Qualitätswahrnehmung
Die Unschärfe von Bildern auf Retina-Bildschirmen ist kein harmloses technisches Detail. Forschungen in der kognitiven Psychologie zeigen, dass die Schärfe von Bildern einer der einflussreichsten Faktoren bei der Wahrnehmung von Qualität und Glaubwürdigkeit einer Website ist. Eine von Google und der Universität Basel (Tuch et al., 2012) veröffentlichte Studie hat gezeigt, dass Nutzer in weniger als 50 Millisekunden ein Urteil über die Glaubwürdigkeit einer Website fällen und dass visuelle Qualität der dominante Faktor bei diesem Urteil ist.
Konkret: Wenn Ihr Logo unscharf ist, wenn Ihre Produktfotos an Schärfe mangeln, wenn Ihre Icons pixelig erscheinen, nehmen Ihre Nutzer Ihre Website als weniger professionell und weniger vertrauenswürdig wahr. Und sie sind sich dessen wahrscheinlich nicht einmal bewusst — es ist eine instinktive Reaktion.
Für E-Commerce-Websites ist die Auswirkung noch direkter. Unscharfe Produktfotos reduzieren das Vertrauen in das Produkt und erhöhen die Retourenquoten. Für Markenwebsites ist ein unscharfes Logo ein Signal von Amateurismus, das jede Branding-Arbeit konterkariert.
Technische Lösungen und ihre Grenzen
Das Web hat mehrere Mechanismen entwickelt, um Bilder zu liefern, die an die Bildschirmdichte angepasst sind. Aber ihre Umsetzung ist fragil, und ihre Verifikation ist noch fragiler.
Die Attribute srcset und sizes
Das HTML-Attribut srcset ermöglicht die Angabe mehrerer Versionen eines Bildes für verschiedene Pixeldichten. Der Browser wählt automatisch die am besten geeignete Version für den Bildschirm des Nutzers. Das sizes-Attribut ergänzt srcset, indem es dem Browser die geplante Anzeiggröße des Bildes mitteilt, damit er die optimale Quelle wählen kann, noch bevor er das Bild herunterlägt.
Theoretisch die ideale Lösung. Praktisch ist die Umsetzung voller Tüucken. Sie müssen mehrere Versionen jedes Bildes generieren und pflegen (1x, 2x, manchmal 3x). Sie müssen sicherstellen, dass jede Version korrekt im srcset referenziert ist. Wenn Sie ein neues Bild hinzufügen und vergessen, die 2x-Version zu generieren, fällt der Retina-Browser auf die 1x-Version zurück, und das Bild wird unscharf.
Das Problem ist, dass nichts in Ihrer Test-Pipeline prüft, ob das srcset korrekt ist. Ihre Unit-Tests können prüfen, ob das srcset-Attribut im HTML existiert, aber sie können nicht prüfen, ob die referenzierten Bilddateien tatsächlich existieren und die richtige Auflösung haben.
CSS-Bilder und Media Queries
Für CSS-Hintergrundbilder verwendet die konventionelle Technik Media Queries mit dem Auflösungsselektor, um 2x-Bilder auf HiDPI-Bildschirmen auszuliefern. Auch das funktioniert — vorausgesetzt, Sie tun es für jedes Hintergrundbild und pflegen diese Duplizierung im Laufe der Zeit.
Das Risiko ist dasselbe wie bei srcset: Vergessen oder Fehler bei der Wartung. Ein neuer Entwickler, der ein Hintergrundbild ohne die Hochauflösungs-Media-Query hinzufügt. Ein CSS-Refactoring, das die Media Query versehentlich löscht. Ein 2x-Bild, das im CSS referenziert ist, aber nach einer Migration nicht mehr auf dem Server existiert.
Vektorformate (SVG)
SVG-Bilder sind von Natur aus unempfindlich gegenüber dem DPR. Als Vektorgrafiken sind sie in jeder Auflösung scharf. Deshalb sollten Icons und Logos idealerweise SVG sein.
Aber nicht alle Inhalte können SVG sein. Fotos, Screenshots, komplexe Rasterillustrationen bleiben in PNG, JPEG oder WebP. Und selbst SVGs können visuelle Probleme verursachen: Ein SVG-Icon mit falsch konfigurierter ViewBox kann mit falschen Proportionen angezeigt werden, oder ein Icon, das eingebettete Bitmaps enthält, kann teilweise unscharf sein.
Das Problem der manuellen Verifikation
Alle diese technischen Lösungen teilen eine gemeinsame Schwäche: Keine verifiziert sich selbst. Sie können eine perfekte Infrastruktur zur Generierung von Multiresolution-Bildern haben, aber wenn ein Glied der Kette bricht — eine Build-Pipeline, die keine 2x-Bilder mehr generiert, ein CDN, das nicht die richtige Datei ausliefert, ein Template, das das srcset vergisst — ist das Ergebnis ein unscharfes Bild in der Produktion.
Manuelle Verifikation ist theoretisch möglich, aber praktisch im großen Maßstab unmöglich. Jedes Bild auf jeder Seite auf einem Retina-Bildschirm zu prüfen, die 3x-Mobilversion und die 2x-Desktop-Version zu vergleichen, sicherzustellen, dass CSS-Hintergrundbilder in hoher Auflösung sind — das ist eine stundenlange Arbeit, die bei jedem Deployment wiederholt werden muss.
Visuelles HiDPI-Testen: Die einzige zuverlässige Verifikation
Hier bietet visuelles Testen auf HiDPI-Viewports einen Wert, den nichts anderes liefern kann.
Erfassen, was der Nutzer tatsächlich sieht
Ein visuelles Testtool, das für die Aufnahme von Screenshots mit einem Device Pixel Ratio von 2 oder 3 konfiguriert ist, rendert die Seite genau so, wie ein Retina-Bildschirm es tun würde. Die Bilder werden mit der effektiven Bildschirmauflösung geladen und angezeigt. Wenn ein Bild in 1x ist und der Viewport in 2x, erscheint das Bild im Screenshot unscharf — genau so, wie es auf dem Bildschirm Ihres Nutzers erscheinen würde.
Der Vergleich dieser hochauflösenden Screenshots mit den Baselines erkennt automatisch Bilder, die nicht in ausreichender Auflösung vorliegen. Das visuelle Diff zeigt präzise die Bereiche der Seite, in denen sich die Schärfe geändert hat. Kein manuelles Durchsuchen jeder Seite mit einem Retina-Bildschirm nötig — das Tool macht es für Sie, systematisch, bei jedem Deployment.
Auflösungsregressionen erkennen
Visuelles HiDPI-Testen ist besonders effektiv bei der Erkennung von Regressionen — Situationen, in denen ein Bild, das in 2x war, dies nicht mehr ist. Das passiert öfter als man denkt: Ein CMS-Update, das Bildvarianten zurücksetzt, eine Speichermigration, die Hochauflösungsversionen vergisst, eine Template-Änderung, die ein srcset durch ein einfaches src ersetzt.
Ohne visuelles Testen bleiben diese Regressionen wochen- oder monatelang unerkannt. Mit einem visuellen Test, der in DPR 2 aufnimmt, wird die Regression beim nächsten Build erkannt. Das Diff zeigt klar, dass das Bild, das scharf war, unscharf geworden ist.
Verschiedene Pixelverhältnisse abdecken
Der Bildschirmmarkt ist fragmentiert. Moderne iPhones verwenden DPR 3. MacBooks verwenden DPR 2. Android-Bildschirme variieren zwischen 1,5, 2, 2,75 und 3. Desktop-4K-Bildschirme mit 150-%-Skalierung haben DPR 1,5.
Ein umfassender visueller Test erfasst Ihre Seiten bei mehreren DPRs, um sicherzustellen, dass die Bilder auf jedem Bildschirmtyp scharf sind. Sie können DPR 2 priorisieren (das die Mehrheit der Retina-Bildschirme abdeckt) und DPR 3 für kritische Seiten hinzufügen (Startseite, Produktseiten, Landingpages).
Jenseits von Bildern: Was HiDPI noch offenbart
Visuelles Testen in hoher Auflösung erkennt nicht nur unscharfe Bilder. Es offenbart CSS-Ränder von 1px, die je nach DPR unterschiedlich angezeigt werden (Hairline Borders vs. Doppelpixel). Es zeigt Verläufe, die bei 2x Banding aufweisen, während sie bei 1x glatt erscheinen. Es deckt benutzerdefinierte Schriften auf, deren Subpixel-Rendering zwischen Pixeldichten variiert. Und es fängt Favicons und App-Icons in ungenügender Auflösung ab — ein klassisches Versäumnis der Retina-Strategie.
Visuelles HiDPI-Testen in Ihren Workflow integrieren
Die Integration ist einfach. Beginnen Sie mit drei repräsentativen Viewports: Desktop 1440px bei DPR 2 (MacBook Pro), Mobil 390px bei DPR 3 (iPhone 14/15), Tablet 810px bei DPR 2 (iPad). Priorisieren Sie Seiten mit kritischen Bildern: Startseite, Produktseiten, Landingpages. Integrieren Sie HiDPI-Aufnahmen in Ihre CI-Pipeline — der Mehraufwand beträgt einige Sekunden pro Seite.
Hören Sie auf, blind zu entwickeln
Die Mehrheit Ihrer Nutzer sieht Ihre Website auf einem hochauflösenden Bildschirm. Wenn Sie nicht in hoher Auflösung testen, testen Sie eine Version Ihrer Website, die Ihre Nutzer nicht sehen. So einfach ist das.
Visuelles Testen in DPR 2 und 3 ist kein Luxus für große Teams. Es ist eine Notwendigkeit für jeden, der visuelle Qualität ernst nimmt. Und mit einem No-Code-Tool ist es eine zugängliche Notwendigkeit: keine Skripte, keine komplexe Konfiguration, nur Aufnahmen in hoher Auflösung, die automatisch mit Ihren Baselines verglichen werden.
Ihre Bilder verdienen es, scharf zu sein. Ihre Nutzer verdienen es, Ihre Website so zu sehen, wie Sie sie gestaltet haben. Visuelles HiDPI-Testen ist das Mittel, beides zu garantieren.
FAQ
Was ist der Unterschied zwischen Retina, HiDPI und hoher Auflösung?
Diese Begriffe bezeichnen dasselbe Konzept mit unterschiedlichen Ursprüngen. "Retina" ist Apples Marketingbegriff für seine Bildschirme mit hoher Pixeldichte (DPR >= 2). "HiDPI" (High Dots Per Inch) ist der generische technische Begriff, der von der Branche verwendet wird, insbesondere von Google für Android und Chrome OS. "Hohe Auflösung" ist der allgemeine Begriff. Im Kontext des visuellen Testens bedeuten alle drei dasselbe: ein Bildschirm, dessen Device Pixel Ratio größer als 1 ist, der Bilder höherer Auflösung für eine scharfe Darstellung erfordert.
Verbraucht visuelles Testen in DPR 2 mehr Ressourcen als DPR 1?
Ja, möglich. Ein Screenshot in DPR 2 enthält viermal so viele Pixel wie ein Screenshot in DPR 1 (das Doppelte in Breite und Höhe). Die Bilddatei ist daher größer, der erforderliche Speicher ist höher, und der Pixelvergleich dauert etwas länger. In der Praxis ist dieser Unterschied für die meisten Projekte vernachlässigbar. Der Mehraufwand an CI-Zeit liegt in der Größenordnung von einigen Sekunden pro Seite, und der Speichermehraufwand ist mit moderner Screenshot-Kompression handhabbar.
Meine Website verwendet WebP- oder AVIF-Bilder. Gilt das Retina-Problem trotzdem?
Ja. WebP und AVIF sind Kompressionsformate, keine Lösungen für das Auflösungsproblem. Ein WebP-Bild von 400x300 Pixeln wird auf einem 2x-Bildschirm genauso unscharf sein wie ein JPEG-Bild von 400x300 Pixeln. Das Format des Bildes bestimmt die Kompressionsqualität und die Dateigröße, nicht die intrinsische Auflösung des Bildes. Sie müssen weiterhin Bilder in 2x oder 3x ausliefern, sie werden nur effizienter in WebP oder AVIF komprimiert als in JPEG oder PNG.
Wie finde ich heraus, welche Bilder auf meiner Website nicht in Retina-Auflösung sind?
Der direkteste Weg ist der visuelle Test in DPR 2. Nehmen Sie Ihre Seiten mit einem visuellen Testtool auf, das auf DPR 2 konfiguriert ist, und vergleichen Sie mit den Baselines in DPR 1. Die unscharfen Bereiche erscheinen klar im Diff. Alternativ ermöglichen die Chrome DevTools die Emulation eines hohen DPR und die manuelle Inspektion jedes Bildes, aber dieser Ansatz ist mühsam und nicht automatisierbar. Automatisiertes visuelles Testen ist die einzige Methode, die bei jedem Deployment eine umfassende Verifikation garantiert.
Ersetzt visuelles HiDPI-Testen die Verwendung von srcset?
Nein. Das srcset ist die technische Lösung auf Codeebene, um die richtigen Bilder an die richtigen Bildschirme zu liefern. Visuelles HiDPI-Testen ist die Verifikation, dass diese Lösung korrekt funktioniert. Beide sind komplementär. Das srcset ist die Prävention; der visuelle Test ist die Erkennung. Sie brauchen beides, denn selbst ein korrekt implementiertes srcset kann bei einem CMS-Update, einer Speichermigration oder einer Änderung der Build-Pipeline brechen.
Sollte man neben DPR 2 auch in DPR 3 testen?
Das hängt von Ihrer Zielgruppe ab. Wenn ein signifikanter Anteil Ihrer Nutzer auf aktuellen iPhones surft (DPR 3), ist das Testen in DPR 3 für Ihre kritischsten Seiten sinnvoll. Für die Mehrheit der Websites deckt DPR 2 den häufigsten Fall ab und erkennt die meisten Auflösungsprobleme. Ein Bild, das in DPR 2 scharf ist (also in 2x ausgeliefert wird), wird in DPR 3 etwas weniger scharf sein, aber der Unterschied ist viel weniger wahrnehmbar als der Übergang von 1x zu 2x. Beginnen Sie mit DPR 2 und fügen Sie DPR 3 hinzu, wenn Ihre Analytics es rechtfertigen.
Weiterführende Lektüre
- Visuelles Testing und A/B-Testing: Testen Sie Ihre Tests, Bevor Sie Sie Starten
- Visuelles Testen, Kontrast und Farbenblindheit: Prüfen, Was Ihre Nutzer Wirklich Sehen
Ihre Nutzer sehen Ihre Website in hoher Auflösung. Sie sollten sie genauso testen. Delta-QA erfasst Ihre Seiten in DPR 2 und 3 und erkennt unscharfe Bilder, bevor Ihre Nutzer sie sehen.