Het Dutch Umbraco User Festival (DUUG) 2012 werd gehouden in Leiden en is georganiseerd door Mindbus, de eerste Umbraco Certified Gold Partner in Nederland. Zo'n 100 Umbraco ontwikkelaars hoorden Niels Hartvig, de oprichter van Umbraco, enkele belangrijke aankondigingen maken met betrekking tot de toekomst van Umbraco.

Hartvig begon echter met een kritische noot met betrekking tot Umbraco versie V5. Dit is, zoals je misschien al hebt gehoord, een volledig opnieuw opgebouwde versie die gebouwd is op Microsoft's ASP.NET MVC. Deze versie belooft nog meer uitbreidbaar te zijn door data te integreren die van verschillende bronnen afkomstig kan zijn. Dit wordt mogelijk gemaakt door wat men 'the Hive' noemt.

Het blijkt nu dat het Umbraco core team iets te veel vertrouwen had in de eerste Umbraco V5 versie, en deze te weinig getest had in concrete websites. Deze versie is te traag en heeft usability gebreken. Hartvig slaat nu Mea Culpa en sprak over de verbeteringen die in de steigers staan voor Umbraco V5.

Umbraco 5.1

Zo wordt volgende week Umbraco 5.1 uitgebracht. Deze versie heeft heel wat performantie verbeteringen. Ook de langverwachte Membership functionaliteit is geïntegreerd en er zitten 20 Razor snippets voor bijvoorbeeld navigatie en breadcrumbs in deze versie. Daarnaast werd er ook aandacht besteed aan het gebruik van ontwikkeltools zoals Visual Studio en Webmatrix. Een online enqûete wees uit dat 75 % van de Umbraco ontwikkeling met behulp van deze tools gebeurd. Met Umbraco 5.1 is het daarom mogelijk om via Scaffolding controllers en views aan te maken, wat Umbraco 5 ontwikkeling een stuk gemakkelijker maakt. Ook een Visual Studio Template voor een Umbraco 5 project is in de maak.

Een andere verbetering in Umbraco 5.1 is de beschikbaarheid van Fluent API's. Deze API's werden sterk geïnspireerd door jQuery waar het mogelijk is om verschillende methods aaneen te reigen. Via deze Fluent API's wordt het een stuk gemakkelijker om nieuwe content programmatorisch aan te maken.

Umbraco 5.2

Hartvig lichtte ook al een tipje van de sluier voor de Umbraco versie die na versie 5.1 komt.In deze versie, die verwacht wordt rond de periode dat Umbraco's jaarlijkse community event Code Garden 2012 plaats vindt, zal er een Node Selector beschikbaar zijn. Deze Node Selector is de opvolger van de populaire Multinode Tree Picker in Umbraco 4. Aangekondigd voor Umbraco 5.2 is ook betere functionaliteit voor het creëren en distribueren van packages via een Package Creator.

Umbraco 4.8, the 'Ultimate V4 version'

Umbraco 4.8 wordt verwacht in mei 2012. Niels omschreef deze versie als 'de ultieme versie voor Umbraco 4'. Het zal tevens ook de laatste upgrade voor Umbraco 4 zijn. Alle externe class libraries worden geüpgraded naar hun laatste versie en alle pull requests zullen ingevoegd worden. Het grote nieuws met deze versie is echter dat de beste componenten van uComponents geïntegreerd worden in de Umbraco core.

Umbraco Concorde

Zoals wijlen Steve Jobs de gewoonte had, werd het belangrijste nieuws echter voor het laatst bewaard. Niels Hartvig lichtte een tipje van de sluier met betrekking tot een Umbraco versie voor de Cloud. Deze versie, het 'Concorde' project gedoopt zal 'Umbraco as a Service' aanbieden. Umbraco wil zich hiermee diversifiëren van andere CMS cloud oplossingen die volgens Hartvig teveel oude wijn in nieuwe zakken is en de traditionele hosting problemen niet oplossen.

