How Modern Screens Impact front-end Performance

How Modern Screens Impact Front-end Performance: Density vs Technology

Green UX December 11, 2025

Density vs Technology

The evolution of screens (Retina, high PPI, DPR2/3, P3 gamut, mini-LED and now OLED) has radically changed the way our interfaces are rendered. Yet the topic is usually explained with all the clarity of a badly burned pirate DVD menu: density, DPR, PPI, Retina, subpixels... everything gets mixed up, and many developers no longer really know what actually impacts front-end performance.

Spoiler: it is not the panel technology. What really matters is pixel density and the way assets are managed. An OLED screen will never slow down a site; a poorly prepared image on a DPR3 screen, however, can make it look blurry, heavy or simply badly built. This article brings order to this hybrid topic, where hardware, rendering, responsive images and energy constraints all intersect, so we can finally understand what actually counts.

Key concepts index

PPI: pixels per inch (number of physical pixels on one inch of the panel) → physical density of the screen, expressed in pixels per inch. The higher the PPI, the sharper the display. It is a hardware-level measure, like battery size or the number of LEDs in a display. Example: a 5" Full HD screen → ~440 PPI; a 27" 4K screen → ~163 PPI; a modern iPhone Pro → ~460 PPI.
DPI: dots per inch → legacy term for PPI, mostly used in print. On the web, you can ignore it.
Density (HiDPI): quantity of physical pixels in a given surface area. It is what determines perceived sharpness. A high-density (HiDPI) screen uses several physical pixels to render a single CSS pixel. Consequences: x2/x3 images, SVG mandatory, text more sensitive to typographic flaws.
Retina: marketing term coined by Apple. It does not describe a panel type. It simply refers to a high-density screen (HiDPI) where one CSS pixel is rendered using several physical pixels (DPR > 1). Panel technology is unrelated: an LCD screen can be “Retina”, and so can an OLED.
Subpixels: every physical pixel is made of three subpixels (red, green and blue, R/G/B), laid out horizontally or vertically depending on the panel. Their combination creates the perceived color. The structure varies between technologies (LCD, OLED, PenTile).
Subpixel rendering: antialiasing technique used by rendering engines (CoreText, DirectWrite, etc.) that exploits R/G/B subpixels to smooth letter edges and increase sharpness. Very useful on low-density screens, less perceptible on HiDPI and sometimes disabled depending on the OS or panel technology.
CSS pixel: virtual unit used by browsers to keep interfaces readable and consistent across all screens. A CSS pixel is never a physical pixel: its size adapts to density (PPI), devicePixelRatio, zoom and accessibility settings. It prevents UIs from becoming microscopic on high-density displays and serves as the common base unit for responsive layout.
DPR: devicePixelRatio = (physical pixel size) / (CSS pixel size) → ratio between physical pixels and CSS pixels. This is how the browser translates real hardware density into CSS units, the bridge between physical reality and layout. Example: on a high-PPI display, several physical pixels are used to render a single CSS pixel: DPR 2, 3, sometimes 4.
Gamut (sRGB, P3): range of colors a display can render. Modern screens can show a wider gamut, which impacts image quality and weight.
Resolution: total number of physical pixels the screen can display, expressed as width × height (for example 1920×1080). Resolution alone says nothing about sharpness: two screens can share the same resolution and have very different sharpness depending on their physical size. Example: 1920×1080 on 5" → very sharp (high PPI); 1920×1080 on 27" → much softer (low PPI).
Display technology (LCD, mini-LED, OLED): panel type. Almost no direct impact on classic front-end performance, but a significant impact on perceived visuals and, for OLED, on energy consumption.
Responsive images (srcset, sizes, image-set): mechanisms that allow the browser to choose the most appropriate image depending on density and actual rendered size.
Modern formats (AVIF, WebP, SVG): lighter formats designed for high-density displays, now essential for performance.

What display technology does not change

LCD, mini-LED or OLED do not change loading times, CSS performance, JS execution or layout behavior. Browsers do not even know which panel technology is used (and do not care).

What actually changes is visual perception:

richer colors (especially with P3),
deeper blacks,
slightly different text rendering on OLED.

But in terms of classic front-end performance (asset weight, requests, rendering, layout), nothing changes. The only real difference is energy impact: on OLED, black pixels are effectively off, so a dark design consumes far less energy than a bright one. On mobile, that can improve battery life. On desktop, it reduces power consumption and can add up significantly if users spend a lot of time on a given interface.

