Alhoewel Code Garden altijd een evenement vol verrassingen is zal deze editie nog lang in het geheugen blijven hangen. Wat werd aangekondigd als "The Year of v5" bleek de begrafenis van v5 te zijn. Op woensdag 13 juni 2012 kondigde de stichter van het open source CMS, Niels Hartvig, de stopzetting aan van de ontwikkeling aan Umbraco 5. Bekijk de keynote van Niels Hartvig op Code Garden 2012

De vorige editie van Code Garden, 2011, stond volledig in het teken van de splinternieuwe opvolger van Umbraco 4, wat is er gebeurd sinds de lancering van Umbraco 5 in januari 2012? Om Niels te citeren, "We hebben een monster gecreëerd, het was nooit onze bedoeling, maar dit is wat we gedaan hebben. Umbraco 5 was niet representatief voor de waarden waar Umbraco voor staat: eenvoud, transparantie en gebruiksvriendelijkheid.

De problemen met Umbraco v5

De voornaamst problemen zijn de performantie en de complexiteit van v5.

Perfomantie: Het was gedurende de periode April 2012 dat het Umbraco hoofdkwartier (HQ) begon te realiseren dat er fundamentele performantie problemen waren met v5. De forum discussie van de Umbraco community rond de performantie gebreken van v5 staat nog steeds online. Op het Dutch Umbraco Festival 2012 kondigde Niels Hartvig deze problemen publiek aan. De Business Logic Layer (BLL) van Umbraco 5 zou moeten herschreven worden.

Complexiteit: De architectuur van v5 werd gebouwd met het oog op flexibiliteit en schaalbaarheid, maar bleek te complex voor de community die er websites mee moeten bouwen en het uitbreiden met packages.

Deze complexiteit kan misschien wel als de voornaamste reden beschouwd worden waarom de ontwikkeling van v5 werd stopgezet. Participatie is immers de essentie van een open source community en Umbraco 5 bleek net deze participatie te verhinderen.

Doorontwikkeling van Umbraco v4

Het Umbraco Hoofdkwartier besefte dat ze deze situatie niet kon laten aanslepen. De beslissing om de ontwikkeling van het v5 project te stoppen werd een paar dagen voor hun jaarlijkse conferentie genomen op wat omschreven wordt als de Code Garden Retreat. Dit is een soort van bezinning van leden van het Hoofdkwartier met de meest actieve en participatieve leden uit de Umbraco community.

Het was op deze Code Garden Retreat dat men moest kiezen uit een aantal opties. Eén van die opties was om de Business Logic Layer van Umbraco v5 volledig te herschrijven, maar dit zou 6 tot 9 maanden in beslag nemen. Een lange periode waarbij het Hoofdkwartier weer zou afgezonderd zijn van de rest van de community en waarbij ontwikkelaars die reeds begonnen waren met het bouwen van websites in v5 geen oplossing zouden krijgen voor hun problemen met v5.

Daarom besliste men op de bezinning om de oplossing om te draaien en te beginnen met het doorontwikkelen van Umbraco 4, dat sowieso toe was aan een oppoetsbeurt. Men zal de kern van Umbraco v4 verbeteren via korte releases, op een manier die compatibel is met voorgaande releases van Umbraco. Eens dit is afgerond zal men beginnen met het overzetten van de beste stukken van v5 naar v4.

Op het einde van juni 2012 komt Umbraco 5.2 nog uit om de ergste problemen op te lossen voor degenen die reeds websites in Umbraco 5 ontwikkeld hebben. Maar Niels Hartvig liet er geen misverstand over bestaan: "We zullen de ontwikkeling van Umbraco 5 stoppen en we kunnen niet aanbevelen om nieuwe projecten in v5 te starten".

Umbraco's voornaamste troef: de Umbraco Community

Nadat Niels deze bom had gedropt tijdens zijn keynote op Code Garden 2012 werd een paneldiscussie georganiseerd waarbij de Umbraco Community vragen kon stellen of hun bezorgdheden uiten. Een Zweeds ontwikkelaar die reeds dertig jaar actief is in de software business prees Niels voor zijn moed om toe te geven dat het Umbraco 5 project gefaald heeft. Hij verwees naar het second system syndrome, een fenomeen waarbij veel software bedrijven over de kop gingen nadat ze hun software systeem volledig herschreven hadden.

Alhoewel dit slecht nieuws was voor de webontwikkelaars die reeds begonnen zijn met het ontwikkelen van projecten in Umbraco 5, of met het volgen van een certificeringsprogramma voor v5, reageerden de meeste aanwezigen opgelucht. Zij zien de focus terug verschuiven naar het CMS waar ze het meeste van houden en het best kennen. In zekere zin ging deze editie van Code Garden terug naar zijn roots, zijnde de Community, waar het Umbraco Hoofdkwartier de voeling mee verloren had door de vele beslommeringen met het Umbraco 5 project.

Dit werd het meest duidelijk door het herinvoeren van een oude traditie op Code Garden, de "open circle" discussies. Hierbij kunnen de community leden zelf de onderwerpen bepalen die zij belangrijk vinden voor de toekomst van Umbraco. Nadat de onderwerpen aangebracht waren werden deze in verschillende groepen besproken. Iedereen kon hierbij zijn stem laten horen, en de resultaten van de discussies zullen online gezet worden.

En wat gebeurd er met MVC?

Hoe moet het nu verder met de integratie van ASP.NET MVC in Umbraco, want hier was het met Umbraco 5 uiteindelijk om te doen? Volgens Shannon Deminick, één van de ontwikkelaars van het Umbraco 5 project is het integreren van de ASP.NET MVC technologie in Umbraco v4 niet zo ingewikkeld. Hij is alvast gestart met een "proof of concept" project. Aanvankelijk zal gekeken worden om MVC voor de rendering van pagina's in te zetten. Als dit verwezenlijkt is zal begonnen worden met het implementeren van MVC voor de backoffice van Umbraco v4

foto: Douglas Robar

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.