Umbraco Concorde zal daarom geöptimaliseerd zijn voor team development door het gebruik van Git voor versie management beheer. Hierdoor zal het mogelijk zijn om volledige Umbraco oplossingen te 'branchen' en te 'mergen'. Ook worden automatisch upgrades voorzien met Umbraco Concorde en zal de prijs goedkoper uitvallen dan voor een VPS oplossing. Gevraagd naar de prijs liet hij ontvallen dat die zal schommelen rond de 19 Euro per maand voor een Umbraco Concorde project. Deze nieuwe bron van inkomsten moet het voor het Umbraco Core Team mogelijk maken zich meer toe te leggen op het doorontwikkelen van de Umbraco Core.

Samenvatting

De toekomst van Umbraco ziet er zeer rooskleurig uit. Ontwikkelen voor Umbraco 5 wordt een stuk gemakkelijker met behulp van de Fluent API's en Scaffolding. Terwijl je dit leest werkt het Umbraco Core Team hard aan de ontwikkeling van documentatie voor Umbraco V5 en is een volledige makeover van hun video bibliotheek, Umbraco.tv, voorzien. Het Umbraco Concorde project zal het mogelijk maken om met het gemak van een vingerknip Umbraco websites aan te bieden via de Cloud. De inkomsten die Umbraco Concorde zal genereren zullen door het Umbraco Core Team aangewend worden om zich meer toe te leggen op de ontwikkeling aan de Umbraco Core.

Als je nog het eerste deel van deze reeks herinnert, daarin had ik het over de 'vuistregels voor de performantie van je website'. Eén van die vuistregels luidt als volgt: 

"Verstuur het zo infrequent mogelijk"

Een techniek hiervoor zagen we in deel 3, namelijk het instellen van Content Expiration Headers

In het vierde deel van deze reeks over de optimalisatie van de performantie van je website bekijken we een andere techniek om data infrequent te versturen, namelijk het inschakelen van Content Distribution Networks

Content Distribution Networks (CDN)

Het idee achter een CDN, is dat de webserver wordt ontlast doordat statische bestanden (CSS, afbeeldingen, Javascript) niet op de eigen server worden opgeslagen, maar op een netwerk van geografisch verspreide servers. Deze servers slaan de bestanden van je website op in hun cache. Wanneer een bezoeker op je website komt en een bestand opvraagt die nog niet in de cache van het CDN zit, zal dese server het bestand ophalen van jou server en in zijn cache opslaan. De volgende bezoeker die dit bestand opvraagt krijgt het bestand rechtstreeks vanuit de cache van het CDN opgediend.

Omdat de servers van het CDN geografisch verspreid zijn over de wereld, krijgt een bezoeker die een bestand op je website opvraagt, dit heel snel via de dichtsbijgelegen CDN server in zijn regio. Dit verloopt een stuk sneller dan wanneer de bezoeker het bestand via jou server zou moeten ophalen.

Grote spelers op de CDN markt zijn Akamai, Limelight, Internap en Amazon. CDN's worden voornamelijk gebruikt voor statische bestanden zoals afbeeldingen, CSS en Javascript maar er zijn manieren om het ook te gebruiken voor dynamisch gegenereerde bestanden.

CDN's worden tegenwoordig ook vaak gebruikt voor het hosten van jQuery libraries. Zowel Microsoft ,Google als jQuery.com voorzien gratis diensten om jQuerie libraries te downloaden van hun CDN-netwerk:

• Microsoft: http://www.asp.net/ajaxlibrary/CDN.ashx
• Google https://developers.google.com/speed/libraries/devguide
• Jquery.com: http://docs.jquery.com/Downloading_jQuery

In het volgende demonstreer ik hoe je een link naar een bestand in een lokale folder (/scripts) op de server kunt vervangen door een link naar hetzelfde jQuery library bestand op het CDN van Microsoft.

Verwijzing naar een lokaal bestand op de webserver:

<script type="text/javascript" src="scripts/jquery-1.7.2.min.js">

Verwijzen naar het jQuery library bestand op het CDN van Microsoft

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js">

Een kritische lezer zal opmerken dat je op deze manier afhankelijk bent van de uptime van het CDN. Alhoewel de kans dat een CDN van Google of Microsoft uitvalt gering is, kan een uptime van 100% inderdaad niet gegarandeerd worden. Dit kan echter opgelost worden met een fallback naar een lokaal bestand indien het CDN down is:

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js">

