Vi er en hel del, der vil sige: “Det var på tide!”. At der skal gå så mange år er et bevis på visionsløse og uvidende politikere. Danskerne burde have været vænnet til at bruge digitale løsninger for mange år siden. Mange er i øvrigt allerede vænnet til det, da de fleste anvender digitale løsninger i deres arbejde i det private erhvervsliv, og der er vel næppe ret mange, der ikke anvender netbanker.

Men 2015 er desværre for optimistisk. Hvis alt går som det plejer at gøre, så ender dette med kæmpe udbud, hvor store koncerner vinder opgaven for derefter at blive forsinket i hele år. Så planen om, at alle danskere skal tvinges på det digitale rådhus i 2015 kan man allerede nu godt begrave. Vi taler sandsynligvis 2017.

I artiklen, som i øvrigt kan læses her, kommer Bjarne Hastrup, som er formand for Ældresagen, med en vigtig pointe. Han anfører, at hvis danskerne i højere grad skal anvende selvbetjeningsløsninger, så er der behov for at arbejde en del med brugervenlighed. Faktisk efterlyser han en Steve Jobs i den offentlige sektor.

Man kan nok stille sig tvivlende overfor om en Steve Jobs-klon vil befinde sig ret længe i en koncern a la KMD og CSC. Jeg tvivler på, at en ægte Steve Jobs ville befinde sig særlig godt i disse virksomheder. Tværtimod ville de danske Steve Jobs-kloner nok nærmere befinde sig i mindre virksomheder – som så nok ikke får lov til at bygge disse løsninger, fordi de ikke hedder KMD eller CSC.

Og det mener jeg faktisk er et problem. Virksomheder som KMD og CSC har stor erfaring i at bygge offentlige løsninger, men det er oftest offentlige løsninger, der er byggede til at tilgodese medarbejderne i den offentlige sektor, og ikke borgerne. Hvis man kigger på de løsninger, som er rettede imod borgerne, så er det på ingen måde imponerende.

Problemet er ikke bare, at der er tale om elendig usability. Der er naturligvis ingen tvivl om, at de offentlige myndigheder ville kunne nå rigtig langt, hvis man blot begyndte at anvende basale principper for brugervenlighed. Et par usability-eksperter, som fik lov til at bestemme over brugergrænsefladen og designoplevelsen, ville kunne øge brugen af selvbetjeningsløsningerne voldsomt.

Men det virkelige problem ligger i, at mange selvbetjeningsløsninger ofte tager udgangspunkt i det offentliges behov, og ikke borgerens. Og det er her, at de mange mindre virksomheder kunne komme ind i billedet. Kunne man forestille sig, at iværksættere ville være bedre til at fange borgernes behov, og udmønte disse i bedre selvbetjeningsløsninger?

Jeg tror, at man er nødt til se selvbetjeningsløsninger som projekter, der involverer opbygningen af en fælles infrastruktur, som mange forskellige selvbetjeningsløsninger kan trække på. Tænk sig, hvis vi kom til at stå i den situation, at det offentlige blev tvunget til at stille alle deres data til rådighed for danske iværksættere. Prøv at tænke på det væld af løsninger, der kunne dukke op, og prøv at tænke på alle de potentielle virksomheder, der kunne skabes på det grundlag.

Dette ville naturligvis kræve, at de store koncerner i form af KMD og CSC skulle stå for driften af en sådan infrastruktur. Men det er jo allerede det, som de gør i dag, og på den måde udnytter man blot deres ekspertise, mens nye iværksættere får mulighed for at lave nye koncepter til selvbetjeningsløsninger, som i langt højere grad tager udgangspunkt i borgernes behov. Jeg tror, at et sådant samarbejde – hvor man aktiverer de mange gode ideer i græsrødderne – ville kunne øge fremdriften ganske dramatisk.

Kort fortalt går det ud på, at hvis din hjemmeside har flere end 25.000 brugere, som anvender kortfunktionen på hjemmesiden, så skal der betales. Det vil sige, at de første 25.000 brugere er gratis – herefter skal der betales $4 for hver 1.000 brugere, som anvender kortfunktionen.

I Googles verden er 25.000 brugere lig med 25.000, som åbner en side med et Google kort på. Det betyder, at alle efterfølgende handlinger – som eksempelvis zoom, panorering og klik på kortet – ikke tæller med i de 25.000. Men hvis en bruger så reloader siden, så er der tale om endnu en “bruger”.

Spørger man mig, så er det ganske få danske hjemmesider, der kommer op på dette tal. Der vil naturligvis være visse større danske hjemmesider, som risikerer at blive ramt af dette, men de fleste virksomheder, som har eksempelvis en forhandlervisning baseret på Google Maps, vil ikke blive ramt. Det er nok de færreste, som genererer 25.000 visninger på en dag.

Der er mulighed for at læse meget mere om de nye priser her: http://code.google.com/apis/maps/faq.html#tos_pricing.

Hvis du ikke er med på, hvad jeg mener, så er her et eksempel:
CAPTCHA’er er automatisk genererede og de er sat i verden for at forhindre spambots. Princippet er, at spambots ikke kan genkende de tegn, som bliver genereret, og derfor – er tanken bag – kan man være sikker på, at spambots ikke får adgang til at udfylde formularen. Hvilket kan være en ret stor fordel i tilfælde af, at du hedder Facebook eller Google, og har adgang til milliarder af menneskers brugerkonti.

Men min egen oplevelse er, at de også forhindrer rigtige mennesker i at udfylde formularer. Jeg har i det mindste selv den oplevelse, at hvis jeg møder en CAPTCHA, så overvejer jeg ganske grundigt, om jeg overhovedet gider udfylde formularen. Og hvis jeg så beslutter mig for rent faktisk at udfylde formularen, så kan jeg alligevel i sidste ende blive så frustreret over CAPTCHA’en, så jeg til sidst alligevel beslutter mig for at droppe at indsende formularen.

Jeg er ganske sikker på, at der er andre, der også har det på samme måde. Og hvis man foretager en søgning på nettet, så finder man lynhurtigt andre, som støtter dette synspunkt. Josh Fraser har skrevet et blogindlæg, som har overskriften “Why you should never use a CAPTCHA” (http://www.onlineaspect.com/2010/07/02/why-you-should-never-use-a-captcha/). I dette indlæg argumenterer han for, at det ikke kan betale sig at anvende CAPTCHA’er, da spambots alligevel efterhånden er blevet så avancerede, at de godt kan bryde koden, og dermed få adgang. Og så fremfører han, at man – som ejer af en hjemmeside – ligeså godt kunne benytte sig af en teknik, som går ud på, at man indsætter et skjult felt i formularen. Dette felt kaldes f.eks. ‘e-mail’ – de fleste spambots vil reagere på dette og udfylde det, men det vil de almindelige brugere ikke, da feltet er skjult. På den måde kan man skelne spambots fra almindelige brugere, og de almindelige brugere undgår at skulle blive konfronteret med en brugerfjendsk CAPTCHA.

Dermed mente jeg, at jeg var nået frem til en konklusion: Jeg ville fremover anbefale alle og enhver, jeg kom i nærheden af, at de ikke skal anvende CAPTCHA’er på deres hjemmesider. Glæden varede lige indtil, jeg foretog en ny søgning på Google, og fandt frem til Chris Poulter, som har skrevet et blogindlæg med overskriften “Why you should always use a CAPTCHA” (http://www.chrispoulter.com/blog/entry/why-you-should-always-use-a-captcha). Argumentet er, at man vil blive oversvømmet af spam, hvis man ikke har en effektiv mekanisme i form af en CAPTCHA i formularen til at beskytte sig.

Så konklusionen er altså, at man i en formular bør have en mekanisme, der kan undgå spambots, og man bør samtidig undgå CAPTCHA’er. Dermed er vi tilbage ved den teknik, som går ud på, at indsætte et skjult felt i formularen. Denne teknik er yderligere beskrevet på Ned Batchelder’s blog: (http://nedbatchelder.com/text/stopbots.html)

Denne teknik stopper ikke alle spambots. Men den stopper de mest almindelige, som spreder deres spam med spredehagl. Og argumentet er, at hvis du “bare” er en middelstor dansk hjemmeside, så vil der nok ikke være ret mange spammere, der vil specialbygge en spambot til dig. Heldigvis!

Min pointe er, at hvis du er ejer af en hjemmeside, så bør du overveje meget grundigt, hvordan du designer dine formularer. Det siger næsten sig selv, men ikke desto mindre er der stadig rigtig mange, der forhindrer deres brugere i at udfylde formularer. Det er synd – især hvis du er en virksomhed, som lever af nettet.

Hvad er jeres erfaring?

Hurtigere udvikling

Men!

Konklusion

Mere materiale

• Dynamicweb 8 API Refactoring Explained (http://nicolaipedersen.com/blog/2011/10/dynamicweb-8-api-refactoring-explained.aspx)

Men med de nuværende teknologier er det ofte svært at præsentere flotte diagrammer på en hjemmeside. Derfor ser man, at disse grafer  og diagrammer bliver gemt væk i et PDF-dokument, der først skal downloades til brugerens computer. Eller også er de indsat som gif-billeder på siden. Alternativt – og meget sjældent – bliver diagrammerne genereret ved hjælp af Flash, Silverlight eller andre proprietære teknologier. Og oftest ender man med at give op, og i stedet præsentere data i form af en tabel.

Generelt gør de nuværende teknologier det rigtig svært at lave grafer, som er tilgængelige for alle brugere. Uanset om man præsenterer grafer i form af et eksternt PDF-dokument, eller i form af eksempelvis Flash, så står man med et tilgængelighedsproblem. Mange mennesker vil undlade at downloade PDF-dokumentet og synshandicappede brugere, som anvender skærmlæsere, vil ikke kunne afkode Flash-scriptet. Derfor er disse teknikker i praksis ikke anvendelige på offentlige hjemmesider – som paradoksalt er de hjemmesider, der oftest har behov for at præsentere store mængder af data.

HTML5

Dette er noget, som kan løses ved hjælp af HTML5 og jQuery. (Læs mere om HTML5 her: http://da.wikipedia.org/wiki/HTML5). HTML5 indeholder et såkaldt canvas-element, som giver mulighed for dynamisk at generere bitmap grafik. Kombineret med JavaScript-biblioteket jQuery giver det mulighed for at generere diagrammer on-the-fly. Filament Group har udviklet et jQuery-plugin, som er i stand til at tage data fra en almindelig HTML-tabel, og skabe en graf ud fra disse data. (Læs mere om dette plugin her: http://www.filamentgroup.com/lab/update_to_jquery_visualize_accessible_charts_with_html5_from_designing_with/)

Dette er en rigtig smart teknik, fordi det giver mulighed for både at præsentere data i tabelform, og automatisk præsentere data ved hjælp af grafer. Teknikken giver flere fordele:

1. Tilgængelighed
   Man sikrer tilgængeligheden – i forhold til overholdelse af W3C og WCAG AA – ved at data både eksisterer i form af en tabel og i form af grafik.
2. Automatisering
   Redaktøren skal kun fokusere på at indsætte en simpel tabel indeholdende data. Teknikken vil derefter sørge for at konvertere data automatisk.
3. Brugervenlighed
   Man gør hjemmesiden mere brugervenlig og tilgængelig overfor de brugere, som kan se og anvende grafen. Det bliver nemmere og hurtigere at overskue data.

Dynamicweb og grafer

Dynamicweb indeholder muligheden for at indsætte tabeller. Og efterhånden overholder disse tabeller også tilgængelighedskriterierne. Det gør det derfor muligt at indsætte tabeller, som rent faktisk validerer, og som derfor også er anvendelige på offentlige hjemmesider.

Vi har i Bleau udviklet et lille modul, som kan indsættes på et afsnit, og som kan konvertere data fra en tabel til en graf – naturligvis ved hjælp af ovenstående plugin.

I ovenstående billede ses et screenshot af en simpel demo indeholdende en tabel med salgstal på forskellige varegrupper. Tabellen er lavet som et helt almindeligt Dynamicweb-afsnit, og ved hjælp af en simpel tabel.

Systemet sørger derefter for automatisk at generere en graf ud fra de data, der er tilgængelige i tabellen. Kolonne- og rækkeoverskrifter identificeres automatisk – hvilket dog naturligvis kræver, at disse er korrekt indsat i tabellen. Kolonne- og rækkeoverskrifter anvendes herefter til at generere de labels, der anvendes i grafen.

Hvis der er en overskrift på tabellen, så indsættes denne overskrift ligeledes som overskrift i grafen. Tabellen bibeholdes naturligvis på siden, så synshandicappede brugere stadig kan anvende siden.

Det skal understreges, at den tabel, som indsættes i afsnittet, skal være valid. Det betyder, at det er en rigtig dårlig ide at indsætte en tabel fra eksempelvis Word, da en sådan tabel indeholder en masse HTML-kode, som ikke er valid. Grafen vil ikke blive genereret eller vil komme til at se underlig ud.

Administration

Som sagt er modulet særdeles simpelt, og det eneste, vi gør er, at formidle data fra Dynamicweb til et jQuery-plugin. I modulet er der en lang række indstillinger, som man kan vælge at sætte – eller også kan man vælge at læne sig op af standardværdierne.

Indstillingerne giver mulighed for at konfigurere en lang række parametre – eksempelvis højde og bredde – og de fleste af disse parametre har karakter af at være orienterede imod at styre udseendet af grafen. Bemærk også, at man kan vælge mellem fire forskellige typer af grafer:

• Søjlediagram
• Lagkagediagram
• Linjediagram
• Kurvediagram

Alle indstillinger kan overstyres ved hjælp af den medfølgende template-fil, og de medfølgende CSS-filer. Her kan man desuden udbygge funktionaliteten, hvis man har lyst til det.

Browsere

HTML5 Canvas-elementet er understøttet i alle moderne browsere. Det vil sige, at hvis du anvender seneste generation af Mozilla, Chrome, Opera, Safari og Internet Explorer, så kan din browser vise grafik ved hjælp af HTML5-teknologien. Anvender du en ældre version af Internet Explorer, så vil canvas-elementet ikke fungere. Da en hel del brugere – desværre – stadig anvender ældre versioner af Internet Explorer, så vil vi dermed stå med den udfordring, at disse brugere ikke vil kunne se grafen.

Men det er i virkeligheden ikke et problem. Den teknik, der anvendes til at skabe graferne med, tager selv hensyn til hvilken browser, der anvendes. Og anvendes der en ældre browser, så vises kun tabellen – og ingen graf. De brugere, som stadig render rundt i oldtiden, straffes dermed ved, at de ikke kan se den fantastiske nye verden.

Det semantiske web

Vi er blevet vant til temmelig intelligente søgemaskiner, som er i stand til at finde frem til information på millisekunder. Søgemaskinerne indekserer milliarder af hjemmesider, og præsenterer et imponerende søgeresultat lynhurtigt. Men pointen er, at søgemaskinen ikke “forstår” dine søgeord. Den kender ikke betydningen af hverken søgeordet eller søgeresultatet – i stedet scanner søgemaskinen alle de sider, der er i dens indeks, for at finde sider med det søgeord, som du har indtastet.

Det semantiske web ændrer på dette. I stedet for at skrive “Red hot chilli peppers billet Herning”,og muligvis få en temmelig lang liste af søgeresultater, så kunne jeg skrive “Hvornår spiller Red hot chilli peppers i Herning?”. Når vi kan skrive og tale til en søgemaskine, og vide, at den rent faktisk fatter, hvad vi spørger den om, så vil hele vores interaktion med søgemaskinen ændre sig ganske drastigt, og det vil give mulighed for helt nye typer af produkter fra søgemaskinerne. Tænk på den dag, hvor vi kan stille et spørgsmål til vores smartphone, og smartphonen reagerer ved at komme med et fyldestgørende svar med det samme!

Fremtiden er her – næsten – allerede

Google har igennem nogen tid eksperimenteret med dette. Prøv eksempelvis at søge på “Chicken pasta” på Google.com’s nye opskriftssøgning (http://www.google.com/search?q=chicken+pasta&tbs=rcp%3A1). Når du søger på disse søgeord, så returnerer Google en lang række opskrifter fra en masse forskellige websites.

Læg også mærke til i ovenstående screenshot, at Google viser søgeresultatet anderledes, end hvis det blot var et almindeligt søgeresultat. Brugeren får væsentligt flere informationer end normalt – man kan eksempelvis se en liste med ingredienser, hvor lang tid retten tager at lave, man kan se andre brugeres anmeldelser af retten, og man kan ikke mindst se et billede af retten. Alt i alt hjælper man derfor brugeren til at foretage et bedre valg allerede i Google.

Et lignende eksempel kan ses, hvis du tager din smartphone, og søger på eksempelvis “Frisør”. Google ved, at hvis du står i Vejle, så er du nok interesseret i frisører i Vejle, og ikke i Korsør, og derfor returnerer Google primært resultater fra Vejle.

Hvilken betydning har det for mig?

Der er en vigtig årsag til, at Google er i stand til at præsentere opskrifter på den ovenstående strukturerede facon. Denne årsag er de såkaldte microdata, som er en endnu ikke vedtaget standard, som følger med HTML5. Men at standarden endnu ikke er officielt vedtaget er de tre søgemaskiner altså temmelig ligeglade med!

Microdata er HTML-markup, som beskriver informationerne på en side. Med denne markup kan man eksempelvis beskrive, at en overskrift i virkeligheden er navnet på en person, og at et nummer er et telefonnummer til en bestemt person. Et eksempel på dette kan ses af følgende HTML:

<div itemscope="itemscope" itemtype="http://schema.org/Person">
<div itemprop="jobTitle">
Partner</div>
<div itemprop="name">
Peter Terkildsen
</div>
<div>
<span>Telefon</span><span itemprop="telephone">29479109</span></div>
<div>
<span>Email</span><span itemprop="email">email@email</span></div>
</div>

Læg mærke til de attributter, som er tilføjet til HTML’en: “itemscope”, “itemtype” og “itemprop”. Disse attributter benyttes til at beskrive den information, som følger. I ovenstående HTML fortæller jeg således, at der er tale om en person, og at det er personens navn, jobtitel, telefon og e-mail, som står i teksten.

På den måde kan man beskrive forskellige typer af objekter. Her og nu er der standarder for:

• Kreativ udgivelse (bøger, film, musik)
• Event
• Organisation
• Person
• Lokation
• Produkt
• Anmeldelse

Under de forskellige typer er der forskellige undertyper. Eksempelvis er der på en lokation mulighed for at angive, at der er tale om en turistattraktion. Google, Bing og Yahoo! har lavet en fælles hjemmeside, som beskriver disse nærmere: http://schema.org/docs/gs.html#microdata_itemscope_itemtype

Pointen er, at der er tale om mange forskellige typer, og har du – som ejer af en hjemmeside – information, som kan klassificeres som en af disse typer, så kan du med fordel markere informationen op. Har du eksempelvis et e-handels website, så vil det give rigtig god mening at klassificere produkterne korrekt ved hjælp af semantisk data markup, da Google dermed vil vide, at der er tale om produkter med dertil hørende information. Eksempel fra Googles dokumentation:

<pre><div itemscope itemtype="http://data-vocabulary.org/Product">
  <span itemprop="brand">ACME</span> <span itemprop="name">Executive
    Anvil</span>
  <img itemprop="image" src="anvil_executive.jpg" />

  <span itemprop="description">Sleeker than ACME's Classic Anvil, the
    Executive Anvil is perfect for the business traveler
    looking for something to drop from a height.
  </span>
  Category: <span itemprop="category" content="Hardware > Tools > Anvils">Anvils</span>
  Product #: <span itemprop="identifier" content="mpn:925872">
    925872</span>
  <span itemprop="review" itemscope itemtype="http://data-vocabulary.org/Review-aggregate">
    <span itemprop="rating">4.4</span> stars, based on <span itemprop="count">89
      </span> reviews
  </span>

  <span itemprop="offerDetails" itemscope itemtype="http://data-vocabulary.org/Offer">
    Regular price: $179.99
    <meta itemprop="currency" content="USD" />
    $<span itemprop="price">119.99</span>
    (Sale ends <time itemprop="priceValidUntil" datetime="2010-11-05">
      5 November!</time>)
    Available from: <span itemprop="seller">Executive Objects</span>
    Condition: <span itemprop="condition" content="used">Previously owned,
      in excellent condition</span>
    <span itemprop="availability" content="in_stock">In stock! Order now!</span>
  </span>
</div></pre>

Med ovenstående markup vil du sikre dig, at Google får præcis information om dit produkt. Google (og de andre søgemaskiner) vil lære væsentlige detaljer såsom navnet, anmeldelser, priser, lagerbeholdning og meget andet. Det vil ikke give dig en bedre placering i Google, men det vil give brugeren af Google væsentlig flere informationer, og dermed kan du måske lokke flere brugere ind på websitet.

Ovenstående er et screenshot, som er taget fra www.google.com ved en søgning efter en Iphone. Funktionen er endnu ikke kommet til Danmark, så vi må nøjes med at se fremtiden i USA. Som du kan se fra ovenstående, så bliver produkterne præsenteret allerede i søgeresultatet med billede, produktkategori, pris og anmeldelser, og Google har bygget en decideret prissammenligningsfunktion, så man hurtigt kan finde frem til billigste produkt. Læg også mærke til de mange muligheder, der er for at filtrere søgeresultatet i venstre side.

Så hvis man skal prøve at summere op, hvorfor dette er interessant for dig, som ejer af en hjemmeside, så er der følgende argumenter:

• Dine informationer bliver præsenteret væsentligt pænere i Google. Har du produktoplysninger vil disse oplysninger kunne blive præsenteret allerede i søgeresultatet.
• I dag har semantisk data markup ingen betydning for placeringen i Google. Men man kan sagtens forestille sig, at det får en betydning i den nærmeste fremtid. Det handler derfor om at gøre sig klar til fremtiden.
• Hvis du anvender Bleau Google Site Search på din egen hjemmeside, så vil du kunne præsentere informationer på samme vis, som Google gør det, og dermed skabe et endnu bedre søgeresultat.

Hvordan gør jeg?

Det lyder enormt bøvlet, at man skal indsætte diverse HTML-kode for at få dette vil at virke. Men hvis du har dine data i en database eller i et CMS, så behøver det slet ikke at være besværligt. I så tilfælde er det blot at bede en udvikler om at tilføje HTML‘en til den HTML, der allerede er lavet.  I Bleau har vi lavet de nødvendige rettelser til vores telefonbogsmodul, så alle medarbejdere tagges korrekt op, og vi laver snarest en rettelse til Dynamicweb eCommerce, så også produkter bliver gjort tilgængelige. Man kunne hurtigt gøre det samme med eksempelvis Dynamicwebs kalendermodul.

Man kan håbe på, at de enkelte CMS-producenter snarest tager dette til sig, og bygger det ind over alt i deres produkter. Jeg ved, at Drupal allerede er på vej – men hvad med Sitecore, Umbraco og Dynamicweb?

Indtil det sker, så er det dog temmelig let at implementere, så det er bare om at komme i gang!

Links

Hvis du vil vide mere, så er der her et par links:

• Schema.org (http://schema.org) – de tre søgemaskiners fælles hjemmeside, som indeholder en masse dokumentation
• Googles Rich Snippets tool (http://www.google.com/webmasters/tools/richsnippets) – et Google-tool, som kan teste de informationer, som du har tilføjet til din HTML
• Google og microdata (http://www.google.com/support/webmasters/bin/topic.py?topic=21997) – dokumentation til hvordan Google anvender Microdata

Men ofte bliver andre funktioner ikke testet så omfattende, og resultatet er, at man kan overse problemer, som kan skyldes mange andre ting. Konsekvensen kan være, at man lancerer et website, som har en række grundlæggende problemer i forhold til performance. Måske opdager man disse problemer – måske ikke. Og selv hvis man opdager, at der er noget galt, så kan man stå i den situation, at man har svært ved at se, hvor det går galt. Måske er det kun i visse browsere, at man har problemet? Måske er det kun visse brugere?

Ny funktion i Google Analytics: Site speed

Derfor har Google nu lanceret en ny feature i deres Google Analytics. Denne feature kalder de for ‘Site Speed’, og den er genial, fordi den løbende overvåger websitet. Kort fortalt gør funktionen det, at den laver en række stikprøvemålinger, hvor en sides samlede loadtid registreres.

Et eksempel kan ses i ovenstående skærmbillede, som viser en top 10 over de sider, som performer dårligst. Yderst til venstre i listen vil man normalt kunne se sidens navn – det er ikke taget med i dette skærmbillede, da det ville kunne afsløre kunden.

Tallene viser, at den side, som performer dårligst, har en gennemsnitlig loadtid på 6,79 sekunder. Denne side har haft 8.809 sidevisninger, så i forhold til de øvrige sider, så er dette en ret vigtig side, da den bliver forespurgt ofte. Der kan derfor være rigtig god mening i at optimere denne side.

Yderst til højre ses ‘Page Load Sample’, som viser hvor mange stikprøver, der er foretaget af de enkelte sider. Site Speed funktionen har kun været i brug ganske få dage, og derfor er tallene i dette tilfælde temmelig lave. Det betyder naturligvis, at disse tal kan nå at ændre sig ganske meget.

Kombinationer af data

Google Analytics opsamler allerede en forfærdelig masse data om brugernes adfærd på websitet. Det interessante i denne forbindelse er, at man kan kombinere disse data med data om sidernes loadtid.

I ovenstående skærmbillede har jeg kombineret site speed data med oplysninger om brugernes browsere. Sjovt nok er de første 9 på listen sider, der er blevet besøgt af brugere med Internet Explorer….

Man kan gå endnu dybere i dette skærmbillede ved at vælge at kigge på specifikke browserversioner.

Bounce rate

Man må formode, at der kan være en god sammenhæng imellem en side, som loader langsomt, og en høj bounce rate. Derfor viser Google Analytics også en sides bounce rate ud for de enkelte sider. Fordelen ved denne metode er, at man som ejer af en hjemmeside hurtigt kan se om der er behov for at arbejde med performance. Det vil sige, at man på denne måde kan prioritere sin indsats. En side med mange besøg, elendig loadtid og en høj bounce rate er vigtigere at få optimeret end en side med få besøgende og en lav bounce rate.

Mangler

I min verden er Site Speed en meget værdifuld funktion, som alle, der driver en hjemmeside, bør interessere sig rigtig meget for. Der er dog et par ting, som kunne gøre funktionen endnu mere interessant. Måske er det blot fordi, at jeg endnu ikke har fundet ud af, hvordan man finder disse data?

Det kunne eksempelvis være rigtig interessant at kombinere den gennemsnitlige loadtid med data om antal besøgende. På den måde ville jeg kunne se om en side begynder at performe dårligere, efterhånden som der kommer flere besøgende på siden. Er der en flaskehals et sted?

Implementering

Det er meget nemt at implementere funktionen. Hvis man allerede har Google Analytics til at køre på sit website, så kræver det blot, at følgende bliver tilføjet til den eksisterende tracking code:

_trackPageLoadTime();

Hvis du ønsker at læse mere om, hvordan funktionen implementeres, så er der hjælp at hente her: http://www.google.com/support/analyticshelp/bin/answer.py?hl=en&answer=1205784&topic=1120718&utm_source=gablog&utm_medium=blog&utm_campaign=newga-blog&utm_content=sitespeed.