Webafbeeldingen opschalen voor Retina-displays: een ontwikkelaarsgids

Als u ooit op uw MacBook Pro of iPhone hebt ingezoomd op een website en gemerkt hebt dat sommige afbeeldingen scherp zijn terwijl andere wazig lijken, hebt u het Retina-display-probleem uit eerste hand ervaren. Als frontend-ontwikkelaars leveren we pixels — en in 2025 landen de meeste van die pixels op schermen met device pixel ratio's ruim boven 1.0.

Deze gids behandelt alles wat u moet weten: wat device pixel ratio werkelijk betekent, hoe u de juiste afbeelding naar het juiste scherm stuurt, wanneer u raster helemaal overslaat en SVG gebruikt, en hoe u een optimalisatie-pipeline bouwt die uw Lighthouse-score in het groen houdt.

Device Pixel Ratio (DPR) begrijpen

Device Pixel Ratio is de verhouding tussen CSS-pixels (de logische eenheden die we in onze stylesheets schrijven) en fysieke apparaatpixels (de daadwerkelijke hardwarepunten op het scherm). Een DPR van 2 betekent dat elke CSS-pixel overeenkomt met een 2×2 raster van fysieke pixels — vier keer zoveel punten.

Veelvoorkomende DPR-waarden per apparaat

De praktische implicatie is eenvoudig maar diepgaand: als u een <img> toont op 400×300 CSS-pixels op een 2x-scherm, rekt de browser een 400×300 bronafbeelding uit over 800×600 fysieke pixels. Het resultaat is dat kenmerkende "zachte" uiterlijk — technisch correct, maar zichtbaar inferieur aan een natief scherpe afbeelding.

De wiskunde achter Retina-Ready afbeeldingen

Om een pixelperfecte afbeelding te serveren bij elk DPR, vermenigvuldigt u de CSS-weergavedimensies met het DPR:

Bronbreedte  = CSS-weergavebreedte  × DPR
Bronhoogte = CSS-weergavehoogte × DPR

Voor een hero-banner weergegeven op 1200×600 CSS-pixels:

• 1x-scherm: 1200×600px bron (1:1 mapping)
• 2x-scherm: 2400×1200px bron (4× het aantal pixels)
• 3x-scherm: 3600×1800px bron (9× het aantal pixels)

Responsive afbeeldingen met srcset en sizes

Het HTML-attribuut srcset is de hoeksteen van Retina-ready responsive afbeeldingen. Het geeft de browser een menu van afbeeldingsbestanden op verschillende resoluties, en de browser selecteert de meest geschikte op basis van het DPR van het apparaat en de viewport-grootte.

Basis srcset met breedtedescriptors

<img
  src="/images/hero-800w.jpg"
  srcset="
    /images/hero-400w.jpg   400w,
    /images/hero-800w.jpg   800w,
    /images/hero-1200w.jpg 1200w,
    /images/hero-1600w.jpg 1600w,
    /images/hero-2400w.jpg 2400w
  "
  sizes="
    (max-width: 640px) 100vw,
    (max-width: 1024px) 75vw,
    50vw
  "
  alt="Hero-afbeelding productpresentatie"
  width="1200"
  height="600"
  loading="lazy"
  decoding="async"
/>

Laten we ontleden wat hier gebeurt:

1. srcset somt elk afbeeldingsbestand op gevolgd door zijn intrinsieke breedte (de w-descriptor). De browser weet nu precies hoeveel pixels elk bestand bevat.
2. sizes vertelt de browser hoe breed de afbeelding wordt gerenderd op verschillende breakpoints. Op schermen tot 640px breed vult de afbeelding het volledige viewport (100vw). Op tablets 75%. Op desktop 50%.
3. De browser combineert sizes met devicePixelRatio om de ideale bronbreedte te berekenen en kiest vervolgens de dichtstbijzijnde match uit srcset.

srcset met pixeldichtheid-descriptors

Voor afbeeldingen met vaste grootte (zoals avatars of iconen) kunt u de x-descriptor gebruiken:

<!-- Avatar met vaste grootte: altijd 48×48 CSS-pixels -->
<img
  src="/avatars/user-48.png"
  srcset="
    /avatars/user-48.png  1x,
    /avatars/user-96.png  2x,
    /avatars/user-144.png 3x
  "
  alt="Gebruikersavatar"
  width="48"
  height="48"
