Heeft je website te kampen met trage prestaties en veel netwerkverkeer? Omdat cookies vaak de boosdoener zijn, is een effectieve oplossing om cookieloze domeinen te gebruiken.

Hoewel cookies een van de belangrijkste bouwstenen zijn van onze online ervaring, zijn ze niet altijd zo lekker als hun naam doet vermoeden. Naast privacy- en veiligheidsproblemen met externe cookies, kunnen cookies die automatisch aan de afbeeldingen en andere statische content van je site worden gekoppeld een ernstige invloed hebben op de prestaties van je pagina’s.

Gelukkig is het mogelijk om het dode gewicht (in dit geval, dode cookies) te verminderen door cookieloze domeinen te gebruiken. In deze complete handleiding bespreken we de basisprincipes van cookieloze domeinen, waarom ze zo nuttig zijn, en hoe je je WordPress site kunt configureren om ze te gebruiken.

Maar laten we eerst eens in de digitale koektrommel kijken hoe domeinen cookies gebruiken – ten goede of ten kwade.

Wat zijn cookieloze domeinen?

Cookieloze domeinen zijn delen van een website die geen cookies naar de browsers van gebruikers sturen.

Maar waarom zou je niet altijd cookies willen aanbieden? Is het immers niet beleefd zijn om je bezoekers zoveel mogelijk cookies te geven?

Niet noodzakelijkerwijs. Als we het hebben over cookieloze domeinen, hebben we het natuurlijk over HTTP cookies. In tegenstelling tot onze favoriete lekkernijen zijn HTTP cookies kleine pakketjes gegevens die websites naar de browsers van gebruikers sturen. Hoewel ze niet erg smakelijk zijn, zijn ze uiterst nuttig om websites in staat te stellen gebruikers te “onthouden” bij hun volgende bezoek.

Maar net als bij echte cookies wil je niet te veel HTTP cookies aanbieden. Zoals we straks zullen zien, stellen bezoekers een klein aantal cookies zeer op prijs – maar geef ze meer dan ze nodig hebben en ze krijgen een traag en opgeblazen gevoel.

Wat zijn HTTP cookies?

HTTP cookies vind je overal op het web.

Wanneer je een website bezoekt, is de kans groot dat de website je vraagt om cookies op te slaan in je browser. Naast informatie over de website zelf en de pagina die je hebt bezocht, bevatten cookies een persoonlijke identificatiecode die aan jou en je browser is gekoppeld. Met deze identificatie kan de website “onthouden” of je de pagina al eerder hebt bezocht.

Laten we eens beter bekijken hoe deze cookie-uitwisseling werkt (spoiler alert: er komt geen chocolade, deeg en de geur van versgebakken koekjes bij kijken).

Hoe websites HTTP cookies naar de webbrowsers van gebruikers sturen
Hoe websites HTTP cookies naar de webbrowsers van gebruikers sturen

Zoals de afbeelding hierboven laat zien, kan de uitwisseling worden onderverdeeld in drie stappen:

  1. Je browser vraagt een webpagina op. Wanneer je een adres (bijvoorbeeld een domein URL zoals “kinsta.com”) in de adresbalk van je browser invoert of op een weblink klikt, genereert je browser een HTTP verzoek dat de website vertelt dat hij de pagina wil bekijken. Dit verzoek wordt naar de webserver gestuurd die de website en zijn pagina’s host.
  2. De webserver stuurt de pagina én de cookie. Na ontvangst van je verzoek stuurt de webserver de gevraagde pagina en een cookie met bepaalde informatie terug. Zoals we al eerder zeiden, bevat deze cookie bijna altijd een persoonlijke identificatie voor jou en je browser.
  3. De browser vraagt een andere pagina op bij dezelfde server. Stel nu dat je op een link naar een andere pagina op de website klikt, zoals “Shop” of “Over ons” op een e-commerce site. Hier stuurt je browser opnieuw een verzoek naar de webserver inclusief de cookie die hij oorspronkelijk had gekregen. Wanneer de webserver dit verzoek ontvangt, ziet hij de eerder verzonden cookie en herinnert hij zich dat je de website al bezocht hebt. Met die informatie kan de webserver meer gepersonaliseerde ervaringen leveren, zoals het bijhouden van een actieve login of items in een winkelwagentje.

