[{"data":1,"prerenderedAt":1034},["ShallowReactive",2],{"blog-post-nl-what-is-a-ddos-attack":3,"related-posts-nl-what-is-a-ddos-attack":135},{"post":4,"slugMap":134},{"id":5,"title":6,"author":7,"body":8,"category":102,"date":103,"description":104,"extension":105,"faq":106,"meta":121,"navigation":122,"path":123,"readingTime":124,"seo":125,"slug":126,"stem":127,"tags":128,"__hash__":133},"blog\u002Fblog\u002Fnl\u002Fwhat-is-a-ddos-attack.md","Wat is een DDoS-aanval en hoe bescherm je een website ertegen?","EuroraCloud Team",{"type":9,"value":10,"toc":92},"minimark",[11,15,19,24,32,35,39,42,45,48,52,55,58,62,65,68,72,75,85,89],[12,13,6],"h1",{"id":14},"wat-is-een-ddos-aanval-en-hoe-bescherm-je-een-website-ertegen",[16,17,18],"p",{},"Een DDoS-aanval (Distributed Denial of Service) probeert een website offline te halen door hem te overspoelen met veel meer verkeer dan hij aankan, tegelijk verstuurd vanaf talloze machines, totdat echte bezoekers er niet meer doorheen komen. Bescherming ertegen betekent dat je dat kwaadaardige verkeer eruit filtert voordat het je server bereikt, met een mitigatielaag die voor de site staat en de aanval absorbeert of blokkeert. Het doel is simpel: de site beschikbaar houden voor echte gebruikers, ook terwijl een aanval bezig is.",[20,21,23],"h2",{"id":22},"wat-is-een-ddos-aanval","Wat is een DDoS-aanval?",[16,25,26,27,31],{},"Een Denial of Service-aanval heeft als doel een website of dienst onbereikbaar te maken. Een ",[28,29,30],"em",{},"Distributed"," Denial of Service-aanval doet hetzelfde vanaf veel bronnen tegelijk, vaak duizenden gecompromitteerde apparaten die samen als botnet optreden, wat het veel lastiger maakt om te stoppen door simpelweg één adres te blokkeren. Het verkeer is bedoeld om iets eindigs uit te putten: de verbindingen van de server, de verwerkingscapaciteit, of de bandbreedte van het netwerk waarop hij draait.",[16,33,34],{},"Het belangrijkste verschil met een gewone verkeerspiek is de bedoeling en het patroon. Een drukke verkoopdag stuurt je meer echte bezoekers, terwijl een DDoS-aanval je verkeer stuurt dat alleen bedoeld is om middelen op te slokken en echte bezoekers te verdringen. Volgens de DDoS-rapportages van Cloudflare is het aanvalsvolume jaar op jaar sterk gestegen en worden de grootste geregistreerde aanvallen inmiddels gemeten in terabits per seconde, ver buiten wat een enkele onbeschermde server kan absorberen.",[20,36,38],{"id":37},"hoe-werkt-een-ddos-aanval-eigenlijk","Hoe werkt een DDoS-aanval eigenlijk?",[16,40,41],{},"De meeste aanvallen vallen in drie brede types, en het helpt om te weten welk type welk is, omdat ze verschillend worden afgeweerd.",[16,43,44],{},"Volumetrische aanvallen zijn het brute-krachttype: ze verzadigen je beschikbare bandbreedte met pure hoeveelheid, zoals een UDP-flood, zodat er niets anders meer doorheen kan. Protocolaanvallen richten zich op de manier waarop verbindingen worden opgezet en putten server- of firewallmiddelen uit met bijvoorbeeld SYN-floods, die verbindingen openen en nooit voltooien. Aanvallen op de applicatielaag zijn het stilst en vaak het lastigst te herkennen: ze bootsen echt gebruikersgedrag na en sturen verzoeken die legitiem lijken, maar gericht zijn op de duurste onderdelen van je site, zoals een zoek- of loginfunctie, totdat de applicatie bezwijkt.",[16,46,47],{},"Wat alle drie gemeen hebben, is dat ze een resource overbelasten. Het verweer is in alle gevallen hetzelfde: het kwaadaardige verkeer identificeren en verwijderen voordat het de aangevallen resource bereikt.",[20,49,51],{"id":50},"wat-kost-een-ddos-aanval-een-bedrijf","Wat kost een DDoS-aanval een bedrijf?",[16,53,54],{},"De voor de hand liggende kosten zijn de storing: zolang de site onbereikbaar is, kunnen bezoekers niet boeken, kopen of contact opnemen, en voor een zorg- of kliniekwebsite kan dat betekenen dat patiënten niet bij zorginformatie of afspraakformulieren kunnen. Schattingen uit de sector leggen de kosten van ongeplande websitedowntime vaak op duizenden euro's per uur voor een bedrijf dat online transacties doet, al hangt het werkelijke bedrag volledig af van wat je site voor je doet.",[16,56,57],{},"De minder zichtbare kosten tellen ook mee. Er is de reputatieschade van een site die zichtbaar plat ligt, de personeelsuren die in brandjes blussen gaan zitten, en in sommige gevallen een DDoS-aanval die als rookgordijn wordt gebruikt om af te leiden van een tweede inbraakpoging. Voor een gereguleerde of patiëntgerichte organisatie roept een storing bovendien vragen op over beschikbaarheid en continuïteit die verder gaan dan gemiste omzet.",[20,59,61],{"id":60},"hoe-houdt-ddos-mitigatie-een-site-online","Hoe houdt DDoS-mitigatie een site online?",[16,63,64],{},"Effectieve mitigatie plaatst een filterlaag tussen het internet en je server, zodat verkeer wordt geïnspecteerd voordat het je ooit bereikt. Legitieme bezoekers komen erdoorheen, terwijl verkeer dat overeenkomt met aanvalspatronen aan de rand wordt geabsorbeerd of weggegooid, verspreid over infrastructuur met veel meer capaciteit dan een enkele origin-server.",[16,66,67],{},"Dit werkt het best als een altijd actieve laag in plaats van iets dat je midden in een aanval aanzet, omdat de eerste minuten van een aanval de minuten zijn waarin de schade ontstaat. Een mitigatiedienst ziet het verkeer als eerste, herkent de kenmerken van de hierboven genoemde aanvalstypes en schaalt op om volume te absorberen dat je eigen hardware zou overweldigen. Bij EuroraCloud draait de DDoS-mitigatie vanaf onze gedecentraliseerde infrastructuur in Nederland, Frankrijk en Duitsland, waardoor verkeer binnen Europa blijft om redenen van datasoevereiniteit en latency, en tegelijk de capaciteit biedt om grote aanvallen op te vangen.",[20,69,71],{"id":70},"wat-moet-je-nu-doen","Wat moet je nu doen?",[16,73,74],{},"Begin met weten of je op dit moment überhaupt een mitigatielaag hebt, want veel websites zijn alleen beschermd door de standaardinstellingen van hun hostingprovider, die vaak mager zijn. Als een aanval vandaag je site offline zou halen, is dat het gat om te dichten, ongeacht of je ooit eerder geraakt bent, want de hele bedoeling van mitigatie is dat het al aanstaat wanneer een aanval begint.",[16,76,77,78],{},"Wil je zien waar je eigen site staat, dan kan EuroraCloud je huidige situatie bekijken en je laten zien wat onze mitigatie oplost. ",[79,80,84],"a",{"href":81,"rel":82},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=ddos",[83],"nofollow","Bekijk wat EuroraCloud oplost",[20,86,88],{"id":87},"conclusie-wat-moet-je-onthouden-over-ddos-bescherming","Conclusie: wat moet je onthouden over DDoS-bescherming?",[16,90,91],{},"Een DDoS-aanval hoeft niets te doorbreken om je te raken. Hij maakt je site simpelweg onbereikbaar, en voor een bedrijf dat afhankelijk is van zijn website om te informeren, te boeken of te verkopen, is een uur offline een reële kostenpost. De drie aanvalstypes werken verschillend, maar het antwoord op alle drie is hetzelfde: een mitigatielaag voor je site die kwaadaardig verkeer wegfiltert voordat het binnenkomt. Het nuttigste wat je kunt doen is controleren of die laag er vandaag al is, want mitigatie beschermt je alleen als het draait voordat een aanval begint, niet erna.",{"title":93,"searchDepth":94,"depth":94,"links":95},"",2,[96,97,98,99,100,101],{"id":22,"depth":94,"text":23},{"id":37,"depth":94,"text":38},{"id":50,"depth":94,"text":51},{"id":60,"depth":94,"text":61},{"id":70,"depth":94,"text":71},{"id":87,"depth":94,"text":88},"Fundamenten","2026-07-13","Een DDoS-aanval overspoelt je website met verkeer totdat echte bezoekers er niet meer bij kunnen. Zo werken deze aanvallen, wat een storing werkelijk kost, en hoe mitigatie een site online houdt.","md",[107,109,111,113,115,118],{"question":23,"answer":108},"Een DDoS-aanval (Distributed Denial of Service) probeert een website onbereikbaar te maken door hem te overspoelen met verkeer vanaf veel bronnen tegelijk, vaak duizenden gecompromitteerde apparaten die als botnet optreden. Het verkeer is bedoeld om een eindige resource uit te putten, zoals de verbindingen van de server, de verwerkingscapaciteit of de netwerkbandbreedte, zodat echte bezoekers er niet meer doorheen komen.",{"question":38,"answer":110},"Aanvallen vallen in drie brede types. Volumetrische aanvallen verzadigen de beschikbare bandbreedte met pure hoeveelheid. Protocolaanvallen putten server- of firewallmiddelen uit door misbruik te maken van de manier waarop verbindingen worden opgezet, zoals SYN-floods. Aanvallen op de applicatielaag bootsen echt gebruikersgedrag na en richten zich op dure functies zoals zoeken of inloggen totdat de applicatie bezwijkt. Alle drie overbelasten een resource, en het verweer is telkens het kwaadaardige verkeer verwijderen voordat het het doel bereikt.",{"question":51,"answer":112},"De directe kosten zijn de storing: zolang de site onbereikbaar is, kunnen bezoekers niet boeken, kopen of contact opnemen. Schattingen leggen ongeplande websitedowntime vaak op duizenden euro's per uur voor een bedrijf dat transacties doet, al hangt het werkelijke bedrag af van wat de site doet. Indirecte kosten zijn reputatieschade, personeelsuren voor brandjes blussen, en het risico dat een DDoS-aanval als rookgordijn wordt gebruikt voor een tweede inbraak.",{"question":61,"answer":114},"Mitigatie plaatst een filterlaag tussen het internet en je server en inspecteert verkeer voordat het je bereikt. Legitieme bezoekers komen erdoorheen, terwijl verkeer dat overeenkomt met aanvalspatronen aan de rand wordt geabsorbeerd of weggegooid, verspreid over infrastructuur met veel meer capaciteit dan een enkele server. Het werkt het best als een altijd actieve laag in plaats van iets dat je midden in een aanval aanzet, omdat de eerste minuten van een aanval de minuten zijn waarin de schade ontstaat.",{"question":116,"answer":117},"Wat moet je nu doen om een website tegen DDoS te beschermen?","Begin met controleren of je überhaupt een mitigatielaag hebt, want veel sites vertrouwen alleen op de magere standaardinstellingen van hun hostingprovider. Als een aanval vandaag je site offline zou halen, is dat het gat om te dichten, ongeacht of je eerder geraakt bent, want mitigatie helpt alleen als het al aanstaat wanneer een aanval begint.",{"question":119,"answer":120},"Wat moet je onthouden over DDoS-bescherming?","Een DDoS-aanval hoeft niets te doorbreken om je te raken; hij maakt je site simpelweg onbereikbaar, wat een reële kostenpost is voor elk bedrijf dat afhankelijk is van zijn website. De drie aanvalstypes werken verschillend, maar het antwoord op alle drie is een mitigatielaag voor de site die kwaadaardig verkeer wegfiltert voordat het binnenkomt. Het nuttigste wat je kunt doen is controleren of die laag vandaag al draait, want mitigatie beschermt je alleen als het aanstaat voordat een aanval begint.",{},true,"\u002Fblog\u002Fnl\u002Fwhat-is-a-ddos-attack","7 minuten",{"title":6,"description":104},"what-is-a-ddos-attack","blog\u002Fnl\u002Fwhat-is-a-ddos-attack",[129,130,131,132],"DDoS","Security","Web-infrastructuur","Uptime","CG_K69FfOTW_Wc0vSgR3G8n1RGOm2MHAXMymOT2_jbs",{"de":126,"en":126,"es":126,"fr":126,"it":126,"nl":126},[136,256,400],{"id":137,"title":138,"author":7,"body":139,"category":225,"date":103,"description":226,"extension":105,"faq":227,"meta":246,"navigation":122,"path":247,"readingTime":124,"seo":248,"slug":249,"stem":250,"tags":251,"__hash__":255},"blog\u002Fblog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy.md","Wat is de Cross-Origin-Opener-Policy header en waarom is die belangrijk?",{"type":9,"value":140,"toc":216},[141,144,147,151,154,157,161,164,167,171,174,177,181,184,187,191,194,197,199,202,209,213],[12,142,138],{"id":143},"wat-is-de-cross-origin-opener-policy-header-en-waarom-is-die-belangrijk",[16,145,146],{},"De Cross-Origin-Opener-Policy header, meestal geschreven als COOP, is een response header die bepaalt of je pagina een venstersamenhang deelt met pagina's van andere origins. Ingesteld op same-origin isoleert hij je document in een eigen browsing context group, zodat een pagina van een andere origin die de jouwe opent, of die jij opent, geen scriptbare verwijzing terug naar je venster kan behouden. Dit sluit een klasse van cross-origin aanvallen die bekendstaan als XS-Leaks en side-channel aanvallen, en het is bovendien de instelling die bepaalde krachtige browserfuncties ontgrendelt.",[20,148,150],{"id":149},"waarom-bestaat-de-cross-origin-opener-policy-header","Waarom bestaat de Cross-Origin-Opener-Policy header?",[16,152,153],{},"COOP bestaat omdat het openen van een venster een verband creëert dat misbruikt kan worden. Wanneer de ene pagina de andere opent met window.open(), of een pagina de jouwe opent, kan de browser via de eigenschap window.opener een verwijzing tussen de twee vensters behouden. Als die twee pagina's van verschillende origins komen, wordt die verwijzing een route waarlangs een cross-origin pagina de jouwe kan aftasten.",[16,155,156],{},"De aanvallen die dit mogelijk maakt zijn subtiel. Ze stelen je gegevens niet rechtstreeks, maar leiden ze af via side channels, timing en gedeelde browserstatus, in een familie van technieken die de securitygemeenschap XS-Leaks noemt. Volgens de documentatie van Mozilla is COOP specifiek geïntroduceerd zodat een site kan garanderen dat zijn top-level document geen browsing context group deelt met cross-origin documenten, en dat is precies wat die verwijzing verbreekt en de route afsluit.",[20,158,160],{"id":159},"wat-doet-de-cross-origin-opener-policy-header-eigenlijk","Wat doet de Cross-Origin-Opener-Policy header eigenlijk?",[16,162,163],{},"COOP bepaalt of je document en de pagina's waarmee het interacteert tot dezelfde browsing context group behoren, het interne browserbegrip dat bepaalt of twee vensters elkaar kunnen scripten. Als je hem strikt instelt, gaat je venster in een eigen groep en verliest elk cross-origin venster zijn verwijzing naar het jouwe.",[16,165,166],{},"De header kent een kleine set waarden. De standaardwaarde, unsafe-none, past geen isolatie toe en laat je document een browsing context group delen met cross-origin pagina's. De strikte waarde, same-origin, isoleert je document zo dat alleen same-origin pagina's die zelf ook same-origin instellen in dezelfde groep kunnen blijven. Een tussenwaarde, same-origin-allow-popups, behoudt die isolatie maar laat popups die je zelf opent gewoon functioneren, wat de praktische keuze is voor sites die afhankelijk zijn van popup-flows zoals betaling of single sign-on. Wanneer een cross-origin venster onder same-origin wordt geopend, wordt zijn window.opener null, zodat de verwijzing simpelweg niet bestaat.",[20,168,170],{"id":169},"wat-gebeurt-er-als-je-hem-niet-instelt","Wat gebeurt er als je hem niet instelt?",[16,172,173],{},"Zonder COOP is de standaard unsafe-none, wat betekent dat er geen isolatie is en de vensterverwijzing openblijft. Een cross-origin pagina die de jouwe opent, of die jij opent, kan een greep op je venster behouden en die gebruiken als opstap voor de hierboven beschreven side-channel technieken.",[16,175,176],{},"Dit is een stil gat, geen luid gat. Niets op je site lijkt kapot, en de meeste bezoekers zullen het nooit veroorzaken, en juist daarom blijft het vaak onaangepakt. Maar voor een site die iets gevoeligs verwerkt, een login, een patiëntenportaal, een betaalstap, is het openlaten van de venstersamenhang een vermijdbare blootstelling, en het is er een die securityscanners en audits steeds vaker aanmerken als een ontbrekende header.",[20,178,180],{"id":179},"hoe-implementeer-je-de-cross-origin-opener-policy-header","Hoe implementeer je de Cross-Origin-Opener-Policy header?",[16,182,183],{},"Je stelt COOP in als één HTTP response header. Voor de meeste sites is de juiste startwaarde Cross-Origin-Opener-Policy: same-origin-allow-popups, die je isolatie geeft terwijl popup-flows behouden blijven; een site zonder zulke afhankelijkheden kan naar de striktere same-origin. Hij kan worden toegevoegd op de webserver, in de applicatielaag, of aan de rand in een CDN of securitylaag die voor de site staat.",[16,185,186],{},"De enige sterke aanbeveling is: test voordat je afdwingt. COOP ondersteunt een report-only modus, verstuurd als Cross-Origin-Opener-Policy-Report-Only, die de browser Reporting API gebruikt om je te laten weten wat de policy zou breken zonder dat het daadwerkelijk breekt. Eerst report-only draaien, letten op popup- of vensterflows die geraakt zouden worden, en pas dan overschakelen naar de afgedwongen header is het veilige pad, zeker op een site met integraties van derden die je niet zelf gebouwd hebt.",[20,188,190],{"id":189},"wat-verandert-er-op-je-site-zodra-hij-aanstaat","Wat verandert er op je site zodra hij aanstaat?",[16,192,193],{},"Voor de meeste sites niets zichtbaars. Gewone paginaladingen, navigatie en same-origin gedrag blijven onaangetast, en de isolatie gebeurt onzichtbaar op browserniveau. De winst is dat cross-origin vensters geen verwijzing naar het jouwe meer kunnen behouden, wat het aanvalsoppervlak wegneemt zonder de gebruikerservaring te raken.",[16,195,196],{},"De plek om te controleren is elke flow die bewust een andere origin opent of erdoor geopend wordt. Een betaalprovider, een identity provider, of een ingebedde tool die via vensterverwijzingen communiceert kan geraakt worden door een strikte same-origin waarde, en dat is precies waarom same-origin-allow-popups bestaat en waarom testen in report-only ertoe doet. Er is ook een voordeel dat het weten waard is: same-origin instellen, samen met de verwante Cross-Origin-Embedder-Policy header, brengt je document in een cross-origin isolated staat die sommige krachtige browserfuncties vereisen, zoals SharedArrayBuffer en timers met hoge resolutie.",[20,198,71],{"id":70},[16,200,201],{},"Begin met controleren of je site überhaupt een Cross-Origin-Opener-Policy header verstuurt, want de standaard van geen header betekent geen isolatie. Als hij ontbreekt, is het risicoarme pad om hem toe te voegen in report-only modus, te bevestigen dat er niets in je popup- of externe flows breekt, en dan same-origin-allow-popups af te dwingen als verstandige standaard, of same-origin als je site geen popup-afhankelijkheden heeft.",[16,203,204,205],{},"Wil je dit correct laten controleren en instellen over je hele site in plaats van stukje bij beetje, dan kan EuroraCloud je huidige security headers bekijken en je laten zien wat ons platform oplost. ",[79,206,84],{"href":207,"rel":208},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[83],[20,210,212],{"id":211},"conclusie-wat-moet-je-onthouden-over-de-cross-origin-opener-policy-header","Conclusie: wat moet je onthouden over de Cross-Origin-Opener-Policy header?",[16,214,215],{},"COOP is een stille maar waardevolle header: hij isoleert je browservenster van cross-origin pagina's en sluit daarmee een klasse van side-channel en popup-aanvallen die geen zichtbaar spoor achterlaten totdat een scanner of een aanvaller ze vindt. Voor de meeste sites is de veilige route om te testen in report-only modus en daarna same-origin-allow-popups af te dwingen, wat het venster beschermt terwijl legitieme popup-flows behouden blijven. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, is de standaard helemaal geen isolatie.",{"title":93,"searchDepth":94,"depth":94,"links":217},[218,219,220,221,222,223,224],{"id":149,"depth":94,"text":150},{"id":159,"depth":94,"text":160},{"id":169,"depth":94,"text":170},{"id":179,"depth":94,"text":180},{"id":189,"depth":94,"text":190},{"id":70,"depth":94,"text":71},{"id":211,"depth":94,"text":212},"Security Headers","De Cross-Origin-Opener-Policy header laat een pagina zijn browservenster isoleren van cross-origin pagina's die hem openen of door hem geopend worden, waarmee een klasse van side-channel en popup-aanvallen wordt gesloten. Dit is wat de header doet, hoe je hem instelt, en wat er verandert als je dat doet.",[228,230,232,235,237,240,243],{"question":150,"answer":229},"COOP bestaat omdat het openen van een venster een scriptbaar verband creëert dat misbruikt kan worden. Wanneer de ene pagina de andere opent, kan de browser via window.opener een verwijzing tussen de twee vensters behouden, en als de pagina's van verschillende origins komen, wordt die verwijzing een route waarlangs een cross-origin pagina de jouwe kan aftasten via side channels en timing, een familie van technieken die bekendstaat als XS-Leaks. COOP laat een site garanderen dat zijn top-level document geen browsing context group deelt met cross-origin documenten, wat die verwijzing verbreekt.",{"question":160,"answer":231},"COOP bepaalt of je document en de pagina's waarmee het interacteert tot dezelfde browsing context group behoren, het interne browserbegrip dat bepaalt of twee vensters elkaar kunnen scripten. Strikt ingesteld gaat je venster in een eigen groep en verliezen cross-origin vensters hun verwijzing naar het jouwe. De waarden zijn unsafe-none (de standaard, geen isolatie), same-origin (strikte isolatie) en same-origin-allow-popups (isolatie die popups die je zelf opent toestaat). Onder same-origin wordt de window.opener van een cross-origin venster null.",{"question":233,"answer":234},"Wat gebeurt er als je de Cross-Origin-Opener-Policy header niet instelt?","Zonder COOP is de standaard unsafe-none, wat betekent dat er geen isolatie is en de vensterverwijzing openblijft. Een cross-origin pagina die de jouwe opent, of die jij opent, kan een greep op je venster behouden en die gebruiken als opstap voor side-channel aanvallen. Niets lijkt kapot, en juist daarom blijft het onaangepakt, maar voor een site met een login, patiëntenportaal of betaalstap is het een vermijdbare blootstelling die scanners steeds vaker aanmerken.",{"question":180,"answer":236},"Stel COOP in als één HTTP response header, op de webserver, in de applicatielaag of aan de rand. Voor de meeste sites is de juiste startwaarde same-origin-allow-popups, die isolatie geeft terwijl popup-flows behouden blijven; een site zonder popup-afhankelijkheden kan de striktere same-origin gebruiken. Test voordat je afdwingt door de report-only modus te gebruiken, verstuurd als Cross-Origin-Opener-Policy-Report-Only, die rapporteert wat de policy zou breken zonder het te breken.",{"question":238,"answer":239},"Wat verandert er op je site zodra de Cross-Origin-Opener-Policy header aanstaat?","Voor de meeste sites verandert er niets zichtbaars; gewone paginaladingen en same-origin gedrag blijven onaangetast en de isolatie gebeurt op browserniveau. De plek om te controleren is elke flow die bewust een andere origin opent of erdoor geopend wordt, zoals een betaal- of identity provider, en dat is waarom same-origin-allow-popups bestaat en waarom testen in report-only ertoe doet. same-origin instellen samen met Cross-Origin-Embedder-Policy schakelt ook een cross-origin isolated staat in die sommige krachtige functies zoals SharedArrayBuffer vereisen.",{"question":241,"answer":242},"Wat moet je nu doen met de Cross-Origin-Opener-Policy header?","Controleer of je site überhaupt een Cross-Origin-Opener-Policy header verstuurt, want geen header betekent geen isolatie. Als hij ontbreekt, voeg hem toe in report-only modus, bevestig dat er niets in je popup- of externe flows breekt, en dwing dan same-origin-allow-popups af als verstandige standaard, of same-origin als je site geen popup-afhankelijkheden heeft.",{"question":244,"answer":245},"Wat moet je onthouden over de Cross-Origin-Opener-Policy header?","COOP is een stille maar waardevolle header die je browservenster isoleert van cross-origin pagina's en daarmee een klasse van side-channel en popup-aanvallen sluit die geen zichtbaar spoor achterlaten. Voor de meeste sites is de veilige route om te testen in report-only modus en daarna same-origin-allow-popups af te dwingen, wat het venster beschermt terwijl legitieme popup-flows behouden blijven. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, is de standaard helemaal geen isolatie.",{},"\u002Fblog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy",{"title":138,"description":226},"what-is-cross-origin-opener-policy","blog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy",[252,225,253,254],"Cross-Origin-Opener-Policy","Webbeveiliging","Browserisolatie","M-M5zYBaNDLpkDcCmTUnLahiH8pz6DhU_huYOopU1kg",{"id":257,"title":258,"author":7,"body":259,"category":225,"date":103,"description":367,"extension":105,"faq":368,"meta":390,"navigation":122,"path":391,"readingTime":392,"seo":393,"slug":394,"stem":395,"tags":396,"__hash__":399},"blog\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy.md","Wat is de Permissions-Policy header en waarom is die belangrijk?",{"type":9,"value":260,"toc":357},[261,264,267,271,274,277,281,294,300,304,307,310,312,315,318,322,325,328,331,333,336,339,341,344,350,354],[12,262,258],{"id":263},"wat-is-de-permissions-policy-header-en-waarom-is-die-belangrijk",[16,265,266],{},"De Permissions-Policy header is een response header waarmee een website bepaalt welke browserfuncties de eigen pagina's, en alle content die daarin is ingesloten, mogen gebruiken. Functies als de camera, microfoon, locatie en betaling kunnen elk worden toegestaan, beperkt tot je eigen origin, of volledig uitgeschakeld. Hem instellen betekent dat zelfs als een script of een ingesloten derde partij een van die functies probeert te bereiken, de browser dat weigert tenzij je beleid het toestaat, wat zowel je privacyblootstelling als je aanvalsoppervlak verkleint.",[20,268,270],{"id":269},"waarom-bestaat-de-permissions-policy-header","Waarom bestaat de Permissions-Policy header?",[16,272,273],{},"Moderne browsers stellen veel krachtige mogelijkheden beschikbaar aan webpagina's: locatie, camera, microfoon, bewegingssensoren en meer. Elk script dat op je pagina draait, inclusief externe scripts die je hebt ingesloten voor analytics, chat of advertenties, kan de browser in principe vragen die mogelijkheden te gebruiken. Permissions-Policy bestaat zodat je op het niveau van de hele site kunt bepalen welke van die functies zijn toegestaan en voor wie.",[16,275,276],{},"Het doel is om het gat te dichten tussen wat een browser kan en wat je site werkelijk nodig heeft. De meeste websites gebruiken nooit de accelerometer of de payment-API, maar zonder beleid blijven die functies bereikbaar voor elke code op de pagina. Volgens de documentatie van MDN wordt de gebruiker, wanneer een beleid een functie blokkeert, niet eens om toestemming gevraagd, en mislukt de poging van een script om die te gebruiken simpelweg, wat precies de afscherming is die je wilt voor functies die je nooit van plan was te gebruiken.",[20,278,280],{"id":279},"wat-doet-de-permissions-policy-header-eigenlijk","Wat doet de Permissions-Policy header eigenlijk?",[16,282,283,284,288,289,293],{},"De header werkt als een lijst van directives, één per functie, elk met een allowlist die aangeeft welke origins hem mogen gebruiken. De syntax is de functienaam, een isgelijkteken, en de toegestane origins tussen haakjes, met meerdere directives gescheiden door komma's, bijvoorbeeld geolocation=(), camera=(self). Een lege allowlist, geschreven als (), schakelt de functie overal uit; self staat hem alleen op je eigen origin toe; een specifieke origin zoals (\"",[79,285,286],{"href":286,"rel":287},"https:\u002F\u002Fexample.com",[83],"\") staat die origin toe; en ",[290,291,292],"code",{},"*"," staat hem overal toe, inclusief ingesloten frames.",[16,295,296,297,299],{},"Een nuttig detail is dat elke functie een standaard allowlist heeft die geldt wanneer je niets opgeeft, en afhankelijk van de functie is die standaard ",[290,298,292],{},", self, of geen. De waarde van het expliciet instellen van de header is dus dat je niet langer op de standaarden per functie leunt, maar een bewuste, uniforme keuze maakt: zet alles uit wat je niet gebruikt, en beperk alles wat je wel gebruikt tot je eigen origin of de specifieke partners die het nodig hebben.",[20,301,303],{"id":302},"hoe-gedraagt-de-header-zich-met-ingesloten-iframes","Hoe gedraagt de header zich met ingesloten iframes?",[16,305,306],{},"Dit is het deel waar de meeste mensen over struikelen, dus het is de moeite waard om precies te zijn. Een functie is alleen beschikbaar binnen een ingesloten iframe als aan twee voorwaarden tegelijk wordt voldaan: je top-level pagina moet de functie in zijn Permissions-Policy toestaan voor de origin van dat frame, en het iframe zelf mag hem niet hebben uitgeschakeld. Met andere woorden: de bovenliggende pagina stelt de buitengrens in, en niets wat is ingesloten kan zichzelf een functie toekennen die de bovenliggende pagina heeft onthouden.",[16,308,309],{},"Er is ook een besturing per iframe die naast de header werkt, het allow-attribuut op het iframe-element, bijvoorbeeld een ingesloten kaart toegevoegd met een frame waarvan het allow-attribuut geolocation toestaat. Het mentale model om vast te houden is dat de header het sitebrede beleid is en het allow-attribuut de uitzondering per insluiting daarbinnen: het frame kan alleen ontvangen wat de header al toestaat, en het attribuut verfijnt of richt dat vervolgens op die specifieke insluiting. Dit is precies waarom een externe widget soms meldt dat een functie is geblokkeerd terwijl de code van de widget correct is, omdat de omliggende pagina die functie nooit voor de origin van de widget heeft toegestaan.",[20,311,170],{"id":169},[16,313,314],{},"Zonder de header valt elke functie terug op zijn eigen standaard allowlist, die voor verschillende functies ruimer is dan een typische site nodig heeft. In de praktijk betekent dat dat mogelijkheden die je nooit gebruikt bereikbaar blijven, en dat ingesloten externe content functies kan aanvragen die je niet zou hebben toegekend als je het gevraagd was.",[16,316,317],{},"Dit is meestal geen urgent gat, en juist daarom blijft het onaangepakt, maar het is wel een reëel gat. Het weegt het zwaarst waar je code insluit die je niet zelf hebt geschreven: een analytics-tag, een chatwidget, een marketingpixel. Het beperken van functies die je niet gebruikt verkleint wat al die ingesloten code kan proberen, en het is precies het soort ontbrekende header dat securityscanners en audits inmiddels op vrijwel elke site aanmerken die hem niet heeft ingesteld.",[20,319,321],{"id":320},"hoe-implementeer-je-de-permissions-policy-header","Hoe implementeer je de Permissions-Policy header?",[16,323,324],{},"Je stelt Permissions-Policy in als één HTTP response header. Een verstandig startbeleid is om de functies uit te schakelen waarvan je weet dat je ze niet gebruikt en de rest tot je eigen origin te beperken, bijvoorbeeld Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), en dan alleen individuele directives te versoepelen waar een echte behoefte bestaat. Hij kan worden toegepast op de webserver, in de applicatielaag, of aan de rand in een CDN of securitylaag voor de site.",[16,326,327],{},"Het helpt om dit tegen een echte site te bekijken in plaats van in abstracte termen. Neem een kliniekwebsite die een ingesloten kaart toont zodat patiënten de praktijk kunnen vinden, en een online boekingstool draait die een betaalstap opent, maar verder geen browserfuncties gebruikt. Een beleid dat op die site is afgestemd zou alles uitschakelen wat hij nooit aanraakt en alleen toestaan wat die twee functies nodig hebben: geolocation beperkt tot de origin van de kaartprovider, payment beperkt tot de boekings- of betaalprovider, en camera, microfoon en de diverse sensorfuncties allemaal uitgezet met een lege allowlist. Het resultaat is een pagina waar de kaart en de checkout precies werken als voorheen, terwijl elke andere mogelijkheid simpelweg niet beschikbaar is voor welk script dan ook, of dat script nu van jou is of van een ingesloten derde partij. Het principe is algemeen toepasbaar: benoem wat de site echt gebruikt, sta die toe aan de specifieke origins die ze leveren, en sluit de rest af.",[16,329,330],{},"Test voordat je hem vastzet. De header heeft een report-only tegenhanger, Permissions-Policy-Report-Only, die de Reporting API van de browser gebruikt om je te vertellen wat een beleid zou blokkeren zonder het daadwerkelijk af te dwingen. Die eerst draaien is de veilige manier om te ontdekken of een echte functie, een kaart die geolocation nodig heeft, een boekingstool die een betaalflow opent, een ingesloten video, door je beleid zou worden gevangen, zodat je die bewust toestaat in plaats van hem per ongeluk te breken.",[20,332,190],{"id":189},[16,334,335],{},"Voor de meeste sites niets zichtbaars. Gewone pagina's die geen beperkte functies gebruiken gedragen zich precies als voorheen, en bezoekers merken niets, omdat het beleid alleen ingrijpt wanneer een stuk code een functie probeert te bereiken die je niet hebt toegestaan.",[16,337,338],{},"De plek om te controleren is elke functie waar je eigen site echt op leunt, en alles wat je ingesloten derde partijen nodig hebben. Een winkelzoeker die geolocation gebruikt, een videobelfunctie die camera en microfoon gebruikt, of een checkout die de payment-API gebruikt, moeten allemaal hun directives zo hebben ingesteld dat de juiste origins worden toegestaan, en dat is precies waarom testen in report-only ertoe doet voordat je afdwingt. Krijg dat één keer goed en de header houdt daarna stilletjes de lijn vast, staat toe wat je bedoelde en weigert al het andere.",[20,340,71],{"id":70},[16,342,343],{},"Begin met controleren of je site überhaupt een Permissions-Policy header verstuurt, want zonder een header valt elke functie simpelweg terug op zijn standaard. Als hij ontbreekt, is het risicoarme pad om hem toe te voegen in report-only modus, de functies op te sommen die je daadwerkelijk gebruikt, te bevestigen dat niets waar je op leunt wordt geblokkeerd, en dan een beleid af te dwingen dat al het andere uitschakelt.",[16,345,204,346],{},[79,347,84],{"href":348,"rel":349},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[83],[20,351,353],{"id":352},"conclusie-wat-moet-je-onthouden-over-de-permissions-policy-header","Conclusie: wat moet je onthouden over de Permissions-Policy header?",[16,355,356],{},"Permissions-Policy is een stille, praktische header: hij laat je de browserfuncties uitschakelen die je site nooit gebruikt en de functies die hij wel gebruikt beperken tot alleen de origins die ze nodig hebben, zodat noch je eigen scripts noch ingesloten derde partijen mogelijkheden kunnen bereiken die je nooit van plan was bloot te stellen. De veilige manier om hem in te voeren is testen in report-only modus, bevestigen dat je echte functies nog werken, en dan een beleid afdwingen dat de rest uitschakelt. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, staat elke functie op zijn standaard.",{"title":93,"searchDepth":94,"depth":94,"links":358},[359,360,361,362,363,364,365,366],{"id":269,"depth":94,"text":270},{"id":279,"depth":94,"text":280},{"id":302,"depth":94,"text":303},{"id":169,"depth":94,"text":170},{"id":320,"depth":94,"text":321},{"id":189,"depth":94,"text":190},{"id":70,"depth":94,"text":71},{"id":352,"depth":94,"text":353},"Met de Permissions-Policy header bepaal je welke browserfuncties, zoals camera, microfoon en locatie, je eigen pagina's en ingesloten content mogen gebruiken. Dit is wat de header doet, hoe je hem instelt, en wat er verandert als je dat doet.",[369,371,373,376,379,381,384,387],{"question":270,"answer":370},"Moderne browsers stellen krachtige mogelijkheden beschikbaar zoals locatie, camera, microfoon en bewegingssensoren, en elk script op je pagina, inclusief ingesloten externe code, kan in principe vragen die te gebruiken. Permissions-Policy bestaat zodat je op siteniveau kunt bepalen welke functies zijn toegestaan en voor wie, en zo het gat dicht tussen wat een browser kan en wat je site echt nodig heeft. Wanneer een beleid een functie blokkeert, wordt de gebruiker niet eens gevraagd en mislukt de poging van een script simpelweg.",{"question":280,"answer":372},"De header is een lijst van directives, één per functie, elk met een allowlist van origins die hem mogen gebruiken. De syntax is de functienaam, een isgelijkteken, en de toegestane origins tussen haakjes, met directives gescheiden door komma's, bijvoorbeeld geolocation=(), camera=(self). Een lege allowlist () schakelt de functie overal uit, self staat alleen je eigen origin toe, een specifieke origin staat die origin toe, en * staat hem overal toe. Elke functie heeft ook een standaard allowlist van *, self of geen die geldt wanneer je niets opgeeft.",{"question":374,"answer":375},"Hoe gedraagt de Permissions-Policy header zich met ingesloten iframes?","Een functie is alleen beschikbaar binnen een ingesloten iframe als aan twee voorwaarden tegelijk wordt voldaan: je top-level pagina moet de functie toestaan voor de origin van dat frame, en het iframe zelf mag hem niet hebben uitgeschakeld. De bovenliggende pagina stelt de buitengrens in en niets wat is ingesloten kan zichzelf een functie toekennen die de bovenliggende pagina heeft onthouden. Het allow-attribuut op het iframe-element werkt daarnaast als uitzondering per insluiting: het frame kan alleen ontvangen wat de header al toestaat.",{"question":377,"answer":378},"Wat gebeurt er als je de Permissions-Policy header niet instelt?","Zonder de header valt elke functie terug op zijn eigen standaard allowlist, die voor verschillende functies ruimer is dan een typische site nodig heeft. Mogelijkheden die je nooit gebruikt blijven bereikbaar, en ingesloten externe content kan functies aanvragen die je niet zou hebben toegekend. Het is zelden urgent, en daarom blijft het onaangepakt, maar het weegt het zwaarst waar je code insluit die je niet zelf schreef, zoals een analytics-tag, chatwidget of marketingpixel, en scanners merken het inmiddels op vrijwel elke site aan die hem niet heeft ingesteld.",{"question":321,"answer":380},"Stel Permissions-Policy in als één HTTP response header, op de webserver, in de applicatielaag of aan de rand. Een verstandig startbeleid schakelt functies uit die je niet gebruikt en beperkt de rest tot je eigen origin, bijvoorbeeld geolocation=(), camera=(), microphone=(), payment=(). Test eerst met de report-only tegenhanger, Permissions-Policy-Report-Only, die de Reporting API van de browser gebruikt om te vertellen wat een beleid zou blokkeren zonder het af te dwingen, zodat je echte functies bewust toestaat in plaats van ze per ongeluk te breken.",{"question":382,"answer":383},"Wat verandert er op je site zodra de Permissions-Policy header aanstaat?","Voor de meeste sites verandert er niets zichtbaars, omdat het beleid alleen ingrijpt wanneer code een functie probeert te bereiken die je niet hebt toegestaan. De plek om te controleren is elke functie waar je eigen site op leunt en alles wat je ingesloten derde partijen nodig hebben, zoals een winkelzoeker met geolocation, een videofunctie met camera en microfoon, of een checkout met de payment-API, die allemaal hun directives zo moeten hebben ingesteld dat de juiste origins worden toegestaan. Daarom doet testen in report-only ertoe voordat je afdwingt.",{"question":385,"answer":386},"Wat moet je nu doen met de Permissions-Policy header?","Controleer of je site überhaupt een Permissions-Policy header verstuurt, want zonder een header valt elke functie terug op zijn standaard. Als hij ontbreekt, voeg hem toe in report-only modus, som de functies op die je daadwerkelijk gebruikt, bevestig dat niets waar je op leunt wordt geblokkeerd, en dwing dan een beleid af dat al het andere uitschakelt.",{"question":388,"answer":389},"Wat moet je onthouden over de Permissions-Policy header?","Permissions-Policy laat je de browserfuncties uitschakelen die je site nooit gebruikt en de functies die hij wel gebruikt beperken tot alleen de origins die ze nodig hebben, zodat noch je eigen scripts noch ingesloten derde partijen mogelijkheden kunnen bereiken die je nooit wilde blootstellen. De veilige manier om hem in te voeren is testen in report-only modus, bevestigen dat je echte functies nog werken, en dan een beleid afdwingen dat de rest uitschakelt. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, staat elke functie op zijn standaard.",{},"\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy","8 minuten",{"title":258,"description":367},"what-is-permissions-policy","blog\u002Fnl\u002Fwhat-is-permissions-policy",[397,225,253,398],"Permissions-Policy","Privacy","HA0UjuttZdPkXfGe014PR-rVNqdxHSkoeDnA4gJrgiY",{"id":401,"title":402,"author":7,"body":403,"category":1021,"date":1022,"description":1023,"extension":105,"faq":1021,"meta":1024,"navigation":122,"path":1025,"readingTime":1021,"seo":1026,"slug":1027,"stem":1028,"tags":1029,"__hash__":1033},"blog\u002Fblog\u002Fnl\u002Fcore-web-vitals-cdn.md","Core Web Vitals: Hoe een CDN je Website Helpt Beter te Scoren",{"type":9,"value":404,"toc":999},[405,412,415,418,421,425,428,433,440,446,451,467,471,474,480,486,491,505,509,515,521,526,540,544,547,551,556,559,562,567,570,596,601,604,608,611,616,619,624,627,638,641,646,649,660,664,669,672,677,680,694,699,702,706,709,713,718,727,730,735,741,744,748,751,778,782,785,805,809,812,833,837,840,845,856,861,872,875,879,884,887,892,895,900,903,908,911,915,918,923,926,931,945,950,953,958,961,965,968,971,983,985,995],[16,406,407,411],{},[408,409,410],"strong",{},"Trefwoorden:"," Core Web Vitals, CDN prestaties, LCP optimalisatie, FID verbetering, CLS oplossingen, website snelheid, Google ranking factoren, pagina-ervaring, web performance optimalisatie, Europees CDN",[413,414],"hr",{},[16,416,417],{},"In 2021 introduceerde Google Core Web Vitals als officiële rankingfactoren, waardoor website-eigenaren fundamenteel anders gingen nadenken over prestaties. Deze metrics—Largest Contentful Paint (LCP), First Input Delay (FID) en Cumulative Layout Shift (CLS)—meten de echte gebruikerservaring en beïnvloeden direct je zichtbaarheid in zoekmachines. Sinds 2024 heeft Google FID vervangen door Interaction to Next Paint (INP), waardoor interactiviteit nog belangrijker is geworden.",[16,419,420],{},"Als je website worstelt met Core Web Vitals, ben je niet alleen. Volgens recente gegevens haalt ongeveer 40% van de websites nog steeds de drempelwaarden van Google niet. Het goede nieuws? Een correct geconfigureerd Content Delivery Network (CDN) kan alle drie de metrics drastisch verbeteren. In deze uitgebreide gids onderzoeken we precies hoe.",[20,422,424],{"id":423},"core-web-vitals-in-2026-begrijpen","Core Web Vitals in 2026 Begrijpen",[16,426,427],{},"Voordat we ingaan op CDN-optimalisatie, laten we eerst begrijpen wat elke metric meet en waarom het belangrijk is.",[429,430,432],"h3",{"id":431},"largest-contentful-paint-lcp","Largest Contentful Paint (LCP)",[16,434,435,436,439],{},"LCP meet laadprestaties—specifiek hoe lang het duurt voordat het grootste zichtbare content-element wordt weergegeven. Dit kan een hero-afbeelding zijn, een video-thumbnail of een groot tekstblok. Google beschouwt een goede LCP als ",[408,437,438],{},"2,5 seconden of minder",".",[16,441,442,445],{},[408,443,444],{},"Waarom LCP belangrijk is:"," Gebruikers ervaren een pagina als \"geladen\" wanneer ze de hoofdcontent kunnen zien. Een trage LCP betekent dat bezoekers naar een leeg of gedeeltelijk geladen scherm staren, wat het bouncepercentage verhoogt.",[16,447,448],{},[408,449,450],{},"Veelvoorkomende LCP-problemen:",[452,453,454,458,461,464],"ul",{},[455,456,457],"li",{},"Trage serverresponstijden",[455,459,460],{},"Render-blokkerende JavaScript en CSS",[455,462,463],{},"Grote, niet-geoptimaliseerde afbeeldingen",[455,465,466],{},"Vertragingen door client-side rendering",[429,468,470],{"id":469},"interaction-to-next-paint-inp","Interaction to Next Paint (INP)",[16,472,473],{},"INP verving First Input Delay in maart 2024 en meet de algehele responsiviteit gedurende de gehele levenscyclus van de pagina. Terwijl FID alleen de vertraging van de eerste interactie mat, houdt INP rekening met alle interacties—klikken, tikken en toetsenbordinvoer—en rapporteert de slechtste (met enige statistische afvlakking).",[16,475,476,477,439],{},"Google beschouwt een goede INP als ",[408,478,479],{},"200 milliseconden of minder",[16,481,482,485],{},[408,483,484],{},"Waarom INP belangrijk is:"," Gebruikers verwachten onmiddellijke feedback wanneer ze met je website interacteren. Een trage knop of niet-reageren formulier voelt kapot aan, zelfs als de pagina snel geladen is.",[16,487,488],{},[408,489,490],{},"Veelvoorkomende INP-problemen:",[452,492,493,496,499,502],{},[455,494,495],{},"Zware JavaScript-uitvoering die de main thread blokkeert",[455,497,498],{},"Third-party scripts die strijden om resources",[455,500,501],{},"Inefficiënte event handlers",[455,503,504],{},"Complexe DOM-operaties tijdens interacties",[429,506,508],{"id":507},"cumulative-layout-shift-cls","Cumulative Layout Shift (CLS)",[16,510,511,512,439],{},"CLS meet visuele stabiliteit—hoeveel de pagina-inhoud beweegt tijdens het laden. Elke keer dat een element onverwacht van positie verandert, draagt het bij aan je CLS-score. Google beschouwt een goede CLS als ",[408,513,514],{},"0,1 of minder",[16,516,517,520],{},[408,518,519],{},"Waarom CLS belangrijk is:"," Onverwachte layout-verschuivingen zijn frustrerend. Je staat op het punt een link te klikken, en plotseling laadt er een advertentie erboven, waardoor alles naar beneden schuift. Nu heb je op het verkeerde geklikt. CLS vangt deze frustratie kwantitatief.",[16,522,523],{},[408,524,525],{},"Veelvoorkomende CLS-problemen:",[452,527,528,531,534,537],{},[455,529,530],{},"Afbeeldingen en embeds zonder gedefinieerde afmetingen",[455,532,533],{},"Dynamisch geïnjecteerde content",[455,535,536],{},"Webfonts die tekst-reflow veroorzaken",[455,538,539],{},"Advertenties en iframes die laat laden",[20,541,543],{"id":542},"hoe-een-cdn-elke-core-web-vital-verbetert","Hoe een CDN Elke Core Web Vital Verbetert",[16,545,546],{},"Een CDN gaat niet alleen over snelheid—het is een prestatieversterker die meerdere pijnpunten tegelijkertijd aanpakt. Hier is hoe het elke metric helpt.",[429,548,550],{"id":549},"cdn-impact-op-lcp","CDN Impact op LCP",[16,552,553],{},[408,554,555],{},"Verminderde Time to First Byte (TTFB)",[16,557,558],{},"De belangrijkste factor in LCP is vaak TTFB—hoe lang de browser wacht voordat het eerste byte HTML ontvangt. Wanneer je server in Frankfurt staat en je bezoeker in Madrid is, moet elk verzoek honderden kilometers afleggen. Een CDN met edge-servers door heel Europa elimineert deze latentie.",[16,560,561],{},"Met EuroraCloud's 45+ Europese points of presence wordt je content geleverd vanaf een locatie die doorgaans binnen 50ms van je bezoekers ligt. Dit alleen al kan 200-500ms van je LCP afschaven.",[16,563,564],{},[408,565,566],{},"Geoptimaliseerde Afbeeldingslevering",[16,568,569],{},"Afbeeldingen zijn het LCP-element op de meeste pagina's. Een CDN kan:",[452,571,572,578,584,590],{},[455,573,574,577],{},[408,575,576],{},"Moderne formaten leveren:"," Automatisch afbeeldingen converteren naar WebP of AVIF, waardoor bestandsgroottes met 30-50% afnemen",[455,579,580,583],{},[408,581,582],{},"Responsieve sizing:"," Passend grote afbeeldingen leveren op basis van device viewport",[455,585,586,589],{},[408,587,588],{},"Lazy loading optimalisatie:"," Zorgen dat above-the-fold afbeeldingen direct laden terwijl andere worden uitgesteld",[455,591,592,595],{},[408,593,594],{},"Compressie:"," Optimale compressie toepassen zonder zichtbaar kwaliteitsverlies",[16,597,598],{},[408,599,600],{},"Caching elimineert origin-verzoeken",[16,602,603],{},"Wanneer content in de edge is gecached, ontvangen bezoekers deze direct zonder enig verzoek naar je origin-server. Dit is dramatisch sneller dan zelfs de meest geoptimaliseerde origin-response.",[429,605,607],{"id":606},"cdn-impact-op-inp","CDN Impact op INP",[16,609,610],{},"Hoewel INP voornamelijk wordt beïnvloed door client-side JavaScript, draagt een CDN op verschillende belangrijke manieren bij:",[16,612,613],{},[408,614,615],{},"Snellere scriptlevering",[16,617,618],{},"Je JavaScript-bestanden bereiken bezoekers sneller wanneer ze vanaf edge-locaties worden geleverd. Dit betekent dat je interactieve elementen eerder functioneel worden.",[16,620,621],{},[408,622,623],{},"HTTP\u002F3 en verbindingsoptimalisatie",[16,625,626],{},"Moderne CDN's ondersteunen HTTP\u002F3 (QUIC), wat biedt:",[452,628,629,632,635],{},[455,630,631],{},"Zero round-trip verbindingsopbouw",[455,633,634],{},"Verbeterd pakketverlies-herstel",[455,636,637],{},"Gemultiplexte streams zonder head-of-line blocking",[16,639,640],{},"Deze optimalisaties verminderen de overhead van het laden van meerdere resources, waardoor meer main thread-tijd overblijft voor het afhandelen van interacties.",[16,642,643],{},[408,644,645],{},"Edge computing voor dynamische features",[16,647,648],{},"Geavanceerde CDN's bieden edge computing-mogelijkheden, waarmee je logica aan de netwerkrand kunt uitvoeren. Dit kan werk van de client offloaden:",[452,650,651,654,657],{},[455,652,653],{},"A\u002FB-testbeslissingen aan de edge in plaats van client-side",[455,655,656],{},"Personalisatie zonder JavaScript",[455,658,659],{},"Formuliervalidatie en -verwerking",[429,661,663],{"id":662},"cdn-impact-op-cls","CDN Impact op CLS",[16,665,666],{},[408,667,668],{},"Placeholder en dimensie-afdwinging",[16,670,671],{},"Een CDN met afbeeldingsoptimalisatie kan automatisch width en height attributen aan afbeeldingen toevoegen, waardoor layout-verschuivingen tijdens het laden worden voorkomen.",[16,673,674],{},[408,675,676],{},"Font-optimalisatie",[16,678,679],{},"Webfonts zijn een grote CLS-boosdoener. Wanneer een aangepast lettertype laadt, veroorzaakt het vaak tekst-reflow (bekend als FOUT—Flash of Unstyled Text). CDN-optimalisatie omvat:",[452,681,682,685,688,691],{},[455,683,684],{},"Preloaden van kritieke fonts",[455,686,687],{},"Font subsetting om bestandsgroottes te verkleinen",[455,689,690],{},"font-display: swap afhandeling",[455,692,693],{},"Fonts leveren vanaf edge-locaties voor sneller laden",[16,695,696],{},[408,697,698],{},"Consistente third-party loading",[16,700,701],{},"Hoewel je niet kunt controleren hoe third-party scripts zich gedragen, zorgt het serveren via je CDN (waar mogelijk) voor meer consistente timing, waardoor onverwachte verschuivingen verminderen.",[20,703,705],{"id":704},"praktische-cdn-configuratie-voor-core-web-vitals","Praktische CDN-Configuratie voor Core Web Vitals",[16,707,708],{},"Laten we specifiek worden over hoe je je CDN configureert voor optimale Core Web Vitals.",[429,710,712],{"id":711},"caching-strategie","Caching Strategie",[16,714,715],{},[408,716,717],{},"Statische assets (afbeeldingen, CSS, JS):",[719,720,725],"pre",{"className":721,"code":723,"language":724},[722],"language-text","Cache-Control: public, max-age=31536000, immutable\n","text",[290,726,723],{"__ignoreMap":93},[16,728,729],{},"Gebruik lange cache-duraties met cache-busting bestandsnamen voor versiebeheer.",[16,731,732],{},[408,733,734],{},"HTML-documenten:",[719,736,739],{"className":737,"code":738,"language":724},[722],"Cache-Control: public, max-age=300, stale-while-revalidate=86400\n",[290,740,738],{"__ignoreMap":93},[16,742,743],{},"Korte TTL met stale-while-revalidate zorgt voor verse content terwijl origin-vertragingen worden vermeden.",[429,745,747],{"id":746},"afbeeldingsoptimalisatie-instellingen","Afbeeldingsoptimalisatie-instellingen",[16,749,750],{},"Schakel deze features in als je CDN ze ondersteunt:",[752,753,754,760,766,772],"ol",{},[455,755,756,759],{},[408,757,758],{},"Automatische WebP\u002FAVIF-conversie"," - Lever moderne formaten aan ondersteunde browsers",[455,761,762,765],{},[408,763,764],{},"Responsieve afbeeldingen"," - Lever passende groottes via Client Hints",[455,767,768,771],{},[408,769,770],{},"Lazy loading injectie"," - Voeg loading=\"lazy\" toe aan below-fold afbeeldingen",[455,773,774,777],{},[408,775,776],{},"Kwaliteitsoptimalisatie"," - Gebruik perceptuele kwaliteitsmetrics (zoals SSIM) in plaats van vaste compressie",[429,779,781],{"id":780},"preloaden-van-kritieke-resources","Preloaden van Kritieke Resources",[16,783,784],{},"Gebruik HTTP\u002F2 Server Push of 103 Early Hints om kritieke resources te preloaden:",[719,786,790],{"className":787,"code":788,"language":789,"meta":93,"style":93},"language-http shiki shiki-themes github-light github-dark","Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\nLink: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n","http",[290,791,792,800],{"__ignoreMap":93},[793,794,797],"span",{"class":795,"line":796},"line",1,[793,798,799],{},"Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\n",[793,801,802],{"class":795,"line":94},[793,803,804],{},"Link: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n",[429,806,808],{"id":807},"beveiligingsheaders-zonder-prestatie-impact","Beveiligingsheaders Zonder Prestatie-impact",[16,810,811],{},"CDN's kunnen beveiligingsheaders aan de edge toevoegen zonder je origin te beïnvloeden:",[719,813,815],{"className":787,"code":814,"language":789,"meta":93,"style":93},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\n",[290,816,817,822,827],{"__ignoreMap":93},[793,818,819],{"class":795,"line":796},[793,820,821],{},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\n",[793,823,824],{"class":795,"line":94},[793,825,826],{},"X-Content-Type-Options: nosniff\n",[793,828,830],{"class":795,"line":829},3,[793,831,832],{},"Referrer-Policy: strict-origin-when-cross-origin\n",[20,834,836],{"id":835},"de-impact-meten","De Impact Meten",[16,838,839],{},"Na het implementeren van CDN-optimalisaties, meet je verbeteringen met:",[16,841,842],{},[408,843,844],{},"Lab tools (synthetisch testen):",[452,846,847,850,853],{},[455,848,849],{},"Google Lighthouse",[455,851,852],{},"WebPageTest",[455,854,855],{},"Chrome DevTools Performance panel",[16,857,858],{},[408,859,860],{},"Velddata (echte gebruikers):",[452,862,863,866,869],{},[455,864,865],{},"Google Search Console Core Web Vitals rapport",[455,867,868],{},"Chrome User Experience Report (CrUX)",[455,870,871],{},"Real User Monitoring (RUM) oplossingen",[16,873,874],{},"De CrUX-data is wat Google daadwerkelijk gebruikt voor ranking, dus geef prioriteit aan velddata boven lab-metingen.",[20,876,878],{"id":877},"veelvoorkomende-fouten-om-te-vermijden","Veelvoorkomende Fouten om te Vermijden",[16,880,881],{},[408,882,883],{},"Te agressief cachen van dynamische content",[16,885,886],{},"HTML te agressief cachen kan ervoor zorgen dat gebruikers verouderde content zien. Gebruik passende TTL's en cache-busting voor gepersonaliseerde elementen.",[16,888,889],{},[408,890,891],{},"Mobiele gebruikers vergeten",[16,893,894],{},"Mobiele netwerken hebben hogere latentie en meer variabele prestaties. Test specifiek op vertraagde mobiele verbindingen.",[16,896,897],{},[408,898,899],{},"Third parties vergeten",[16,901,902],{},"Je CDN kan alleen resources optimaliseren die het levert. Audit third-party scripts en verwijder of stel niet-essentiële uit.",[16,904,905],{},[408,906,907],{},"Alleen lab-data meten",[16,909,910],{},"Lab-tests tonen potentieel, niet realiteit. Je echte gebruikers kunnen andere apparaten, netwerken en gedrag hebben.",[20,912,914],{"id":913},"waarom-europese-bedrijven-kiezen-voor-euroracloud","Waarom Europese Bedrijven Kiezen voor EuroraCloud",[16,916,917],{},"Voor Europese websites is datalocatie belangrijk—zowel voor compliance als prestaties. EuroraCloud biedt:",[16,919,920],{},[408,921,922],{},"45+ Europese Edge-Locaties",[16,924,925],{},"Van Lissabon tot Helsinki, Stockholm tot Athene, je content wordt gecached dicht bij je Europese bezoekers. Dit vertaalt zich naar consistent snelle LCP-tijden over het hele continent.",[16,927,928],{},[408,929,930],{},"Ingebouwde Prestatiefeatures",[452,932,933,936,939,942],{},[455,934,935],{},"Automatische afbeeldingsoptimalisatie met WebP\u002FAVIF-ondersteuning",[455,937,938],{},"HTTP\u002F3 standaard ingeschakeld",[455,940,941],{},"Slimme caching met instant purge-mogelijkheid",[455,943,944],{},"Realtime prestatie-analytics",[16,946,947],{},[408,948,949],{},"GDPR-Conforme Infrastructuur",[16,951,952],{},"Alle verwerking gebeurt binnen de EU. Geen datatransfers naar derde landen, wat je compliance-verplichtingen vereenvoudigt.",[16,954,955],{},[408,956,957],{},"Eenvoudige, Transparante Prijzen",[16,959,960],{},"Geen verborgen kosten voor features die standaard zouden moeten zijn. Prestatieoptimalisatie is inbegrepen, geen add-on.",[20,962,964],{"id":963},"conclusie","Conclusie",[16,966,967],{},"Core Web Vitals zijn niet alleen ijdelheidsmetrics—ze beïnvloeden direct je zoekrankings en gebruikerservaring. Een CDN is een van de meest effectieve tools om alle drie de metrics tegelijkertijd te verbeteren.",[16,969,970],{},"Door latentie te verminderen, assets te optimaliseren en moderne leveringsprotocollen te bieden, kan een correct geconfigureerd CDN je Core Web Vitals scores transformeren. Voor Europese bedrijven zorgt de keuze voor een CDN met sterke Europese aanwezigheid voor de best mogelijke ervaring voor je primaire publiek.",[16,972,973,976,977,982],{},[408,974,975],{},"Klaar om je Core Web Vitals te verbeteren?"," ",[79,978,981],{"href":979,"rel":980},"https:\u002F\u002Fwww.euroracloud.eu",[83],"Probeer EuroraCloud 14 dagen gratis"," en ervaar het verschil dat een European-first CDN kan maken.",[413,984],{},[16,986,987],{},[28,988,989,990,994],{},"Vragen over het optimaliseren van je Core Web Vitals? Neem contact op met ons performance-team via ",[79,991,993],{"href":992},"mailto:support@euroracloud.eu","support@euroracloud.eu","—we helpen je graag.",[996,997,998],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":93,"searchDepth":94,"depth":94,"links":1000},[1001,1006,1011,1017,1018,1019,1020],{"id":423,"depth":94,"text":424,"children":1002},[1003,1004,1005],{"id":431,"depth":829,"text":432},{"id":469,"depth":829,"text":470},{"id":507,"depth":829,"text":508},{"id":542,"depth":94,"text":543,"children":1007},[1008,1009,1010],{"id":549,"depth":829,"text":550},{"id":606,"depth":829,"text":607},{"id":662,"depth":829,"text":663},{"id":704,"depth":94,"text":705,"children":1012},[1013,1014,1015,1016],{"id":711,"depth":829,"text":712},{"id":746,"depth":829,"text":747},{"id":780,"depth":829,"text":781},{"id":807,"depth":829,"text":808},{"id":835,"depth":94,"text":836},{"id":877,"depth":94,"text":878},{"id":913,"depth":94,"text":914},{"id":963,"depth":94,"text":964},null,"2026-02-09","Gepubliceerd: 9 februari 2026 | Categorie: Performance | Leestijd: 8 minuten",{},"\u002Fblog\u002Fnl\u002Fcore-web-vitals-cdn",{"title":402,"description":1023},"core-web-vitals-hoe-een-cdn-helpt","blog\u002Fnl\u002Fcore-web-vitals-cdn",[1030,1031,1032],"CDN","Performance","Web Security","UunFFWK8p4QgARmJKJlb58qZ4osNjRylQMKPCgkHKKM",1785141122437]