/>

Deze aanpak is schoner voor elementen met vaste grootte omdat u het sizes-attribuut niet nodig hebt. De browser matcht simpelweg de descriptor met zijn DPR.

Het <picture>-element voor art direction

Soms hebt u meer nodig dan resolutiewisseling — u hebt volledig andere beelduitsneden of formaten nodig voor verschillende contexten. Daar komt <picture> om de hoek kijken:

<picture>
  <!-- AVIF voor ondersteunende browsers (beste compressie) -->
  <source
    type="image/avif"
    srcset="
      /images/hero-800w.avif   800w,
      /images/hero-1600w.avif 1600w,
      /images/hero-2400w.avif 2400w
    "
    sizes="(max-width: 1024px) 100vw, 50vw"
  />
  <!-- WebP als fallback -->
  <source
    type="image/webp"
    srcset="
      /images/hero-800w.png   800w,
      /images/hero-1600w.png 1600w,
      /images/hero-2400w.png 2400w
    "
    sizes="(max-width: 1024px) 100vw, 50vw"
  />
  <!-- JPEG-fallback voor oudere browsers -->
  <img
    src="/images/hero-800w.jpg"
    srcset="
      /images/hero-800w.jpg   800w,
      /images/hero-1600w.jpg 1600w,
      /images/hero-2400w.jpg 2400w
    "
    sizes="(max-width: 1024px) 100vw, 50vw"
    alt="Productpresentatie"
    width="1200"
    height="600"
    loading="lazy"
  />
</picture>

"

De snelste afbeelding is degene die perfect gedimensioneerd is voor het apparaat dat ernaar kijkt — geen pixel meer, geen pixel minder.

Wanneer SVG beter is dan upscalen

Voordat u tijd investeert in het genereren van 2x en 3x rastervarianten, vraag uzelf af: moet deze afbeelding eigenlijk wel raster zijn? Voor veel gangbare UI-elementen is SVG de objectief betere keuze.

SVG vs Raster: een beslissingsframework

Inline SVG voor maximale prestaties

Voor kritieke UI-iconen elimineert inline SVG een HTTP-verzoek volledig:

<!-- Inline SVG-icoon — nul netwerkverzoeken, directe rendering -->
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"
     width="24" height="24" fill="none" stroke="currentColor"
     stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
  <circle cx="11" cy="11" r="8"/>
  <path d="M21 21l-4.35-4.35"/>
</svg>

Omdat SVG currentColor gebruikt, erft het icoon automatisch de tekstkleur van het bovenliggende element — perfect voor theming en dark mode-ondersteuning.

Een afbeeldingsoptimalisatie-pipeline bouwen

Retina-ready afbeeldingen serveren zonder optimalisatie-pipeline is als een sportwagen kopen en vullen met laagwaardige brandstof. U hebt een systematisch proces nodig dat formaataanpassing, compressie, formaatconversie en levering afhandelt.

De vierfasen-pipeline

Fase 1: Bronvoorbereiding

Begin altijd met de hoogst mogelijke bronkwaliteit. Voor fotografie betekent dat het originele camerabestand of een lossless export. Voor design-assets exporteert u vanuit Figma of Sketch op 3x of hoger.

Fase 2: Multi-resolutiegeneratie

Genereer varianten op standaard breakpoints. Een gangbare set is 400w, 800w, 1200w, 1600w en 2400w:

/* Voorbeeld: CSS voor een responsive hero met background-image */
.hero {
  background-image: url("/images/hero-1200w.png");
  background-size: cover;
  background-position: center;
}

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
  .hero {
    background-image: url("/images/hero-2400w.png");
  }
}

/* Voor achtergrondafbeeldingen zijn media queries de enige manier
   om DPR-bewuste varianten te serveren */

Fase 3: Formaatconversie en compressie

Converteer elke variant naar moderne formaten. De prioriteitsvolgorde is:

1. AVIF — Beste compressie (30–50% kleiner dan WebP), groeiende browserondersteuning
2. WebP — Uitstekende compressie, bijna universele browserondersteuning
3. JPEG/PNG — Fallback voor oudere browsers

