instant@larm workshop | Digicure

instant@larm workshop5. februar 2014

Få fuld udbytte af din investering i instant@larm

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

• 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

www.digicure.dk

4

• Performance afdelingen

• 5 medarbejdere

• Beskæftiger os med:• Performance monitorering• Performance test (load-, stress- og endurance-test)• Performance audits (Webperformance X-ray)• Rådgivning og andre konsulent opgaver

• Vores produkter• 90 % selvudviklet • 10 % software-in-a-box

AgendaTobias Borg Petersen

5

• Hvorfor er god web performance vigtigt?• Hvad er brugernes forventninger til svartider?• Opsætning af KPI’er. Hvilke KPI’er er relevante?• Hvordan laver jeg en SLA for performance?• Hvilke typer værktøjer har jeg brug for? PAUSE• instant@larm gennemgang

PAUSE med sandwiches • Tips til at øge performanceniveauet• Web performance optimering som en løbende proces • Eventuelle spørgsmål og tak for i dag

6

Fokus på web performance

7

Websites bliver langsommere og langsommere…

8

Danske webshops Danske kommuner

Web performanceHvordan står det til i dag?

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

9Kilde: http://httparchive.org

400000

800000

1200000

1600000

2000000International

1.551 KB


10

Flash1%

CSS5% HTML

3%

JavaScript20%

Andet4%Billeder

67%

Flash2%

CSS4% HTML

5%

JavaScript22%

Andet3%

Billeder64%


Danske webshops Danske kommuner

11

12

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

13Kilde: 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

14

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

15

• 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

16

Nedetider kan koste dyrt

Web performance – Hvorfor?Nedetider

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

17

1.5 seconds == SLOW

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

Web performance – Hvorfor?Search Engine Optimization (SEO)

18

De besøgendes forventninger

19

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


20

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

21Kilde: 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


22

Højere krav til performance

2006 = <4 sekunder

2009 = <2 sekunder

2013 = <1 sekund

1960 = <10 sekunder


23

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


24

Performance er en fundamental del af brugeroplevelsen på websitet!

Brugeroplevelsen



25

”Facebook sucks!”

• Intuitive navigering

• Timelines elegance

• Svartiden!


Brugeroplevelsen


26

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/


27

Hvordan kommer man godt fra start

28

Fælles interesse


29

Driftsfolkene: - Reduceret belastning


30

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!


31

Økonomi folkene:- Lavere drift omkostninger!


• Reduceret båndbreddeforbrug

• Reduceret behov for server kraft

• Reduceret strømforbrug

• Reduceret CO2 udledning

32

Web performance optimering - Return of Investment (ROI)


33

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!

34

Opsætning af KPI’er

35

Noget der kan måles på

KPI’er


36

• 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


37

Ikke i blinde!


Du kan ikke forbedre det du ikke måler på!

38

Sådan laver du en SLA for performance niveauet

39

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 være hentet inden for 2

sekunder, målt fra Danmark. Målingerne skal foretages i tidsrummet 08:00 – 16:00

• Vær’ realistisk• Hvis websitet er 8 sekunder om at blive hentet, skal kravet ikke

være 1 sekund. Til at starte med!

• Benchmark op imod konkurrenter• Digicure Performance Index (DPI), www.digicure.dk

40


• Hvilke sider er en del af SLA’en?• Forside, produktside, checkout-flow, kontaktside, søgning

• Udvælg performance metrikker • Connection time• Oppetid • (Download time)

• 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

41


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 svartid: 2,41 sek. (DPI over automobiler, juni 2012)

Krav til Connection time: 0,3 sek. (Danmark), 0,7 sek. (USA), 0,9 sek. (Australien)

Krav til svartid: 2 sek. (Danmark), 4 sek. (USA), 5 sek. (Australien)

Krav til oppetid: 99,98 % (Danmark, USA og Australien)

42


• 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

• Vigtige under udvikling af et website/applikation

43

Hvor skal jeg fokusere mine optimeringer?

44

Dit websites svartider skal være hurtigere!


45

Båndbredde og svartider

46

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

NEJ!


47


48


Båndredde og latency

• Båndbredde indikerer ‘tykkelsen’• Latency indikerer transporttiden • Transporttiden fra A til B = Latency

Fra Danmark

49


50

Latency = transporttiden fra A til B

Fra Danmark

51


52

Båndbredde og svartiderFra Danmark Fra Australien

53


Fra Danmark Fra Australien

54

“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

Kilde: http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/


http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/

55


• Reducering af antal HTTP forespørgsler

• Reducering af website indholdet


57

Optimér websitet – Køb ikke mere hardware

500 kb90 req.

250 kb45 req.


58

Gør som Seatwave


59

Hvad er årsagen til dårlig web performance?

60

For meget indhold

Tungt indhold som ikke er komprimeret korrekt

Server konfigurationer

3. part komponenter


61

Indhold

Ansvarsområder

Applikation

It-infratruktur


62

Ansvarsområde: - Indhold

• Web redaktører

• Webmasters

• E-commerce managers


63

Ansvarsområde: - Applikation

• Webbureauer

• Udviklings-hus

• In-house udvikling


64

Ansvarsområde: - It-infrastruktur

• Webhotel

• Hosting partner

• In-house hosting


65

Hvilke typer testværktøjer har jeg behov for?

66

Udvælg de rigtige værktøjer

Monitorering

Test

Optimering

Udvælg dine testværktøjer

67

• Svartider

• Tilgængelighed

• IKKE ping

• Brugernes oplevelse udefra

• 3. part monitorering

Monitorering

Testværktøjer – Web performance

68


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

69


Real User Monitoring

70


<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

71


Synthetic Monitoring

72


Synthetic Monitoring

73

Testværktøjer – AnbefalingSynthetic Monitoring

+ Real User Monitoring

74

• 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


75

Performance optimering

• Lokalisér potentielle optimeringstiltag

• Udbedre ’flaskehalse’

• Reducér svartider

• Reducér båndbreddeforbrug

• Reducér belastning på it-infrastruktur


76

Performance værktøjer


77

Værktøjerne er på

plads!

Udvælg dine testværktøjer

78


Coming up:

Workshop: instant@larm

instant@larm

instant@larm

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

Digicure anbefaler som minimum:

• 1x URL-måling• 1x Transaktions-måling

instant@larm

instant@larm

Nye features i 2013 (3 opdateringer)

Opdatering nr. 1• Internet Explorer 8 9

Opdatering nr. 2• Nye grafer• Indtastning af SLA• Webperformance X-ray scan• Bestilling af målinger• Live support-chat

Opdatering nr. 3• HTTP forespørgsler på grafer• URL størrelser på grafer• instant@larm lokationer• ”Hover” hjælpe-menuer

Nye features i 2014 (1-2 opdateringer)

Opdatering nr. 1• Alarmering ved maks. antal

HTTP-forespørgsler• Alarmering ved maks. URL

size• Alarming ved brud på SLA

Opdatering nr. 2• Opdatering af fejl-typer• Opdatering af fejl-

beskrivelser• Webperformance X-ray score

i rapporter

instant@larm

Demo

instant@larm

instant@larm

Det nye 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

92

Reducér antalletaf forespørgsler

Hvad kan optimeres på dit website

93

1)

Combinable JavaScript/CSS files

94URL: http://www.smartguy.dk

• Dyre HTTP forespørgsler• Længere svartider• Større belastning på

infrastrukturen

• Effektiv komprimeringReducér forespørgsler:Combinable JavaScript/CSS files


http://www.smartguy.dk/

95


96

Hvor gode er I?

97

3 9

98

2)

Domain Sharding

99

Reducér forespørgsler:Domain Sharding

• 6 åbne forbindelse ad gangen

• Per domæne

• Statiske komponenter

• Cookie-less domæner


100


101

Hvor gode er I?

102

3 9

103

3)

Caching (Expire Headers)

104

“The fastest HTTP request is the one not made.”

Reducér forespørgsler:Caching (Expire Headers)


105

“The fastest HTTP request is the one not made.”

Kilde: http://httparchive.org/


• Caching Headers

• Pas på med dynamiske komponenter

• Indfør versionsnumreo Javascript_v01.jso Javascript_v02.js

• Last-Modified løser næsten problemet


106



107



108

Hvor gode er I?

109

6 6

110

Reducér indhold


111

4)

Activate HTTP Compression

112

• Komprimering af: HTML, CSS og JavaScript

• Ikke billeder, videoer eller PDF’er

• Konfiguration på webserver

• Load balancer problem

Uden gzip/deflate

Med gzip/deflate

Reducér indhold:HTTP Compression


113

Reducér indhold:HTTP Compression


114

Hvor gode er I?

115

7 5

116

5)

Optimise images

117

JPEG-filer kan indeholde: • Embedded thumbnail images• EXIF metadata• Adobe XMP metadata• Camera information and settings• Geographical and timing data• ICC color profile data• Comments

• Kan ikke komprimeres med HTTP Compression!

• Benyt JPEGTran - http://jpegclub.org/jpegtran/

• Webperformance X-ray

Reducér indhold:Optimise images - JPEG


118

Reducér indhold:Optimise images - PNG


119

URL: http://www.tryg.dk/media/boerneulykke-kampagne_220x420_75-15831.png

Reducér indhold:JPEG Candidate Images

879 kb

• PNG/GIF filer JPEG filer

• Reducering i størrelse

Ulemper:• Skarpe hjørner (logoer

eller grafer)

45 kb~94 %


http://www.tryg.dk/media/boerneulykke-kampagne_220x420_75-15831.png

http://www.tryg.dk/media/boerneulykke-kampagne_220x420_75-15831.png

120

Optimér rendering


121

Opsummering

Combinable JavaScripts 3 9Domain Sharding 3 9Caching (Expire Headers) 6 6

HTTP Compression 7 5

122

Performance optimering som en løbende process

123

Performance optimering - som en løbende proces

Tak for i dag!

Tobias Borg Petersen,

mail: [email protected]: digicure.dk

instant@larm workshop | Digicure

Technology