1

Onderwerp: Apart domein voor statische content

Als front-ender heb ik de schone taak gekregen om de performance van de websites te verbeteren door aanpassingen door te voeren in de front-end. Een onderdeel hiervan is het plaatsen van statische content (javascript, stylesheets, video's en afbeeldngen) op een afzonderlijk domein. Hierbij moet alle globale content op een plek beschikbaar worden. Ik moet de caching optimaliseren en een manier vinden om het versiebeheer van de resources te verbeteren. Ik vind het een lastige klus en vraag me af of een van jullie ervaring heeft met het inrichten van een webserver met statische content en nog tips voor mij heeft. Ook links naar bruikbare online artikelen over het onderwerp zijn welkom!

2

Re: Apart domein voor statische content

Hoi Lydie,

Dat zijn behoorlijk wat taken die je hebt! Performance; CDN; caching; versiebeheer...ik vraag me af of dit niet deels taken zijn voor een systeembeheerder of backend/architect?

Qua frontend performance is er genoeg geschreven en is er genoeg te doen qua frontend, maar de overige zaken zijn heel erg afhankelijk van de architectuur van de omgeving waarin je werkt. Mocht er geen architectuur zijn (versiebeheer/caching/CDN), dan lijkt me dit niet echt een taak voor een frontend engineer. Je kan kijken naar Amazon S3 maar dan zal je toch bepaalde backend skills moeten bezitten. Caching en versiebeheer zijn best wel pittige onderwerpen!

Ikzelf gebruik sinds een tijdje PHPfog (AppFog), zij maken gebruik van Amazon en raden aan om static content via S3 te regelen, dit moet je dan zelf doen. Maar redelijk eenvoudig te regelen via de API's (libs) die Amazon (of PHP frameworks) biedt. Maar nogmaals, dit zie ik niet als frontend werkzaamheden.

groet,
Adriaan

3

Re: Apart domein voor statische content

Een apart domein gebruiken voor assets heeft een paar voordelen: ten eerste bypass je de limiet van het aantal concurrent connecties die een browser naar een domein maakt. Als je assets op assets1.example.com, assets2.example.com en assets3.example.com beschikbaar zijn (en je gebruikt deze goed verdeeld in je app; een goed framework doet dat dynamisch) dan geeft dat een snelheidsvoordeel. Daarnaast kun je, als je app cookies gebruikt, deze enkel op www.example.com zetten, zodat assets.example.com geen cookies heeft (en de client daar dus ook niks mee hoeft te doen).

Ik ben het met Adriaan eens overigens dat vrijwel alles wat je schrijft weinig met front-end development te maken heeft. Een deel is systeembeheer en een deel is architectuur.