Webbanalysdagen - Webbanalys: Optimera prestanda

2. Webbanalys… Slösa inte med användarens tid och energi Agenda ≈ 25 minuter • Varför prestanda är viktigt • Hur presterar ”alla” andra? Statistik från 100 webbar ≈ 13k undersidor • Om att jobba med en stilguide + prestandabudget • Att välja en lämplig nivå • Tips på verktyg • Frågor + 5 minuter Presentation, data och referenser finns på tba.nu/wdpres WEBBANALYS: OPTIMERA PRESTANDA

3. Om Marcus Österberg • Jobbar med strategisk rådgivning, särskilt webbanalys och webbstrategi. • Författare av boken Webbstrategi för alla (tba.nu/wfa), kapitel om intranätanalys i bok om intranät (tba.nu/intranatboken). • Anställd hos Västra Götalandsregionen, bland: 1.6m invånare 50k kollegor ≈ 2/3 jobbar med vård ≈ 1/3 kollektivtrafik, kultur, etc. WEBBANALYS: OPTIMERA PRESTANDA

4. WEBBANALYS: OPTIMERA PRESTANDA Spelar prestandan någon roll? • Google: 2% långsammare = 2% färre sökningar/user • Yahoo: 400 millisekunder snabbare = 9% mer trafik • AOL: Snabbare sidor = fler sidvisningar • Amazon: 0,1 sekunder snabbare = 1% mer omsättning • Shopzilla: 5 sekunder snabbare = 25% fler sidvisningar, 7 till 12% mer omsättning • Aberdeen Group: 1 sekund långsammare = 11% färre sidvisningar, 7% färre konverteringar Kolla in referenserna på tba.nu/wdref

5. WEBBANALYS: OPTIMERA PRESTANDA Web analytics is like teenage sex • Everyone talks about it. • Nobody really knows how to do it. • Everyone thinks everyone else is doing it, so everyone claims they are doing it.

6. WEBBANALYS: OPTIMERA PRESTANDA Målsättningar (1 av 2) • Stilguide - dokumentera kommunikation i stort - Bädda in tredjepartstjänster som äventyrar besökarens integritet? - Längd på sidtitlar, får de plats i sökmotorns resultatsidor? - Ska bilder visas i retina-upplösning, eller blir det trögt? - Visa utsmyckande bilder, eller ej? - När använda tabeller? - Meta-description ska finnas på alla viktiga sidor? - Ingen call-to-action = oviktig sida? • Prestandabudget (kommer på nästa bild)

7. WEBBANALYS: OPTIMERA PRESTANDA Målsättningar? (2 av 2) • Prestandabudget – ”teknisk” ambition - Tillgänglighet minst WCAG 2.0 nivå AA. - Tid för sidladdning vid gynnsamma omständigheter under 1 sekund, men under 10 sekunder i eländig glesbygd. - Anses vara mobilvänliga. - Minst betyg 85 av 100 i Google Pagespeed mobilt. - Under 399 Kb för en sidvisning, varav 140 Kb reserverat för redaktörens bidrag. - Strukturell CSS-kod för snabb initial visning av sidan. - Max 2 CSS-filer, max 3 Javascript-filer. - Ge ut strukturerat innehåll, bl.a via Schema.org för god SEO

8. WEBBANALYS: OPTIMERA PRESTANDA En genomsnittlig webbsida (är tung!!) • Totalt 2,4 Mb att ladda ner, varav: - 675 Kb bilder - 1545 Kb Javascript & CSS • Sidladdningstid: - På dator på kontoret ≈ 1-3 sekunder - Mobilen, på 3G/Edge-nätet i svampskogen ≈ några minuter • Pagespeedbetyg: 58 av 100 • Användbarhetsbetyg: 95 av 100

9. WEBBANALYS: OPTIMERA PRESTANDA Google designar om Google+ ”We hit our goal of never downloading more than 60k of HTML, 60k of JavaScript and 60k of CSS at any one time!” - Googles Developer sidor, tba.nu/wagplus Startsidan före: Efter: 22,6 Mb startsida med bilder 0,3 Mb 251 st filer 45 st 2,8 Mb Javascript/CSS 0,1 Mb 12 sekunder laddtid 3 sekunder

10. WEBBANALYS: OPTIMERA PRESTANDA Förbättringspotential (enligt Google) 1. Javascript/CSS-filer blockerar sidvisning = 41.5 2. Använda webbläsarens cache = 15.2 3. Aktivera komprimering av textfiler = 13.5 4. Optimera bilder = 12.9 5. Långsam svarstid på webbservern = 3.9 6. Prioritera synligt innehåll = 3.3 7. Större klickytor = 2.9 8. Inte läsbar textstorlek = 2.3 Hämta datakällan? tba.nu/wddata

11. WEBBANALYS: OPTIMERA PRESTANDA I redskapsboden • Google Pagespeed (gärna automatiserat via APIet) • Google Structured Data Tool • Google Search Console (fd Webmaster Tools) • Egen sökmotor? Indexanalys! • Pingdom – mäter webbplatsens svarstider • Tableau Public – för att utforska loggar och CSV-filer • ELK-stacken - för logganalys (Elasticsearch Logstash Kibana) Min källkod för jobb mot Google Pagespeed API? tba.nu/wdgithub

12. WEBBANALYS: OPTIMERA PRESTANDA Gå all-in i webbprestanda & användbarhet?

13. WEBBANALYS: OPTIMERA PRESTANDA Tack för mig! • Frågor? Jag finns här under dagen! • Presentationen + data finns på tba.nu/wdpres • Ladda ner boken Webbstrategi för alla med 50% rabatt: ange kod wadagen vid köp på tba.nu/wadagen

Editor's Notes

Krångel? Pröva att köra utan mirroring, samt dra över presentationen till projektorn, starta bildspelet där och klicka på knappen "Swap Displays" här ovan. 17,5 minuter vid läsning innantill… xx min i “trött” tillstånd... Har 25 min + 5 min för frågor?
Jag tänkte prata om webbprestanda, hur man dokumenterar sin lägsta-nivå, eller kanske kan man kalla det för sin egen webbstandard. Många av oss har troligen ganska ofta tveksamma upplevelser på webben, det kan vara att det är bedrövligt långsamt, man hamnar vid upprepade tillfällen på felsidor, med mera. Den här presentationen är dels ett brandtal för att göra bättre ifrån sig på webben, men också ett försök att visa på att det är lönsamt. Ska man sätta en lägstanivå, alltså en prestandabudget, är det logiskt att göra det baserat på fakta snarare än magkänsla. Som exempel på hur man kan samla på sig fakta har jag har samlat in statistik från IDGs årliga topp-100-lista med webbplatser, där jag alltså analyserat 13 000 undersidor på dessa 100 webbplatser. Där finns siffror om hur omvärlden presterar vilket kan vara ett stöd för vilken nivå man väljer för sin egen webbplats. >> Först kort om mig >> http://internetworld.idg.se/2.1006/1.614566/topp100-2015--har-ar-sveriges-100-basta-sajter Svenskt näringslivCancerfondenSocialdemokraternaMiljöpartietScouterna Turism FotografiskaSTFGoteborg.comLisebergNordiska museet Söksajter HittaEniroBooliHittahemHemnet Matsajter Recept.nuIcaMathemTastelineMatklubben Prisjämförelsesajter CompricerFlygresor.sePrisjaktReseguidenSpara.se Livsstil MazilyFreerideByggahus.seVätternrundanLaget.se Utbildning Mattecentrum.seStudera.nuUppsala universitetHögskolan DalarnaHandelshögskolan Resor SJSkistarKilroyFritidsresorVing Bank och försäkring ICA-BankenIfIkano BankSEBTrygg-Hansa Träning och hälsa 1177FunbeatSatsUmoLifesum Tidskrifter ChefMamaNöjesguidenDagens SamhällePolitism Underhållning MagineReadlySpotifyStorytelSVTSveriges RadioTV 4URViaplayAcast Myndigheter Patent- och registreringsverketKronofogdenFörsvarsmaktenKriminalvårdenStatens Fastighetsverk Kommuner NorrtäljeStockholmMalmöVärmdöKarlstad Hederspriser BlocketBokavard.seTradera.seLeovegasMrgreenSkjutsgruppenNobelprize.orgPappasappar.seTvdags.seMoviezine Nyheter SvdAftonbladetNyheter24ExpressenOmni E-handel CalirootsHalensNellyEllosRidestoreAdlibrisJunkyardNordic design collectiveBygghemmaSportamore
Jag jobbar som evangelist inom webbanalys och sök – för Västra Götalandsregionen (VGR, alltså). Jag representerar verksamheten gentemot vår IT-organisation och kravställer också våra konsulter. Jag jobbar ibland även vid behov som vår represent med nationella tjänster som 1177.se och Mina Vårdkontakter. Mer eller mindre alla av regionens 1,6 miljoner invånare är I vår tilltänkta målgrupp, på någon av det hundratal webbplatser vi har. Överlägset mest besökt är regionens del av vårdsajten 1177.se - där har vi drygt en miljon besök per månad. (60% på mobil enhet, 30% på skrivbordsdator, 10% med surfplatta) Övriga webbplatser handlar om samhällsinformation, enskilda sjukhus, våra skolor, museer, med mera. >> Det gör av uppenbar anledning webbanalys-arbetet svårare - att precis alla är I tilltänkt målgrupp. Först nu har vi fokuserat på värderingar, kommunikativ stil och hur webbarna ska prestera I stort, men också börjat knyta an mot verksamhetens mål >>
Allt fler pratar om prestanda som i vilken hastighet ens webbplats ska ha när den laddas ner. Att en snabbare webbplats är en bra affär har bland annat följande organisationer undersökt. Varför bry sig och prestanda och användarens upplevelse? Det är inte bara logiskt, det är bra service och ekonomiskt försvarbart. Om någon redan är på din webbplats men inte klarar av att slutföra ett mål kan du ha en oerhörd förbättringspotential, om dom är många nog. Vet du hur många de är? Många har nog inte definierat anti-mål, eller ett användarsegment över när man misslyckas å det grövsta. Att jaga in användare till sin webbplats kostar pengar och energi, något som är bortkastat om du inte har kvalitetskontroll kring användbarheten… Det finns faktiskt ganska gott om data som visar på att webbprestanda spelar roll, ur flera perspektiv. Det borde finnas något för de flesta. I och med att Google har med webbprestanda i sin rankningsalgoritm, så för en sökmotoroptimerare är detta något att tänka på. Har man, som vi I offentlig sektor, eller de av er som jobbar med intranät, inte ett uppenbart ekonomiskt incitament så finns fortfarande saker att hänvisa till. Bland annat att forskning visar på att man orsakar en funktionsnedsättning hos vem som helst genom en långsam upplevelse. Detta konstaterade man redan 1968. Behöver man hänvisa till en auktoritet, eller exakta siffror, så kom användbarhetsgurun Jakob Nielsen för drygt 20 år sedan fram till tre magiska tidpunkter I utbytet mellan en användare och det denne försöker interagera med, nämligen att vid: 0,1 sekunds svarstid så känns utbytet som om det är omedelbart. (Detta är tydligen Googles interna mål om man ska tro deras prestandaprofet Ilya Grigorik). Efter 1 sekund börjar tankarna vandra och man har orsakat en kognitiv funktionsnedsättning hos användaren. Efter 10 sekunder börjar användaren vilja göra något annat under tiden och koncentrationen är som bortblåst. Denna vinkel av webbanalys kanske ligger I utkanten av vad man normalt sett anser ingår I begreppet, jag tolkar dock webbanalys som all form av uppföljning kring ens webbkommunikation. >> Sen kan man ju fråga sig vad webbanalys egentligen är, och inte är >>
Att webbanalys är lite som tonåringars förhållningssätt till sex ligger det nog mer I än många av oss vill medge, särskilt på anställningsintervjun, utvecklingssamtalet med chefen, och så vidare. “Kan du webbanalys? “Ja, föffan!” Den här presentationen kanske kommer ta upp nya vinklar på vad webbanalys handlar om, jag råkar nämligen också vara webbutvecklare. Då har man en viss sorts verktyg och förkunskaper till förfogande. I webbens forntid kravställdes webbplatsers gränssnitt med vilken version av webbläsare man som sämst skulle stödja, typ internet explorer 6. Ofta hade man en lägsta skärmupplösning också, exempelvis som lägst 980 bildpunkter i bredd. Idag kan, och bör, man ställa lite fler krav än så, dessutom göra dem möjliga att följa upp. Jag kommer snart gå in på att dokumentera sin webbplats prestanda, dess prestation, och hur man analyserar sin webbplats baserat på dessa krav - sin egna "webbstandard". För de flesta på denna konferens lär inte det här med målsättning komma som någon nyhet i samband med webbanalys. För oss i offentlig sektor är det dock ofta svårt att sätta mätbara mål. Om det beror på att vi inte vet varför vi har en närvaro på webben låter jag vara osagt, men ni vet nog vad jag tänker :) >> Appropå målsättning har vi på min arbetsplats börjat med detta redan vid designarbetet, så det inte blir en obehaglig överraskning när designen är klar >>
Just på grund av denna frånvaro av ekonomiska incitament har vi kanske lättare att skilja på halvbra mål från halvdåliga. Nu i den mobila verkligheten vi lever i, där användarupplevelsen allt mer är en av få faktorer man kan briljera på börjar webbanalysen ha nytta av en användarcentrering. Att förutsättningarna till konvertering ska finnas, om innehållet i sig är bra nog. Det finns ett antal frågor att besvara när man sätter sin ambitionsnivå. Dessvärre finns det två olika begrepp för dokumentationen av denna ambition, lite beroende på vilken yrkesgrupp man tyr sig till. Stilguide är vanligen innehållsproducentens syn på ambitionsnivå, medan prestandabudget är utvecklarens vinkel. Jag tycker själv att prestandabudget är lite av en bilaga till stilguiden. En stilguide innehåller ofta exempel på typografi, design, tilltal med mera, medan prestandabudget ofta fokuserar på mätbara saker som är kvantifierbara, går att analysera och skicka som mätbara krav till leverantörer. Dessa mål kring webbplatsens kvalitet från besökarens synvinkel kan behöva kompletteras allt eftersom. Men börja dokumentera det mest uppenbara åtminstone. Frågeställningar vi på VGR haft nyligen är höstens granskning av integritet inom offentlig sektor, en serie av artiklar Dagens Nyheter körde. Så vi har funderat på om vi någonsin ska ha med tredjeparter på våra webbplatser. Det kan vara mycket mer än utifall man ska ha Google Analytics, det gäller ju även hur webbplatser designas, ifall man använder externa teckensnittstjänster, bäddar i Facebook-flöde, och det som DN pratat om förstås, sociala dela-knappar. Alla dessa externa beroenden till tredjeparter kan göra en webbplats mer komplex, långsam och utsatt för risker – något vi kommer till snart. Sen har ens stil också med användbarhet kring innehållet att göra. Ifall längden på sidtitlar funkar i alla tänkbara sammanhang, hur man ser på responsiv bildhantering och mycket mer. Här börjar man beskriva vad som är en bra sida. Ett A-lag och ett B-lag utkristalliserar sig. På min hemmaplan ska jag villigt erkänna att vi har ett alldeles för stort B-lag, alltså sidor ingen riktigt kan förklara vilken nytta de tillför. >> För att gå över till prestandabudgeten så… >>
Det är alltid värt att poängtera att med prestanda ska man också tänka in prestation i stort, det handlar inte bara om hastighet. Som du kan se på denna lista är det mest kvantifierbara mål, medan några drar åt det kvalitativa, eller rent utav subjektiva mål. Något som är komplicerat att följa upp fullständigt kvantitativt är tillgänglighetskravet. Anledningen till att vi har med den i vår prestandabudget är enkel, vi var tvungna att välja en nivå för att vår efterlevnad till den nya diskrimineringslagen inte skulle vara helt godtycklig på olika delar av våra webbplatser. I regionens nu beslutade prestandabudget har vi ställt det absoluta kravet om att följa tillgänglighetsriktlinjen WCAG 2.0 som minst på nivå AA. Dessutom några mål för hur snabbt det ska gå att ladda ner en sida. Där blev det väl ett plötsligt uppvaknande i designarbetet. Att vår kommande webbplats inte kan slösa hur man vill med utsmyckande element. Vi har satt gränsen vid 399 Kb och då ska redaktören ha åtminstone 140 Kb till att kunna lägga upp en tyngre bild. Självklart ska en webbplats av idag anses vara mobilvänlig. I det finns många saker man behöver mäta, både designen i stort men också det som innehålsskaparna bidrar med. Vi har preciserat detta till att Googles testverktyg ska anse att alla typer av mallar i vårt publiceringsverktyg ska anses vara mobilvänliga, med någon form av exempelinnehåll. Detta är kravet på de som bygger vår webb, men sedan blir det till att följa upp att redaktörerna inte sumpar den upplevelsen genom att lägga in jättebreda tabeller och så vidare. För att vara tydliga mot våra leverantörer så ska vi gemensamt sätta upp testsidor. Dessa testsidor ska ha som minst 85 av 100 i betyg enligt verktyget Google Pagespeed, då med mobila inställningar. För en dator ska det vara minst 90 av 100 i betyg. Vi har också satt begränsning på antalet filer som krävs för att ladda in en sida. Anledningen till detta är för att för varje fil som ska laddas ner finns en väntetid, ju fler filer desto längre blir den totala väntan på att sidan blir färdig. Detta är inte ett särskilt stort problem under gynnsamma förhållanden när vi sitter på kontoret, men det märks verkligen skillnad när man är på en svajig 3G eller Edge-uppkoppling ute i glesbygd. Jag som plockar hur mycket svamp som helst märker detta när jag tar en paus och slösurfar lite, tänk då om man har ett viktigare ärende än att ögna igenom Reddit, typ ta reda på numret till giftinformationscentralen…? Plocka inte dessa siffrorna rakt av för användning på hemmaplan, detta är vår ambition när vi bygger nytt. Jag är inte säker på att det vore en god idé med just dessa krav om vi nöjt oss med en redesign istället. >> Men hur ser då en vanlig webbsida ut idag >>
Jag har som sagt analyserat 100 webbplatser, 13 000 undersidor på dessa webbplatser. Man kan väl lugnt konstatera att våra webbplatser har blivit överviktiga och I behov av att bantas. Det här problemet uppkom nog I och med allas projekt att få sina webbplatser responsiva. Plötsligen la man in massor med stora bilder, men också ha massor med kod (som Javascript och CSS) för hur allt detta ska presenteras. Att man har dubbelt så mycket Javascript och CSS jämfört med bilderna är helt galet. Att beskriva hur något ska se ut och bete sig är inte så jäkla komplicerat, antagligen har ens utvecklare har tagit på tok för många genvägar. Det som inte tycks vara ett prestandaproblem när vi sitter på kontoret märks desto tydligare när man använder sin mobiltelefon och inte står strax bredvid en 4G-mast. Många gånger tar det flera minuter att ladda hem en webbsida, och ibland fungerar det inte alls för något går snett under all den väntan. Det skapar inte förutsättning till varken lyckliga kunder eller måluppfyllelse. (Den mätningen som är på bilden är hur snabb uppkoppling jag hade hela förra semestern, det I ett samhälle där det bor 350 personer. Nedladdningshastigheten är alltså sämre än de modem vi använde I slutet på 90-talet, och idag är sajterna mångdubbelt tyngre.) Ett simpelt räkneexempel baserat bara på svarstiden jag hade, 1,2 sekunder per fil - en genomsnittlig webbsida I min undersökning har 77 filer. Det blir drygt 1,5 minut, och då har jag inte räknat med att innehållet ska skickas – bara väntan på att filerna ska börja skickas. Som jag nämnde har vi I vår prestandabudget satt 85 av 100 som lägstanivå. Snittet på dessa 13 000 sidor var endast 58 av 100. Vi har tänkt oss ha 100 av 100 möjliga I användbarhet, vilket tydligen är strax högre än genomsnittet på dessa webbplatser. >> De flesta av oss har anledning att bättra oss >> Usability 95 av 100 Pagespeed 58 av 100 (med mobila utgångsvinkel) All data (när det gäller textfiler så är det okomprimerad storlek det handlar om): javascriptResponseBytes 1,18 Mb imageResponseBytes 676 Kb cssResponseBytes 365 Kb htmlResponseBytes 170 Kb otherResponseBytes 47 Kb textResponseBytes 35 Kb totalRequestBytes 12 Kb numberResources 77 st filer numberStaticResources 53 st filer/resurser numberJsResources 21.5 st numberHosts 19 värdar numberCssResources 5.2 st filer
Även fast den genomsnittliga webbplatsen blir tyngre och tyngre så bör vår strävan vara att ständigt bli bättre. Google är en organisation som verkligen tar prestanda på allvar, man kan säga att det är en del av deras affärsmodell – om sidor är långsamma för dem att indexera kommer de behöva mer datorkraft för att få jobbet gjort. När de designade om sitt lilla community under förra året satte de upp ett antal ambitiösa prestandamål. Dessa siffror är vi som kollektiv inte är närheten av. Dessutom trimmade Google bort fettet genom att sänka svarstiden från 0,7 sekunder till endast 0,1 sekunder, så kallad time to first byte. Det är alltså tiden det tar för webbservern att tala om att den lever och börja skicka innehåll. ( Google+ gick från att ha haft 22,6 Mb tyngd på sin startsida till 0,3 Mb (kod och bilder). Från 251 filer som behövde laddas ner till endast 45 stycken. 2,8 Mb Javascript och CSS till 0,1 Mb. För laddtider så gick de från 12 sekunder i snitt ner till 3 sekunder ) >> Om man vill kan man få statistiken jag samlat in viktad av allsmäktiga Google efter hur stor förbättringspotentialen är >>
Att kontrollera sin webbplats enligt Googles kriterier kan säkert kallas för sökmotoroptimering, jag själv skulle påstå att det är helt vanlig webbanalys att ha koll på kvaliteten på sina undersidor. Kolla vad som kan förbättras för att prestera bättre. Kör man med jämna mellanrum igenom alla sina sidor, eller kollar nyskapat material, kan man fånga upp misstagen. Vara lite proaktiv. Jag har tagit fram en topplista över möjliga förbättringar, viktat efter genomslag enligt Googles kriterier, för de där 13 000 sidorna. Listan är rätt intressant, något man inte alltid kan räkna med när man gräver. Första punkten, att Javascript och CSS är ivägen för att sidan ska kunna visa upp sig är något man tar tag I vid ombyggnation. Det är ett lite större jobb. Poängen att kolla det redan innan en redesign är att nästa version av sajten väl åtminstone inte ska få vara sämre på den här punkten. Eller hur? Punkt tre, om att aktivera komprimering tar typ en timme att fixa I värsta fall. Så lider ens webbplats av det problemet är det att betrakta som ett riktigt fynd! Hyggligt stor påverkan, slår igenom på hela webbplatsen och kostar nästan inget. Även fast jag gärna gör reklam för version 2 av protokollet HTTP så är det enligt denna viktning inga stora vinster I att växla över till HTTP/2. Men innan man investerar stort I webbprestanda ska man ta en funderare på HTTP/2 eftersom vissa vanliga brister inte behöver åtgärdas I den versionen. Exempelvis, att sprida ut innehåll på flera filer blir plötsligen god praxis från att vara riktigt dålig praxis. >> Nu över till lite exempel på verktyg >> Hela listan: MinimizeRenderBlockingResources-ruleResults 41.508691551003906 LeverageBrowserCaching-ruleResults 15.224571430231762 EnableGzipCompression-ruleResults 13.5004798746804 OptimizeImages-ruleResults 12.898193531868896 MainResourceServerResponseTime-ruleResults 3.880041975474998 PrioritizeVisibleContent-ruleResults 3.268966446570543 SizeTapTargetsAppropriately-ruleResults 2.851602155181083 UseLegibleFontSizes-ruleResults 2.252938574995132 MinifyJavaScript-ruleResults 1.4148223622154399 Saker sajterna är rätt bra på är dock: ConfigureViewport-ruleResults 0.6290048375950241 SizeContentToViewport-ruleResults 0.5000286395300998 MinifyCss-ruleResults 0.32287951758525796 MinifyHTML-ruleResults 0.3058558415307897 AvoidLandingPageRedirects-ruleResults 0.2076539549925886 AvoidPlugins-ruleResults 0.011975032080544578
Utöver uppenbara verktyg som Google Analytics (eller Piwik som vi I VGR använder för att inte läcka känslig information till utomstående) tänkte jag fresta med några mindre vanliga verktyg jag använder för att få koll, mest för att visa på bredden. Många verktyg har så kallade APIer, vilket gör att man kan automatisera sina kontroller på massvis med sidor och slippa göra stickprov. Just Google Pagespeed är basen I de siffror jag grävt fram om de 100 svenska webbplatserna. Många av er är säkert bekanta med RDFa, Schema.org eller mikrodata? Det handlar om att man för bl.a. sökmotorers skull lämnar ut sin information I ett strukturerat format som avslöjar informationens typ och inte enbart är en ostrukturerad textmassa. Används ofta för kontaktuppgifter, kalenderhändelser och recensioner. Har du en egen sökmotor I organisationen finns möjligheten att ha en ganska unik översikt kring ditt innehåll. Det är verkligen inte gratis, men du kan exempelvis vid ett mobile first-projekt få en attgöra-lista med var PDF-filer hotar att sumpa upplevelsen för dina användare. Allt fler webbplattformar tycks få en sökmotor inbyggd. Tänk på vad som finns I ert sökmotor-index, allt det kan vridas och vändas på. Där finns svaret på hur långa sidtitlar ni har, hur unika de är, vilken stavning ni använder. >> Att jobba användarcentrerat med webbanalys handlar mångt och mycket om empati som drivkraft bakom optimerings-ivern >>
Ett sätt att nå insikt och känna empati med sina användare är att utsätta sig för respresentativa användares vardag. Facebook har 2G-tisdagar, alltså man kan välja att ha sin internetuppkoppling begränsad till maxhastigheten för det mobila 2G-nätet en hel arbetsdag. En sådan dag blir det sannerligen färre tunga filer skapade… Vill man gå längre kan man göra som Peter föreslår, ha en hel vecka av insikt I hur andra har det, de med synnedsättning, de som navigerar med tangentbord, är färgblinda, eller endast har en mobil. Vilka av dessa användare tror du kan få en bättre upplevelse på er webbplats? >> Det var alles >>
Ni som är här får förstås halva priset på min bok Webbstrategi för alla. Tack för din tid och tålamod  Tack!

Webbanalysdagen - Webbanalys: Optimera prestanda

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to Webbanalysdagen - Webbanalys: Optimera prestanda

Similar to Webbanalysdagen - Webbanalys: Optimera prestanda (20)

More from Marcus Österberg

More from Marcus Österberg (17)

Webbanalysdagen - Webbanalys: Optimera prestanda

Editor's Notes