Responsive vs adaptive

Responsive design — de standaard

Responsive design (RWD) is sinds 2010 (Ethan Marcotte's artikel) de dominante aanpak. Eén HTML, één CSS, die zich aanpast aan het scherm via:

• Fluid grids: percentages in plaats van vaste pixel-breedtes
• Flexible images: max-width: 100% zodat foto's nooit groter zijn dan hun container
• CSS media queries: verschillende regels per schermbreedte

Voorbeeld media query:

/* Standaard: mobiel */
.hero { font-size: 24px; }

/* Tablet en hoger */
@media (min-width: 768px) {
  .hero { font-size: 36px; }
}

/* Desktop */
@media (min-width: 1200px) {
  .hero { font-size: 48px; }
}

Voordelen: één codebase, makkelijk te onderhouden, werkt op elk scherm inclusief toekomstige (vouwtelefoons, schermen die we nu nog niet kennen).

Adaptive design — de niche

Adaptive design (AWD) gebruikt meerdere vaste layouts, één per device-categorie:

• Layout 1: mobiel (320-767px)
• Layout 2: tablet (768-1023px)
• Layout 3: desktop (1024px+)

Server detecteert het device (via user-agent of viewport) en stuurt de juiste layout. Het is geen fluid systeem — tussen breakpoints "springt" de layout.

Voordelen: kan iets sneller laden (alleen de juiste CSS), en je kunt per device echt andere features tonen. Nadelen: meer onderhoud, breekt op nieuwe schermafmetingen, server-side detectie is niet altijd betrouwbaar.

Verschil in praktijk

Voorbeeld: een hovenier-site met een 12-foto-portfolio.

• Responsive: 4 kolommen op desktop, 2 op tablet, 1 op mobiel. CSS grid past zich aan. Eén HTML, één codebase.
• Adaptive: server detecteert mobiel → stuurt mobiele HTML met 1-kolom layout. Detecteert desktop → stuurt desktop HTML met 4-kolom. Aparte templates.

Resultaat ziet voor de bezoeker hetzelfde uit. Verschil zit in: onderhouds-effort, performance-marge, complexiteit.

Welke past bij MKB?

Voor 95% van MKB-sites: responsive.

Redenen:

• Eén codebase = goedkoper te onderhouden (1 set updates, niet 3)
• Werkt op elk scherm, inclusief nieuwe formaten
• Geen server-side device-detectie nodig (en die wordt steeds onbetrouwbaarder)
• SEO-vriendelijk: één URL, geen duplicate content
• Mobile-first design is altijd responsive (zie mobile-first uitleg)

De 5% gevallen waarin adaptive zinvol is:

• Grote e-commerce met device-specifieke checkout-flow. Mobiele apple-pay flow vs desktop creditcard-flow — feature-verschil rechtvaardigt complexere techniek.
• Web-apps met heel andere mobiele functionaliteit. Bijvoorbeeld een dashboard dat op mobiel een lite-versie heeft, op desktop een full-feature versie.
• High-traffic sites met agressieve performance-eisen. Bijvoorbeeld nieuwssites die op mobiel een 50KB-payload nodig hebben.

Voor MKB-sites (kapper, hovenier, garage, restaurant, klein bureau, sector-services) is geen van deze drie van toepassing. Responsive volstaat altijd.

Wat 95% van bureaus doet

Bijna elk modern CMS levert responsive output: WordPress (vrijwel elk thema), Webflow, Shopify, Squarespace, Wix. Adaptive vraagt expliciete server-side architectuur en wordt niet door deze platforms standaard ondersteund.

Sterker: 99.9% van bureaus heeft alleen responsive in portfolio. Adaptive is een specialisatie voor enterprise-development. Voor MKB is dat geen verlies — responsive is gewoon de juiste keuze.

Hoe weet je welke je hebt?

Drie tests:

1. Resize je browser-venster langzaam. Krimpt de site vloeiend met je venster mee (responsive) of springt hij op vaste punten (adaptive)?
2. Open dezelfde URL op een iPad-emulator en een iPhone-emulator. Krijg je verschillende HTML (adaptive) of dezelfde HTML met verschillende styling (responsive)?
3. Check je page-source. Heel veel media queries in CSS = responsive. Eén layout zonder media queries plus server-side device-detectie = adaptive.

Wanneer responsive niet goed werkt

Soms zien we MKB-sites die "responsief" zijn maar mobiel slecht werken. Vaak niet de aanpak, maar de uitvoering:

• Breakpoints op verkeerde plekken (overgang bij 1024px is voor desktop, niet voor tablet)
• Te veel verschillende layouts (5+ breakpoints = onderhouds-hel)
• Mobiel-CSS als afterthought (10% van de tijd) terwijl desktop 90% kreeg

De fix is dan niet "responsive vs adaptive" maar "responsive maar mobile-first uitgevoerd". Detail: mobile-first uitleg.

Voor MKB: focus op uitvoering, niet techniek

De vraag "responsive of adaptive" is voor MKB grotendeels academisch — responsive is altijd het antwoord. De échte vraag: is je responsive site mobile-first uitgevoerd, of is mobiel een afterthought?

Bij DesignCheck bouwen we responsive + mobile-first + Lighthouse 90+ garantie. Zie prijzen. Wat dit aan ranking en conversie oplevert: vul de verliescalculator in. Voor MKB in de regio: DesignCheck Mijdrecht.

Hoe responsive zich heeft ontwikkeld tussen 2010 en 2026

Toen Ethan Marcotte in 2010 de term responsive design lanceerde, bestond responsive uit drie technieken. Fluid grids, flexible images en media queries. Dat was alles. Het werkte voor de toestellen van die tijd, een iPad, een paar Android-telefoons en de standaard laptops. Vijftien jaar later is responsive een veel rijker vakgebied. CSS Grid, Flexbox, container queries, viewport units en logical properties hebben de oude technieken aangevuld of vervangen.

Wat in 2010 een media query was, is nu vaak een container query. Een component reageert niet meer op de breedte van het scherm maar op de breedte van zijn eigen container. Dat maakt herbruikbare componenten echt mogelijk, zonder dat je per pagina opnieuw moet beslissen wat groot of klein moet zijn. Voor een MKB-site die meerdere lay-outs combineert, een blog-feed naast een sidebar bijvoorbeeld, scheelt dit hele klassen van bug-bronnen.

De grootste sprong zit in viewport-units. Vroeger gebruikte je vh voor 100 procent van de schermhoogte, met als gevolg dat een sectie net iets te groot werd op iOS Safari door de adresbalk. In 2026 gebruik je dvh voor de dynamische viewport-hoogte, svh voor de kleinste viewport-hoogte of lvh voor de grootste. Daarmee verdwijnt de hele klasse van zichtbare scrolling-glitches die jarenlang frustrerend was.

Container queries in de praktijk

Een container query in CSS gedraagt zich zoals een media query, maar dan op het niveau van een container. Voorbeeld, een product-kaart die in een sidebar staat moet compact zijn met een verticale stapel. Diezelfde kaart in een drie-kolom-grid moet horizontaal zijn met een grotere afbeelding. Met een media query moet je deze gedrags-keuze per pagina-context vastleggen, met een container query niet. De kaart kijkt naar de breedte van zijn eigen container en past zich aan.

.card-grid { container-type: inline-size; }

.card { display: flex; flex-direction: column; }

@container (min-width: 480px) {
  .card { flex-direction: row; }
}

Voor een MKB-site met diensten-cards, project-tegels of blog-thumbnails verkort dit de onderhoudskosten substantieel. Wij gebruiken container queries in Groei- en Premium-pakketten standaard. In Starter alleen waar het concrete winst oplevert, omdat de browser-ondersteuning sinds 2023 wijd genoeg is om er op te bouwen.

Wanneer adaptive wel zinvol is — drie scenario's verder uitgewerkt

De drie genoemde scenario's in de eerdere paragraaf verdienen wat meer detail. Eén, een grote e-commerce met device-specifieke checkout-flow. Een nuance hier, sinds 2024 ondersteunt Apple Pay op desktop ook via Safari, dus de oude rechtvaardiging voor een aparte mobiele checkout is verwaterd. Wat overblijft, een mobile-only flow met QR-code scan, NFC of camera-toegang. Dan ben je beter af met een progressive web app dan met aparte adaptive templates.

Twee, web-apps met heel andere mobiele functionaliteit. Hier is de adaptive aanpak nog steeds verdedigbaar, mits je het patroon kiest waarbij dezelfde URL verschillende renders levert via een server-component-architectuur. Next.js en Remix maken dit relatief eenvoudig. Wat we afraden, een aparte m-subdomain met een eigen content-team. Dat is een onderhoudshel die binnen twee jaar in onbruik raakt.

Drie, high-traffic sites met agressieve performance-eisen. Hier komen we bij grote uitgevers, financiële instellingen of nieuws-platforms. Voor een MKB-bedrijf bestaat dit scenario simpelweg niet. Voor enterprise spelen aspecten als CDN-edge-rendering en HTTP/3 een rol, niet adaptive vs responsive.

Wat 2026 toevoegt aan de keuze

Sinds 2025 hebben we extra technieken die het verschil tussen responsive en adaptive verder doen verbleken. CSS subgrid voor genest grid-werk. Cascade layers voor expliciete CSS-prioriteit. View transitions voor vloeiende animaties tussen pagina's. Allemaal werken ze binnen een responsive aanpak, geen van alle vereisen ze adaptive infrastructuur.

Wat verder verandert is de aanpak van afbeeldingen. De combinatie van srcset, sizes en moderne formaten zoals AVIF maakt het mogelijk dat de browser zelf de juiste afbeelding kiest op basis van schermbreedte, resolutie en bandbreedte. Een goed gebouwde responsive site stuurt naar een iPhone SE een afbeelding van 360 pixels breed in AVIF van 18 kB en naar een 4K-monitor dezelfde foto in 2880 pixels breed van 240 kB. Geen server-detectie nodig.

Voor MKB-bedrijven is dit goed nieuws. Een rebuild in 2026 met moderne CSS levert op vrijwel elke metriek beter resultaat dan een adaptive aanpak uit 2018. Eén codebase, één deploy, één set updates. Bij Keurmeesters is de site volledig responsive opgebouwd, met container queries voor de aanvraag-component en moderne viewport-units voor de hero. Werkt zonder problemen op vouwtelefoons, ultra-wide schermen en alles ertussenin.

Uitgebreid stappenplan om je responsive site te verbeteren

1. Inventariseer alle media-queries in je huidige CSS. Plot ze op een schaal van 320 tot 1920 pixels en controleer of er gaten of overlappingen zitten.
2. Vervang vaste pixel-waarden in fontsizes door clamp-expressies voor vloeiende schaling.
3. Migreer waar mogelijk van media queries naar container queries voor herbruikbare componenten.
4. Vervang vh door dvh voor full-viewport secties op iOS Safari.
5. Update je afbeeldingen naar AVIF met WebP-fallback en JPEG-fallback voor oude browsers.
6. Voeg srcset en sizes toe op alle inhoud-afbeeldingen.
7. Test op een vouwtelefoon-emulator zoals Galaxy Z Fold of Pixel Fold.
8. Controleer dat geen enkele sectie horizontale scroll veroorzaakt op 320 pixels breed.
9. Verifieer dat tikgebieden minstens 44 pixels groot zijn op alle breakpoints.
10. Meet Lighthouse-scores op mobiel, tablet en desktop apart.
11. Vergelijk de CWV-veldgegevens in Search Console tussen mobiel en desktop.
12. Implementeer view transitions voor smooth overgangen, mits je framework dit ondersteunt.
13. Schrap onnodige media queries die geen merkbare visuele verschil opleveren.
14. Documenteer je breakpoints in een design-system zodat toekomstige updates consistent blijven.
15. Plan een onderhoudsmoment per kwartaal om nieuwe device-formaten te testen.

Een woord over toekomstbestendigheid

De keuze tussen responsive en adaptive is in 2026 niet alleen een vraag van wat nu werkt, maar van wat over vijf jaar nog werkt. De geschiedenis is duidelijk. Sites die in 2010 adaptive werden gebouwd, kregen problemen toen Android-toestellen tussen 480 en 1024 pixels breed verschenen. Sites die in 2015 adaptive werden gebouwd, kregen problemen toen iPad Pro op 1366 pixels breed kwam. Sites die in 2020 adaptive werden gebouwd, kregen problemen toen vouwtelefoons op 720 of 768 pixels breed verschenen.

Een responsive site die mobile-first is opgebouwd, met moderne CSS-technieken, werkt morgen ook nog. Hij heeft geen device-database nodig die jaarlijks geactualiseerd moet worden. Hij heeft geen server-side detectie die de bandbreedte van je hosting laat exploderen. Hij heeft één bron van waarheid, namelijk de bezoeker en zijn werkelijke schermbreedte op het moment van laden.

Voor MKB betekent dit, kies altijd responsive en investeer in de uitvoering. Een goed uitgevoerde responsive site is sneller, goedkoper in onderhoud en future-proof. Adaptive is een specialisatie die je inhuurt als je echt enterprise-eisen hebt en het MKB heeft die zelden.

Wat doe je vandaag?

Pak je laptop, open je homepage en sleep het venster langzaam van 1600 pixels naar 320 pixels. Schrijf op welke breakpoints je ziet, hoe scherp de overgangen zijn en of ergens iets buiten beeld valt. Open daarna dezelfde pagina op je telefoon en draai hem horizontaal naar landschap. Werkt alles nog? Bij twee of meer ongerechtigheden, vraag de gratis audit aan en stuur je observaties mee. Wij gebruiken ze als startpunt voor een eerlijk fix-of-rebuild-advies.

Gerelateerde gidsen

• Diagnose: site niet op telefoon
• Mobile-first 2026
• Mobile conversie tips
• Core Web Vitals voor MKB

FAQ — responsive vs adaptive

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.