Steven Aneel Hasz-Singhs slides fra Digicures web performance seminar på Bella Sky, 24. oktober 2012. Steven er stifter og teknisk direktør i webudviklingshuset Codehouse. Her har han gennem en lang årrække været i tæt kontakt med problemstillinger relateret til performanceoptimeringer for større danske forbrugerorienterede virksomheder. I takt med at verden bliver mere global og mange mennesker har adgang til internettet, i alle deres vågne timer, bliver det tilsvarende vigtigt, at virksomheder har fokus på at levere deres indhold effektivt til deres målgruppe. Hvad betyder det for udviklingsprocessen og hvordan skal man prioritere i det daglige arbejde med ens webløsninger? Det er hvad Steven vil fokusere på i dette oplæg.

1. God performance =
God prioritering
København – 24. oktober 2012

2. Hvem er jeg?
• Codehouse
– Stiftet i 2000
– 40 medarbejdere i København
– Specialister i webudvikling baseret på Microsoft-teknologi
– Stor fokus på globalt orienterede virksomheder
• Mig
– Teknisk direktør og stifter af Codehouse
– Arbejder med større danske virksomheder såsom LEGO,
BESTSELLER, PANDORA og Widex

3. Agenda
• Hvad er god performance?
• Frontendudvikling
• Optimering
• Serviceudvikling
• Hosting
• SEO
• Værktøjer
• Spørgsmål

4. Hvad er god performance?
Hvad lægger du vægt, på når du får implementeret nye features til
dine websites?
• Flot design som følger organisationens visuelle identitet i et bredt udvalg af
browsere?
• Flydende animationer som gør indholdet indbydende?
• Features som kan tilfredsstille ”alle” interne interessenter?
Er dine opdrag til leverandører som beskrevet ovenfor primært
baseret på dine behov til features og hvordan de skal designes?

5. Hvad er god performance?
HUSK
Design, animationer og smarte features kan være lige meget hvis…
• …brugeren ikke kan finde dit indhold
• …dine features ikke fungerer på brugerens enhed
• …dit website er langsommere end brugeren gider vente på
Honorerer dit opdrag til leverandører…
• …fremsøgeligt indhold
• …håndtering af diverse enheder
• …korte svartider
God performance kræver
god informationsarkitektur
og gennemtænkt design!

6. Hvad er god performance?
Det er vigtigt, at du kender dine brugere
• Hvor er de geografisk?
– Er alle dine brugere i én region?
– …eller er dine brugere i hele verden?
– …eller primært i en region såsom Europa eller Kina?
• Hvilke enheder forbinder de med?
– Anvender dine bruger desktop?
– …eller tablets?
– …eller touch phones?
– …eller alle tre?
• Hvad er deres opkobling?
– Forbinder de med modem?
– …eller bredbånd?
– …eller 3G?
– …eller edge?

7. God analyse = God prioritering
• God performance kan ikke opnås uden grundig analyse
• God performance er altid en afvejning mellem
– Visuelle ønsker og behov
– Organisatoriske krav
– Brugernes krav
Teknik kan ikke levere god performance alene

8. Hvad er det, der går galt?
• Forstår du hvordan internettet fungerer?
• En bruger åbner sin browser
– Hvilke features understøtter den?
– Hvor hurtig er den, og hvor hurtig er brugerens processor?
– Hvor mange forbindelser kan den åbne ad gangen?
• Brugeren indtaster en URL og går til siden
– Hvor hurtig er brugerens internetforbindelse?
– Brugeren skal først slå dit domæne op for at få din servers adresse
– Din server svarer tilbage med den ”HTML” du vil vise brugeren
• Browseren viser dit indhold for brugeren
– Når browseren har hentet HTML til din side er det kun starten…
– Hvilke billeder er der på din side? Hvor hentes de fra? Er de optimeret til web?
– Hvilke fonte bliver der brugt? Er det websafe fonte? Hvor bliver de hentet fra?
– Hvilke javascript og css ressourcer bruger du? Hvor bliver de hentet fra?
Størrelsen per side er globalt set vokset fra 838kb til 1227kb fra
1/10-2011 til 1/10-2012 fordelt på 80-85 ressourcer

9. Frontendudvikling
• Hvilke browsere / styresystemer skal du understøtte?
– Desktop: IE / Chrome / Firefox / Safari
– Mobile: Safari / Chrome / Opera Mini
– Tablet: Safari / Chrome / Opera Mini
• Hvad skal du tænke over, når du udvikler til enhederne?
– Desktop: Skærmopløsning
– Mobile: Touch Device, edge netværk, skærmopløsning og processor
– Tablet: Touch Device, edge netværk, skærmopløsning og processor
• Har du en strategi for, hvordan du håndterer Mobile og Tablet?
– Mobile Sites / Responsive Design / Responsive + Server Side (RESS)
Husk at undersøge hvad dine brugere anvender!
Generel statistik er ofte misvisende og irrelevant
for din kontekst

10. Frontendudvikling
• HTML og CSS
– Overhold standarder og minimer inline styling
• Fonte
– 1/10 2011 havde 6% af alle sider custom fonte
– 1/10 2012 havde 12% af alle sider custom fonte
• Flash
– 1/10 2011 havde 48% af alle sider flash
– 1/10 2012 havde 37% af alle sider flash
• CSS og Javascript
– Flash er ofte unødvendigt – brug CSS og Javascript

11. Udvikling - optimering
• Gzip
– Husk altid at tjekke om din løsning understøtter gzip – spar
50% trafik!

12. Udvikling - optimering
• Slå CSS og Javascript sammen til færre filer
– Fra 17 requests
– Til 3 requests

13. Udvikling - optimering
• Brug minifiers – gør indholdet mindre
– Mellemrum, linjeskift og andet ligegyldigt for brugeren fylder
også!

14. Udvikling - optimering
• Brug sprites
– Fra 5 requests
– Til 1 request
• I mange tilfælde kan det optimere langt mere såsom 50
requests til 3

15. Udvikling - optimering
• Optimér dine billeder
– Upload billedet i et passende format til web
– Upload billedet i en størrelse du gerne vil bruge på nettet
– Optimér dit billede til web (farvedybde mv.)
– Billeder optimeret typisk 50% mindre end det billede designeren eller
fotografen har produceret – nogle gange endda 90% mindre
• Lad være med at indlæse billeder, brugeren alligevel ikke kan se
til at starte med
– Indlæs billeder dynamisk med javascript

16. Udvikling – services
• Antagelser:
– En side tager 3 sekunder at vise
– En simpel operation som brugeren skal gennemføre på siden tager 500ms
• Spørgsmål:
– Hvorfor skal brugeren vente på at hele siden bliver hentet igen hvis det kunne
gøres på 1/6 af tiden?
• Overvejelser:
– Kan dine services implementeres med Javascript og RESTfull services?
• Eksempel:
– En bruger henter en liste af produkter – det tager 3 sekunder
– En bruger klikker på det ene produkt for at lægge det i sin kurv
– Denne hændelse sker med jQuery og REST og tager 300ms
– Når operationen er gennemført opdateres kurven på siden med jQuery

17. Udvikling – services
• Antagelser:
– En side tager 3 sekunder at vise
– En (for brugeren) simpel operation skal gennemføres men tager 15 sekunder fordi serveren
skal behandle komplekse data eller kæmpe datamængder
• Spørgsmål:
– Hvorfor skal brugeren vente bare fordi dit system har mange data?
– Hvis operationen er kompleks, går det ud over andre brugere imens?
• Overvejelser:
– Kan du adskille ”læse” og ”skrive” operationer?
– Er det vigtigt for brugeren at vente på at operationen er 100% gennemført?
• Eksempel på CQRS*:
– En bruger klikker på ”Like”
– Facebooks cache opdateres og den opdaterede status vises
– Senere skrives data i Facebooks persistente databaser
* CQRS = Command Query Responsibility Segregation

18. Optimering = God prioritering
• God performance kan ikke opnås uden at:
– Begrænse antallet af forbindelser browseren skal lave
– Begrænse antallet af domæner browseren skal forbinde til
– Begrænse mængden af data der sendes til browseren
– Optimere billeder
• De bedste resultater opnås ved at:
– Kende sin målgruppe og målrette sin indsats mod dem
– Have principper og retningslinjer for hvordan man optimerer
– Overholde standarder
En optimeret løsning ødelægges
MEGET nemt
af indhold der ikke er optimeret

19. Hosting
Hvor hurtigt loader dine brugere en side?
• Et eksempel
– En bruger har 5mbit forbindelse
– 5mbit svarer til 625 kb/s
– Det svarer til at det med optimale download-forhold tager 2 sekunder at
downloade indholdet til at vise gennemsnitlig side på 1.250 kb
– Hvis man dertil lægger DNS-opslag, Connection tid og TTFB (Time to first
Byte) bliver tallet hurtigt højere… Dette tal er i så fald nærmere 3-5
sekunder
• Jo mindre homogen din brugergruppe er, jo mere sløret bliver
ovenstående
– Kan du antage så høj forbindelse?
– Hvis de sidder rundt om i hele verden vil connection tid og TTFB blive højere

20. Hosting
• To vigtige spørgsmål
– Hvor er dine brugere henne i verden?
– Hvornår anvender dine brugere dit website?
• Webfarms
– Dedikerede miljøer med fuld kontrol
– Brugere kan sagtens fordeles ud på flere webfarms baseret på Geo DNS
• Cloud
– Applikationsdrift i et delt center
– Skalerer efter behov
– Gode faciliteter til failover mv.
• Content Delivery Networks
– Høj performance på levering af indhold
– Massive netværk med ”edge”-servere på mange geografiske lokationer

21. SEO
Hvor meget af din trafik på dit website er genereret af søgning?
• For nye websites er det op imod 70-80% af trafikken der er drevet af søgninger
• For etablerede sites er det ofte mindre, men stadig over 30%
• Heraf står Google for 90% på verdensplan
Derfor er det vigtigt at du overvejer følgende:
• Google prioriterer performance…
Ingen brugere gider anvende et langsomt website
• Google prioriterer også efter princippet ”Mobile First”…
Den massive vækst i mobile enheder kræver fokus

22. Værktøjer
• Der findes mange værktøjer, som kan give et indblik i dit
websites performance
• Test dit site løbende… Mange gange og på mange sider!
• Sammenlign med andre sites… Man kan ofte lære af andre!
• Brug f.eks. Yslow løbende under udviklingsprocessen for at følge med i om
løsningen er implementeret i overensstemmelse med jeres principper og guides
• Brug f.eks. webpagetest.org til at simulere, hvordan websitet føles for brugere
rundt om i verden på forskellige internetforbindelser i forskellige browsere
Ligesom du tester layout og funktionalitet,
er det vigtigt at du gennemgår,
hvordan løsningen er optimeret

23. God performance =
God prioritering
• Hvis du ikke prioriterer performance, kan du ligeså godt lade
være med at lave et website
• Dine brugere kan ikke finde dit indhold og gider ikke vente på et
langsomt site alligevel
• God performance kræver god IA og gennemtænkt design og et
konstant fokus på at producere ordentligt indhold
• Overvej
– Dit valg (og fravalg) af frontendteknologier såsom Flash / fonte mv.
– Minimering af ressourcer (CSS / Javascript og designbilleder)
– Hvordan skal dine services implementeres
– Hvordan skal din løsning hostes og gøres tilgængelig for brugerne
HELD OG LYKKE

24. Spørgsmål?
Codehouse A/S | Amerikavej 15 B | 1756 København V
Tlf. (+45) 70 25 75 25 | info@codehouse.com | www.codehouse.com

25. Links
• Statistik og baggrund
– http://httparchive.org
– http://www.fdim.dk
– http://www.w3schools.com/browsers/browsers_stats.asp
– http://googlewebmastercentral.blogspot.dk/2010/04/using-site-speed-in-
web-search-ranking.html
• Optimering
– http://combres.codeplex.com
– http://getcassette.net
– http://www.websiteoptimization.com/speed/tweak/css-sprites/
• Værktøjer
– http://www.webpagetest.org
– https://addons.mozilla.org/en-US/firefox/addon/yslow/
– http://code.google.com/intl/da-DK/speed/page-speed/

26. Kontakt
• Steven Singh, Teknisk direktør (CTO)
– ssi@codehouse.com
– Mobil: +45 2612 5919
• Bjarne Riis, Administrerende direktør (CEO)
– bri@codehouse.com
– Mobil: +45 2619 1701

27. Codehouse A/S | Amerikavej 15 C, 2. | DK-1756 København K | Tlf. (+45) 70 25 75 25 | info@codehouse.dk | www.codehouse.dk