<script>window.jQuery || document.write('<script src="/scripts/jquery-1.7.2.min.js">\x3C/script>')</script>

In de eerste script-tag staat de verwijzing naar de jQuery library op het CDN. Indien dit bestand niet kan opgehaald worden, bijvoorbeeld omdat het CDN down is, dan wordt dynamisch een verwijzing naar het bestand op de lokale server gegenereerd, waardoor de jQuery library ten allen tijde beschikbaar is.

Samenvatting

Er is eigenlijk geen reden om geen CDN te gebruiken: je statische bestanden zoals afbeeldingen, css en Javascript worden sneller gedownload door je bezoekers omdat de servers waarop deze bestanden zich bevinden, geografisch dichter gelokaliseerd zijn dan je eigen webserver. Dit is zeker het geval bij websites die veel internationale bezoekers hebben. Daarnaast wordt je eigen webserver ook voor een stuk ontlast omdat deze minder requests te verwerken krijgt.

Content Expiration

In deel 1 van deze reeks over het verbeteren van de performantie van je website, zagen we drie vuistregels van web performantie:

• Reduceer het aantal http requests
• Verstuur zo weinig mogelijk
• Verstuur het zo infrequent als mogelijk

In deze blogpost gaan we dieper in op een techniek om data van de server naar de browser zo infrequent als mogelijk te versturen. Zoals bij http compressie is dit ook een maatregel op het niveau van de infrastructuur, meer bepaald de webserver.

Waarom Content Expiration?

Wanneer een bezoeker een webpagina op je website consulteert, slaat de browser bestanden zoals afbeeldingen, css en Javascript bestanden op de browser cache. Men zou verwachten wanneer de webpagina opnieuw wordt opgevraagd, de browser deze bestanden onmiddellijk laadt vanuit de cach, maar dit is helaas niet het geval.

De browser stuurt eerst een request naar de server om te controleren of de desbetreffende files in zijn cache niet gewijzigd zijn op de server. Indien dit het geval is stuurt de server de file opnieuw naar de browser, indien de file niet gewijzigd is antwoord de server met een 304 status code. Dit is hoe een server de browser te kennen heeft dat de inhoud van een file niet gewijzigd is.

Als de file niet gewijzigd is worden dus heel wat onnodige requests en responses verstuurt voor bestanden die onmiddellijk vanuit de browsercache geladen zouden kunnen worden.

Wat we in het nu volgende zullen doen is de browsercache beter benutten met behulp van content expiration.

Een voorafgaande test

Om het effect van het instellen van content expiration aan te tonen voer ik een Page Speed test uit op mijn website:

Afbeelding 1 Page Speed test voorafgaand aan het instellen van content expiration

De Page Speed Score is 91/100. Dit is hetzelfde als mijn vorige test toen ik http compressie had ingesteld (lees mijn blogpost over http compressie).

Content expiration instellen op een webfolder

Zoals je in afbeelding 1 kunt zien, geeft de Page Speed tool aan om browser caching in te stellen voor de webfolders 'css' en 'scripts'. Ik zal voor deze demo content expiration instellen op de 'css' folder:

1. Ik open IIS 7.5 en browse naar de css folder van mijn website
2. In het Functie Paneel dubbelklik ik op 'HTTP Response Headers'
3. In het Actie Paneel klik ik op de link 'Set Common Headers'
4. Het dialoogvenster 'Set Common HTTP Response Headers' verschijnt en ik vink 'expire web content' aan
5. In hetzelfde dialoogvenster kies ik het 'After' keuzerondje en vul 365 (dagen) in bij 'expiration period' (zie afbeelding 2)

Afbeelding 2 de content expiration headers voor de css folder worden ingesteld op 365 dagen

Test na het instellen van de content expiration headers

Als ik een nieuwe Page Speed test uitvoer op de homepage van mijn test site, stel ik vast dat de Page Speed Score gestegen is van 91/100 naar 96/100. Het indicator licht voor browser caching staat nu op groen en de suggestie om de css folder te cachen is verdwenen (zie afbeelding 3).

Afbeeling 3 Na het instellen van content expiration op de css folder is de Page Speed Score gestegen naar 96/100

