static subdomein?
Ik las onlangs dat het slim is om al je content (afbeeldingen, css etc.) op een apart subdomein te hosten, bijvoorbeeld static.domein.nl. Dit subdomein kun je dat cookie-vrij houden, waardoor je site sneller laadt.
Nu vraag ik me af of iemand van jullie dat doet. Zet iemand hier z'n content op een apart subdomein?
Zelf lijkt het me best handig. Het enige nadeel wat ik zo snel zou kunnen bedenken is wanneer je je site via https wilt beveiligen. Dan moet je niet alleen een certificaat voor subdomein www aanschaffen, maar ook voor subdomein static.
Wat denken jullie ervan?
En om meldeingen van 'Mixed content' te voorkomen bij gebruik van SSL zul je een tweede certificaat moeten aanschaffen.
Als het even kan meerdere domeinen. In beginsel is de reden om aparte domeinen te gebruiken niet zozeer het meekomen van Cookie headers e.d, hier zit het verlies qua snelheid niet in: in beginsel heeft het te maken met aantal gelijktijdige verbindingen per domein die de meeste browsers opleggen. Meestal ligt dit rond een stuk of 10. Wanneer je dan meer dan 10 statische resources gebruikt worden deze per 10 gedownload, wat verlies oplevert. Een oplossing is dan dus om meerdere (sub)domeinen te gebruiken. Je kan uiteraard ook gewoon lazyloading toepassen, dat bespaart je ook wat bandbreedte.
>> Sterker zelfs, als je een eigen CDN (Content Delivery Network) gaat gebruiken, zal je ook via subdomeinen dataverkeer van Cookie-headers ontvangen.
Kun je uitleggen wat je hiermee bedoelt? Wat bedoel je met zo'n CDN en hoe krijg ik dan cookie-headers binnen?
Wat ik eigenlijk bedoel is, stel je hebt een klant pietjepuk.nl. Loont het zich dan om een subdomein static.pietjepuk.nl of content.pietjepuk.nl in te stellen voor de content??
Voordeel is dus het verhaal met de cookies, maar nadeel is dat als ik dit via https wil beveiligen, ik 2 certificaten nodig zou hebben (kassa). Wat is dan wijsheid?
Je kunt ook kiezen om twee manieren te gebruiken. Indien je op http zit gebruik je static.pietjepuk.nl, indien je op https zit gebruik je gewoon pietjepuk.nl. Https is sowieso een stuk trager dan http, waardoor je veel minder merkt van een eventueel performance verlies. Voor de cache is het niet heel prettig, maar https verkeer wordt standaard toch al niet gecached ivm de veiligheid, dus dat zie ik niet als een heel groot probleem.
Ikzelf gebruik geen CDN-host, maar op zich is het niet verkeerd voor mij om er eens naar te kijken.
Oké, maar houdt dat dan in dat je 2 mappen hebt met daarin dezelfde dubbele content? Ik neem aan dat het static subdomein in een andere map uitkomt dan het www subdomein. Dus de content in de static map is via het www subdomein dan niet bereikbaar lijkt me. Of zie ik dat verkeerd?
>> Als je een subdomein gebruikt, krijg je ook cookie-headers binnen, omdat je vast wel cookies hebt die voor alle subdomeinen geldig zullen zijn.
Waarom zou je cookies hebben die voor alle subdomeinen geldig zijn? De bedoeling is juist dat je alleen cookies gebruikt voor www.domein.nl en dat op die manier static.domein.nl cookie-vrij blijft.
Dat ligt aan je scripts die je gebruikt. Maar soms wil je dat graag, als je een inlogsysteem over meerdere subdomeinen gebruikt.
Ah oke ... in zo'n geval wordt het inderdaad een ander verhaal. Maar is zo'n static subdomein nu echt de moeite waard vraag ik me af. En dan heb ik het met name over het https-verhaal. Als je daardoor ineens 2 certificaten nodig hebt, lijkt het me niet echt zinvol. Maar wellicht is de oplossing van Ben (zie hierboven) een idee, maar ik weet niet precies wat hij bedoelt. Heb je dan 2 mappen met dezelfde content?
http://static.pietjepuk.nl en https://www.pietjepuk.nl/static. Afhankelijk van welk protocol gebruikt wordt kun je dan kiezen welke van de 2 plekken je gebruikt. Echter: 1x static hebben biedt niet veel meerwaarde. De gemiddelde cookie is zo klein dat het verschil niet meetbaar is. Dat is dan ook niet waar je het voor moet doen. Een betere oplossing zou iets zijn als static-1, static-2 etc, en afhankelijk van de resource die je wilt hebben (je kunt bijvoorbeeld een modulo over de crc van de gevraagde bestandsnaam doen om te bepalen welke host je wil hebben) de host bepalen. Dit biedt als voordeel dat je meer resources tegelijk binnen kunt halen. Dit hoeven ook geen aparte ip's te zijn, omdat browsers het aantal verbindingen bepalen op basis van de hostnaam en niet het ip.
Wat je ook nog kunt doen is gewoon een wildcard certificaat aanschaffen voor *.pietjepuk.nl, en het hele gezeur van wel of niet https overslaan en in je statische resources dan gewoon wijzen naar //static.pietjepuk.nl. Dit zorgt dan meteen dat je resources automatisch over het gevraagde protocol komen.
Correct, 2 mappen met statische content, bijvoorbeeld Wat je ook nog kunt doen is gewoon een wildcard certificaat aanschaffen voor *.pietjepuk.nl, en het hele gezeur van wel of niet https overslaan en in je statische resources dan gewoon wijzen naar //static.pietjepuk.nl. Dit zorgt dan meteen dat je resources automatisch over het gevraagde protocol komen.
http://static.pietjepuk.nl en https://www.pietjepuk.nl/static. Kan dat nooit met 1 map? Want als ik alle content dan dubbel moet opslaan, weegt het ongemak niet op tegen het gemak. En iets van een rewrite rule ... zou dat nog kunnen? Dus dat static.pietjepuk.nl/plaatje.jpg intern word doorgelinkt naar pad/naar/www/images/plaatje.jpg Of kan zoiets niet?
>> Wat je ook nog kunt doen is gewoon een wildcard certificaat aanschaffen voor *.pietjepuk.nl
Zou kunnen, maar dat is een stuk duurder dan een certificaat voor alleen www.
Thanks voor het meedenken. Als ik het al zou doen, dan zou ik voor 1 static map gaan, anders wordt het te omslachtig. Maar als ik jou goed begrijp ... ik heb dan dus inderdaad 2 mappen nodig: >> Wat je ook nog kunt doen is gewoon een wildcard certificaat aanschaffen voor *.pietjepuk.nl
Zou kunnen, maar dat is een stuk duurder dan een certificaat voor alleen www.