Kernpunkte
- Ueber 75 % der mobilen Nutzer und ein wachsender Anteil der Desktop-Nutzer surfen auf Retina- oder HiDPI-Bildschirmen (Quelle: StatCounter, 2025)
- Ein in 1x-Aufloesung ausgeliefertes Bild erscheint auf einem 2x-Bildschirm unscharf — ein Mangel, der auf dem Nicht-Retina-Bildschirm des Entwicklers unsichtbar ist
- Unit- und funktionale Tests pruefen nicht die Aufloesung der an den Browser ausgelieferten Bilder
- Visuelles Testen auf HiDPI-Viewports erfasst das Rendering so, wie der Nutzer es tatsaechlich sieht, und erkennt unterdimensionierte Bilder
Visuelles Testen bezeichnet laut der Definition des ISTQB (International Software Testing Qualifications Board) "die Verifikation, dass die Benutzeroberflaeche 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 fuer die Mehrheit Ihrer Nutzer wahrscheinlich unscharf aus, und Sie wissen es nicht.
Das ist keine Uebertreibung. Als Apple 2010 Retina-Bildschirme mit dem iPhone 4 einfuehrte, stieg das Pixelverhaeltnis 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 Verhaeltnisse von 2x oder mehr. Laut StatCounter-Daten fuer 2025 stammen ueber 75 % der mobilen Sitzungen von Geraeten mit hoher Pixeldichte, und dieser Anteil waechst auch auf dem Desktop mit der Verbreitung von 4K- und 5K-Bildschirmen stetig.
Das Ergebnis: Wenn Sie ein Bild von 400x300 Pixeln fuer 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 Schaerfe 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 tatsaechliche Pixelverhaeltnis nicht emuliert.
Dieser Artikel vertritt eine unmissverstaendliche Position: Wenn Sie Ihre Website nicht visuell in HiDPI-Aufloesung testen, testen Sie Ihre Website nicht so, wie Ihre Nutzer sie sehen. Und automatisiertes visuelles Testen ist die einzige zuverlaessige Methode, um diese Probleme im grossen Massstab zu erkennen.
Das Retina-Problem: Eine Unschaerfe, 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 erklaert
Das Device Pixel Ratio (DPR) ist das Verhaeltnis 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, benoetigt er 400x400 physische Pixel, um diesen Raum zu fuellen. Wenn das Quellbild nur 200x200 Pixel hat, verwendet der Browser einen Interpolationsalgorithmus, um die fehlenden Pixel zu erfinden. Das Ergebnis: eine charakteristische Unschaerfe, 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 Gruende dafuer.
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 ueberein. 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, haengt das emulierte DPR von Ihrer Konfiguration ab. Standardmaessig verwendet Chrome ein DPR von 1 fuer die gaengigsten emulierten Geraete in der Device-Leiste. Sie koennen 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 Unschaerfe sehen, bemerken Sie sie vielleicht nicht. Die Unschaerfe von 1x-Bildern auf einem 2x-Bildschirm ist subtil. Das Auge passt sich an. Sie muessen aktiv ein 1x- und ein 2x-Bild nebeneinander vergleichen, um den Unterschied wahrzunehmen — und wer macht das regelmaessig?
Die Auswirkung auf die Qualitaetswahrnehmung
Die Unschaerfe von Bildern auf Retina-Bildschirmen ist kein harmloses technisches Detail. Forschungen in der kognitiven Psychologie zeigen, dass die Schaerfe von Bildern einer der einflussreichsten Faktoren bei der Wahrnehmung von Qualitaet und Glaubwuerdigkeit einer Website ist. Eine von Google und der Universitaet Basel (Tuch et al., 2012) veroeffentlichte Studie hat gezeigt, dass Nutzer in weniger als 50 Millisekunden ein Urteil ueber die Glaubwuerdigkeit einer Website faellen und dass visuelle Qualitaet der dominante Faktor bei diesem Urteil ist.
Konkret: Wenn Ihr Logo unscharf ist, wenn Ihre Produktfotos an Schaerfe mangeln, wenn Ihre Icons pixelig erscheinen, nehmen Ihre Nutzer Ihre Website als weniger professionell und weniger vertrauenswuerdig wahr. Und sie sind sich dessen wahrscheinlich nicht einmal bewusst — es ist eine instinktive Reaktion.
Fuer E-Commerce-Websites ist die Auswirkung noch direkter. Unscharfe Produktfotos reduzieren das Vertrauen in das Produkt und erhoehen die Retourenquoten. Fuer Markenwebsites ist ein unscharfes Logo ein Signal von Amateurismus, das jede Branding-Arbeit konterkariert.
Technische Loesungen 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 ermoeglicht die Angabe mehrerer Versionen eines Bildes fuer verschiedene Pixeldichten. Der Browser waehlt automatisch die am besten geeignete Version fuer den Bildschirm des Nutzers. Das sizes-Attribut ergaenzt srcset, indem es dem Browser die geplante Anzeiggroesse des Bildes mitteilt, damit er die optimale Quelle waehlen kann, noch bevor er das Bild herunterlaegt.
Theoretisch die ideale Loesung. Praktisch ist die Umsetzung voller Tueucken. Sie muessen mehrere Versionen jedes Bildes generieren und pflegen (1x, 2x, manchmal 3x). Sie muessen sicherstellen, dass jede Version korrekt im srcset referenziert ist. Wenn Sie ein neues Bild hinzufuegen und vergessen, die 2x-Version zu generieren, faellt der Retina-Browser auf die 1x-Version zurueck, und das Bild wird unscharf.
Das Problem ist, dass nichts in Ihrer Test-Pipeline prueft, ob das srcset korrekt ist. Ihre Unit-Tests koennen pruefen, ob das srcset-Attribut im HTML existiert, aber sie koennen nicht pruefen, ob die referenzierten Bilddateien tatsaechlich existieren und die richtige Aufloesung haben.
CSS-Bilder und Media Queries
Fuer CSS-Hintergrundbilder verwendet die konventionelle Technik Media Queries mit dem Aufloesungsselektor, um 2x-Bilder auf HiDPI-Bildschirmen auszuliefern. Auch das funktioniert — vorausgesetzt, Sie tun es fuer 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 Hochaufloesungs-Media-Query hinzufuegt. Ein CSS-Refactoring, das die Media Query versehentlich loescht. 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 gegenueber dem DPR. Als Vektorgrafiken sind sie in jeder Aufloesung scharf. Deshalb sollten Icons und Logos idealerweise SVG sein.
Aber nicht alle Inhalte koennen SVG sein. Fotos, Screenshots, komplexe Rasterillustrationen bleiben in PNG, JPEG oder WebP. Und selbst SVGs koennen visuelle Probleme verursachen: Ein SVG-Icon mit falsch konfigurierter ViewBox kann mit falschen Proportionen angezeigt werden, oder ein Icon, das eingebettete Bitmaps enthaelt, kann teilweise unscharf sein.
Das Problem der manuellen Verifikation
Alle diese technischen Loesungen teilen eine gemeinsame Schwaeche: Keine verifiziert sich selbst. Sie koennen 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 moeglich, aber praktisch im grossen Massstab unmoeglich. Jedes Bild auf jeder Seite auf einem Retina-Bildschirm zu pruefen, die 3x-Mobilversion und die 2x-Desktop-Version zu vergleichen, sicherzustellen, dass CSS-Hintergrundbilder in hoher Aufloesung sind — das ist eine stundenlange Arbeit, die bei jedem Deployment wiederholt werden muss.
Visuelles HiDPI-Testen: Die einzige zuverlaessige Verifikation
Hier bietet visuelles Testen auf HiDPI-Viewports einen Wert, den nichts anderes liefern kann.
Erfassen, was der Nutzer tatsaechlich sieht
Ein visuelles Testtool, das fuer 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 wuerde. Die Bilder werden mit der effektiven Bildschirmaufloesung 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 wuerde.
Der Vergleich dieser hochaufloesenden Screenshots mit den Baselines erkennt automatisch Bilder, die nicht in ausreichender Aufloesung vorliegen. Das visuelle Diff zeigt praezise die Bereiche der Seite, in denen sich die Schaerfe geaendert hat. Kein manuelles Durchsuchen jeder Seite mit einem Retina-Bildschirm noetig — das Tool macht es fuer Sie, systematisch, bei jedem Deployment.
Aufloesungsregressionen 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 oefter als man denkt: Ein CMS-Update, das Bildvarianten zuruecksetzt, eine Speichermigration, die Hochaufloesungsversionen vergisst, eine Template-Aenderung, 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 naechsten Build erkannt. Das Diff zeigt klar, dass das Bild, das scharf war, unscharf geworden ist.
Verschiedene Pixelverhaeltnisse 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 koennen DPR 2 priorisieren (das die Mehrheit der Retina-Bildschirme abdeckt) und DPR 3 fuer kritische Seiten hinzufuegen (Startseite, Produktseiten, Landingpages).
Jenseits von Bildern: Was HiDPI noch offenbart
Visuelles Testen in hoher Aufloesung erkennt nicht nur unscharfe Bilder. Es offenbart CSS-Raender von 1px, die je nach DPR unterschiedlich angezeigt werden (Hairline Borders vs. Doppelpixel). Es zeigt Verlaeufe, die bei 2x Banding aufweisen, waehrend sie bei 1x glatt erscheinen. Es deckt benutzerdefinierte Schriften auf, deren Subpixel-Rendering zwischen Pixeldichten variiert. Und es faengt Favicons und App-Icons in ungenuegender Aufloesung ab — ein klassisches Versaeumnis der Retina-Strategie.
Visuelles HiDPI-Testen in Ihren Workflow integrieren
Die Integration ist einfach. Beginnen Sie mit drei repraesentativen 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 betraegt einige Sekunden pro Seite.
Hoeren Sie auf, blind zu entwickeln
Die Mehrheit Ihrer Nutzer sieht Ihre Website auf einem hochaufloesenden Bildschirm. Wenn Sie nicht in hoher Aufloesung 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 fuer grosse Teams. Es ist eine Notwendigkeit fuer jeden, der visuelle Qualitaet ernst nimmt. Und mit einem No-Code-Tool ist es eine zugaengliche Notwendigkeit: keine Skripte, keine komplexe Konfiguration, nur Aufnahmen in hoher Aufloesung, 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 Aufloesung?
Diese Begriffe bezeichnen dasselbe Konzept mit unterschiedlichen Urspruengen. "Retina" ist Apples Marketingbegriff fuer 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 fuer Android und Chrome OS. "Hohe Aufloesung" ist der allgemeine Begriff. Im Kontext des visuellen Testens bedeuten alle drei dasselbe: ein Bildschirm, dessen Device Pixel Ratio groesser als 1 ist, der Bilder hoeherer Aufloesung fuer eine scharfe Darstellung erfordert.
Verbraucht visuelles Testen in DPR 2 mehr Ressourcen als DPR 1?
Ja, moeglich. Ein Screenshot in DPR 2 enthaelt viermal so viele Pixel wie ein Screenshot in DPR 1 (das Doppelte in Breite und Hoehe). Die Bilddatei ist daher groesser, der erforderliche Speicher ist hoeher, und der Pixelvergleich dauert etwas laenger. In der Praxis ist dieser Unterschied fuer die meisten Projekte vernachlaessigbar. Der Mehraufwand an CI-Zeit liegt in der Groessenordnung 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 Loesungen fuer das Aufloesungsproblem. 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 Kompressionsqualitaet und die Dateigroesse, nicht die intrinsische Aufloesung des Bildes. Sie muessen 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-Aufloesung 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 ermoeglichen die Chrome DevTools die Emulation eines hohen DPR und die manuelle Inspektion jedes Bildes, aber dieser Ansatz ist muehsam 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 Loesung auf Codeebene, um die richtigen Bilder an die richtigen Bildschirme zu liefern. Visuelles HiDPI-Testen ist die Verifikation, dass diese Loesung korrekt funktioniert. Beide sind komplementaer. Das srcset ist die Praevention; der visuelle Test ist die Erkennung. Sie brauchen beides, denn selbst ein korrekt implementiertes srcset kann bei einem CMS-Update, einer Speichermigration oder einer Aenderung der Build-Pipeline brechen.
Sollte man neben DPR 2 auch in DPR 3 testen?
Das haengt von Ihrer Zielgruppe ab. Wenn ein signifikanter Anteil Ihrer Nutzer auf aktuellen iPhones surft (DPR 3), ist das Testen in DPR 3 fuer Ihre kritischsten Seiten sinnvoll. Fuer die Mehrheit der Websites deckt DPR 2 den haeufigsten Fall ab und erkennt die meisten Aufloesungsprobleme. 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 Uebergang von 1x zu 2x. Beginnen Sie mit DPR 2 und fuegen 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: Pruefen, Was Ihre Nutzer Wirklich Sehen
Ihre Nutzer sehen Ihre Website in hoher Aufloesung. Sie sollten sie genauso testen. Delta-QA erfasst Ihre Seiten in DPR 2 und 3 und erkennt unscharfe Bilder, bevor Ihre Nutzer sie sehen.