Er zijn verschillende cookies voor verschillende doeleinden. In het bovenstaande voorbeeld onderhoudt de webserver die zich bezighoudt met sessiebeheer je login of winkelwagenitems – met andere woorden, je individuele sessie op hun website. Evenzo kunnen cookies ook worden gebruikt om gepersonaliseerde ervaringen te leveren, zoals het tonen van recente bestellingen, bekeken items, of zelfs gerichte advertenties.

Het klinkt misschien leuk om overal cookies te krijgen, maar het is niet je van het. Zoals we in de volgende paragraaf zullen zien, is het feitelijk mogelijk dat een website teveel cookies levert – waarvan veel mensen liever niet “eten”

Zo gebruiken domeinen HTTP cookies

Hoewel persoonlijke identificatie een zeer belangrijk gebruik is van HTTP cookies, is dat niet het enige. In feite kunnen cookies worden gebruikt voor een breed scala aan doeleinden om meer gepersonaliseerde webervaringen te bieden, gerichte content te leveren en meer.

Zo kunnen cookies worden gebruikt om de privacy te schenden
Zo kunnen cookies worden gebruikt om de privacy te schenden

We hebben al besproken hoe websites en browsers HTTP cookies uitwisselen om je te “onthouden”. Hoewel dat nuttig kan zijn voor het onderhouden van inlogsessies en het tonen van items in het winkelwagentje, kunnen cookies ook gebruikt worden voor meer snode (of ronduit vervelende) doeleinden.

Hier zijn enkele van de meest voorkomende manieren waarop domeinen HTTP cookies gebruiken.

  • Sessiebeheer. Deze ken je inmiddels al. Sessiebeheer wordt vaak beschouwd als het meest “goedaardige” gebruik van HTTP cookies, omdat het enige doel ervan is een consistente gebruikerservaring te bieden die de gebruiker helpt voorkomen dat hij bepaalde handelingen moet herhalen. Hoewel het zien van eerdere activiteiten voor sommige gebruikers privacyproblemen kan opleveren, is het relatief onschuldig. De echte privacyproblemen ontstaan wanneer cookies worden gebruikt voor tracking, wat we binnenkort zullen behandelen.
  • Personalisatie. Sessiebeheer kan ook worden gebruikt om webpagina’s te personaliseren op basis van de voorkeuren en activiteiten van de gebruiker. Bijvoorbeeld, na het selecteren van de taal van hun keuze, kunnen gebruikers de website bij volgende bezoeken in diezelfde taal bekijken, zonder dat ze dat elke keer hoeven te veranderen. Cookies kunnen websites ook in staat stellen zich aan te passen aan de specifieke eisen van verschillende webbrowsers.
  • Tracking. Cookies hebben ook een controversiële kant. Omdat je browser de cookies opslaat die websites je geven, kunnen die cookies gebruikt worden om je overal op het web te volgen. Je kunt bijvoorbeeld een website bezoeken die je browser een trackingcookie geeft om aangesloten adverteerders op het web te laten weten dat je hun pagina hebt bezocht. Wanneer adverteerders deze cookie opmerken, kunnen ze gerichte advertenties voor de oorspronkelijke website tonen of zelfs gebruiken als een ingang voor cyberaanvallen. In elk geval kunnen trackingcookies het gevoel geven dat je “gevolgd” wordt – iets wat een hoop ethische en privacy bezwaren met zich meebrengt.

Gelukkig worden de meeste HTTP cookies gebruikt voor sessiebeheer en personalisatie. Maar zelfs de meest onschuldige cookies kunnen problemen veroorzaken.

Tot nu toe hebben we het idee onderzocht van één pagina die één cookie verstuurt. In werkelijkheid stuurt één pagina meestal meerdere cookies, vaak één voor elk pagina-element – HTML, afbeeldingsbestanden, enzovoort. Hoewel sommige van deze cookies nodig zijn voor sessiebeheer en personalisatie, zijn veel ervan dat niet.

Daardoor is het mogelijk om te veel cookies te sturen, en dat kan verschillende problemen veroorzaken. Die problemen bespreken we in de volgende paragraaf.

Te veel cookies voeren

Anders dan de meeste gewone documenten zijn webpagina’s een verzameling van verschillende elementen die ze vorm, structuur en betekenis geven. Elk van deze elementen kan zijn eigen cookie hebben.

Terwijl gewone documenten die we in .pdf of .docx format bekijken een enkele “combinatie” lijken van tekst en afbeeldingen, zijn webpagina’s opgebouwd uit vele afzonderlijke, kleine onderdelen.

HTML, CSS en JavaScript zijn de belangrijkste onderdelen van de meeste websites
HTML, CSS en JavaScript zijn de belangrijkste onderdelen van de meeste websites

Als je bijvoorbeeld een webpagina opvraagt, vraag je eigenlijk om afzonderlijke pagina onderdelen, zoals HTML (structuur), CSS (stijl/opmaak), JavaScript (interactiviteit) en media, zoals afbeeldingen. Als je browser dus een webpagina ontvangt, ontvangt en combineert hij deze componenten om de complete pagina op je scherm weer te geven.

Als de webserver ook cookies verstuurt, stuurt hij tijdens dit proces automatisch een cookie mee met elk element. Dat betekent misschien niet veel voor een eenvoudige webpagina met slechts een paar afbeeldingen, maar het kan snel heel veel worden als een webpagina tientallen of zelfs honderden verschillende onderdelen heeft – en voor elk daarvan een cookie stuurt.

Net als het eten van te veel koekjes in het echte leven, leidt het verzenden en ontvangen van teveel HTTP cookies tot trage prestaties. Omdat het verzenden van extra gegevens extra tijd en resources vergt, kan het meezenden van cookies bij elk element gemakkelijk een enorme hoeveelheid netwerkresources verbruiken.

Zet je domein op dieet: ga de cookieloze route

Gelukkig is de oplossing voor het verzenden van te veel cookies eenvoudig: om de prestaties te verbeteren, eet (lees: stuur) je gewoon minder cookies.

Maar welke cookies moeten we opgeven? In de meeste gevallen is het het beste om de cookies te verwijderen van alle statische elementen op je pagina.

Statische elementen zijn elementen waarvan je niet verwacht dat ze veranderen door gebruikersgedrag, zoals statische afbeeldingen of statische bestanden, zoals CSS bestanden. Daarom hoeven er geen cookies aan vast te zitten, waardoor het verwijderen ervan een van de beste manieren is om de netwerkbelasting te verminderen en de prestaties te verbeteren.

Natuurlijk is het verwijderen van cookies niet zo eenvoudig als het uitvinken van een “cookies” vakje.

In plaats daarvan gebruiken webservers cookieloze domeinen om statische content zonder cookies apart van content met cookies te verspreiden. Een cookieloos domein is meestal een apart domein (zoals een subdomein of FQDN, zoals “static.kinsta.com” of “kinsta.com“).

Structuur van een URL met een subdomein
Structuur van een URL met een subdomein

Gelukkig is het niet erg moeilijk om cookieloze domeinen te gebruiken als je de juiste tools gebruikt – en het opzetten van een subdomein is niet de enige methode om dat te doen.

Maar voordat we onze handen vuil maken, laten we eerst een paar van de grootste voordelen van het gebruik van cookieloze domeinen bekijken, en hoe groot de impact op je website (en je budget) kan zijn.

Waarom cookieloze domeinen gebruiken?

Het verwijderen van extra cookies klinkt misschien als iets dat je zo maar even doet – en eerlijk gezegd is dat ook zo.

Maar aan deze kleine actie zijn grote voordelen verbonden. Door alleen de cookies te sturen die je nodig hebt, verlicht je je netwerkverkeer en profiteer je van veel van de onderstaande voordelen – waarvan sommige helemaal niets te maken hebben met prestaties.

Vermindert onnodig netwerkverkeer

De meeste voordelen van het gebruik van cookieloze domeinen komen voort uit het verminderen van netwerkbelasting door onnodig cookieverkeer.

Zoals we eerder hebben besproken, vereist het verzenden van pagina-elementen naar je bezoekers een bepaalde hoeveelheid netwerkresources. Naast de elementen zelf, wordt elk element (of zelfs meerdere delen van hetzelfde element) verzonden met response headers die routingsinformatie bevatten, samen met andere elementen zoals cookies.

Hoewel cookies relatief kleine gegevensbestanden zijn, kan het verzenden van veel ervan bij elk paginaverzoek snel oplopen. Als gevolg daarvan moeten gebruikers langer wachten tot de pagina geladen is, terwijl je arme webhost overstelpt wordt (en je daardoor over je limiet heengaat).

Als je echter cookieloze domeinen gebruikt, elimineer je het overschot dat veroorzaakt wordt door het versturen van onnodige cookies.

Verbetert de prestaties van de website

Zoals je je kunt voorstellen heeft het verminderen van netwerkbelasting door het verminderen van cookies een aanzienlijke invloed op laadtijden en websiteprestaties.

Omdat elke paginaklik een apart verzoek aan de webserver is, kunnen gebruikers langere tijd moeten wachten om de basisnavigatie uit te voeren (Homepagina > Over ons > Shop, enz.). Hoewel paginaelementen en cookies worden gecachet en opnieuw worden gebruikt na de eerste keer laden, kan dit toch een probleem vormen als de pagina’s veranderen of de gebruiker nog dieper in je website duikt.

Voordelen SEO en gebruikerservaring

Door onnodig verkeer te verminderen om de websiteprestaties te verbeteren, kan je website ook voordelen zien met betrekking tot zoekmachineoptimalisatie (SEO) en natuurlijk de klant- en gebruikerservaring.

Klantervaring is het meest voor de hand liggende voordeel: met een kortere laadtijd hebben gebruikers sneller toegang tot de gewenste content. Daardoor zullen ze je website (en je producten of diensten) eerder verkennen en minder snel gefrustreerd wegklikken.

Hetzelfde voordeel geldt ook voor SEO. Hoewel laadtijden van pagina’s geen directe invloed hebben op SEO, heeft je bouncepercentage – het percentage bezoekers dat van je pagina wegklikt – dat zeker wel.

Shoppers willen niet lang wachten op het laden van een pagina
Laadtijden van pagina’s

Volgens een rapport van Unbounce verlaat driekwart van de bezoekers een pagina als ze vier seconden of langer moeten wachten op het laden ervan.

Dit betekent dat zelfs als het verwijderen van onnodige cookies je laadtijden met slechts een seconde verbetert, je toch een enorme vermindering van in bounces ziet en, als gevolg daarvan, een boost in je zoekmachinerankings.

Verlaagt hostingkosten

Netwerkverkeer kost je uiteindelijk geld aan webhostingkosten.

Dat betekent dat als je meer cookies verstuurt dan je nodig hebt, je ook veel meer betaalt aan webhostingkosten. En als cookies de prestaties van een pagina beïnvloeden, wordt de schade verdubbeld: Naast het betalen voor meer verkeer, zul je nog meer moeten betalen om hetzelfde rendement te krijgen door het verhoogde bouncepercentage – veroorzaakt door trage laadtijden.

Gelukkig kunnen managed hostingdiensten zoals Kinsta je helpen je paginabezoeken volledig te benutten. Kinsta biedt APM tools en andere features om je te helpen het maximale uit je WordPress website te halen.

Cookieloze toekomstbestendigheid

Tot slot, hoewel het nu misschien geen direct voordeel is, zal het leveren van cookieloze content je helpen je beter voor te bereiden op een cookieloze toekomst.

Nu de controverse over cookies toeneemt in het licht van privacy-eisen, zoals de GDPR, zoeken veel grote zoekmachines en technologiebedrijven naar manieren om cookies helemaal uit te bannen. Hoewel cookies waarschijnlijk een voorlopig nog niet zullen verdwijnen, zou dat uiteindelijk best kunnen – en hoe eerder je er klaar voor bent, hoe gemakkelijker de overgang zal zijn.

Methoden om cookieloze domeinen te gebruiken

