En alle redenen zijn goed om het prijzen te laten regenen. In ons geval is dat omdat we 5 jaar bestaan. Wil je weten wanneer je kan deelnemen, laat dan je e-mail adres achter.
We gebruiken dat adres trouwens maar één maal: om de start van de wedstrijd aan te kondigen.
Eind januari lanceerden we de nieuwe webshop voor de babyspeciaalzaak Monsters With An Attitude. Deze webshop is, net zoals alle andere webshops & projecten die we afleveren, “tailor made” naar de noden en wensen van de klant.
Zowel de look&feel als de functionaliteit werden vastgelegd na enkele rondes feedback en aanpassingen samen met de klant. Een goed inlevingsvermogen in de business en werkwijze van de klant laat toe om het aantal iteraties tot een minimum te houden terwijl we naar een maximum aan klantentevredenheid streven.
Wie de vorige posts op deze blog gelezen heeft weet dat we bepaalde ontwikkelings- en functionaliteitsprincipes hanteren. We kunnen ze gerust “web industry best practices” noemen. Wat nu volgt is een mix van een case study en whitepaper voor een webshop.
Eerst en vooral hebben we de analysefase. De eerste sessies met de klant zijn eerder brainstormsessies. Alle mogelijke functionaliteiten, inclusief de toeters en bellen, die relevant kunnen zijn voor dit type project worden uitvoerig besproken. Op het einde van de analysefase leggen we samen met de klant vast wat er zal worden uitgewerkt, hoeveel dat zal kosten en hoe lang dat zal duren. Vaak wordt er op dit ogenblik beslist om bepaalde opties al dan niet meteen te nemen of te verschuiven naar een volgende fase. Dankzij deze gefaseerde aanpak kan een project geleidelijk groeien.
Heel belangrijk is dat, naast de functionaliteit, ook de business processes van de klant mee onder de loupe worden genomen. In overleg worden scenario’s opgesteld voor de verschillende types van gebruikers (doelpubliek) die de website gaan gebruiken. Een gebruikerscenario identificeert handelingen met stappen en acties die moeten gebeuren om bepaalde doelen te kunnen bereiken.
Tijdens de analysefase staan deze gebruikerscenario’s centraal. Enerzijds bepalen ze de functionaliteit en logica. Anderzijds kunnen ze worden gebruikt ter controle of alle afgesproken functionaliteiten zijn verwerkt, maar ook of de website gebruiksvriendelijk en logisch is opgebouwd.
Uit de hele analyse vloeit uiteindelijke een prototype. Vincent had enkele posts terug over dit punt al een interessante uiteenzetting online geplaatst.
Tijdens de analysefase kan ook al aandacht worden besteed aan de look&feel van de webshop. Onderschat het belang hiervan niet. Een shop moet niet alleen functioneel goed werken, het moet er ook professioneel uitzien en vertrouwen wekken. Bovendien wordt de webshop het uithangbord voor de winkel. Een reden te meer om een knap en origineel design af te leveren. De klant weet op dit vlak meestal wel heel duidelijk waar hij naartoe wil. Onze designer Gert wist, zoals altijd, enkele verbluffende, toepasselijke designs uit zijn mouw te schudden.
Na deze eerste fases, die meestal wel parallel verlopen, start de technische ontwikkeling van de webshop. Tijdens de interne, technische kick-off meeting worden heel wat zaken besproken. We spreken goed af hoe de zaken technisch geïmplementeerd zullen worden. Doorgaans volgen nu 3 grote brokken in de ontwikkeling:
De ontwikkeling wordt opgedeeld in fases op basis van functionaliteit. Iedere fase wordt ontwikkeld en getest voor men naar de volgende fase overstapt. Veelal steunt een latere fase op eerder ontwikkelde fases dus is het van extreem belang dat men iedere fase goed test. Unit testing is hierbij een grote hulp.
Een belangrijk voordeel van fasering is dat men op het einde van iedere fase feedback kan vragen van de klant. Zo vermijdt je eventuele “verrassingen” op het einde van de complete ontwikkelingscyclus. Betrek je klant zo snel mogelijk bij de ontwikkeling. Iedere fase waarbij men binnen een korte periode een bepaalde functionaliteit ontwikkelt, test en ter goedkeuring voorlegt aan de klant noemt men een sprint.
Er zijn een aantal best-practices die we in de kijker willen zetten:
Als laatste willen we je ook even laten meekijken achter de schermen want de publieke webshop is slecht de helft van de webapplicatie.
Deze beheersmodule laat toe de gegevens van klanten, producten, bestellingen en stock te beheren. Daarnaast is er ook nog volledige synchronisatie voorzien tussen de database voor de webapplicatie en de Filemaker-software in de winkel zodat de klant geen dubbel beheer moet doen voor de fysische winkel en de webshop.
De beheersmodule laat o.a. de volgende zaken toe:
Oh ja, de ontwikkeling gebeurde in ASP.NET. Maar dit is slechts een triviaal gegeven.
Verdere informatie over dit project kan je terugvinden op de projectpagina
Na het optimaliseren van de serverinstellingen is het deze keer de beurt aan de optimalisatietechnieken die je kan toepassen op de frontend, in je HTML, CSS en Javascript.
In het inleidende artikel haalde ik enkele cijfers aan: 80 à 90% van de snelheid van een website wordt bepaald bij het ophalen van de verschillende componenten. Dit ophalen van assets gebeurt aan de hand van HTTP requests.
In de RFC 2616 staat het volgende te lezen:
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
De eerste draft van deze RFC dateert van januari 1997 en toen was die connectielimiet nog te verantwoorden, omdat breedbandconnecties toen heel zeldzaam waren.
To find a decent balance, IE and Firefox by default restrict users to 6 connections total and 2 connections per host for HTTP 1.1 connections.
Omwille van historische redenen wordt standaard in browsers het aantal simultane connecties naar dezelfde host beperkt tot 2. De geavanceerde browsergebruiker kan die waarden wel aanpassen, maar de modale bezoeker van je website zit dus met die limiet van 2 connecties per host.
Opmerking: Internet Explorer 8 zal de limiet optrekken van 2 naar 6 connecties per host.
De performantie van je website hangt, zoals je nu al zal doorhebben, grotendeels af van het aantal componenten op de pagina.
Bij een standaard browserinstallatie, downloaden die componenten parallel in groepjes van 2 per hostnaam.
Gelukkig kan je deze beperking omzeilen en dit door de componenten te spreiden over 2 hostnamen. Zo kan je de response time dus halveren.
Je zou hier nog verder in kunnen gaan en bijvoorbeeld 4 of meer hostnames gebruiken, maar omwille van de vertraging die optreedt bij DNS lookups, kan dit dan weer een negatieve impact hebben op de performantie. Het kan in sommige gevallen de server CPU, bandbreedte of aantal simultane connecties belasten.
Volgens onderzoek van Yahoo! is het spreiden van componenten over 2 tot 4 hostnamen ideaal voor performantie.
Verschillende grote sites plaatsen hun statische componenten onder een andere hostname: Yahoo! op yimg.com, Youtube op ytimg.com en Amazon op images-amazon.com. Je hoeft zelfs geen afzonderlijke domeinnaam aan te kopen, het kan evengoed met een subdomein.
Ik haalde de techniek ook al aan in het vorige artikel uit de reeks met optimalisatietips, meerbepaald in de sectie over cookies:
Bij de meeste websites staan de cookies gewoon op de root (/), wat die cookie dan voor elk object zet. Daarom is het aan te raden om je statische content op een aparte domein, of subdomein te plaatsen, waarop dan geen cookies worden geplaatst.
Wij hebben er een gewoonte van gemaakt om de statische content (CSS, Javascript files, afbeeldingen, …) onder een subdomein te plaatsen. Meestal iets als static.example.be.
Je kan de performantie van je website dus drastisch verhogen door het aantal HTTP requests tot een minimum te beperken.
In het vorige artikel legde ik uit hoe je via enkele serveraanpassingen componenten kan cachen voor hergebruik… Maar ook op de frontend kan je nog enkele performantie verhogende technieken toepassen.
Bij CSS Sprites worden verschillende afbeeldingen gecombineerd in 1 grotere afbeelding. Voorbeelden vind je op verschillende sites, waaronder die van BBC (voorbeeld), Yahoo (voorbeeld), Google (voorbeeld), … Met CSS sprites kan je dus al een groot aantal requests reduceren tot 1 of slechts enkele requests.
Een bijkomend voordeel van CSS sprites is dat de gecombineerde afbeelding, in de meeste gevallen ook kleiner in bestandsgrootte is dan de optelsom van de verschillende afzonderlijke groottes en dit doordat er minder kleurentabellen en formaatinformatie moet opgeslagen worden.
Op complexe websites met een groot kleurenpallet kan je dan opteren om eventueel meerdere sprites te gebruiken.
Zo heeft het ontwikkelingsteam van de BBC website 60 externe afbeeldingen kunnen samenvoegen tot 3 sprites: 1 voor achtergronden, 1 voor kleurverlopen en 1 voor de afgeronde hoekjes.
De meeste websites gebruiken meerdere scripts of stylesheet documenten. Vaak kunnen deze zonder probleem gecombineerd worden: dus alle Javascript files combineren tot 1 script file, en alle CSS files tot 1 stylesheet document. Uitzonderingen zijn natuurlijk de print stylesheet en de stylesheets specifiek voor Internet Explorer (via conditional comments).
Je kan, zoals ons, een onderscheid maken tussen development en productie omgevingen en blijven werken met afzonderlijke files tijdens het ontwikkelen van de website en deze dan op de productieserver samenvoegen, eventueel via een geautomatiseerd server-side script.
Je kan HTTP compressie toepassen op serverniveau, om bestandsgroottes in realtime te verkleinen, maar je kan je ook baseren op minifying. Hierbij worden onnodige karakters uit de files verwijderd. Het gaat dan om commentaarregels, spaties, tabinsprongen, newlines, … Het resultaat is een compactere (maar minder leesbare) file. Ideaal dus voor productieomgevingen.
Obfuscation gaat als techniek nog verder, waarbij het moeilijker wordt om de source files correct te interpreteren. Het vervangt functienamen en variabelen door kortere karakters (a, b, c, …). Deze compressiemethode kan echter ook bugs in je code introduceren. Wees dus voorzichtig bij gebruik.
Enkele populaire tools om je code te minimaliseren zijn: JSMin en onze persoonlijke favoriet, YUICompressor.
Onze methodiek bij Javascript files is: de namen van variabelen en functies zo compact mogelijk te houden en dan de verschillende files via een PHP script samen te voegen, om daarna te comprimeren (via de minify techniek) en dan via HTTP compressie in de browser te bezorgen.
Gemiddeld kan je met de minify techniek op de bestandsgrootte zo’n 20% besparen. Als je het combineert met HTTP compressie kan je er vaak nog eens een extra 5% van krijgen.
We kennen ondertussen allemaal het belang van CSS. Maar toch kan je ook met CSS nog de mist in gaan. Vooral bij grotere sites is het soms moeilijk om het aantal CSS regels beperkt te houden. Vandaar deze quote van Nate Koechley:
We spend a lot of time on familiarizing ourselves with all the properties and values of CSS, but the power of professional CSS lies in choosing the right selectors.
Het komt er dus op neer om je CSS compact te houden, ondermeer door het kiezen van de juiste selectors.
Je kan je CSS ook optimaliseren door:
Ondanks het gemak van het importeren van CSS via @import, is het ten stelligste af te raden. Zelfs al staat de @import regel helemaal bovenaan de HTML pagina, dan nog zullen die files pas als allerlaatste ingeladen worden. Het verhindert dus de vlotte rendering van de website.
Het laden van de externe CSS files gebeurt best via de <link> tag in de head van het document.
In tegenstelling tot externe CSS files, plaats je scripts best onderaan de pagina. Vele developers doen dit net in de head van het HTML document, maar dat heeft een negatieve inpact op de performantie.
Tijdens het laden van zo’n script wordt namelijk het downloaden in parallel tijdelijk geblokkeerd. De reden hiervoor is dat het script document.write kan bevatten, waardoor de structuur van de HTML nog voor het renderen kan wijzigen.
Een andere reden voor dit gedrag is omdat browsers willen vermijden dat het ene script onbedoeld voor het andere wordt geladen. Hierdoor zouden Javascript errors kunnen optreden, wanneer de ene file afhankelijk is van de andere.
Tijdens het downloaden van Javascript files, worden er dus geen andere componenten gedownload… Als je wil dat de website snel wordt weergegeven, dan plaats je dus best Javascript files onderaan de pagina.
Je zou eventueel het attribuut defer kunnen toevoegen aan je script in de head, waarmee je aangeeft dat die file geen document.write zal bevatten, maar helaas werkt dat niet in Firefox en dus eigenlijk is dat geen optie.
Door te preloaden kan je optimaal gebruik maken van de tijd nadat de browser alle huidige componenten heeft ingeladen, om nieuwe te downloaden, die je misschien nodig hebt op volgende pagina’s.
We onderscheiden 3 scenario’s waarin je assets kan preloaden:
In dit geval worden de assets altijd ingeladen wanneer je bepaalde een pagina bezoekt. Een goed voorbeeld hiervan is de homepage van Google. Hierop downloaden ze de sprite met de afbeeldingen voor de resultaten pagina van zodra de homepage klaar is met laden (onLoad event). Wanneer de gebruikers dus iets zoekt en op de resultatenpagina terecht komt, dan zit de sprite al in de browsercache.
Hier start je het downloaden van sommige componenten of scripts van zodra de gebruiker bepaalde controls of widgets begint te gebruiken. Voorbeelden hiervan vind je op de Yahoo! homepage.
Bij het redesignen van een website kan je een tijdje op voorhand de stylesheets, scripts of afbeeldingen van het nieuwe design laten downloaden. Wanneer de nieuwe site dan gelanceerd wordt, blijft hij toch snel presteren, omdat de componenten in de browsercache van de trouwe bezoekers zullen zitten.
Tot zover dus de theorie. In het volgende artikel ga ik met concrete voorbeelden en cijfers aantonen hoeveel voordeel je kan halen uit caching, het beperken van het aantal HTTP requests, de CSS en Javascript technieken, … En vooral met welke tools je de performantie kan meten, om zelf ook aan de slag te gaan. Stay tuned!
In dit artikel uit de reeks met website optimalisatietips, ga ik toelichten welke aanpassingen je kan voorzien in de Apache serverconfiguratie, om een betere performantie te bekomen.
Het cachen van componenten, is het tijdelijk opslaan van vaak geraadpleegde website elementen, op de lokale harde schijf van de persoon die de website bezoekt of op een proxyserver van een bedrijf of ISP. Het gaat dan in de eerste plaats om afbeeldingen, CSS en Javascript files.
Doordat deze files niet opnieuw van de server moeten gedownload worden, kunnen het aantal HTTP requests beperkt worden en moeten er minder DNS Lookups gebeuren (die typisch 20-120 milliseconden in beslag nemen).
We maken een onderscheid tussen een empty cache en een primed cache. Empty cache slaat op een lege cache, relatief tegenover jouw website. De bezoeker heeft dus van jouw pagina’s geen componenten in cache.
Bij een primed cache zitten al jouw componenten in de cache van de gebruiker.
Volgens onderzoek van Yahoo! wordt 62% tot 95% van de tijd gespendeerd aan het maken van HTTP requests. Als je dus een druk bezochte website hebt, met veel terugkerende bezoekers, dan haal je veel voordeel uit caching.
<meta http-equiv="Expires" ...>)Wij richten ons in dit artikel tot de 3de manier.
Als je een Expires Header gebruikt die ver in de toekomst ligt, dan kan je verzekeren dat het element gecached wordt door browsers. Een Expire Header vertelt de browser namelijk vanaf wanneer het element opnieuw van op de server ingeladen moet worden.
Om caching te activeren op een Apache 2.0 server, moet je volgende modules inschakelen:
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.soEen snelle manier om bestanden te cachen, is aan de hand van de extensie. Eerst dien je mod_expires aan te zetten:
ExpiresActive OnCaching voor je site inschakelen:
<Directory "/var/www/htdocs" />
Options FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
ExpiresDefault A3600
<FilesMatch "\.html$">
ExpiresDefault A86400
</FilesMatch>
<FilesMatch "\.(gif|jpg|png|js|css)$">
ExpiresDefault A31536000
</FilesMatch>
</Directory>
ExpiresDefault A3600 zet de default expiry time op 3600 seconden (of 1 uur) na toegang tot de file. De HTML files zullen maximum 1 dag (86400 seconden) gecached worden, en de assets uit de 2de FileMatch maximum 1 jaar (31536000 seconden).
Je kan de caching voor files ook specifiëren aan de hand van het MIME type.
<VirtualHost *>
...
ExpiresActive On
ExpiresDefault "access plus 3600 seconds"
<Directory "/var/www/htdocs" />
Options FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
ExpiresByType text/html "access plus 1 day"
ExpiresByType text/css "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
</Directory>
</VirtualHost>Dankzij de AllowOverride All kan je de caching ook bepalen op mapniveau, via een .htaccess file:
<FilesMatch "\.(css)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>Meer details kan je lezen op:
http://httpd.apache.org/docs/2.2/mod/mod_expires.html
Als de componenten een lange tijd in de cache van de browser kunnen zitten, dan moet je ook een manier voorzien om toch een download van bepaalde assets te forceren. Je kan een versienummer voorzien in de bestandsnaam (bv all.min.1.0.2.js) of in de mappenstructuur (bv /js/1.0.2/all.min.js).
Als je het voorrecht hebt dat jouw site ingesteld staat als homepage in de browser van een gebruiker, dan worden alle assets die worden ingeladen, niet gecached !
In die uitzonderlijke gevallen is het te verantwoorden om de CSS en Javascript inline te plaatsen, om zo het aantal HTTP requests te beperken en de reactiesnelheid van de site te verhogen.
Een handige manier op je pagina sneller te doen laden, is door HTTP compressie toe te passen op tekstuele content (HTML, CSS, Javascript, XML, …). Dit wordt in vrijwel alle browsers ondersteund, meerbepaald in diegene die HTTP 1.1 en PNG files ondersteunen. (Internet Explorer 4 en later, Firefox, Opera 5.12+).
In Apache bestaat een module om content on fhe fly te comprimeren (mod_gzip – voor Apache 1.3+, mod_deflate – voor Apache 2+)
De module activeren in Apache 2 is eenvoudig:
LoadModule deflate_module modules/mod_deflate.soConfigureren kan via:
AddOutputFilterByType DEFLATE text/html text/plain
text/xml text/css application/javascriptHiermee zeg je dus: comprimeer alle html, plain text, xml, css en javascript files.
Meer details kan je lezen op:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
ETags zijn ontworpen om beter te kunnen achterhalen wanneer een component in cache hetzelfde is als op de server. Een ETag id is uniek voor een specifieke resource op een specifieke server. Op drukke websites met meerdere servers kan dit dus problemen opleveren bij het cachen.
De Etag bestaat uit 3 componenten: INode, MTime en Size. Een optie is dus om de Etag zo te configureren, dat het de server niet vermeld bij de Etag.
<Directory /usr/local/httpd/htdocs>
FileETag MTime Size
</Directory>Een andere optie is om ETags gewoon uit te schakelen en je volledig te baseren op Expires of Cache-Control headers.
Header unset Etag
FileETag noneMeer details kan je lezen op:
http://httpd.apache.org/docs/2.2/mod/core.html#fileetag
Cookies worden meegestuurd met elke request. Dus ook wanneer je statische content, zoals afbeeldingen inlaadt.
Bij de meeste websites staan de cookies gewoon op de root (/), wat die cookie dan voor elk object zet. Daarom is het aan te raden om je statische content op een aparte domein, of subdomein te plaatsen, waarop dan geen cookies worden geplaatst. Een andere manier om overhead te vermijden is om het pad van je cookies beter te specifiëren.
Verwijder ook de overbodige cookies, zodat deze niet telkens meegestuurd worden met iedere request.
Je kan beter ook een kortere of zelfs geen Expiry date zetten. Zo wordt de cookie sneller opnieuw verwijderd, en verbetert de responsetijd voor de gebruiker weer.
Let ook op: sommige proxy servers weigeren files te cachen waaraan cookies gekoppeld zijn.
Dit artikel richtte zich voornamelijk toch de Apache configuratie. Je kan de technieken echter ook toepassen in andere serveromgevingen. In een later artikel zullen we dan toelichten hoe je het kan configureren in een Internet Information Services (IIS) omgeving.
Wil je weten (en meten) hoe het gesteld is met de performantie van je website: lees dan zeker ook het artikel met een overzicht van de tools om performantie te meten.
Op @media 2008 hebben Vincent en ik de presentatie gezien van Nate Koechley, frontend engineer bij Yahoo!. Tijdens deze uiteenzetting zijn een hele reeks tips aan bod gekomen, over hoe je nu precies een website kan optimaliseren.
Het omzetten van de webdesigns naar HTML templates met CSS en Javascript interactie werd vroeger voornamelijk uitgevoerd door de webdesigner en de webprogrammeur.
Omwille van de groeiende complexiteit van projecten en de hogere eisen voor websites worden deze taken nu steeds vaker uitgevoerd door de zogenaamde frontend developers of frontend engineers, de term die ze bij Yahoo! gebruiken.
Kort samengevat bestaat de taak van de frontend developer erin de browser te zeggen hoe een website moet weergegeven worden. Klinkt eenvoudig. In de praktijk moet je rekening houden met de verschillende platformen, browsers, verschillende renderingengines per browser, versies van browsers, … De frontend developer moet niet alleen de specificaties kennen, maar ook hoe browsers deze interpreteren.
Het volstaan al lang niet meer om mooie websites te maken. Ze moeten ook functioneel zijn, toegankelijk, goed gepositioneerd in zoekmachines en veel te vaak onderschat: performant.
Wanneer we aan website optimalisatie denken, dan ging in het verleden vaak de aandacht naar backend optimalisatie: database queries, indexes, memory management,… In de realiteit dragen deze backend optimalisaties gemiddeld maar voor 10 à 20% toe aan de snelheid van een website. De overige 80 – 90% wordt besteed ná het ophalen van de HTML pagina, dus bij de verschillende requests voor externe componenten én het downloaden ervan.
Er is dus een groot onderscheid te maken tussen 2 soorten performantie:
Omdat de frontend in grote mate verantwoordelijk is voor de snelheid van de website, is het dus ook de taak van de frontend developer om de response time van een website zo laag mogelijk te houden.
Hoe je dat precies kan doen, licht ik de komende weken toe in een reeks artikels over website optimalisatie, met volgende onderwerpen: