Waarom LiteSpeed vaak sneller is dan NGINX – interne architectuur uitgelegd

LiteSpeed NGINX vertoont in een directe vergelijking vaak merkbare verschillen, omdat beide webservers verzoeken intern anders verwerken en prioriteren. Ik leg duidelijk uit hoe event loops, geïntegreerde cache en protocollen zoals HTTP/3 samenwerken en waarom dit precies een meetbaar snelheidsvoordeel oplevert.

Centrale punten

Ik vat vooraf de belangrijkste bevindingen samen, zodat je de architectuur sneller kunt begrijpen. De lijst helpt je om prioriteiten te stellen en technische beslissingen met meer zekerheid te nemen. Elk punt behandelt een kernfactor die van belang is in benchmarks en in het dagelijks gebruik. Lees daarna verder om de mechanica achter de effecten te begrijpen. Ik koppel de uitspraken aan concrete praktijkvoorbeelden en vermeld waar nodig bronvermeldingen zoals [1][2].

• Architectuur van evenementen: Beide werken op basis van gebeurtenissen, LiteSpeed integreert meer functies rechtstreeks in de pijplijn.
• Cache-integratie: LiteSpeed heeft een cache in de kern, NGINX heeft vaak aparte regels en tools nodig.
• HTTP/3/QUIC: LiteSpeed levert in veel tests hogere doorvoersnelheden bij een lagere CPU-belasting [2].
• Bronnen: Slanke standaardinstellingen zorgen bij LiteSpeed voor meer verzoeken per kern [2][5].
• WordPress: Plug-in-gebaseerde besturing levert snelle resultaten zonder diepgaande serverconfiguraties [4][5].

Deze punten geven al de richting aan: geïntegreerde functies besparen tijd en rekenkracht. In het volgende deel ga ik in op de onderliggende Architectuur van evenementen en leg de verschillen in de request-pijplijn uit. Daarna zie je waarom cachebeslissingen de snelheid bepalen en hoe protocollen de doorslag geven. Zo kun je uiteindelijk een beslissing nemen die past bij de belasting, het budget en de tech-stack.

Evenementarchitectuur in het kort uitgelegd

Beide servers werken gebeurtenisgestuurd, maar ze geven verschillende prioriteiten aan taken in de pijplijn. NGINX maakt gebruik van een masterproces met meerdere workers die via epoll/kqueue veel verbindingen parallel bedienen [3]. LiteSpeed maakt ook gebruik van een event-model, maar integreert cache, compressie, protocoloptimalisatie en veiligheidsfilters nauwer met de kern [1][5]. Hierdoor bespaar ik bij LiteSpeed vaak contextwisselingen en kopieerwerk tijdens de verwerking. Voor een grondigere afstemming van workers en threads is het de moeite waard om eens te kijken naar de Threadpool-optimalisatie.

In de praktijk voelt deze architectuur bij LiteSpeed „korter“ aan, omdat er minder afzonderlijke componenten tussen aankomst en antwoord zitten. Ik profiteer hiervan vooral bij veel kleine verzoeken en gemengde inhoud. NGINX bereikt vergelijkbare waarden, maar heeft daarvoor meestal gerichte optimalisaties per nodig. Stapel. Wie dat wil, kan NGINX heel nauwkeurig afstemmen op workloads; zonder fijnafstemming laat men echter potentieel liggen [3][4].

PHP-integratie en procesmodel

Een onderschatte snelheidsfactor is de koppeling met PHP. LiteSpeed maakt gebruik van LSAPI, een slanke, persistent verbonden interface die queueing, keep-alive en procesbeheer zeer nauw coördineert met de webserver [1][5]. Dit vermindert contextwisselingen en vermindert de latentie tussen de webserver en PHP-workers. NGINX communiceert doorgaans met PHP-FPM via FastCGI. FPM is stabiel en wijdverspreid, maar de wachtrijen, socketbuffers en dynamiek (statisch/dynamisch/op aanvraag) moeten goed aansluiten bij het verkeersprofiel, anders stijgen de TTFB-pieken – vooral bij korte PHP-transacties, zoals gebruikelijk is in WordPress [3][4].

Ik merk dat LSAPI onder burst-belasting minder „zaagtand“-latenties vertoont, omdat verzoeken vloeiender worden doorgegeven. Daar komt nog de nauwe koppeling aan de geïntegreerde paginacache van LiteSpeed bij: wanneer er een cache-miss optreedt, verloopt de overgang naar PHP vaak sneller. Met NGINX + PHP-FPM kan ik dit ook optimaliseren (socket vs. TCP, pm.max_children, opcache fijn afstemmen), maar dit vereist diagnose en tests per omgeving. Voor veel teams is de geïntegreerde interactie bij LiteSpeed de betrouwbaardere basis [1][5].

Cache-strategieën: geïntegreerd versus extern

Het grootste verschil in het dagelijks leven zit hem in Caching. NGINX biedt FastCGI en proxycache, maar ik onderhoud de regels, sleutels, PURGE-logica en app-specifieke uitzonderingen handmatig [3][4]. Voor dynamische CMS-systemen zoals WordPress of winkelsystemen heb ik snel extra tools nodig om een vergelijkbare flexibiliteit te bereiken. LiteSpeed biedt de paginacache direct in de server, inclusief ESI voor dynamische blokken en nauwe afstemming met PHP-toepassingen [1][4][5]. Zo blijft de cache consistent en vinden purges op de juiste plaatsen plaats, zonder dat ik ingewikkelde scripts hoef te bouwen.

Ik zie in projecten vaak dat LiteSpeed „out of the box“ hoge cache-hitpercentages levert. De LiteSpeed Cache Plugin neemt HTML-cache, objectcache-koppeling, beeldoptimalisatie en zelfs Critical CSS voor zijn rekening – alles te regelen in de WordPress-backend [4][5]. NGINX kan dat ook, maar vereist meerdere bouwstenen en consequent onderhoud van de configuratie. Deze verschillen komen in elk realistisch scenario tot uiting. hosting snelheidstest zichtbaar, vooral bij grote verkeerspiek [3][5]. Uiteindelijk besluit ik: investeer ik tijd in configuraties – of kies ik voor een nauw geïntegreerde oplossing.

HTTP/2 en HTTP/3 in vergelijking

Moderne protocollen bepalen Latency en doorvoersnelheid. Beide servers ondersteunen HTTP/2 en HTTP/3 (QUIC), maar LiteSpeed laat in verschillende benchmarks een hogere gegevensdoorvoersnelheid zien bij een lager CPU- en RAM-verbruik [2]. Dit valt vooral op wanneer verbindingen onstabiel zijn, bijvoorbeeld bij mobiele gebruikers of internationale routes. QUIC compenseert pakketverlies beter en LiteSpeed maakt hier zeer efficiënt gebruik van. Al met al worden TTFB en overdrachtstijden verkort, vaak zonder dat er hardware hoeft te worden vervangen.

De volgende tabel geeft een overzicht van de belangrijkste aspecten van het protocol. Ik concentreer me op typische effecten die ik regelmatig in projecten waarneem en die worden ondersteund door de bronnen [2][3][5]. Let vooral op het verschil in CPU-belasting en de verwerking van hoge RTT. Deze factoren verklaren veel snelheidswinst in het dagelijks gebruik. Het overzicht helpt je bij het stellen van prioriteiten voor je Stapel in te stellen.

Aspect	LiteSpeed	NGINX	Praktisch effect
HTTP/3/QUIC-doorvoer	Hoger in veel tests [2]	Solide, deels zwakker geschaald [2]	Kortere transfers bij wisselende latentie
CPU-belasting per verzoek	Minder CPU bij identiek scenario [2]	Deels hogere CPU-belasting [2]	Meer reserves per kern onder belasting
Headercompressie	Zeer efficiënt [5][6]	Efficiënt	Beter bij veel kleine objecten
HTTP/2-multiplexing	Nauw geïntegreerd in het pijpleidingontwerp [1]	Zeer goed	Minder blokkades, vloeiender oproepen

Ik geef in projecten prioriteit aan HTTP/3 wanneer er veel mobiele toegang, internationale reikwijdte of mediabelasting is. Voor puur lokale doelgroepen met een stabiele verbinding is HTTP/2 vaak voldoende. Wie LiteSpeed gebruikt, profiteert al vroeg van volwassen QUIC-optimalisaties [2]. Met NGINX bereik je vergelijkbare waarden als je de protocolparameters zeer nauwkeurig afstemt op het netwerk en Werkbelasting afstemt. Deze inspanning loont vooral in gespecialiseerde omgevingen.