Zoals we eerder hebben uitgelegd, is het algemene idee van een cookieloos domein het leveren van statische content zonder cookies. Hoewel het maken van een apart statisch domein of subdomein de meest directe manier is om dit te doen, is het ook mogelijk met CDN’s en een paar WordPress trucs.

Maak een apart, cookieloos domein

Met deze methode maak je een apart domein voor het hosten van de statische onderdelen van je website, zoals afbeeldingen en CSS.

Hoewel je een volledig aparte domeinnaam kunt registreren, is het meestal gemakkelijker en voordeliger om een subdomein van je bestaande domeinnaam te maken. De meeste cookieloze domeinen gebruiken gewoon een statisch voorvoegsel (bijvoorbeeld “static.jouwdomein.com“) als subdomein.

Let op dat dit alleen werkt als de “www” versie van je domein (bijv.”www.jouwdomein.com“) het hoofddomein is in het rootbestand van je website.

Om het subdomein cookieloos te maken, zou je normaal gesproken je .htaccess bestand direct moeten opzoeken en bewerken met custom code. Maar, zoals we later zullen zien, is het veel gemakkelijker om gewoon je WordPress site opnieuw te configureren of een plugin te gebruiken.

Hoe je je cookieloze subdomein ook configureert, je kunt statische componenten uploaden, zoals je CSS componenten, afbeeldingen, tekst en JavaScript.

Gebruik een Content Delivery Network (CDN)

Het gebruik van een content delivery network of CDN is een uiterst handige manier om cookieloze domeinen te gebruiken.

Hier kun je, in plaats van aparte subdomeinen aan te maken en configuratiebestanden te bewerken, je CDN gewoon vertellen om cookies te negeren en te strippen uit de responsheaders van je statische componenten. Dat klinkt misschien wat ingewikkeld, maar het is eigenlijk een eenvoudige feature in veel CDN’s.

Let op dat niet elke CDN deze functionaliteit biedt. Daarom is het over het algemeen beter om de configuratie van je website te veranderen, tenzij je al een CDN gebruikt waarmee je cookies kunt uitschakelen.

Herconfigureer je WordPress site

Als je WordPress gebruikt, heb je geluk: om een cookieloos domein aan te wijzen hoef je alleen maar een paar regels in je wp-config.php bestand aan te passen. Ga door naar de volgende paragraaf (WordPress configureren om cookieloze domeinen te gebruiken) voor de volledige instructies.

Gebruik een WordPress plugin

Een andere gemakkelijke WordPress optie is het gebruik van een plugin voor het maken van statische versies van WordPress websites.

Een populaire plugin om dit te doen is WP2Static (letterlijk “WordPress-to-Static”). Nadat je de plugin hebt geïnstalleerd, open je hem gewoon in je WordPress dashboard en configureer je de instellingen om je website te exporteren naar een statische versie:

Een statische versie van een WordPress site maken in WP2Static
WP2Static

WordPress configureren om cookieloze domeinen te gebruiken

Zoals gezegd biedt WordPress een eenvoudige manier om cookieloze domeinen te implementeren. Het proces komt neer op een paar eenvoudige stappen:

  1. Een alternatief subdomein en bijbehorende DNS toevoegen
  2. WordPress vertellen welk domein de statische assets zal weergeven
  3. Bestaande WordPress databaserecords bijwerken om dit nieuwe adres weer te geven

Kinsta klanten kunnen het MyKinsta dashboard gebruiken om enkele van deze taken uit te voeren. Veel andere WordPress gebruikers zullen hetzelfde kunnen doen in cPanel.

We zullen beide hieronder behandelen.

MyKinsta gebruiken om een cookieloos domein in te stellen

Kinsta klanten kunnen binnen het MyKinsta dashboard subdomeinen (of compleet andere domeinen) koppelen aan een WordPress instantie. Veel klanten zullen ook de tools van MyKinsta gebruiken om DNS voor die domeinen te configureren.

In dit voorbeeld maken we een cookieloos domein aan op static.example.com voor onze website die al draait op www.example.com.

Stap 1. Een subdomein aanmaken in MyKinsta