Een nader onderzoek met Fiddler

Om een meer gedetailleerd overzicht te krijgen van het dataverkeer tussen mijn browser en de server gebruik ik Fiddler.

Vooraleer ik de content expiration header instelde op de css folder, kon ik in Fiddler verschillende 304 status codes zien voor de files in de css en scripts folder (zie afbeelding 4).

Afbeelding 4 Fiddler toon de 304 status responses van de server aan de browser

Zoals ik voorheen betekent een 304 status code dat de inhoud van het bestand op de server niet gewijzigd is.

Nadat ik de content expiration op de css folder heb ingesteld kan ik in Fiddler zien dat al de bestanden in deze folder een max-age header hebben van 31536000 seconden (zie afbeelding 5). Dit is uitgerekend, 365 dagen. De browser laadt deze bestanden nu direct vanuit de browsercache zonder eerst een request naar de server de sturen om te weten of dit bestand gewijzigd is op de server. Dit is de reden waarom de Page Speed Score gestegen is van 91/100 naar 96/100

Afbeeling 5 de bestanden van de css folder worden voor 365 dagen gecached (max-age=31536000)

Wat als mijn bestand op de server gewijzigd is?

De lezer kan zich afvragen wat er gebeurd als een gecached bestand gewijzigd is op de server. De browser zal in dit geval nog steeds het oude bestand vanuit de cache laden.

Een manier om de browser duidelijk te maken dat het bestand gewijgid is en dat hij een nieuw bestand moet cachen, kunnen we onze bestanden voorzien van volgnummers. De browser zal dan zien dat er nieuwe bestanden zijn, deze downloaden en ze opslaan in de browsercache.

Het is natuurlijk omslachtig om elk bestand een volgnummer te geven. Daarom worden verschillende bestanden meestal gebundeld in één bestand, dit gebundelde bestand krijgt dan een volgnummer. Het bundelen van bestanden is echter een onderwerp van een volgende blogpost.

Besluit

Door het verstandig aanwenden van content expiration headers op onze webfolders kunnen we ervoor zorgen dat de browser gecachete bestanden onmiddellijk laadt zonder voorafgaande request naar de server. Dit is niet alleen een grote verbetering voor de performantie van onze website, maar ontlast ook de server van onnodige werk en zorgt voor minder dataverkeer.

In de volgende blogpost bekijken we een andere techniek om de server minder te belasten, namelijk het gebruik van Content Delivery Networks.

Http Compression

In deel 1 van de blogpost reeks over het verbeteren van de performantie van je website heb ik gesteld dat één van de vuistregels van web performantie is om 'zo weinig mogelijk te versturen' van de server naar de browser. Een manier om dit te bewerkstelligen is het gebruiken van http compression op je webserver. Zoals we later zullen zien is dit heel gemakkelijk in te stellen op IIS 7

Wat is http compression?

Http compressie reduceert de omvang van de bestanden die verstuurd worden van de server naar de browser door deze bestanden in een compressie formaat te versturen.

De server analyseert de "Accept Encoding" header in de request van de browser, dit is de manier waarop de browser aan de server te kennen heeft dat het gecompresseerde content kan verwerken. Als de server deze header aantreft zal het in zijn response de content in gecompresseerd formaat versturen. Als de server een request ontvangt waarbij de browser geen gecompresseerd formaat ondersteunt zal het zijn response in een normaal formaat versturen.

Http compression in IIS 7

