Bilder mit hohem DPI-Wert für variable Pixeldichten

Boris Smus
Boris Smus
X Startseite

Eines der Merkmale der komplexen Gerätelandschaft von heute ist, dass es eine sehr große Bandbreite an verfügbaren Pixeldichten. Einige Geräte haben sehr hochauflösende Displays, während andere bleiben zurück. Anwendungsentwickler müssen eine Reihe von Pixeldichten, was ziemlich schwierig sein kann. Im mobilen Web Herausforderungen werden durch mehrere Faktoren verschärft:

  • Große Vielfalt von Geräten mit unterschiedlichen Formfaktoren.
  • Beschränkte Netzwerkbandbreite und Akkulaufzeit.

Was Bilder betrifft, besteht das Ziel von Web-App-Entwicklern darin, die so effizient wie möglich Bilder in bester Qualität erstellen. In diesem Artikel erfahren Sie, zeigen wir Ihnen einige nützliche Techniken, mit denen Sie dies heute und in naher Zukunft erreichen können. in der Zukunft.

Vermeiden Sie nach Möglichkeit Bilder.

Bevor Sie die Dose Würmer öffnen, denken Sie daran, dass es im Web viele leistungsstarken Technologien, die weitgehend auflösungs- und dPI-unabhängig sind. Text, SVG und ein Großteil der CSS-Elemente funktionieren einfach. aufgrund der Web-Funktion zur automatischen Pixelskalierung (über devicePixelRatio).

Sie können jedoch nicht immer Rasterbilder vermeiden. Zum Beispiel könnten Sie mit Assets, die sich in reinem SVG/CSS nur schwer replizieren lassen, oder Sie es mit einem Foto zu tun haben. Das Bild lässt sich zwar automatisch in SVG umwandeln, ist eine vektorisierte Aufnahme von Fotos wenig sinnvoll. weil vergrößerte Versionen meist nicht gut aussehen.

Hintergrund

Es gibt bisher noch keine Erfahrung mit Kompaktheitsgrad

Anfangs hatten Computerdisplays eine Pixeldichte von 72 oder 96 dpi (Punkte pro Zoll)

Die Pixeldichte von Displays wird allmählich verbessert, mobilen Anwendungsfall, bei dem Nutzer ihr Smartphone in der Regel näher an sodass die Pixel besser sichtbar sind. 2008 waren 150-dpi-Smartphones die eine neue Norm. Der Trend zu einer erhöhten Anzeigedichte setzte sich fort. neue Smartphones haben 300-dpi-Displays (mit der Marke "Retina" von Apple).

Der heilige Gral ist natürlich ein Display, bei dem Pixel unsichtbar sind. Beim Formfaktor für Smartphones ist die aktuelle Generation von Retina-/HiDPI-Displays können diesem Idealfall sehr nahe kommen. Aber neue Arten von Hardware und Wearables wie Project Glass werden wahrscheinlich auch weiterhin um die Pixeldichte zu erhöhen.

In der Praxis sollten Bilder mit niedriger Punktdichte auf neuen Bildschirmen genauso aussehen wie auf alten Fotos gemacht, aber im Vergleich zu den scharfen Bildern mit hoher Dichte die Nutzende daran gewöhnt sind, die Bilder mit niedriger Punktdichte zu unübersichtlich verpixelt aussehen. Hier sehen Sie eine grobe Simulation, auf einem 2-fachen Display. Im Gegensatz dazu sieht das 2-fache Bild recht gut aus.

<ph type="x-smartling-placeholder">
</ph> Pavian 1x
Pavian 2x
Paviane! mit unterschiedlichen Pixeldichten.

Pixel im Web

Als das Web konzipiert war, hatten 99% der Bildschirme 96 dpi (oder wie ) und es wurden wenige Änderungen gemacht. vorne. Aufgrund der großen Unterschiede bei Bildschirmgrößen und -dichten brauchte eine Standardmethode, um Bilder auf verschiedenen Bildschirmdichten und -abmessungen.

In der HTML-Spezifikation wurde dieses Problem kürzlich durch Definition eines Referenzpixels, mit dem Hersteller die Größe bestimmen eines CSS-Pixels.

Anhand des Referenzpixels kann ein Hersteller die Größe des das physische Pixel des Geräts relativ zum Standard- oder idealen Pixel. Dieses wird als Geräte-Pixel-Verhältnis bezeichnet.