Als je je WordPress site aanvankelijk bij Kinsta hebt opgezet met de wildcard optie bij de domeinnaam (zoals: *.example.com), dan ben je al klaar om elke subdomeinnaam te ondersteunen. Zo niet, dan kun je het nieuwe domein toevoegen voor cookieloze content zoals dit:

  • Selecteer WordPress sites in het linkermenu.
  • Klik op de naam van je WordPress site.
  • Selecteer Domeinen in het linkermenu.
  • Klik op de knop Domein toevoegen.
Screenshot: Nog een domein toevoegen binnen MyKinsta.
Een subdomein toevoegen binnen MyKinsta.

In het volgende dialoogvenster:

  • Typ de naam van je cookieloze domein.
  • Klik op de knop Domein toevoegen.
Screenshot: Een nieuwe domeinnaam typen binnen MyKinsta.
Opgeven van het nieuwe subdomein binnen MyKinsta.

Vervolgens heeft je nieuwe statische domein een DNS record nodig dat naar je bestaande website wijst. Als je DNS voor je domeinen beheert via een externe provider, dan gebruik je daarvoor hun tools. Als je DNS door ons wordt geleverd, configureer je je nieuwe domein in MyKinsta als volgt:

  • Selecteer DNS in het linkermenu van de MyKinsta homepage.
  • Scroll op de DNS beheer pagina naar beneden naar het DNS records blok en klik op de Een DNS-record toevoegen knop.

We raden aan je nieuwe subdomein aan DNS toe te voegen als een CNAME record, zodat je alleen gebruik hoeft te maken van de second-level voor associaties met IP adressen. Hieronder voegen we een CNAME record toe voor static dat verwijst naar example.com:

Screenshot: Een DNS record aanmaken binnen MyKinsta.
Een CNAME record aanmaken in MyKinsta DNS beheer.

Stap 2. Cookies uitschakelen op je statische subdomein

Nu gaan we het wp-config.php bestand van je WordPress site bewerken, zodat assets in de wp-content map worden geleverd vanaf het “static” domein en cookies alleen worden geleverd via het “www” adres.

De meeste Kinsta klanten zullen een FTP/SFTP client gebruiken om in te loggen op hun WordPress site en wp-config.php te downloaden naar hun bureaublad om het te bewerken:

Screenshot: wp-config.php downloaden met een SFTP client.
Het downloaden van het wp-config.php bestand naar het bureaublad.

Gebruik een teksteditor om de volgende regels toe te voegen aan het wp-config.php bestand (waarbij je de voorbeelddomeinen vervangt door je eigen domeinen):

define("WP_CONTENT_URL", "https://static.example.com/wp-content");
define("COOKIE_DOMAIN", "www.example.com");

Nadat je het bestand hebt opgeslagen, upload je het naar je WordPress site en vervang je de vorige versie.

Stap 3. Bestaande onderdelen omleiden naar het subdomein

De bovenstaande stappen maken het mogelijk dat cookies worden uitgedeeld wanneer browsers content zoals pagina’s en blogberichten laden vanaf het “www” adres, maar zorgen ervoor dat content zoals media uploads en assets zoals JavaScript, CSS en fonts binnen thema’s worden geassocieerd met het “statische” domein.

Je website kan echter al content hebben met links naar die onderdelen op het “www” adres. Je kunt dat opruimen met zoek-en-vervang-opdrachten in de WordPress database zelf.

Maak altijd een backup van je WordPress site voordat je in de database gaat werken. Nadat dat gedaan is:

  • Selecteer WordPress Sites in het linkermenu van het MyKinsta dashboard.
  • Klik op de naam van je WordPress site.
  • Selecteer Domeinen in het linkermenu.
  • Scroll op de pagina Site informatie naar beneden naar het blok Toegang database. (Je kunt hier eventueel database gebruikersnaam en wachtwoord informatie kopiëren)
  • Klik op de link phpMyAdmin openen.
  • Log in op je WordPress database.
  • Klik op het tabblad SQL.
Screenshot: content in de WordPress database bijwerken met phpMyAdmin.
Een SQL query uitvoeren om asset links in WordPress content bij te werken.

Voer het volgende commando uit om er zeker van te zijn dat alle assetlinks in je bestaande berichten naar je cookieloze subdomein worden geleid (nogmaals, zorg ervoor dat je de domeinen vervangt door je eigen domeinen):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/')

