Digicure seminar i Jylland | Session 1, web performance monitorering

God performance
er god kundeservice
7. maj 2014
Session 1 – ”Kom godt fra start”
Tobias Borg Petersen,
Performancekonsulent fra Digicure A/S
www.digicure.dk

Hvem er jeg
Tobias Borg Petersen
2
@_tobibp
tbp@digicure.dk
Webperformance.nu/blog
Performancekonsulent i Digicure
Front End udvikler (.NET)
dk.linkedin.com/in/tobiasbp

www.digicure.dk
3
• Stiftet i 2003
• Kontor i Lyngby
• 22 medarbejdere
• Beskæftiger os med analyse og rådgivning
• It-sikkerhed
• Web performance
• It-sikkerhedsuddannelser
• CISSP
• CEH – Ethical hacker
• CVSE – Vmware Hacking / Advanced Security

Agenda
Tobias Borg Petersen
4
• Morgenmad √
• Velkomst v/ Jesper Helbrandt, direktør Digicure A/S √
• Introduktion til hvorfor web performance er vigtigt
• Opsætning af KPI’er og SLA’er inden for web performance
• Hvor skal man fokusere sine optimeringer? Hvor er
effekten størst?
• Hvilke typer af værktøjer har man behov for?
• God web performance på de mobile enheder. Hvordan?

6
Hvorfor er performance vigtigt?

7
Hvorfor er performance vigtigt?
• Hurtigere, hurtigere og hurtigere
• Internet forbindelser bliver hurtigere
• Computere bliver hurtigere
• Telefonerne bliver hurtigere
• Browserne bliver hurtigere
• Styresystemer bliver hurtigere
• Næsten alt bliver hurtigere
• Og brugerne bliver mere og mere utålmodige

8
Websites bliver langsommere
og langsommere…

9
Danske webshops Danske kommuner
Web performance
Hvordan står det til i dag?
Kilde: http://www.digicure.dk/performance.html

10
Flash
1%
CSS
5%
HTML
3%
JavaScript
20%
Andet
4%Billeder
67%
Flash
2%
CSS
4%
HTML
5%
JavaScript
22%
Andet
3%
Billeder
64%
Web performance
Danske webshops Danske kommuner

11Kilde: http://httparchive.org
International
1.590 KB
400000
800000
1200000
1600000
2000000
Web performance

12Kilde: http://httparchive.org
Web performance
Svartid Tilgængelighed

13
Kommuner
Mar 2013
Webshops
Okt 2013
International
(httparchive.org)
Forespørgsler 62 req. 80 req. 94 req.
Størrelse 991 KB 1.229 KB 1590 KB
Potentiel
Besparelse
(størrelse)
38 % 19 % --
Web performance

15
20 %
.. mindre trafik blot ved at øge svartiden med
500 ms.
Web performance – Hvorfor?
Lavere bruger engagement
Kilde: http://velocityconf.com/velocity2009/public/schedule/detail/8523

16Kilde: http://blog.kissmetrics.com/loading-time/
• 47 % af de adspurgte
brugere forventer at et
website er vist indenfor 2
sekunder
brugere vil forlade et
website der er mere end
3 sekunder om at blive vist
brugere mener at hurtige
sidevisninger er vigtigt for
websites loyalitet

17
• 3 ud af 4 online shoppere
bliver stressede og
irriterede ifm. handel på et
langsomt website
• 1 ud af 5 af dem der før
har forladt en
indkøbskurv, var pga. et
langsomt website
Kilde: http://blog.kissmetrics.com/loading-time/

18
GlassesDirect.co.uk
Kilde: http://blog.tagman.com/2012/03/just-one-second-delay-in-page-load-can-cause-7-
loss-in-customer-conversions/
Økonomiske gevinster

19
• Svartider –50-70 %
• Båndbredde forbrug –43 %
• DB CPU –75 %
• Samtidige brugere +300 %
Kilde: http://www.nccgroup.com/media/19242/seatwave_our_optimisation_story.pdf
Tekniske gevinster

20
Nedetider kan koste dyrt
Nedetider
Kilde: http://venturebeat.com/2013/08/19/amazon-website-down/

21
Søgeoptimering og lange svartider
Search Engine Optimization (SEO)

22
An SEO expert walks into a bar,
bars, pub, tavern, public house,
Irish pub, drinks, beer, alcohol…

23
1.5 seconds == SLOW
Kilde: http://www.qubitproducts.com/wp-content/uploads/2012/04/Site-Speed-
Whitepaper1.pdf

24
‘Google Recommends Mobile Websites Load in
One Second or Less’
Nu også på
mobile websites
Kilde: http://www.cmswire.com/cms/customer-experience/google-recommends-mobile-websites-load-in-
one-second-or-less-022080.php

25
De besøgendes forventninger

26
John Kemeny &
Thomas Kurtz
”We found, that any response time that
averages more than 10 seconds, destroys the
illusion of having one’s own computer”
1960’erne
Kilde: http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-
slow-loading-sites.html?pagewanted=all&_r=0

27
Forrester
Research
2006 = 4 sekunder
2006 og 2009 2009 = 2 sekunder
Kilde: http://www.getelastic.com/performance/
Kilde: http://www.akamai.com/html/about/press/releases/2009/press_091409.html

28Kilde: http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-
slow-loading-sites.html?pagewanted=all&_r=0
Forsinkelse Brugerens reaktion
0 – 100 ms. Instant/øjebklikkelig
100 – 300 ms. En mindre forsinkelse
300 – 1000 ms. Fortsat fokus på opgave
1 sek. + Mental fokus forsvinder
10 sek. + ”Jeg kommer tilbage
senere..” – hvis det sker

29
Højere krav
til performance
2006 = <4 sekunder
2009 = <2 sekunder
2013 = <1 sekund
1960 = <10 sekunder

30
Hvis dit website er længere end
1 sekund om at blive vist,
taber du allerede besøgende nu

31
Performance er en fundamental del af
brugeroplevelsen på websitet!
Brugeroplevelsen
Højere krav
til performance

32
”Facebook sucks!”
• Intuitive navigering
• Timelines elegance
• Svartiden!
Brugeroplevelsen
Højere krav
til performance

33
Performance
is about respect
”Respect your user’s time and they will be
more likely to walk away with a positive
experience.”
Brat Frost
Kilde: http://bradfrostweb.com/blog/post/performance-as-design/

34
Hvordan kommer man godt fra start

35
Fælles
interesse

36
Driftsfolkene:
- Reduceret belastning

37
Marketing og salg:
- Øget aktivitet
på websitet
• Lavere bounce rate
• Øget antal sidevisninger
• Længere besøgstid
• Bedre søgerangering
• Øget konverteringsrater
• Større brugertilfredshed!

38
Økonomi folkene:
- Lavere drift
omkostninger!
• Reduceret båndbreddeforbrug
• Reduceret behov for server kraft
• Reduceret strømforbrug
• Reduceret CO2 udledning

39
Web performance optimering
- Return of Investment (ROI)

40
Du bruger massevis af penge
på din tilstedeværelse på
Internettet
• Website design og udvikling
• Driftsomkostninger
• Marketing
• eCommerce software
Performance optimering
øger ROI for alle punkter!

42
Noget der
kan måles på
KPI’er

43
• Konverteringsrater
• Køb af varer, tilmeldelse til nyhedsbreve
• Sidevisninger
• Antal sidevisninger per minut en bruger genererer
• Besøgstid på website
• Tiden brugerne tilbringer på websitet
• Bounce rate
• Hvor mange brugere hopper fra
• Tilgængelighed
• Nedetider hvor websitet ikke er tilgængeligt
• Svartider
• Hvor hurtigt får brugerne vist sidevisningerne
• Apdex
• En indikation på om der bliver leveret acceptable svartider

44
Svartider
• Time To First Byte, TTFB
• Tiden det tager at forbinde til webserveren
• Time To Render, TTR
• Tiden det tager at vise det første visuelle af websitet
• Document Complete
• Tiden det tager onload() at bliver udført
• Fully Loaded
• Tiden det tager at hente alt indhold på siden
• Requests
• Antallet af forespørgsler som websitet består af
• Pagesize
• Mængden af data som er at finde på websitet

45
Apdex
• Værdi mellem 0,00 – 1,00
• 1,00 er det højst opnåelige
Apdex =
Eksempel:
Tilfredsstillende forespørgsler = <1 sek. Document Complete
Acceptable forespørgsler == 1-2 sek. Document Complete
Uacceptable forespørgsler == >2 sek. Document Complete
Tilfredsstillende forespørgsler + (Acceptable forespørgsler/2)
Total antal forespørgsler

46
Svartider og Apdex
• Svartider og Apdex ved generelle sideindlæsninger
• Tiden det tager at forbinde til webserveren
• Svartider og Apdex for forretningskritiske funktioner
• Login, køb af vare eller udfyldning af formular
Testopsætning
• Side-typer (forside, produktside, osv.)
• Geografiske målelokationer
• Browsertype
• Måleværktøj
• Benchmarking, DPI

47
Ikke i blinde!
Du kan ikke forbedre
det du ikke måler på!

48
Sådan laver du en SLA for
performance niveauet

49
performance niveauet – 1/4
• Klar og tydelig
• X : ”Websitet skal være hurtigt”
• X : Websites forside skal være hentet inden for 2 sekunder
• ✔: Websites forside skal have en Time-To-First-Byte tid
under 300 ms. og Document Complete på under 2
sekunder. Der skal måles fra Danmark. Målingerne skal
foretages i tidsrummet 08:00 – 16:00 med en Internet
Explorer Browser 9. Måleværktøjet er instant@larm.
• Vær’ realistisk
• Hvis websitet er 8 sekunder om at blive hentet, skal kravet ikke
være 1 sekund.
• Benchmark op imod konkurrenter
• Digicure Performance Index (DPI), www.digicure.dk

50
• Hvilke sider er en del af SLA’en?
• Forside, produktside, checkout-flow, kontaktside, søgning
• Udvælg performance metrikker
• Time-To-First-Byte, TTFB
• Oppetid
• (Time-To-Render, TTR | Document Complete | Fully Loaded)
• Udvælg lokationer hvorfra målingerne skal foretages
• Lokalt og/eller globalt?
• Hvad er dine brugernes forventninger?
• Brugerundersøgelse
• Case studies
• Vælg browsertype
• Mobil
• Desktop

51
Eksempel: Service Level Agreement (SLA)
Webside: Forsiden af www.eksempel.dk
Lokationer: Danmark, USA og Australien
Browsertype: Desktop – Internet Explorer 9
Værktøj: instant@larm
Gennemsnitlig Document Complete: 2,41 sek. (DPI over automobiler)
Krav til TTFB:
0,3 sek. (Danmark), 0,7 sek. (USA), 0,9 sek. (Australien)
Krav til Document Complete:
2 sek. (Danmark), 4 sek. (USA), 5 sek. (Australien)
Krav til oppetid:
99,98 % (Danmark, USA og Australien)

52
• SMART – Specific, Measureable, Attainable, Realistic and Time bound
• Revurdér en SLA løbende
• Monitorér dine konkurrenter
• Foretag løbende brugerundersøgelser
• Sørg for at monitorere performance niveauet – Også selvom det ser
godt ud
• Gør brugerne opmærksomme på at der arbejdes hen imod højt
performance niveau
• Performance SLA’er er vigtige under udvikling af
websites/applikationer

53
Når forretningen bliver global

54
CDN,
Content Delivery Network

55
• Smart-route teknologi
• Komponenter placeret
geografisk tættere på
brugeren
• Typisk statiske
Fordele:
• Reducering af trafik
• Større skalérbarhed

56
Hvordan vælger jeg den
rette CDN udbyder?
Få styr på dit behov
• Hvilke fil formater skal du have
hosted?
• Hvor kommer dine brugere fra?
(geografiske lokationer)
• Hvad er trafikken på nuværende
tidspunkt?
• Hvad forventer man af fremtidig
trafik?
Og ikke mindst..
• Lyt ikke til rygter! CDN er stadig
en forholdsvis ny teknologi

57
• Supporteres de nødvendige fil
formater?
• Hvor er datacentrene geografisk
placeret?
• Hvordan bliver man faktureret?
• Er der en SLA for performance?
• Oppetid
• Netværk og server
• Svartider
• Fra flere geografiske
lokationer
• Kompensering
• Ikke kun pr. minuts nedetid
Spørgsmål til
udbyderen

58
HUSK!
Monitorér CDN performance

59
kræver en strategi

60
$
kræver en strategi
1. Identificér en forretningskritisk funktion på websitet
2. Definér målemetoden og succeskriterierne
3. Mål det nuværende performance niveau
4. Optimér performance niveauet
5. Indkassér fortjenesten

61
$
kræver en strategi
Igen og igen og igen..

62
Hvor skal jeg fokusere mine
optimeringer?

63
Dit websites svartider
skal være hurtigere!
optimeringer?

65
Vil den stigende hastighed på
båndbreddelinjerne løse vores problemer?
NEJ!
Båndbredde og svartider

67
Båndredde og latency
• Båndbredde indikerer ‘tykkelsen’
• Latency indikerer transporttiden
• Transporttiden fra A til B == Latency

Fra Danmark
68

69
Latency == transporttiden fra A til B
Båndbredde

Fra Danmark
70

71
Fra Danmark Fra Australien

72

73
Kilde: http://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
• Lysets hastighed er en begrænsning
• Læg kortere kabler
• 450 millioner kroner per sparet ms.
• Løsning: Flyt indholdet tættere på og
reducér antallet af forespørgsler

74
Streaming er begrænset af båndbredde
Web browsing er begrænset af latency

75
optimeringer?
What’s Steve Souders saying!

76
“80-90% of the end-user response time is spent on the frontend.
Start there.” – Steve Sourders, Google
20 % BE = Time To First byte (TTFB)
• Database opslag
• Web service kald
• HTML generering
80% FE = Download af indholdet:
• Billeder
• CSS
• Scripts
• Flash
optimeringer?

77
Back End: 13 % – Front End: 87 % Back End: 20 % – Front End: 80 % Back End: 11 % – Front End: 89 %
Back End: 23 % – Front End: 77 %Back End: 13 % – Front End: 87 %Back End: 16 % – Front End: 84 %
Back End: 15 % – Front End: 85 % Back End: 6 % – Front End: 94 %

• Reducering af antal HTTP forespørgsler
optimeringer?

79
optimeringer?

• Reducering af antal HTTP forespørgsler
• Reducering af website indholdet
optimeringer?

81
Optimér websitet – Køb ikke mere hardware
500 kb
90 req.
250 kb
45 req.
optimeringer?

82
Gør som Seatwave
optimeringer?

83
Hvad er årsagen til dårlig
web performance?

84
For mange forespørgsler
Tungt indhold som ikke
er komprimeret korrekt
Server konfigurationer
3. part komponenter
web performance?

85
Indhold
Ansvarsområder
Applikation
It-infratruktur
web performance?

86
Ansvarsområde:
- Indhold
• Web redaktører
• Webmasters
• E-commerce managers
web performance?

87
Ansvarsområde:
- Applikation
• Webbureauer
• Udviklings-hus
• In-house udvikling
web performance?

88
Ansvarsområde:
- It-infrastruktur
• Webhotel
• Hosting partner
• In-house hosting
web performance?

89
Hvilke typer testværktøjer
har man behov for?

90
Udvælg de
rigtige værktøjer
Monitorering
Test
Optimering
Udvælg dine testværktøjer

91
• Svartider
• Tilgængelighed
• IKKE kun ping
• Brugernes oplevelse udefra
• 3. part monitorering
Monitorering
Testværktøjer – Web performance

92
Real User MonitoringSynthetic Monitoring
• Data fra brugernes browsers
• Stor mængde data
• IKKE fra Safari, Opera, IE8, Blackberry
og Android 2.3
• Man har ingen indflydelse på:
• Netværk
• Hardware
• Andet software installeret hos
brugerne
• Ingen data når brugerne sover
• Trend spotting
• Fast testopsætning:
• Software
• Hardware
• Netværk
• Alarmer
• Simulering af user-flow
• Tilgængeligheds monitorering

93
Real User Monitoring

94
<script>
_gaq.push(['_setAccount','UA-XXXX-X']);
_gaq.push(['_setSiteSpeedSampleRate', 100]); // #protip
_gaq.push(['_trackPageview']);
</script>
Google Analytics >> Content >> Site Speed
● Automatisk opsamling af data – standard er kun 1% af besøgene
● Maksimalt 10.000 sidevisninger/day
Real User Monitoring

95
Synthetic Monitoring

96

97
Testværktøjer – Anbefaling
+ Real User Monitoring

98
• Load test
• Hvor meget kan websitet
holde til
• Stress test
• Hvor meget kan websitet
holde til under en stor
belastning
• Endurance test
• Hvordan opfører websitet
sig under en længere
vedvarende belastning
Performancetest

99
Performance
optimering
• Lokalisér potentielle optimeringstiltag
• Udbedre ’flaskehalse’
• Reducér svartider
• Reducér båndbreddeforbrug
• Reducér belastning på it-infrastruktur

100
Performance
værktøjer

119
Værktøjerne
er på plads!
Udvælg dine testværktøjer

120
God web performance på de
mobile enheder

121
Performance på mobile enheder
Fra desktop PC til..

122
Mobil performance

123Kilde: http://www.businessinsider.com/mobile-will-eclipse-desktop-by-2014-2012-6

124
Land Mobile-only
brugere
Egypten 70 %
Indien 59 %
Sydafrika 57 %
Indonesien 44 %
USA 25 %
Kilde: onDevice Research

125
”Der er flere der
har adgang til
mobiltelefon, end
adgang til
rindende vand og
tandbørster”
Kilde: http://blogs.worldbank.org/africacan/more-cell-phones-than-toilets

126

127
Er de mobile brugere
mere tålmodige?

128
”85 % af de mobile
bruger forventer at
mobile sites loader
lige så hurtigt eller
hurtigere end
desktop sites”
Kilde: http://www.strangeloopnetworks.com/web-performance-infographics/

129

130

131
”75 % af de mobile
brugere vil forlade
et website, hvis det
tager længere end
5 sekunder at få
indholdet vist”

132
Hvad skal man være opmærksom på når
man skal levere god performance
på det mobile netværk?

13
3
Kilde: http://www.webperformancetoday.com/2013/08/06/8-mobile-performance-
assumptions/
Belastning på radiomast
Vejret
Retning mod radiomast
Afstand

13
4
Fra Holland Fra Australien
4G Netværket
- ’Under the hood’

13
5
4G Netværket
- Vil gøre livet nemmere
LTE/4G 3G
’Idle’ tilstand < 100 ms < 2,5 sek.

13
6
4G Netværket
Samlet latency ‘Idle’
Edge 670-830 ms +2,5 sek.
3G 120-280 ms +2,5 sek.
4G 65-86 ms +100 ms
Desktop 10-30 ms -
Kilde: https://docs.google.com/presentation/d/1wAxB5DPN-
rcelwbGO6lCOus_S1rP24LMqA8m1eXEDRo/present#slide=id.g11c1373c5_5_0

13
7

13
8
OpenSignal.com

13
9
4G Netværket
Kilde: https://docs.google.com/presentation/d/1wAxB5DPN-
rcelwbGO6lCOus_S1rP24LMqA8m1eXEDRo/present#slide=id.g11c1373c5_5_0
TDC Telia Telenor 3 ‘Idle’
Edge 994 ms 1109 ms 1294 ms 930 ms +2,5 sek.
3G 437 ms 280 ms 399 ms 317 ms +2,5 sek.
4G 76 ms 223 ms 90 ms 162 ms +100 ms
Samlet latency ‘Idle’
Edge 670-830 ms +2,5 sek.
3G 120-280 ms +2,5 sek.
4G 65-86 ms +100 ms
Desktop 10-30 ms -

14
0
4G Netværket
• 4G er ikke tilgængelig for os alle
endnu
• 3G netværket forsvinder ikke
foreløbigt
Hvad kan vi gøre ved det?
• Websites størrelse
• Antal forespørgsler (VIGTIG)
Løsninger:
• Reducér mængden af data
• Reducér antallet af forespørgsler
• Komprimering
• Caching

14
1
Opsummering 1/2
Hvad har vi gennemgået?
• Introduktion til hvorfor web performance er vigtigt
• Cases, SEO og svartider
• Brugernes forventning
• Hvordan kommer man godt fra start
• Opsætning af KPI’er og SLA’er inden for web performance
• Hvilke KPI’er har web performance indflydelse på
• Hvilke SLA’er har man mulighed for at opsætte
• Hvordan specificerer man en SLA
• SLA’er for CDN udbydere
• Performance optimering kræver en strategi
• Performance optimering som en løbende proces

14
2
Opsummering 2/2
Hvad har vi gennemgået?
• Hvor skal man fokusere sine optimeringer? Hvor er effekten
størst?
• Båndbredde og svartider
• Reducér forespørgsler og indhold
• Hvilke typer af værktøjer har man behov for?
• Monitorering, test og optimering
• instant@larm og WebPageTest.org
• God web performance på de mobile enheder. Hvordan?
• Mobil brugernes stigende trafik og forventninger
• 3G /4G netværket og latency

Google har altid ret
“As a product manager you should know
that speed is product feature number
one.”
- Larry Page (Google Founder)

Tobias Borg Petersen,
mail: tbp@digicure.dk
www: digicure.dk

Performance monitorering
• Synthetic monitoring
• Uvildig 3. part
• 24/7/365 overvågning
• SaaS løsning – ingen installation
• Alarmering pr. SMS og/eller e-mail
Simulering af en reel brugeradfærd
• Målt udefra – foran firewall, load
balancers, LAN
• Simulerer Internet Explorer 9
Typer af målinger
• URL-måling
• Inkl. mobile enheder
• FTP-måling
• SMTP-måling
• PING-måling
• CITRIX-måling
• Transaktions-måling
instant@larm

Step 1 – Gå til forside
Step 2 – Indtaster ’E-mail’
Step 3 – Indtaster ’Password’
Step 4 – Klikker ’Sign-in’ Step 5 – Klikker ’Sign Out’
instant@larm

Nye måle metrikker
• Time-to-render, TTR
• Document Complete/Fully Loaded
• Cashed vs. Non-Cashed
• Speed Index
Fejlfinding (Debug-mode)
• Video optagelse
• HAR-fil generator
• Screenshots ved fejl
Andet
• Helt nyt design og teknisk platform
• Automatisk oprettelse af målinger
• Valg af browsertype
• API
• Mobil app
Det nye instant@larm

Digicure seminar i Jylland | Session 1, web performance monitorering

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Digicure seminar i Jylland | Session 1, web performance monitorering

Ähnlich wie Digicure seminar i Jylland | Session 1, web performance monitorering (20)

Digicure seminar i Jylland | Session 1, web performance monitorering

Hinweis der Redaktion