The real impact is density (PPI)

Retina is not a technology, it is a ratio. As PPI increases, devicePixelRatio (DPR) goes up (2x, 3x), and assets need to be sharper. High-density screens do not forgive: approximate images or raster icons are exposed immediately.

What high-density screens instantly reveal

under-dimensioned images,
non-vector icons (blurry PNGs),
weak typography (too thin or poor contrast),
8-bit gradients straight out of nostalgic Windows XP.

A dense screen is a magnifying glass. And a magnifying glass forgives nothing.

Getting assets right: where the real work is

Which means you need to implement conditional rendering that is both optimized and UX-safe.

Images and DPR

To correctly display a 100×100 CSS pixel square:

DPR 2 → 200×200 px image,
DPR 3 → 300×300 px image.

If no resource is provided for DPR3, the browser will fetch the 2x image, stretch it and render it blurry. That means worse UX and wasted bandwidth.

A solid example

<picture>
      <source
        media="(min-width: 1024px)"
        type="image/avif"
        srcset="
          ${content.custom.desktopImage.URL}?sw=1200&sh=675&sm=fit 1x,
          ${content.custom.desktopImage.URL}?sw=2400&sh=1350&sm=fit 2x
        "
      >
      <source
        media="(min-width: 1024px)"
        type="image/webp"
        srcset="
          ${content.custom.desktopImage.URL}?sw=1200&sh=675&sm=fit 1x,
          ${content.custom.desktopImage.URL}?sw=2400&sh=1350&sm=fit 2x
        "
      >
    
      <source
        media="(max-width: 1023px)"
        type="image/avif"
        srcset="
          ${content.custom.mobileImage.URL}?sw=750&sh=1000&sm=fit 1x,
          ${content.custom.mobileImage.URL}?sw=1500&sh=2000&sm=fit 2x
        "
      >
      <source
        media="(max-width: 1023px)"
        type="image/webp"
        srcset="
          ${content.custom.mobileImage.URL}?sw=750&sh=1000&sm=fit 1x,
          ${content.custom.mobileImage.URL}?sw=1500&sh=2000&sm=fit 2x
        "
      >
    
      <img
        src="${content.custom.mobileImage.URL}?sw=750&sh=1000&sm=fit"
        width="750"
        height="1000"
        alt="${content.custom.imageAlt}"
        loading="lazy"
        decoding="async"
      >
    </picture>

Image formats

Knowing which formats to use is key to reducing impact:

AVIF: excellent compression, P3 support, ideal for HiDPI,
WebP: good modern compromise,
JPEG: still useful as fallback (broad browser compatibility),
PNG: for complex transparency only, otherwise avoid,
SVG: mandatory for icons and logos,
Lottie: lightweight vector animations (to replace GIFs and small MP4s).

Text, subpixels and CSS units

HiDPI reduces the effect of subpixel rendering, which makes every typographic flaw more visible. You need:

typefaces that behave well on HiDPI,
solid contrast,
reasonable sizes (no 12px anorexic body text),
extra care with ultra-thin fonts on OLED.

CSS units: prefer rem over px.

On high-density or OLED screens, legibility depends both on rendering precision and on effective text size. Pixel units are rigid: they do not always respect zoom and user preferences and often produce text that is too small on HiDPI. rem (or em) units give you a fluid, accessible typographic scale that adapts better to density variations. In practice: if you want text that is truly readable on modern displays, rem beats px.

P3 gamut: wider, nicer and slightly dangerous

Gamut is the range of colors a display can render. Historically, the web has been based on sRGB, a fairly limited color space. Modern displays (especially Apple and OLED) support Display-P3, a gamut roughly 25% wider, with more saturated reds and greens and higher perceived contrast.

In practice:

an sRGB image can look a bit dull on a P3 display,
a P3 image can be unnecessarily heavy if the display only supports sRGB,
modern formats such as AVIF handle wide gamut very well without blowing up file size.

Simple rule:

Use P3 only when aesthetic consistency is critical (luxury, photography, premium brands). Stick to sRGB for standard contexts. I will cover this in depth in a dedicated article (formats, export workflows, ICC profiles, DPR and color management).

Why DPR stops at 3x

DPR is very unlikely to go beyond 3x because OS vendors and hardware manufacturers define these buckets. Apple, Google and Microsoft have converged on a set of maximum values for a few reasons:

Perceptual limit: beyond 3x, most people cannot see additional sharpness at normal viewing distance (the Retina threshold),
Cost and performance: DPR 4 or 5 would dramatically increase GPU and energy cost and force the download of much heavier assets (for example about 9 million pixels for a DPR3 image versus 16 million for DPR4, for the same CSS size),
UI stability: too many scaling ratios would make UI behavior harder to predict and design for.

This is very likely the end of the road. As front-end developers, our job is to make sure assets are optimized up to DPR3.

What screens people actually use in 2025

HiDPI has become the norm on mobile: most Android smartphones are DPR2, and all iPhones have shipped with HiDPI + P3 support for years. On desktop, the picture is more mixed: Windows is still mostly sRGB and DPR1, while the whole Apple ecosystem (MacBook, iMac, Studio Display) is 100% HiDPI and 100% P3.

In practice: sRGB + DPR1 still represents a large share of “mainstream” traffic, while P3 + DPR2/3 is already the reality for premium users, the ones who notice rendering flaws instantly.

OLED + DPR3: balancing design ambition and front-end performance

The widespread arrival of OLED will improve perceived contrast, make UI flaws more visible, demand more precise typography, reward high-quality gradients and shadows, and give dark themes a real energy advantage: fewer lit pixels means lower power use, which is a green UX topic that will only grow.

Screen evolution is essentially a matter of discipline around assets, formats, densities and gamuts. Density forces us to design better image pipelines. P3 gamut forces cleaner color management. DPR3 forces a clean asset pipeline. OLED forces energy awareness.

You need a genuine balance between the art director’s vision, who wants huge, immaculate visuals because “pixels are a noble material”, and the lead front-end’s reality, whose job is to prevent those same visuals from crushing performance like a mammoth sitting on a 4G modem. A luxury brand will happily accept heavier, higher-resolution, often P3 images to serve design excellence; it is then up to front-end to tame that ambition with advanced responsive techniques: conditional loading up to DPR3, clean fallbacks, smart format choices, HiDPI-friendly typography, and so on. On more standard projects, you can stay pragmatic: lighter assets, tuned for DPR1–2, in classic sRGB, and an optimization strategy that favors efficiency over museum-grade visual theatrics.

Summary table - Asset management best practices

Bitmap images: provide 1x / 2x / 3x variants via srcset. This ensures optimal sharpness per DPR and avoids blur plus wasteful reloads. Avoid: a single image served to everyone.
Responsive images: always use srcset + sizes (or <source> / <picture>). The browser chooses the best resource (minimal weight for acceptable quality). Avoid: images much wider than the viewport.
Modern formats: favor AVIF, with WebP as fallback and JPEG as last resort. This optimizes weight, quality, P3 support and compression. Avoid: photographic PNGs, uncompressed JPEGs.
Logos and icons: use SVG by default. This guarantees perfect sharpness on all DPR values with minimal weight. Avoid: 1x PNG icons and bitmap sprite sheets.
Animations: use Lottie (vector JSON) whenever possible. Lightweight, scalable, HiDPI-friendly. Avoid: GIFs and heavy MP4s for tiny UI animations.
CSS backgrounds: use image-set() to handle DPR. This serves the right ratio for each density. Avoid: a single 1x image stretched and blurry.
P3 vs sRGB: export in P3 only when necessary; AVIF is recommended for P3 workflows. This preserves color fidelity on OLED/Retina without huge files. Avoid: oversized P3 PNGs.
Text and typography: HiDPI-friendly fonts and solid contrast. HiDPI/OLED make every typographic flaw obvious. Avoid: fonts that are too thin or low contrast.
Dark mode (OLED): favor dark or muted themes. On OLED, black pixels are off, which saves energy. Avoid: vast, pure-white areas everywhere.
Asset weight: aim for less than 150–200 KB for the LCP image when possible. That keeps LCP fast and perceived UX smooth. Avoid: 1 MB hero images “because the art director said so”.
Fallbacks: always plan AVIF → WebP → JPEG. This guarantees compatibility without surprises. Avoid: AVIF alone with no fallback.
Project strategy: luxury projects can accept heavier assets if they are responsive and conditional, preserving visual excellence. For standard projects, DPR1–2 is enough for most users, with simpler optimization for excellent results. Avoid: serving “luxury” assets to everyone, or over-optimizing simple projects just for the sake of it.