Udover den dårlige brugeroplevelse du giver dine kunder ved et langsomt website, koster det f.eks. også ekstra hos Adwords og giver ringere søgeordsplaceringer.
Matt Cutts fra Google udtaler, “Historically, we haven’t had to use it in our search rankings, but a lot of people within Google think that the web should be fast. It should be a good experience, and so it’s sort of fair to say that if you’re a fast site, maybe you should get a little bit of a bonus. If you really have an awfully slow site, then maybe users don’t want that as much” (Se video’en her).

Det findes mange muligheder når det kommer til optimering af et websites performance, som for eksempel at bruge Content Delivery Networks eller at hoste sitet i en cloudløsning (f.eks. som DSB har gjort på Microsofts Azure). Der er dog en række simple tiltag man kan gøre, for at optimere siderne så at oplevelsen for besøgeren forbedres markant.

Brug dit CMS indbyggede caching
Umbraco og Sitecore, for eksempel, har avancerede caching funktionaliteter som virker ”out of the box”. Hvis man planlægger, og tager hensyn til, hvilke elementer som er delt mellem alle besøgere, og hvilke som er dynamiske, kommer man rigtig langt med sit CMS standardfunktionalitet.

Hvis det er specifikke dele, eller databasekald, på en side som er ’dyrt’ (dvs. koster på den tid serveren skal bruge), kan man nemt implementere custom caching for lige den del – som opdateres når nyt indhold publiceres. Publiceringsfunktionen tager så lidt længere tid, men den tid vil brugerne spare i stedet for.

Minimer mængden af data som sendes til brugeren
Ved for eksempel at bruge SqishIt, kan man minimere mængden af Javascript og CSS som sendes til brugerens browser. Det er også muligt at samle alle javascript-filer til én, hvilket samlet gør at der sendes færre forespørgsler til serveren. En bonus ved dette er at browsercaching af Javascript og CSS derved håndteres automatisk, fordi navnet automat-genereres og optræder som en ny fil når koden er blevet opdateret.

I ASP.net-løsninger kan man slå ’viewstate’ fra for de kontroller som ikke bruger det, for at sende mindre data.

Når man således har minimeret data som skal sendes til besøgerens browser, kan man derefter komprimere data på serveren (og sende i ’pakket’ form) for at yderligere spare værdifuld båndbredde (og derved overførselstid). Alle moderne browsere understøtter Gzip for ’udpakning’.

Brug indexes i stedet for databasekald
I stedet for at serveren skal udføre kostbare databasekald, for eksempel ved produktfiltreringer, kan data placeres i søgeindekses som er optimerede for søgninger. I Umbraco og Sitecore bruges Lucene som standard, og man skal altså ikke bruge tid og penge for at få avanceret indeksering af sit indhold.

Jeg skriver muligvis, fordi vi, her 2 måneder før direktivet træder i kraft som dansk lov, endnu ikke ved hvordan reglerne bliver, og hvordan de skal fortolkes. Loven rammer alle hjemmesider, der gemmer eller henter oplysninger på brugerens ”terminaludstyr” (enten selv eller for tredjepart), det vil for de fleste hjemmesider være i form af de såkaldte cookies.

I praksis betyder de nye regler, at brugerne skal vide hvad der bliver gemt af oplysninger om dem når de surfer på din hjemmeside, og hvad de oplysninger bruges til. Brugerne skal give deres samtykke til det, og de skal kunne vælge det fra. For dig som website ejer, betyder det sansynligvis at det bliver sværere at analysere trafikken, og derved målrette og segmentere din kommunikation.

IT- og Telestyrelsens udkast til ”Bekendtgørelse om krav til information og samtykke ved lagring af og adgang til oplysninger i slutbrugeres terminaludstyr” stiller krav om, at hjemmesider først må gemme/hente oplysninger efter, at brugeren har givet samtykke. Samt skal give brugeren:

• information som ”fremstår i et klart, præcist og letforståeligt sprog eller tilsvarende billedskrift” (gid man kunne stille samme krav til en bekendtgørelse).
• ”en umiddelbart tilgængelig adgang til at afslå samtykke eller tilbagekalde samtykke”

Undtaget fra kravene er oplysninger, der er en teknisk forudsætning for, at hjemmesiden kan virke, dvs. f.eks. login-funktionalitet eller virtuelle indkøbskurve.

Videre læsning:

• EU direktiv 2009/136/EF af 25. november 2009 (se punkt 66)
• Lov om elektroniske kommunikationsnet og –tjenester (se §9)
• IT- og Telestyrelsens høring om ” Bekendtgørelse om krav til information og samtykke ved lagring af og adgang til oplysninger i slutbrugeres terminaludstyr”