Pixelverhältnis des Geräts berechnen

Angenommen, ein Smartphone hat ein Display mit einer physischen Pixelgröße von 180 Pixel per Zoll (ppi) Die Berechnung des Geräte-Pixel-Verhältnisses dauert Schritte:

  1. Vergleichen Sie den tatsächlichen Abstand, mit dem das Gerät gehalten wird, mit dem Abstand für das Referenzpixel.

    Laut Spezifikation sind bei 28 Zoll idealerweise 96 Pixel pro Zoll. Da es sich jedoch um ein Smartphone handelt, als in der Hand eines Laptops. Nehmen wir an, dass die Entfernung 45 cm.

  2. Multiplizieren Sie das Distanzverhältnis zur Standarddichte (96 ppi), um erhalten Sie die ideale Pixeldichte für eine bestimmte Entfernung.

    idealPixelDensity = (28/18) * 96 = 150 Pixel pro Zoll (ungefähr)

  3. Das Verhältnis der physischen Pixeldichte zum idealen Pixel ermitteln um das Pixelverhältnis des Geräts zu ermitteln.

    devicePixelRatio = 180/150 = 1,2

So wird devicePixelRatio berechnet.
Ein Diagramm mit einem Referenzwinkelpixel wie „devicePixelRatio“ berechnet wird.

Wenn ein Browser nun wissen muss, wie er ein Bild an die Bildschirmgröße an die ideale oder Standardauflösung anpasst, mit dem Pixel-Verhältnis des Geräts von 1,2, was besagt, dass für jedes ideale Pixel hat dieses Gerät 1,2 physische Pixel. Die Formel, um zwischen idealen (gemäß Webspezifikation) und physische Pixel (Punkte auf dem Gerätebildschirm) lautet:

physicalPixels = window.devicePixelRatio * idealPixels

In der Vergangenheit haben Gerätehersteller tendenziell devicePixelRatios (DPRs). iPhone und iPad von Apple melden DPR von 1 und ihre Retina Vergleichsbericht 2. In der CSS-Spezifikation wird empfohlen,

Die Pixeleinheit bezieht sich auf die ganze Anzahl von Gerätepixeln, das Referenzpixel annähert.

Ein Grund, warum runde Verhältnisse besser sein können, ist, dass sie zu weniger Subpixel-Artefakte

Die Realität der Geräte ist jedoch viel vielfältiger. Bei Android-Smartphones liegt die Niederschlagswahrscheinlichkeit oft bei 1,5. Das Nexus 7-Tablet hat einen DPR von ~ 1, 33.Dies wurde durch eine ähnliche Berechnung wie die obige ermittelt. Künftig werden es mehr Geräte mit variablen dynamischen Ausdrucken geben. Aus sollten Sie nie davon ausgehen, dass Ihre Kunden ganzzahlige Impressions

Übersicht über HiDPI-Bildtechniken

Es gibt viele Methoden, das Problem zu lösen, die besten qualitativ hochwertige Bilder so schnell wie möglich zu erhalten. Dabei gibt es zwei Kategorien:

  1. Optimieren einzelner Bilder
  2. Optimierung der Auswahl zwischen mehreren Bildern

Einzelbild-Ansätze: Verwenden Sie nur ein Bild, aber gehen Sie damit etwas Schlaues vor. Diese Ansätze haben den Nachteil, dass Sie unweigerlich Abstriche machen werden. da Sie HiDPI-Bilder noch auf älteren Modellen Geräte mit geringerem DPI-Wert. Hier sind einige Ansätze für das Einzelbild Fall:

  • Stark komprimiertes HiDPI-Bild
  • Ein tolles Bildformat
  • Progressive-Bildformat

Mehrere Bilder verwenden: Mehrere Bilder verwenden, aber etwas cleveres umsetzen welche Daten geladen werden sollen. Diese Ansätze haben einen inhärenten Aufwand für die mehrere Versionen desselben Assets zu erstellen eine Entscheidungsstrategie zu entwickeln. So sehen die einzelnen Optionen aus:

  • JavaScript
  • Serverseitige Zustellung
  • CSS-Medienabfragen
  • Integrierte Browserfunktionen (image-set(), <img srcset>)

Stark komprimiertes HiDPI-Bild