Http compression is ingebouwd vanaf IIS 7. Als je nog steeds IIS 6 gebruikt kun je deze blogpost raadplegen om http compressie in te schakelen met IIS 6 (http://weblogs.asp.net/owscott/archive/2004/01/12/57916.aspx)

Op IIS 7 is standaard enkel static compression ingeschakeld. Static compression betekent dat IIS bij de eerste request de statische bestanden zoals Javascript en CSS bestanden zal compresseren, en die vervolgens gecached zal bewaren zodat het bij een volgende request deze gecachete en gecompresseerde bestanden kan aanbieden.

Bij Dynamic compression wordt ook dynamische content gecompresseerd. Dat is ten koste van een kleine belasting, ongeveer 1%, op de processor, maar als je zo krap zit aan rekenkracht heb je een groter probleem dan dynamische compressie. Bovendien kun je IIS 7 opdragen om dynamische compressie uit te schakelen van zodra de processor belasting een bepaalde grens overschrijdt.

Http compression demo met IIS 7.5

Om de voordelen van IIS compressie te demonstreren gaan we een kleine test doen. Ik heb een testsite geïnstalleerd en static en dynamic compression op de webserver uitgeschakeld.

Als ik deGoogle Page Speed test uitvoer op de homepage, krijg ik een Page Speed score van 76/100 (zie afbeelding 1). De rode indicator geeft aan compressie een kritische factor voor de performantie is:

"If you compress your files with gzip, their filesize will be decreased with 104.4 KiB (a gain of 71%)"

Afbeelding 1 Met http compression uitgeschakeld, bedraagt de  Page Speed score 76/100

Voer de volgende stappen uit om compression in te schakelen in IIS:

1. Open IIS 7.5
2. Kies je website in de boomstructuur
3. Dubbelklik op 'Compression' in het Features pane
4. Vink zowel 'enable static content compression' als 'enable dynamic content compression'  aan (zie afbeelding 2)
5. Klik  'apply' in het Actions Pane om de aanpassingen op te slaan

Afbeeling 2 Static en dynamic content compression inschakelen in IIS 7.5

Wanneer ik nogmaal de Page Speed test laat uitvoeren levert dit een enorme snelheidswinst op. In plaats van 76/100 krijgt mijn homepage nu een Page Speed score van 91/100  (zie afbeelding 3)

Afbeelding 3 Na het inschakelen van http compression op IIS, krijgt de homepage een Page Speed score van 91/100

Conclusie

Het inschakelen van static en dynamic compression in IIS levert een enorme reductie op van de grootte van de bestanden die de server naar de browser stuurt.

Dit resulteert niet enkele in een aanzienlijke performantiewinst, maar ook in een beperkter verbruik van de bandbreedte.

Nu dat alle grote browsers http compressie ondersteunen is er eigelnlijk geen goede reden meer om http compressie niet in te schakelen.

In deze blogpost reeks bespreken we hoe je de performantie van je website kunt verbeteren

In de eerste blogpost in deze reeks krijg je een overzicht van het belang van snelle download tijden van je webpagina's, de vuistregels van performantie optimalisatie en bespreken we ook enkele tools en services voor het meten van de performantie van je website.

Waarom de performantie van je website optimaliseren?

Het optimaliseren van de performantie van je website is hoofdzakelijk voor twee redenene van belang:

• Snellere pagina download tijden
• Beperking bandbreedte verbruik

Snellere pagina download tijden

Snellere download tijden van je webpagina's is niet enkel van belang voor je bezoekers - waarvan we weten dat ze je website zullen verlaten als ze te lang moeten wachten vooraleer een webpagina gedownload is. Snelle download tijden van je webpagina's is ook van belang voor de indexering van je webpagina's door Google. Google maakte in 2008 officieel bekend dat het voortaan ook de download tijden van de pagina's mee in rekening zou brengen bij het berekenen van de kwaliteitsscore van de webpagina's die het indexeert (lees het officiële bericht van Google).

Beperking bandbreedte verbruik

Het beperken van het dataverkeer tussen de clients (browsers) en je server kan de belasting op je server reduceren en je aldus geld besparen. In volgende blogposts zullen we bijvoorbeeld zien hoe je het aantal requests van de clients naar je server kunt verminderen.

Vuistregels voor de performantie van je website

Er zijn drie vuistregels:

• Reduceer het aantal http requests
• Verstuur zo weinig mogelijk
• Verstuur het zo infrequent als mogelijk

Reduceer het aantal http requests

Om de performantie van je website te verbeteren moet je proberen het aantal requests van de browser naar de server te beperken. Technieken hiervoor is het bundelen van verschillende bestanden in één bestand en het gebruik van sprites voor je afbeeldingen. In een volgende blogpost in deze reeks over web performantie zullen we dieper op deze technieken ingaan.

Verstuur zo weinig mogelijk

Technieken hiervoor zijn:

• Minificatie van je CSS Stylesheet bestanden en je Javascript bestanden
• Configureren van http compressie op je webserver
• Optimaliseren van je afbeeldingen

In een volgende blogpost gaan we dieper in op deze technieken.

Verstuur het zo infrequent als mogelijk

Hiervoor bestaan er hoofdzakelijk twee technieken:

• Instellen van Content Expiration headers
• Gebruik van een Content Delivery Network (CDN)

In een volgende blogpost behandelen we hoe je content expiration headers in IIS kunt instellen om het aantal requests van browsers naar je webserver te beperken.

We bekijken ook enkele CDN's. Dit zijn globale netwerken van webservers die je eigen webserver ontlasten. Een ander voordeel is dat deze servers zich geografisch gezien dichter bij je bezoekers bevinden waardoor deze de content van je website sneller kunnen downloaden.

Meten, meten en meten

Vooraleer je van start gaat met het optimaliseren van de performantie van je website moet je eerste de performantie meten voor de verbeteringen en de problemen localiseren die zorgen voor tragere download tijden van je webpagina's.

Nadat je de problemen gelocaliseerd hebt en hiervoor de nodige aanpassingen hebt aangebracht dien je terug de performantie te meten en te onderzoeken of je remedies werkelijk een oplossing zijn voor deze performantie problemen.

In het nu volgende bekijken we enkele tools waarmee je de performantie van je website kunt meten.

Fiddler

Een van de meest gebruikte tools voor het analyseren van de performantie van je website is Fiddler. Fiddler werd ontwikkeld door Microsoft ingenieur Erik Lawrence en maakt het mogelijk om alle trafiek tussen de browser en de webserver te analyseren. Fiddler beschikt over enkele aardige features zoals de Transfer Timeline die een visuele weergave geeft van alle requests naar de server en de tijd nodig om deze bestanden te downloaden.

Afbeelding 1: de Transfer Timeline in Fiddler

meer informatie: www.fiddlertool.com

Network Monitor (Microsoft)

Network Monitor is een gratis tool van Microsoft. Het verschil met Fiddler is dat Fiddler enkel de http trafiek analyseert terwijl Network Monitor alle netwerk protocols analyseert.

Meer informatie: http://www.microsoft.com/download/en/details.aspx?id=4865#overview

Page Speed (Google)

Page Speed is een open source project voor het meten van de performantie van je website. Het leuke aan Page Speed is dat het aanbevelingen geeft voor het verbeteren van de performantie van je website.

Afbeelding 2: Google Page Speed als uitbreiding voor de Chrome browser

Page Speed is beschikbaar als een uitbreiding voor de Chrome browser en als een online service.

Meer informatie: http://code.google.com/speed/page-speed/

LogParser (Microsoft)

LogParser is een andere Microsoft tool voor het analyseren van je IIS log files. Je kunt hiervoor SQL query achtige instructies invoeren en het resultaat exporteren naar .CSV, XML en vele andere formaten.

Meer informatie: http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1976

LogParser is een tool die gebruikt wordt via de Command line. Er bestaan ook tools met een grafische interface bovenop LogParser zoals LogParser Lizard van Lizard Labs  (http://www.lizard-labs.net/log_parser_lizard.aspx)

Third party services

Keynote and Gomez zijn commerciële diensten voor lange termijn performantie trends die ook benchmarks ten opzichte van andere grote websites uitvoeren.

Keynote: http://www.keynote.com/products/web_performance/web-performance-testing.html

Gomez: http://www.gomez.com/instant-test-pro/

Samenvatting

In deze eerste blogpost in de reeks over de optimalisatie van de performantie van je website werd een overzicht gegeven van de vuistregels en de technieken voor het verbeteren van de performantie.

Hierbij werd het belang van het meten benadrukt, meten zowel voor als na het optimaliseren van de performantie.

Ten slotte werden enkele tools voor het meten van de performantie besproken.

In de volgende blogpost in deze reeks zullen we dieper ingaan op de performantie maatregelen die je kunt nemen op het niveau van de webserver. Hierbij zullen we technieken behandelen zoals http compressie, het instellen van Content Expiration headers en het gebruik van een Content Delivery Network (CDN).