<!-- Het resultaat in uw HTML na pipeline-verwerking -->
<picture>
  <source type="image/avif" srcset="/img/photo.avif" />
  <source type="image/webp" srcset="/img/photo.png" />
  <img src="/img/photo.jpg" alt="Geoptimaliseerde foto" />
</picture>

Fase 4: CDN-levering

Serveer afbeeldingen vanaf een CDN met edge caching. Veel CDN's (Cloudflare, Vercel, Imgix) bieden on-the-fly beeldtransformatie, die fasen 2 en 3 volledig kan vervangen:

<!-- Cloudflare Image Resizing -->
<img
  src="/cdn-cgi/image/width=800,format=auto,quality=80/images/hero.jpg"
  srcset="
    /cdn-cgi/image/width=400,format=auto,quality=80/images/hero.jpg   400w,
    /cdn-cgi/image/width=800,format=auto,quality=80/images/hero.jpg   800w,
    /cdn-cgi/image/width=1200,format=auto,quality=80/images/hero.jpg 1200w,
    /cdn-cgi/image/width=2400,format=auto,quality=80/images/hero.jpg 2400w
  "
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="CDN-geoptimaliseerde hero"
/>

Next.js Image-component: de moderne aanpak

Als u aan een Next.js-project werkt, handelt de ingebouwde <Image>-component de meeste Retina-zorgen automatisch af. Het is de grootste verbetering van levenskwaliteit voor beeldverwerking in React.

Basisgebruik

<!-- Next.js genereert automatisch srcset met
     meerdere resoluties en serveert WebP/AVIF -->
<img
  src="/_next/image?url=%2Fimages%2Fhero.jpg&w=1200&q=75"
  srcset="
    /_next/image?url=%2Fimages%2Fhero.jpg&w=640&q=75   640w,
    /_next/image?url=%2Fimages%2Fhero.jpg&w=750&q=75   750w,
    /_next/image?url=%2Fimages%2Fhero.jpg&w=828&q=75   828w,
    /_next/image?url=%2Fimages%2Fhero.jpg&w=1080&q=75 1080w,
    /_next/image?url=%2Fimages%2Fhero.jpg&w=1200&q=75 1200w
  "
  sizes="100vw"
  alt="Hero-afbeelding"
  loading="lazy"
  decoding="async"
/>

Geavanceerde configuratie

Pas de gegenereerde formaten aan in next.config.js:

<!-- Wat Next.js Image produceert voor een responsive hero -->
<!-- Met priority-prop voor above-the-fold LCP-afbeeldingen -->
<img
  src="/_next/image?url=%2Fhero.jpg&w=3840&q=80"
  srcset="
    /_next/image?url=%2Fhero.jpg&w=640&q=80    640w,
    /_next/image?url=%2Fhero.jpg&w=1080&q=80  1080w,
    /_next/image?url=%2Fhero.jpg&w=1920&q=80  1920w,
    /_next/image?url=%2Fhero.jpg&w=3840&q=80  3840w
  "
  sizes="100vw"
  alt="Above-the-fold hero"
  fetchpriority="high"
  decoding="async"
  style="color:transparent"
/>

Prestatieoverwegingen en Core Web Vitals

Afbeeldingen zijn doorgaans de zwaarste assets op elke webpagina, vaak goed voor 50–70% van het totale paginagewicht. Retina-afbeeldingen goed aanpakken heeft een directe, meetbare impact op uw Core Web Vitals.

Impact op belangrijke metrics

Lighthouse Audit: "Correct gedimensioneerde afbeeldingen"

Lighthouse markeert afbeeldingen waarvan het geserveerde bestand aanzienlijk groter is dan de weergavegrootte. Zo slaagt u consistent voor deze audit:

1. Serveer nooit één te grote afbeelding. Gebruik srcset om geschikte formaten te bieden.
2. Richt op maximaal 2x voor de meeste gevallen. 3x-afbeeldingen serveren biedt afnemende visuele opbrengsten terwijl de bestandsgrootte aanzienlijk toeneemt. De meeste gebruikers kunnen het verschil tussen 2x en 3x niet waarnemen op schermen kleiner dan 27 inch.
3. Comprimeer agressief. WebP op kwaliteit 80 is visueel niet te onderscheiden van JPEG op kwaliteit 95 voor de meeste fotografische inhoud, bij ruwweg de helft van de bestandsgrootte.

"

We ontdekten dat de overstap van niet-geoptimaliseerde PNG's naar correct gedimensioneerde WebP met srcset onze afbeeldingslast met 73% verminderde en onze Lighthouse Performance-score verbeterde van 62 naar 94.

Lazy loading-strategie

Niet elke afbeelding hoeft direct te laden. Gebruik native lazy loading voor below-the-fold content:

<!-- Above the fold: direct laden met hoge prioriteit -->
<img
  src="/hero-800w.png"
  srcset="/hero-800w.png 800w, /hero-1600w.png 1600w"
  sizes="100vw"
  alt="Hero-banner"
  fetchpriority="high"
  decoding="async"
/>

<!-- Below the fold: lazy load -->
<img
  src="/feature-800w.png"
  srcset="/feature-800w.png 800w, /feature-1600w.png 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Feature-screenshot"
  loading="lazy"
  decoding="async"
  width="800"
  height="450"
/>

Checklist voor responsive afbeeldingen best practices

Na het doorwerken van honderden afbeeldingsoptimalisatie-audits, is hier de gedestilleerde checklist die ik bij elk project volg:

Voor elke afbeelding op uw site

• Stel expliciete width- en height-attributen in om CLS te voorkomen
• Gebruik loading="lazy" voor below-the-fold afbeeldingen en fetchpriority="high" voor de LCP-afbeelding
• Voeg betekenisvolle alt-tekst toe voor toegankelijkheid en SEO
• Gebruik decoding="async" om de main thread niet te blokkeren

Voor fotografische inhoud

• Genereer minstens 4–5 srcset-varianten (bijv. 400w, 800w, 1200w, 1600w, 2400w)
• Serveer AVIF met WebP-fallback via <picture> of CDN auto-formaat
• Comprimeer op kwaliteit 75–85 voor WebP (visueel lossless voor de meeste inhoud)
• Begrens de maximale resolutie op 2x van de grootste verwachte weergavegrootte (bijv. 2400w voor een 1200px container)

Voor iconen en UI-elementen

• Gebruik SVG waar mogelijk — het is resolutie-onafhankelijk en minuscuul
• Neem kritieke SVG-iconen inline op om HTTP-verzoeken te elimineren
• Gebruik een icon-sprite of symboolsysteem voor herhaalde iconen
• Pas fill="currentColor" toe voor automatische thema-aanpassing

Voor CSS-achtergrondafbeeldingen

• Gebruik image-set() voor DPR-bewuste achtergronden (het CSS-equivalent van srcset):

.hero-bg {
  /* Fallback voor oudere browsers */
  background-image: url("/images/hero-1x.png");

  /* Moderne DPR-bewuste syntax */
  background-image: image-set(
    url("/images/hero-1x.png") 1x,
    url("/images/hero-2x.png") 2x
  );
  background-size: cover;
  background-position: center;
}

Conclusie

Retina-ready afbeeldingen zijn geen luxe — ze zijn een basisverwachting op het moderne web. Het goede nieuws is dat de tools en standaarden volwassen zijn: srcset en sizes geven browsers alles wat ze nodig hebben om slimme beslissingen te nemen, SVG elimineert het DPR-probleem volledig voor vectorinhoud, en frameworks zoals Next.js automatiseren het zware werk.

De sleutel is het bouwen van een systematische pipeline: begin met bronnen van hoge kwaliteit, genereer meerdere resoluties, comprimeer in moderne formaten, en laat de browser (of CDN) het juiste asset naar het juiste apparaat sturen. Doe dit goed, en u levert pagina's die er vlijmscherp uitzien op elk scherm terwijl uw Lighthouse-score stevig in het groen blijft.

Bronnen en verdere lectuur

• MDN: Responsive Images — Volledige ontwikkelaarsreferentie voor gebruik van srcset, sizes en het picture-element
• web.dev: Serve Responsive Images — Google's prestatiegerichte gids voor het serveren van optimale afbeeldingen per apparaat
• CSS-Tricks: Using SVG — Waarom SVG het ideale formaat is voor resolutie-onafhankelijke webafbeeldingen
• Smashing Magazine: Retina Images — Diepgaande technische gids voor het omgaan met high-DPI-displays in moderne webontwikkeling