Bilder machen bereits sensationelle 60% der Bandbreite aus, die für das Herunterladen eines durchschnittliche Website. Durch die Bereitstellung von HiDPI-Bildern für alle Kunden erhöhen Sie diese Zahl. Wie viel größer wird es wachsen?

Ich habe Tests durchgeführt, bei denen 1x- und 2x-Bildfragmente mit JPEG generiert wurden. bei 90, 50 und 20. Hier ist das von mir verwendete Shell-Skript (mit ImageMagick), um sie zu generieren:

<ph type="x-smartling-placeholder">
</ph> Kacheln – Beispiel 1. Kacheln-Beispiel 2. Kacheln – Beispiel 3.
Beispiele von Bildern mit unterschiedlichen Komprimierungen und Pixeln Dichte.

Bei dieser kleinen, unwissenschaftlichen Stichprobennahme scheint es, dass Bilder einen guten Kompromiss zwischen Qualität und Größe aufweisen. Für mein Auge komprimierte 2x-Bilder sehen tatsächlich besser aus als unkomprimierte 1x-Bilder. Bilder.

Natürlich werden hochkomprimierte Bilder von geringer Qualität bis zu schlechter als die Bereitstellung von qualitativ hochwertigeren Geräten ist. führt zu Qualitätseinbußen bei der Bildqualität. Beim Vergleich der Qualität: 90 bis zu 20 Bilder fest, was die Schärfe und die mit größerer Körnigkeit. Diese Artefakte sind in Fällen, in denen bei denen qualitativ hochwertige Bilder entscheidend sind (z. B. ein Foto-Viewer Anwendung) oder für App-Entwickler, die keine Kompromisse eingehen möchten.

Der Vergleich oben wurde ausschließlich mit komprimierten JPEGs durchgeführt. Es lohnt sich Wir weisen darauf hin, dass es viele Kompromisse zwischen implementierten Bildformaten (JPEG, PNG, GIF) unterstützt.

Ein tolles Bildformat

WebP ist ein ziemlich überzeugendes Bildformat, das und gleichzeitig eine hohe Bildqualität. Natürlich ist es nicht überall implementiert werden.

Eine Möglichkeit besteht darin, über JavaScript zu prüfen, ob WebP unterstützt wird. Sie laden ein 1 Pixel Bild über den Daten-URI, warten Sie, bis entweder geladene oder Fehlerereignisse ausgelöst wurden, und und überprüfen Sie, ob die Größe korrekt ist. Modernizr Schiffe mit ein solches Skript zur Funktionserkennung, das über Modernizr.webp.

Am besten geht das jedoch, image() in CSS ein. Wenn ihr also ein WebP- Bild- und JPEG-Fallback-Datei auf, können Sie Folgendes schreiben:

#pic {
  background: image("foo.webp", "foo.jpg");
}

Bei diesem Ansatz gibt es einige Probleme. Erstens ist image() nicht flächendeckend umgesetzt werden. Zweitens bläst die WebP-Komprimierung JPEG- ist es immer noch eine relativ inkrementelle Verbesserung. mit dieser WebP-Galerie etwa 30% kleiner. WebP allein reicht nicht aus, um das Problem mit hohem DPI-Wert zu lösen.

Progressive-Bildformate

Progressive-Bildformate wie JPEG 2000, Progressive JPEG und Progressive PNG und GIF bieten den (etwas umstrittenen) Vorteil, dass das Bild bevor es vollständig geladen ist. Sie können einen Größenaufwand verursachen, auch wenn es diesbezüglich widersprüchliche Beweise gibt. Jeff Atwood behaupten, dass der progressive Modus „ungefähr 20% zur Größe von PNG-Bildern hinzufügt“, etwa 10% der Größe von JPEG- und GIF-Bildern“. Stojan Stefanov besagt, dass der Progressive-Modus bei großen Dateien effizienter ist (in in den meisten Fällen).

Auf den ersten Blick sehen progressive Bilder sehr vielversprechend aus. die schnellstmögliche Bereitstellung bestmöglicher Bilder. Die Idee ist, dass der Browser den Download und die Decodierung eines Bildes beenden kann, sobald es dass zusätzliche Daten die Bildqualität (d. h. die gesamte Verbesserungen der Grafikqualität sind Subpixel).