Hvis du vil have en analyse af, hvad loven kommer til at betyde for din hjemmeside eller høre mere om mulighederne, kan Seniorkonsulent Per Jakobsen hjælpe dig.

Sådan lyder det fra webudvikler Mads Kierulff fra firmaet Kraftvaerk, efter at Version2 mandag skrev om, hvordan halvdelen af de danske netbutikker har alvorlige sikkerhedshuller.

Han peger på fire typiske begynderfejl, der kan have store konsekvenser for sikkerheden:

1. Mulighed for SQL-injection, fordi forespørgslerne ikke bliver renset for farlige input.
2. Manglende HTTPS på betalingssiderne.
3. Minus-varer i indkøbskurven.
4. Javascript i kommentarfeltet

Læs hele artiklen hos Version2

Læs mere i vores case eller i artiklen hos Version 2

The reason for doing so is, according to the announcement, that: “the term is now basically being used to mean anything Web-standards-related, so it’s time to move on!”

Kill your darlings

While I agree that it feels wrong to include new-fangled CSS and javascript functionality under the HTML5 umbrella, it’s also kind of sad to throw away a nice shield-shaped logo just like that. Or not… But anyways, here’s a quick take on a revision, based on the pure CSS HTML5 logo by Darcy Clarke:

Have a go with your own take on jsFiddle

Under interviewet fik vi besked om at vi var blandet de 20 finalister i region København, og dermed var inviteret til regionskåringen der fandt sted i E&Y Tower i Søborg (det gl. TV-byen). Kraftvaerk vandt desværre ikke, men ikke desto mindre er vi meget stolte over at være kommet i betragtning, og ikke mindst at vi nu er i selskabet “top 120 entreprenører i Danmark”.

Kraftvaerk ønsker i øvrigt Sitecore tillykke med prisen som regionsvinder i København.

Se gerne en video fra eventen hos Ernst & Young.

Fakta:

Antal aktie- og anpartsselskaber i DK 216.234. Heraf levede 412 op til E&Y’s krav til at komme i betragtning som Entrepreneur of the Year. Af disse 412 virksomheder blev 120 udvalgt til interview og det er altså blandet dem Kraftvaerk er at finde.

Vi vil gerne  benytte lejligheden til at takke Kraftvaerk København for støtte og opbakning. Ikke mindst vil vi takke alle vores dejlige kunder og medarbejdere som har gjort det til en fornøjelse at starte virksomhed.

PS! Ved det godt kære Københavnere – men bagerbutikken var udskiftet med dameundertøjs butik….

Et gammelt søkort ledte to hold rundt til en række udfordringer, og vanen tro vandt pigerne de fleste aktiviteter, inklusiv øl stafetten. Knapt så cool men sandt.

<urlMappings enabled="true">
	<!-- This is needed since the sitemap does not allow duplicate urls -->
	<add url="~/NewDir/Default.aspx" mappedUrl="~/OldDir/Default.aspx" />
	<add url="~/NewDir/Equipment.aspx" mappedUrl="~/NewDir/Equipment.aspx" />
</urlMappings>

However the HTML form action on each of the new mapped pages pointed to the old page, ie “/OldDir/Default.aspx”. I don’t know why ASP.NET insists on using the old URL rather than the real requested URL, but I guess it could be due to some security issue in some rare situation. There’s of course a number of different ways to correct this form action URL. One way is to simply set an action URL in you page load handler:

Form.Action = Request.RawUrl;

Request.RawUrl contains the actual requested URL. This means you have to do this on every mapped page. It just doesnt feel right.
Another approach I read about on blog post by Scott Gu is to use ControlAdapters. A ControlAdapter can be used to alter the rendering of a WebControl. In this case I want to alter a HtmlForm control and its Action property. The use of a ControlAdapter is registered in a browser definition file.

<controlAdapters>
  <adapter controlType="System.Web.UI.HtmlControls.HtmlForm"
		   adapterType="Kraftvaerk.MappedUrlHtmlFormControlAdapter" />
</controlAdapters>

You implement a ControlAdapter by inheriting from System.Web.UI.Adapters.ControlAdapter.

public class MappedUrlHtmlFormControlAdapter : System.Web.UI.Adapters.ControlAdapter
{
	protected override void Render(System.Web.UI.HtmlTextWriter writer)
	{
		// Override the Action property
		((System.Web.UI.HtmlControls.HtmlForm)Control).Action = Page.Request.RawUrl;

		base.Render(writer);
	}
}

By using a ControlAdapter you don’t have to change a single line in your code-behind files, so if you have a lot of mapped URLs this approach is much easier to maintain. However, keep in mind that the adapter will be used on all pages, and therefore could break some logic that expects the default form action url in ASP.NET.