Beveiliging, WAF en rate limiting

Prestaties zijn slechts de halve waarheid – stabiele responstijden instellen Beveiliging vooruit. LiteSpeed integreert ModSecurity-regels, anti-DDoS-mechanismen, verbindingslimieten en „soft deny“-strategieën zeer dicht bij de pijplijn [1][5]. Hierdoor kunnen kwaadaardige patronen vroegtijdig worden gestopt, zonder kostbare overdrachten naar lagere niveaus. NGINX biedt met limit_req, limit_conn en goede TLS-standaardinstellingen zijn sterke bouwstenen; een volwaardige WAF wordt echter vaak geïntegreerd als een extra module (bijv. ModSecurity v3), wat het onderhoud en de latentie kan verhogen [3][8].

In het dagelijks leven let ik op drie dingen: schoon Tariefgrenzen per padgroep (bijv. /wp-login.php, API's), zinvolle Header-hardening en slanke WAF-regelsets met duidelijke uitzonderingen, zodat echte gebruikers niet worden afgeremd. LiteSpeed biedt hier „bruikbare standaardinstellingen“, terwijl ik NGINX bewust modulair houd – dat vereist discipline, maar loont met transparantie in veiligheidsgevoelige omgevingen [3][5].

Hulpbronnenverbruik en schaalbaarheid onder belasting

Bij hoge parallelliteit telt elke besparing CPU-instructie. LiteSpeed verwerkt in HTTP/3-tests meer verzoeken per seconde en houdt de responstijden korter, vaak bij een lagere CPU-belasting [2]. Andere vergelijkingen laten zien dat OpenLiteSpeed en NGINX dicht bij elkaar liggen, met kleine voordelen voor OpenLiteSpeed bij TTFB en LCP [3][6]. Bij statische bestanden ligt NGINX soms voor, maar de verschillen blijven vaak klein [3][4]. Ik ken deze patronen van belastingstests met gemengde inhoud: kleine objecten, TLS, compressie en cache-hits spelen LiteSpeed in de kaart.

Belangrijk blijft: extreme waarden ontstaan vaak door agressieve caching of speciale testopstellingen [4]. Realistische workloads vertonen verschillen, maar zelden factoren met dubbele cijfers. Daarom plan ik capaciteiten in corridors en meet ik knelpunten nauwkeurig aan de hand van het toepassingsprofiel. Met een nette observability-opstelling kan ik zien of CPU, RAM, I/O of netwerk onder druk staan. Daarop baseer ik vervolgens server- en Cache-parameter.

Bedrijf: herlaadbeurten, doorlopende updates en observatievermogen

Bij continu gebruik is het belangrijk dat updates en configuratiewijzigingen soepel kunnen worden doorgevoerd. NGINX blinkt uit met Herladen zonder downtime via het master-/workermodel blijven sessies doorgaans bestaan; alleen gedeelde caches of TLS-sessiecaches kunnen bij verkeerde planning tijdelijk hun trefpercentages verliezen [3]. LiteSpeed beheerst graceful restarts en minimaliseert daarbij verbindingsonderbrekingen. Bovendien zijn logrotatie en configuratiewijzigingen goed te integreren [1][5]. Beide profiteren van duidelijke CI/CD-pijplijnen met syntaxiscontroles, staging en geautomatiseerde smoke-tests.

Voor Waarneembaarheid Ik vertrouw op fijnkorrelige logs (padgroepen, cache-status, upstream-tijden) en statistieken per virtuele host. LiteSpeed biedt gedetailleerde cache-hit-informatie en statusoverzichten; bij NGINX lees ik veel uit access_log met upstream_antwoord_tijd, verzoek_tijd en gedifferentieerde logformaten uit [3][4]. In beide gevallen geldt: alleen wie de padgroepen scheidt, kan zien of een enkel eindpunt de totale latentie domineert.

WordPress in de praktijk: waarom LiteSpeed uitblinkt

Het merendeel van de sites draait op WordPress, Daarom telt de realiteit in het dagelijkse CMS-gebruik. LiteSpeed scoort hier met full-page cache, ESI, objectcache-koppeling, beeldoptimalisatie en Critical CSS – alles rechtstreeks vanuit de plug-in te bedienen [4][5]. Ik krijg solide waarden zonder SSH-toegang en automatische purges na updates houden de cache schoon. NGINX levert statische assets razendsnel, maar voor dynamische pagina's heb ik extra modules, regels en onderhoud nodig [3][4][8]. Dat werkt goed, maar kost tijd en discipline in de configuratiebeheerpijplijn.

Winkels, lidmaatschappen en multisite-opstellingen profiteren sterk van ESI en granulaire cachecontrole. LiteSpeed synchroniseert deze beslissingen nauw met PHP, wat de trefkans verhoogt en de TTFB verlaagt [4]. Wie NGINX gebruikt, kan vergelijkbare resultaten behalen als de PURGE-logica, cookies en cache-keys exact passen. In audits zie ik vaak kleine fouten die veel snelheid kosten. Hier maakt de geïntegreerde aanpak van LiteSpeed een merkbaar verschil. Snelheid.

Interne mechanismen die vaart brengen

Verschillende ontwerpbeslissingen zorgen ervoor dat LiteSpeed sneller werkt. Een zeer efficiënte header- en body-compressie bespaart bandbreedte bij veel kleine objecten zoals API-calls en trackingpixels [5][6]. De request-pipeline koppelt caching, WAF-regels, anti-DDoS en logging zodanig aan elkaar dat er weinig contextwisselingen ontstaan [1][5]. Persistente verbindingen plus agressieve, maar voorzichtige HTTP/2-multiplexing houden verbindingen effectief open [2][5]. Daar komen nog praktische standaardinstellingen voor time-outs, buffers en compressie bij, die vanaf de fabriek solide meetwaarden mogelijk maken [1][5]. Ik hoef minder aanpassingen te doen om een betrouwbare Basis te bereiken.

NGINX beschikt over vergelijkbare mechanismen, maar vereist vaker gerichte fijnafstemming [3][4]. Wie hier tijd in investeert, wordt beloond – vooral in gespecialiseerde scenario's. Ik zorg ervoor dat bij beide servers de TLS-parameters, Brotli/Gzip-niveaus, open bestandslimieten en kernel-netwerkinstellingen op elkaar zijn afgestemd. Dan verdwijnen veel micro-latenties die anders van invloed zijn op TTFB en LCP. Architectuur plus standaardinstellingen verklaren waarom LiteSpeed vaak dit kleine, cruciale Plus benodigdheden.

LiteSpeed versus NGINX in een directe vergelijking

Ik zie een terugkerend patroon: LiteSpeed overtuigt vooral met HTTP/3, actieve compressie en geïntegreerde cache, terwijl NGINX bij statische bestanden en als reverse proxy blinkt het uit [2][3][8]. In veel tests komt LiteSpeed als winnaar uit op het gebied van efficiënt gebruik van bronnen, met name per kern en bij hoge RTT [2]. Wat betreft de configuratie-inspanning is het beeld anders: LiteSpeed biedt veel „klikbare“ functies in het plug-in-ecosysteem, NGINX biedt enorme flexibiliteit via configuraties [4][5]. Wie al met NGINX-infrastructuur werkt, kan met behulp van nette sjablonen en CI/CD sterke resultaten behalen. Voor extra perspectieven is het de moeite waard om even te kijken naar de Apache versus NGINX Vergelijking.

Ik weeg dit onderdeel altijd af tegen de projectdoelstellingen. Als het gaat om snelle CMS-levering met weinig administratieve rompslomp, dan raad ik LiteSpeed duidelijk aan. Voor microservices, edge-functionaliteit en speciale routing overtuigt NGINX met modulariteit en volwassenheid. Het budget en de vaardigheden van het team zijn ook van invloed op de beslissing. Uiteindelijk telt wat ik op de lange termijn nodig heb. betrouwbare Antwoordtijden aanhouden.

Licenties en varianten: OpenLiteSpeed, LiteSpeed Enterprise en NGINX

Voor de praktijk is het belangrijk om onderscheid te maken tussen: OpenLiteSpeed dekt veel prestatiekenmerken, leest .htaccess echter niet bij elke aanvraag opnieuw; wijzigingen worden doorgaans pas na het herladen van de pagina van kracht. LiteSpeed Onderneming biedt volledige functionaliteit, ondersteuning en comfortfuncties – dat is aantrekkelijk bij managed hosting, omdat tuning, WAF en cache nauw samenwerken [1][5]. NGINX is in de open source-variant zeer wijdverbreid en kostenefficiënt; enterprise-functies in commerciële edities richten zich op gebruiksgemak en uitgebreide monitoring-/healthcheck-functies [3].

Wat het budget betreft, baseer ik mijn beslissing op de totale bedrijfskosten: als het team weinig tijd heeft voor fijnafstemming en WordPress centraal staat, is de licentie voor LiteSpeed vaak snel terugverdiend. In gecontaineriseerde of zeer gespecialiseerde omgevingen wint NGINX door OSS-flexibiliteit en brede communitypatronen [3][8].

Containers, ingress en edge-implementatie

In Kubernetes-opstellingen heeft NGINX als Ingress-component geïntroduceerd. Zijn configureerbaarheid, CRD-uitbreidingen en beproefde patronen voor Blauw/groen, Canary en mTLS maken het daar tot de eerste keuze [3][8]. LiteSpeed wordt minder vaak als ingang gebruikt, maar eerder als app-gerelateerde webserver, wanneer de voordelen van de geïntegreerde cache (bijv. voor CMS) direct moeten worden benut. Aan de rand – bijvoorbeeld achter een CDN – werken beide goed; LiteSpeed kan dankzij HTTP/3/QUIC en agressieve compressie een extra niveau van latentie compenseren, NGINX overtuigt met zeer slanke statische server en robuuste proxying.

Voor gemengde architecturen gebruik ik vaak NGINX als externe proxy-/ingress-laag en LiteSpeed dichter bij de applicatie. Zo combineer ik het beste van twee werelden: gestandaardiseerde ingress-beleidsregels en directe applicatiecache.

Migratie en compatibiliteit

Wie van Apache komt, profiteert bij LiteSpeed van de uitgebreide .htaccess compatibiliteit en de naadloze omgang met herschrijfregels [1][5]. Dit vermindert de migratie-inspanning aanzienlijk. Bij NGINX moet Regels herschrijven vaak worden vertaald; dat is haalbaar, maar vereist ervaring om edge-cases (query strings, redirect-cascades, caching-vary) correct weer te geven [3][4].

Voor WordPress migreer ik bij voorkeur in twee stappen: eerst statische assets en TLS, daarna paginacache en objectcache. Zo zie ik waar TTFB daadwerkelijk ontstaat. Aan de NGINX-kant plan ik vroegtijdig PURGE-strategieën en sleutels (cookie-, apparaat- en lang-parameters), bij LiteSpeed activeer ik selectief functies in de plug-in om neveneffecten te voorkomen. Het doel blijft: groot nut bij minimale complexiteit.

Hostingpraktijk: wanneer LiteSpeed bijzonder zinvol is

LiteSpeed komt het best tot zijn recht wanneer dynamische content, veel gelijktijdige bezoekers en weinig administratietijd samenkomen. WordPress-blogs, magazines, WooCommerce-winkels, lidmaatschapspagina's en multisite-installaties profiteren hier merkbaar van [2][3][5]. HTTP/3/QUIC biedt bovendien voordelen voor mobiele en internationale doelgroepen. In dergelijke opstellingen bereik ik zeer lage TTFB-waarden en plan ik de belasting met minder hardware-reserves. Voor statische of gecontaineriseerde architecturen als Omgekeerde proxy blijft NGINX een uitstekende keuze [3][8].

Ik beoordeel eerst het verkeersprofiel, het cache-hitpercentagepotentieel en de build-/deploy-processen. Daarna besluit ik of een geïntegreerd cachesysteem of een modulaire proxy-setup geschikt is. LiteSpeed Enterprise in managed hosting vereenvoudigt veel, omdat tuning en het plugin-ecosysteem hand in hand gaan. NGINX blijft de eerste keuze voor dedicated proxy-rollen, vooral in Kubernetes- of service mesh-omgevingen. De juiste keuze volgt het toepassingsprofiel – niet de hype, maar de meetbare resultaten. effecten.

Concrete tuning-tips voor beide servers

Ik begin met schoon HTTPS-Setup: TLS 1.3, moderne cijfers, 0-RTT alleen na risicobeoordeling, OCSP Stapling actief. Voor compressie gebruik ik Brotli voor tekstbestanden, Gzip als fallback, kies gematigde niveaus, zodat de CPU-belasting niet te hoog wordt. Bij caching richt ik me op cache-keys, vary-headers en exacte PURGE-paden; LiteSpeed doet veel daarvan automatisch, NGINX heeft exacte regels nodig. Bij HTTP/3 stem ik pacing, max streams en initial congestion window zorgvuldig af en meet ik de effecten. Voor praktische richtwaarden verwijs ik naar deze compacte Webhostingprestaties Overzicht.

Observeerbaarheid bepaalt welke instellingen correct zijn. Ik log TTFB, LCP, foutcodes, origin-response-times en CPU-/RAM-quota's afzonderlijk per padgroep. Zo kan ik zien of cache-busting, third-party-calls of database-locks de snelheid beperken. Kernelparameters (net.core, net.ipv4, ulimits) stel ik in op het verwachte verbindingsvolume. CDN en beeldoptimalisatie maken het plaatje compleet. Alleen de som van deze stappen zorgt voor duurzaamheid. Snelheid.

Benchmarks correct interpreteren: methodiek verslaat marketing

Veel vergelijkingen hebben te lijden onder inconsistente opstellingen. Ik controleer altijd: zijn cache-strategieën vergelijkbaar? Is warm cache gescheiden van cold cache? Zijn HTTP/3-parameters identiek, inclusief packet pacing en ACK-frequenties? Is network shaping (RTT, Loss) gebruikt om mobiele realiteiten te simuleren? Zonder deze controles zijn cijfers moeilijk te interpreteren [2][3][5].

Voor reproduceerbare resultaten werk ik met duidelijke scenario's: statisch (Brotli aan/uit), dynamisch zonder cache, dynamisch met volledige paginacache, API-belasting met kleine JSON-responses. Ik meet elke fase met en zonder TLS, en bovendien in verschillende concurrency-niveaus. Ik evalueer p50/p90/p99 en correleer deze met CPU- en contextwisselingscijfers. Zo kan ik zien of de architectuur echt schaalbaar is – en niet alleen in individuele gevallen uitblinkt.

Typische fouten en snelle oplossingen

• Onverwachte TTFB-pieken: Bij NGINX vaak verkeerd gedimensioneerde PHP-FPM-wachtrijen of te agressieve proxy_buffering-Instellingen; bij LiteSpeed vaak ontbrekende cache-hits door verkeerde Vary-cookies [3][4][5].
• Cache-busting door cookies: Tracking- of consent-cookies verhinderen hits. Oplossing: duidelijke regels voor het negeren van cookies/whitelists opstellen; in LiteSpeed te regelen via een plug-in, in NGINX via key-design [4][5].
• HTTP/3 onstabiel: MTU/PMTU, pacing, initiële CWND en defecte middleboxen. Op korte termijn terugvallen op HTTP/2 toestaan, op lange termijn QUIC-parameters voorzichtig aanpassen [2][3].
• Beeldoptimalisatie verbruikt CPU: Offload in Jobs/Queues, limieten instellen voor gelijktijdige optimalisaties. LiteSpeed-plugin biedt goede standaardinstellingen, NGINX-stacks maken gebruik van externe pijplijnen [4][5].
• WebSockets/Realtime: Time-outs verhogen, buffers klein houden, proxy-lees-/verzend-time-outs differentiëren. Bij LiteSpeed en NGINX aparte paden definiëren, zodat ze niet worden beïnvloed door cachingregels [3][5].

Kort samengevat

Beide webservers gebruiken een Evenement-architectuur, maar LiteSpeed integreert cache, protocollen en compressie dieper in de pijplijn. Hierdoor bespaar ik in veel projecten CPU, tijd en complexiteit – en krijg ik merkbaar betere TTFB- en doorvoersnelheden, vooral met HTTP/3 [2][3][5]. NGINX blijft sterk als reverse proxy en bij statische bestanden; met een deskundige configuratie presteert het in veel scenario's even goed [3][6][8]. Voor WordPress en dynamische inhoud bereik ik met LiteSpeed sneller consistente resultaten, omdat de plug-in en de server naadloos samenwerken [4][5]. Het profiel van je project blijft doorslaggevend: verkeerspatronen, teamvaardigheden, budget en de vraag of je geïntegreerde Functies voorkeur geeft aan of modulaire configuratiekracht kiest.