Verbindungen sind zwar leicht zu beenden, aber oft teuer. neu starten. Bei einer Website mit vielen Bildern ist es am effizientesten, eine einzelne HTTP-Verbindung aktiv halten und sie so lange wie möglich wiederverwenden. Wenn die Verbindung vorzeitig beendet wird, weil ein Image muss der Browser eine neue Verbindung herstellen, was in Umgebungen mit niedriger Latenz sehr langsam sein kann.

Eine Problemumgehung ist die Verwendung der Anfrage HTTP Range, mit der sich Browser einen Bereich der abzurufenden Byte angeben. Ein intelligenter Browser HEAD-Anfrage an die Kopfzeile zu erhalten, sie zu verarbeiten, zu entscheiden, Image tatsächlich benötigt wird, und dann abrufen. Der HTTP-Bereich ist von Webservern schlecht unterstützt, sodass dieser Ansatz nicht praktikabel ist.

Ein offensichtlicher Nachteil dieses Ansatzes besteht darin, Wählen Sie aus, welches Bild geladen werden soll. Verwenden Sie nur unterschiedliche Elemente desselben Bildes. Die Angaben zu Art Direction sind daher nicht relevant. für den Anwendungsfall.

Mit JavaScript entscheiden, welches Bild geladen werden soll

Die erste und naheliegendste Methode bei der Entscheidung, welches Bild geladen werden soll, ist, um JavaScript im Client zu verwenden. So können Sie herausfinden, alles über den User-Agent und das Richtige zu tun. Sie können Pixel-Verhältnis des Geräts über window.devicePixelRatio bestimmen, Bildschirm abrufen und eine gewisse Netzwerkverbindung herstellen, das Schnüffeln über navigator.connection oder das Senden einer gefälschten Anfrage, wie der foresight.js verwenden. Sobald Sie alle können Sie entscheiden, welches Bild geladen werden soll.

Es gibt etwa eine Million JavaScript-Bibliotheken, die oben beschriebenen Schritte ausführen, die leider nicht besonders herausragend.

Ein großer Nachteil bei diesem Ansatz besteht darin, dass die Verwendung von JavaScript verzögern Sie das Laden des Bildes, bis der Look-Ahead-Parser abgeschlossen. Das bedeutet im Grunde, dass die Bilder nicht einmal Wird erst heruntergeladen, nachdem das pageload-Ereignis ausgelöst wurde. Mehr dazu in Artikel von Jason Grigsby

Entscheiden, welches Image auf den Server geladen werden soll

Sie können die Entscheidung auf die Serverseite verschieben, indem Sie eine benutzerdefinierte Anfrage schreiben Handler für jedes von Ihnen bereitgestellte Image erstellt. Ein solcher Handler würde eine Prüfung auf Retina- basierend auf dem User-Agent (die einzige Information, die an Server). Je nachdem, ob mit der serverseitigen Logik HiDPI-Assets laden Sie das entsprechende Asset, das nach einigen bekannte Konvention).

Leider bietet der User-Agent nicht unbedingt genügend um zu entscheiden, ob ein Gerät eine hohe oder niedrige qualitativ hochwertige Bilder zu erstellen. Selbstverständlich sind alle Der User-Agent ist ein Hack und sollte möglichst vermieden werden.

CSS-Medienabfragen verwenden

Bei deklarativen CSS-Medienabfragen können Sie Ihre Absicht angeben damit der Browser für Sie das Richtige tun kann. Neben den der häufigen Nutzung von Medienabfragen, der Anpassung an die Gerätegröße, stimmt auch mit devicePixelRatio überein. Die zugehörige Medienabfrage lautet Geräte-Pixel-Verhältnis und zugehörige Mindest- und Höchstvarianten, während Sie zu erwarten ist. Wenn Sie Bilder mit hohem DPI-Wert und das Geräte-Pixel laden möchten Grenzwert einen Grenzwert überschreitet, können Sie Folgendes tun:

#my-image { background: (low.png); }

@media only screen and (min-device-pixel-ratio: 1.5) {
  #my-image { background: (high.png); }
}

Es wird etwas komplizierter, wenn alle Anbieterpräfixe insbesondere aufgrund von Abweichungen bei der Platzierung der „Min.“ und „max“ Präfixe:

@media only screen and (min--moz-device-pixel-ratio: 1.5),
    (-o-min-device-pixel-ratio: 3/2),
    (-webkit-min-device-pixel-ratio: 1.5),
    (min-device-pixel-ratio: 1.5) {

  #my-image {
    background:url(high.png);
  }
}

Auf diese Weise erhalten Sie wieder die Vorteile des Look-Ahead-Parsings, mit der JS-Lösung verloren. Außerdem können Sie flexibel auswählen, Ihre responsiven Haltepunkte (z. B. niedrige, mittlere und hohe DPI-Bilder), die beim serverseitigen Ansatz verloren gegangen sind.

Leider ist sie immer noch etwas unhandlich und führt zu einem seltsamen Aussehen. CSS (oder erfordert eine Vorverarbeitung). Außerdem beschränkt sich dieser Ansatz auf CSS-Eigenschaften festlegen, sodass es keine Möglichkeit gibt, ein <img src> festzulegen, und Ihre Bilder müssen alles Elemente mit Hintergrund sein. Wenn Sie sich streng auf die kann es passieren, dass Ihr High-DPI-Wert auf einem Smartphone ein riesiges 2-faches Bild-Asset EDGE-Verbindung: Das ist nicht nutzerfreundlich.

Neue Browserfunktionen verwenden

In letzter Zeit wurde viel über die Unterstützung das Problem mit dem Bild mit hohem DPI-Wert. Apple ist kürzlich in den Weltraum eingebrochen, damit die CSS-Funktion image-set() in WebKit eingebunden wird. Daher sind sowohl Safari und Chrome unterstützen diese Methode. Da es sich um eine CSS-Funktion handelt, image-set() wird das Problem für <img>-Tags nicht behandelt. Eingabetaste @srcset. Damit wurde das Problem behoben, dieser Artikel) enthält (noch!) keine Referenzimplementierungen. Der nächste Abschnitt geht näher auf image-set und srcset ein.

Browserfunktionen für High DPI-Unterstützung

Letztendlich hängt die Entscheidung, welchen Ansatz Sie wählen, davon ab, Anforderungen. Denken Sie jedoch daran, dass alle die zuvor genannten Ansätze haben Nachteile. In Zukunft image-set und srcset werden weithin unterstützt. Sie sind die geeignete Lösungen für dieses Problem zu finden. Lassen Sie uns vorerst darüber sprechen, einige Best Practices an, die uns diesem idealen wie möglich zu machen.

Erstens: Wie unterscheiden sich diese beiden? image-set() ist ein Preisvergleichsportal -Funktion, die als Wert der CSS-Eigenschaft für den Hintergrund verwendet werden kann. srcset ist ein für <img>-Elemente spezifisches Attribut mit ähnlicher Syntax. Mit beiden Tags können Sie Image-Deklarationen angeben, aber mit dem können Sie festlegen, welches Bild basierend auf dem Darstellungsbereich geladen werden soll. Größe.

Best Practices für Image-set

Die CSS-Funktion image-set() ist mit folgendem Präfix verfügbar: -webkit-image-set(). Die Syntax ist ganz einfach: kommagetrennte Bilddeklarationen, die aus einem URL-String oder url()-Funktion gefolgt von der zugehörigen Auflösung. Beispiel:

background-image:  -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

Dadurch weiß der Browser, dass zwei Bilder zur Auswahl stehen. Eines ist für 1x-Displays optimiert, das andere für 2x-Displays. Der Browser wählt dann anhand verschiedener bis hin zur Netzwerkgeschwindigkeit, wenn der Browser intelligent ist und (derzeit nicht implementiert, soweit ich weiß).

Der Browser lädt nicht nur das richtige Bild, sondern skaliert es auch entsprechend anpassen. Mit anderen Worten, der Browser geht davon aus, dass zwei Bilder doppelt so groß wie 1-fache Bilder. Das 2-fache Bild wird daher Faktor von 2, damit das Bild auf der Seite die gleiche Größe hat.

Anstatt 1x, 1.5x oder Nx anzugeben, können Sie auch eine bestimmte die Pixeldichte des Geräts in dpi.

Das funktioniert gut, außer in Browsern, die den image-set nicht unterstützen. angezeigt, bei dem überhaupt kein Bild angezeigt wird. Das ist eindeutig schlecht, muss ein Fallback oder eine Reihe von Fallbacks verwendet werden, um dieses Problem zu beheben:

background-image: url(icon1x.jpg);
background-image: -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);
/* This will be useful if image-set gets into the platform, unprefixed.
    Also include other prefixed versions of this */
background-image: image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