Je hebt nu met succes een cookieloos domein in WordPress geconfigureerd met behulp van MyKinsta. Gebruik dit domein om alle statische content te hosten waarvoor je geen WordPress cookies wilt sturen en gebruik je gewone domein voor al het andere.

CPanel gebruiken om een cookieloos domein in te stellen

Hier zijn de stappen om te bereiken wat we hierboven deden in MyKinsta met behulp van cPanel of een van de populaire cPanel alternatieven.

Stap 1. Maak een subdomein aan in cPanel

Navigeer naar de Domains sectie van de cPanel hoofdpagina. Maak in de tool Subdomains eenvoudig een subdomein aan dat verbonden is met het topleveldomein van je huidige WordPress site.

Deze instellingen zie je hieronder om het subdomein static.example.com aan te maken.

Een subdomein aanmaken in cPanel
Een subdomein aanmaken in cPanel

Stap 2. Configureer het subdomein als statisch in cPanel

Nu je nieuwe statische subdomein klaar is, is het tijd om het zijn naam waar te maken door het statische content in WordPress te laten serveren.

Dit doen we door het wp-config.php bestand van je WordPress site te bewerken. De eenvoudigste manier om dit bestand te openen is in cPanel’s File Manager tool.

Navigeer in File Manager naar de map public_html van je website en selecteer wp-config.php (1). Selecteer dan de optie Edit (2) om het bestand te bewerken.

Het bestand wp-config.php zoeken in de cPanel File Manager tool
Zoek het bestand wp-config.php op

Voeg in het wp-config.php bestand de volgende regels toe (zorg ervoor dat je de domeinen vervangt door je eigen!):

define("WP_CONTENT_URL", "https://static.example.com/wp-content");
define("COOKIE_DOMAIN", "www.example.com");

Klik op “Save Changes.”

Stap 3. Leid bestaande berichten om naar het subdomein

Tot slot moet je je bestaande berichten omleiden naar het nieuwe statische subdomein. Maar maak eerst een backup van je WordPress site, voor het geval hij daarna niet meer goed werkt.

Open in de Database sectie van cPanel de PhpMySQL tool. Selecteer de database van je site en dan de _posts tabel.

Klik op het SQL tabblad van de _posts tabel. Voer het volgende commando uit om te controleren of de URL’s van je berichten naar je cookieloze subdomein worden geleid (zorg ervoor dat je de domeinen vervangt door je eigen domeinen):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/')
Bestaande berichten omleiden naar het nieuwe statische subdomein
Bestaande berichten omleiden naar het nieuwe statische subdomein

En dat is het! Je hebt nu een cookieloos domein in WordPress ingesteld met behulp van cPanel. Gebruik het cookieloze domein voor statische content zoals afbeeldingen, CSS, JavaScript en lettertypen, terwijl je cookies toestaat op het primaire domein van je site.

Samenvatting

Het gebruik van cookieloze domeinen is een zeer effectieve manier om de prestaties van je site te verbeteren, de hostingkosten te verlagen, en zelfs je klantervaring en SEO te verbeteren.

Zoals we hebben gezien is het instellen van cookieloze domeinen in WordPress niet moeilijk en heeft het veel voordelen. Maar alleen een managed WordPress host zoals Kinsta kan deze voordelen ten volle benutten.

Met handige tools voor het verwijderen van set-cookieheaders en directe databasetoegang om berichten om te leiden naar een statisch subdomein, is het nog nooit zo eenvoudig geweest om cookieloze domeinen te gebruiken. Kinsta’s APM tools en andere prestatiemonitoringsfeatures kunnen je bovendien helpen de resultaten te tracken.

Neem voor meer informatie en om Kinsta zelf te zien contact met ons op of plan vandaag nog een gratis demo.

Jeremy Holcombe Kinsta

Content & Marketing Editor bij Kinsta, WordPress Web Developer en Content Writer. Buiten alles wat met WordPress te maken heeft, geniet ik van het strand, golf en films. En verder heb ik last van alle problemen waar andere lange mensen ook tegenaan lopen ;).