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 jegTobias Borg Petersen

2

@_tobibp

[email protected]

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

AgendaTobias 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?

5

Fokus på web performance

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 performanceHvordan står det til i dag?

Kilde: http://www.digicure.dk/performance.html

http://www.digicure.dk/performance.html

10

Flash1%

CSS5% HTML

3%

JavaScript20%

Andet4%Billeder

67%

Flash2%

CSS4% HTML

5%

JavaScript22%

Andet3%

Billeder64%


Danske webshops Danske kommuner


http://www.digicure.dk/performance.html

11Kilde: http://httparchive.org

400000

800000

1200000

1600000

2000000International

1.590 KB


http://httparchive.org/

12Kilde: http://httparchive.org


Svartid Tilgængelighed


13

KommunerMar 2013

WebshopsOkt 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 % --


14

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

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

• 40 % af de adspurgte brugere vil forlade et website der er mere end

3 sekunder om at blive vist

• 52 % af de adspurgte brugere mener at hurtige sidevisninger er vigtigt for websites loyalitet

Web performance – Hvorfor?Lavere bruger engagement

http://blog.kissmetrics.com/loading-time/

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/

Web performance – Hvorfor?Lavere bruger engagement

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/

Web performance – Hvorfor?Økonomiske gevinster

http://blog.tagman.com/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/

http://blog.tagman.com/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/

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

Web performance – Hvorfor?Tekniske gevinster

http://www.nccgroup.com/media/19242/seatwave_our_optimisation_story.pdf

20

Nedetider kan koste dyrt

Web performance – Hvorfor?Nedetider

Kilde: http://venturebeat.com/2013/08/19/amazon-website-down/

http://venturebeat.com/2013/08/19/amazon-website-down/

21

Søgeoptimering og lange svartider

Web performance – Hvorfor?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


http://www.qubitproducts.com/wp-content/uploads/2012/04/Site-Speed-Whitepaper1.pdf

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

http://www.cmswire.com/cms/customer-experience/google-recommends-mobile-websites-load-in-one-second-or-less-022080.php

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


http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0




27

ForresterResearch

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



32

”Facebook sucks!”

• Intuitive navigering

• Timelines elegance

• Svartiden!


Brugeroplevelsen


33

Performanceis 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

Hvordan kommer man godt fra start• Website design og udvikling

• Driftsomkostninger

• Marketing

• eCommerce software

Performance optimering øger ROI for alle punkter!

41

Opsætning af KPI’er

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 CompleteAcceptable forespørgsler == 1-2 sek. Document CompleteUacceptable 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

Sådan laver du en SLA for 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

Performance optimering kræver en strategi

60

$Performance optimering 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

$

Performance optimering kræver en strategi

Igen og igen og igen..

62

Hvor skal jeg fokusere mine optimeringer?

63

Dit websites svartider skal være hurtigere!


64

Båndbredde og svartider

65

Vil den stigende hastighed på båndbreddelinjerne løse vores problemer?

NEJ!


66


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

Båndbredde og svartiderFra Danmark Fra Australien

72


Fra Danmark Fra Australien

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


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


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


79


• Reducering af antal HTTP forespørgsler

• Reducering af website indholdet


81

Optimér websitet – Køb ikke mere hardware

500 kb90 req.

250 kb45 req.


82

Gør som Seatwave


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


85

Indhold

Ansvarsområder

Applikation

It-infratruktur


86

Ansvarsområde: - Indhold

• Web redaktører

• Webmasters

• E-commerce managers


87

Ansvarsområde: - Applikation

• Webbureauer

• Udviklings-hus

• In-house udvikling


88

Ansvarsområde: - It-infrastruktur

• Webhotel

• Hosting partner

• In-house hosting


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


Synthetic Monitoring

97

Testværktøjer – AnbefalingSynthetic Monitoring

+ 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


101

WebPageTest.org

102

WebPageTest.org

103

WebPageTest.org

104

WebPageTest.org

105

WebPageTest.org

106

WebPageTest.org

107

WebPageTest.org

108

Waterfall charts typer

109

Manglende caching

110

Langsom Back-End

111

Redirect

112

Langsom Redirect

113

Manglende filer

114

Manglende Keep-Alive

115

Langsom og blokerende fil

116

Store filer

117

For mange filer

118

Langsom Time-To-Render

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?

133

Kilde: http://www.webperformancetoday.com/2013/08/06/8-mobile-performance-assumptions/

Belastning på radiomast

Vejret

Retning mod radiomast

Afstand


134

Fra Holland Fra Australien

4G Netværket - ’Under the hood’


135


4G Netværket - Vil gøre livet nemmere

LTE/4G 3G

’Idle’ tilstand < 100 ms < 2,5 sek.


136



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


137


Fra Danmark Fra Australien

138


OpenSignal.com


139


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 -

140


• 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


141

Opsummering 1/2Hvad 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

142

Opsummering 2/2Hvad 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: [email protected]: digicure.dk

145

instant@larm

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 forsideStep 2 – Indtaster ’E-mail’Step 3 – Indtaster ’Password’

Step 4 – Klikker ’Sign-in’ Step 5 – Klikker ’Sign Out’

instant@larm

instant@larm

instant@larm

instant@larm

Det nye instant@larm

instant@larm

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

signup.instantalarm.dk

Gratis demo i 2 måneder

Technology

Digicure seminar i Jylland | Session 1, web performance monitorering