Webmove Blog

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).

Deze blogpost is het vierde deel in een blogpost reeks over de ontwikkeling van meertalige websites in Umbraco. In deel 1 en deel 2 bespraken we de structurele opties voor een meertalige website en gingen we stap voor stap aan de slag met de ontwikkeling van een meertalige website. In deel drie bespraken we hoe je via de Relations API meertalige pagina's aan elkaar kunt linken zodat de bezoeker bij selectie van een taalkeuze op dezelfde pagina blijft maar de content in de geselecteerde taal krijgt.

We sluiten deze reeks rond de ontwikkeling van meertalige websites af met een toelichting van de Translation Workflow in Umbraco.

De Translator Account

Umbraco maakt het mogelijk via de Umbraco Backoffice op een geïntegreerde manier samen te werken met professionele vertaalbureaus. Hiervoor werd een speciale account, de Translator Account (zie fig.1), in het leven geroepen. Deze geeft de vertaler toegang tot een beperkt gedeelte van het systeem, nl. enkel de hem toegewezen vertaalopdrachten, en de account heeft ook geen publiceerrechten, deze blijven voorbehouden aan de content administrators.

Fig. 1 de translator account met beperkte toegangsrechten

Een vertaalopdracht toekennen aan een vertaler.

Eens een translator account is aangemaakt is het toekennen van een vertaalopdracht heel eenvoudig:

1. Log in als administrator en ga naar de te vertalen content in de Content Sectie.
2. Klik rechts op de node die vertaalt moet worden
3. Klik op het 'Send To Translation' menu item (zie fig.2)
4. Selecteer in het dialoogvenster de vertaler aan wie je de vertaalopdracht wil toekennen.
5. Selecteer de taal waarnaar de content moet vertaald worden.
6. Optioneel kun je ook de subpagina's selecteren en commentaar aan de vertaalopdracht toevoegen.

Fig. 2 Send To Translation

Fig. 3 Een vertaalopdracht toekennen aan een vertaler

Indien je dit wenst kun je ook de volledige website toekennen in een vertaalopdracht. Je hoeft dan enkel de rootnode van de website te selecteren voor je vertaalopdracht.

Het taakvenster van de vertaler

Wanneer de vertaler, aan wie de vertaalopdracht werd toegekend, inlogt met zijn Translator account, dan ziet hij in de Vertaal Sectie de aan hem toegekende vertaalopdrachten (fig.3):

Fig. 4 Details van een vertaalopdracht

De vertaler ziet in dit venster de content die moet vertaalt worden, alsook de commentaar die de content administrator hierbij gevoegd heeft.

De vertaler kan nu het Xml bestand downloaden naar zijn lokale schijf door te klikken op de 'Download' link. Deze Xml is volgens industriële standaarden opgesteld en kan in alle courante vertaalsoftware programma's geopend worden.

Umbraco verwerkt de vertaling en toont de vertaler dat de pagina werd geüpdated en bewaard. De vertaler heeft ook de mogelijkheid om een preview van de vertaalde pagina te zien (fig.5):

Fig. 5 Bevestiging van geüploade vertaling

Een vertaling nakijken en publiceren

Zoals reeds aangegeven kan de vertaler enkel vertaalde pagina's uploaden maar niet publiceren. De volgende stap in de Translation Workflow is dan dat de content administrator de vertalingen nakijkt en publiceert. In de content tree zijn vertaalde, maar nog niet gepubliceerde pagina's, aangeduid met een oranje asterisks:

Fig. 6 De oranje asterisks geeft aan dat de pagina gewijzigd is maar nog niet werd gepubliceerd

Als de vertalingen zijn nagekeken hoeft de content administrator enkel te klikken op 'Save & Publish' om de veranderingen zichtbaar op de website te maken.

Conclusie

Hierbij zijn we aan het einde van onze reeks over meertalige websites ontwikkelen met Umbraco gekomen.

Het Umbraco CMS laat toe om een multilanguage structuur te kiezen die het best past bij jou website.

Via de Relations API kunnen meertalige alternatieven van een content pagina met elkaar gelinkt worden zodat men bij selectie van een andere taal dezelfde pagina in de geselecteerde taal te zien krijgt.

We zijn ten slotte ook dieper ingegaan op de ingebouwde Translation Workflow die het mogelijk maakt op een geïntegreerde manier binnen de Umbraco Backoffice samen te werken met professionele vertaalbureaus.

Deze blogpost reeks behandelt mogelijkheden en tools die Umbraco CMS biedt bij het ontwikkelen van een multilanguage website. In het eerste deel zagen welke structurele benaderingen er zijn om een multilanguage website in Umbraco aan te maken. In deel twee zijn we dan begonnen met het stap voor stap aanmaken van een multilanguage website. In dit derde deel gaan we gebruikmaken van de Relations API en implementeren we een taalkeuze element zodat de bezoeker tussen taalversies van een pagina kan switchen.

Relations API

Vaak keert men bij multilanguage sites terug naar de homepage van een andere taalversie, wanneer een andere taal wordt geselecteerd. Zou het niet veel handiger zijn, dat wanneer men op de 'Diensten'-pagina zit, men automatisch op de 'Services'-pagina terecht komt wanneer men de Engelstalige versie selecteert? Met de Relations functionaliteit in Umbraco kan dit scenario perfect gerealiseerd worden. Via de Relations API kunnen enkelvoudige of wederkerige relaties tussen twee objecten (pagina's, documenten, media, etc ...) gelegd worden. Deze relaties worden opgeslagen in de umbracoRelation tabel in de database.

In deel twee zagen we hoe we bij het kopiëren van de Nederlandstalige rootnode de checkbox 'Relate copied items to original' kunnen aanvinken. Op dat moment worden alle relaties tussen de gekopieerde nodes en de orginele nodes weggeschreven naar de umbracoRelation tabel:

fig.1 De umbracoRelation tabel in de database

Een Language Selector implementeren in Umbraco

Het enige wat we nu nog nodig hebben is een component die het mogelijk maakt voor de gebruiker om een andere taal te selecteren. Tim Geyssens beschrijft in zijn blog hoe je zelf zo'n Language Selector kunt implementeren in je Umbraco website (http://www.nibble.be/?p=32).

Webmove gebruikt echter de uitstekende Goyaweb Multilanguage Tools, ontwikkelt door Yannick Smits. Deze language selector bevat ook een Razor-script die automatisch naar de anderstalige pagina switched indien er een relatie bestaat in de Relations table. Je hebt ook drie weergave mogelijkheden voor de Language Selector: een dropdownlist, textuele links of afbeeldingen van vlaggetjes:

fig.2 weergave mogelijkheden voor de Language Selector van de Goyaweb Multilanguage Tools

na installatie van de package hoef je enkel een macro aan je template toe te voegen:

<umbraco:Macro  RenderType="Flags"  Alias="MLLanguageSwitcher"  runat="server"></umbraco:Macro>

De bezoekers kunnen nu een ander taalversie van een pagina selecteren door op de vlaggetjes van de taalkeuze component te klikken:

fig.3 De implementatie van de taalkeuze component op de website

Een andere handige package is de Vizioz Relationship package van Chris Houston. Deze package voegt een document type toe via dewelke je de relaties tussen pagina's kunt beheren in de Umbraco Backoffice.

We zijn nu klaar met onze multi-site structuur voor onze multilanguage website. We kunnen onze anderstalige websites onafhankelijk van elkaar beheren, en waar nodig relaties leggen tussen de onderlinge anderstalige pagina's. Gebruikers kunnen via een Language Selector de gewenste taal selecteren.

In het vierde en laatste deel zullen we de ingebouwde Translation Workflow in Umbraco nader bekijken. Deze Translation Workflow maakt het mogelijk om de samenwerking met professionele vertaalbureaus te integreren in de Umbraco Backoffice.