Dadurch wird das entsprechende Asset in Browsern geladen, die Image-set festlegen und andernfalls auf das 1x-Asset zurückgreifen. Der offensichtliche Vorbehalt wird der image-set()-Browser zwar nur wenig unterstützt, die meisten User-Agents um das 1x-Asset zu erhalten.

In dieser Demo wird mit image-set() die korrekte Bild und greift auf das 1x-Asset zu, wenn diese CSS-Funktion unterstützt.

An dieser Stelle fragen Sie sich vielleicht, warum nicht nur Polyfill (d. h. einen JavaScript-Shim erstellen) image-set() Wie sie Es stellte sich heraus, dass es ziemlich schwierig ist, effiziente Polyfills für CSS zu implementieren, Funktionen. Eine ausführliche Erläuterung hierzu finden Sie in diesem www-Stil Diskussion).

Bild-srcset

Hier ist ein Beispiel für srcset:

<img alt="my awesome image"
  src="banner.jpeg"
  srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

Wie Sie sehen, gibt image-set neben den x-Deklarationen nimmt das srcset-Element auch die Werte w und h an, die dem Parameter Darstellungsbereichs vergrößern, sodass die relevanteste Version ausgeliefert wird. Die oben würde Banner-phone.jpeg für Geräte mit Darstellungsbereichsbreite unter 640px, Banner-phone-HD.jpeg zu Geräten mit kleinem Bildschirm und hoher DPI-Rate Banner-HD.jpeg auf Geräten mit hohem DPI-Wert mit Bildschirmen von mehr als 640 px und Banner.jpeg für alles andere verwenden.

„image-set“ für Bildelemente verwenden

Da das srcset-Attribut für img-Elemente in den meisten Browser ist es vielleicht verlockend, die img-Elemente durch <div>-Elemente zu ersetzen, mit Hintergründen und dem Bildsatz-Ansatz. Dies funktioniert mit Vorbehalte. Der Nachteil ist, dass das <img>-Tag lang semantischen Wert. In der Praxis ist das vor allem für Web-Crawler wichtig. und die Barrierefreiheit.

Wenn Sie -webkit-image-set verwenden, sind Sie vielleicht versucht, die CSS-Property für den Hintergrund. Der Nachteil dieses Ansatzes ist, zur Angabe der Bildgröße. Diese ist unbekannt, wenn Sie ein anderes Bild verwenden. Anstatt dies zu tun, können Sie die CSS-Eigenschaft „content“ so verwenden:

<div id="my-content-image"
  style="content: -webkit-image-set(
    url(icon1x.jpg) 1x,
    url(icon2x.jpg) 2x);">
</div>

Dadurch wird das Bild automatisch je nach devicePixelRatio skaliert. Weitere Informationen finden Sie unter dieses Beispiel für die oben beschriebene Technik in der Praxis mit einem zusätzlichen Fallback auf url() für Browser, die image-set.

Polyfilling srcset

Eine praktische Funktion von srcset ist, dass ein natürliches Fallback vorhanden ist. Falls das Attribut srcset nicht implementiert ist, werden alle Browser um das Attribut src zu verarbeiten. Da es sich lediglich um ein HTML- ist es möglich, Polyfills mit JavaScript.

Dieser Polyfill enthält Einheitentests, um sicherzustellen, dass so nah wie möglich an der Spezifikation liegen. Darüber hinaus gibt es Überprüfungen vorhanden, die verhindern, dass der Polyfill Code ausführt, wenn srcset ist nativ implementiert.

Hier ist eine Demo des Polyfills in Aktion.

Fazit

Es gibt keinen magischen Aufzählungspunkt, um das Problem von Bildern mit hohen DPI-Werten zu lösen.

Die einfachste Lösung besteht darin, auf Bilder zu verzichten, indem Sie sich für SVG und CSS entscheiden. . Dies ist jedoch nicht immer realistisch, insbesondere wenn Sie qualitativ hochwertiger Bilder auf Ihrer Website zu erstellen.

Ansätze in JS, CSS und die Verwendung der Serverseite haben alle ihre Stärken. und Schwächen. Der vielversprechendste Ansatz ist jedoch die Nutzung neuer Browserfunktionen. Obwohl die Browserunterstützung für image-set und srcset noch unvollständig ist, gibt es heute sinnvolle Alternativen.

Hier eine Zusammenfassung meiner Empfehlungen: