Upload
strangeloop
View
7
Download
0
Tags:
Embed Size (px)
DESCRIPTION
One approach to performance is to accelerate the network; another is to optimize the application by reducing how much the network is needed and pushing content out towards the user. In this session, Hooman Beheshti reveals how technologies like Front-End Optimization and Content Delivery Networks work alongside the rest of the cloud computing stack to improve performance and increase user productivity.
Citation preview
Web Acceleration and Front End Optimization
Cloud Connect 2013 Santa Clara
Hooman BeheshtiVP Technology, Strangeloop
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2
Web Application Acceleration
• Means lots of things to lots of people– TCP optimization– Caching– HTTP protocol optimization– Compression– Etc
• We’ll focus on “front-end” issues– Front-end Optimization (FEO)– Sometimes called WCO or WPO
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 3
Better Performance = Better Business
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 4
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 5
Impact of page load time on average daily searches per user
50m
s pr
e-he
ader
100m
s pr
e-he
ader
200m
s po
st-he
ader
200m
s po
st-ad
s
400m
s po
st-he
ader
-0.70%
-0.60%
-0.50%
-0.40%
-0.30%
-0.20%
-0.10%
0.00%
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 6
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 7
Impact of additional delay on business metrics
50 200 500 1000 2000-5.00%-4.50%-4.00%-3.50%-3.00%-2.50%-2.00%-1.50%-1.00%-0.50%0.00%
Queries per visitor Query refinement Revenue per visitorAny clicks Satisfaction
Added delay
Pe
rce
nt
ch
an
ge
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 8
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 9
Shopzilla had another angle
Big, high-traffic site◦100M impressions a day◦8,000 searches a
second◦20-29M unique visitors
a month◦100M products
16 month re-engineering◦Page load from 6 seconds
to 1.2◦Uptime from 99.65% to
99.97% ◦10% of previous hardware
needs
http://en.oreilly.com/velocity2009/public/schedule/detail/7709
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 10
5-12% increase in revenue
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 11
Mobile Case Study
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 12
Customer Profile
• Top 200 Internet retailer, US based• Target geography: US and Europe• $3B in revenue• 30,000 employees
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 13
Page Views by Mobile Device
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 14
Experiment
• Induce delay on HTML– 200msec, 500msec, 1000msec
• Apply to small percentage of traffic
• 12 weeks
• Monitor impact on key business metrics
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 15
Results
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 16
Impact on Bounce Rate
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 17
Impact on Returning Visitors
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 18
More Details
• http://www.webperformancetoday.com/2011/11/23/case-study-slow-page-load-mobile-business-metrics/
• http://velocityconf.com/velocityeu/public/schedule/detail/21632
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 19
What Is FEO?
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 20
What Is FEO?
0 6 12
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 21
What Is FEO?
0 6 12
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 22
What Is FEO?
0 6 12
DNS TTFB
TCP Connectio
n
Download
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 23
What Is FEO?
0 6 12
Back End: The time from when the request is made by the browser to last byte of the HTML response
Front End: Everything after the HTML arrives
Important Timers:
Start Render
onload (Document Complete)
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 24
Google’s Waterfall Chart
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 25
Measurement/Tools
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 26
Waterfall Analysis
• Best way to address front-end problems is to diagnose your site/application through waterfall analysis
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 27
Waterfall Tools: webpagetest.org
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 28
Waterfall Tools: HTTPWatch
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 29
Waterfall Tools: Firebug
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 30
Waterfall Tools: WebKit Dev Tools
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 31
Waterfall Tools: PCAP2HAR
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 32
Measurement – a pretty big deal
• Synthetic performance “proxies”– Backbone testing services– Desktop tools and browser plugins– Browser-based tests– But:
• Not real users• Often no latency/bandwidth limitations imposed on
testing agents
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 33
Measurement – a pretty big deal
• Real User Monitoring (RUM)– Using real user beacons– Services available – Can build your own– Now a part of Google Analytics– Caveat: need lots of data!
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 34
W3C’s Navigation Timing
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 35
Front End Problems
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 36
Front End Performance Problems
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 37
Front End Performance Problems
• Latency: – every round trip incurs a
latency penalty
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 38
Front End Performance Problems
• Latency: – every round trip incurs a
latency penalty
• Payload: – last mile bandwidth isn’t
infinite
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 39
Front End Performance Problems
• Latency: – every round trip incurs a
latency penalty
• Payload: – last mile bandwidth isn’t
infinite
• Caching: – coming back to the page must
be much faster
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 40
Front End Performance Problems
• Latency: – every round trip incurs a
latency penalty
• Payload: – last mile bandwidth isn’t
infinite
• Caching: – coming back to the page must
be much faster
• Rendering: – browser work takes time
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 41
Client Platforms
• Desktop vs Mobile– Desktop browsers have more access to
compute resources– Larger screens– Faster networks (lower latency)
• The problems are often similar– Addressing them is often different
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 42
Addressing Front End Problems
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 43
Latency
• TTFB (Time To First Byte)• Every fetch incurs the latency penalty• Two ways to address the problem:
– Reduce latency– Get rid of round trips
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 44
CDN
• Global network of caching proxies that gets content closer to all your users
• The closer the asset, the lower the latency
• CDNs have become a core piece of infrastructure for most modern web sites and services
• Lots of vendors to choose from
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 45
CDN
Edge Cache
Edge Cache
Edge Cache
Edge Cache
Origin Data Center
Origin
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 46
CDN
• Small object delivery– Only static assets are placed on edge caches– Users go direct to origin to get dynamic content– HTML pages reference objects on the CDN
• Whole Site Delivery (Dynamic Site Acceleration)– All transactions go through CDN, even dynamic
content– More than caching
• Acceleration• Security• Optimization
– More expensiveOrigi
n Da
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 47
CDN
Per object TTFB savings of ~50%
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 48
CDN: because physics!!
• Well understood way to leverage science
• Mitigates the latency problem by reducing it for the majority of your users
• Less effective when it comes to mobile users
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 49
Mobile Networks (3G example)
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 50
Resource Consolidation
• Eliminating round trips altogether also fights the latency problem, often more effectively
Combine images into fewer "packages"
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 51
Resource Consolidation
• A number of consolidation techniques– Images (sprites)– JavaScript/CSS consolidation/concatenation– Inlining (DataURI for images)– MHTML (IE only)
• Browser makes one request for the “package”
• HTML is marked up so the browser can get individual resources from inside the package
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 52
Payload Reduction
• Bytes still need to get from server (cloud or otherwise) to client
• Ways to reduce bytes:– HTTP compression– JS/CSS minification– Image compression (lossless or lossy)
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 53
Payload Reduction
• Any reduction in bytes will make pages load faster
• This is particularly important with mobile clients
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 54
Browser Caching
• The browser cache is a resource seldom used optimally
• Reasons why we generally don’t do good browser caching– Caching rules are often complicated– We never want to server stale content
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 55
Browser Caching
• Use long expiry on static objects– Served from origin– Served from CDN
• Invalidation framework is a must– Protect against serving stale content– Example: versioning
/images/image.jpg /images/image.jpg?v=00001
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 56
Browser Caching on Mobile Platforms
• Different than desktop
• The cache available to the browsers is relatively small
• Use HTML5’s localStorage instead of browser cache– A programmable cache, unlike HTTP object
caches– Limited size (~2.5MB per domain)– Good for caching CSS/JS, and small images
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 57
Rendering Issues
• More complicated
• The order of events in the browser makes a difference to how fast a page looks– Put things in the optimal order for rendering
• Deferral– CSS and JS (sometimes images)
• Not at the expense of a page’s start render
– Asynchronous JavaScript
• 3rd party services have an impact on page rendering
• Above the fold vs below the fold
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 58
“The HTML Problem”
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 59
Performance Pain: The HTML Problem
• HTML base pages are often generated after the server runs some business logic
• This is typically observed as “server think time”, which affects time to first byte
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 60
Performance Pain: The HTML Problem
• HTML base pages are often generated after the server runs some business logic
• This is typically observed as “server think time”, which affects time to first byte
TTFB = Latency + Server think time
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 61
Performance Pain: The HTML Problem
• HTML base pages are often generated after the server runs some business logic
• This is typically observed as “server think time”, which affects time to first byte
TTFB = Latency + Server think time
BLOCKED
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 62
Performance Pain: The HTML Problem
• HTML base pages are often generated after the server runs some business logic
• This is typically observed as “server think time”, which affects time to first byte
• Not always logic related: could be caused by issues within the cloud infrastructure itself
• HTML is often seen as dynamic
• Cannot be cached, anywhere in the network
TTFB = Latency + Server think time
BLOCKED
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 63
HTML Caching
• Some level of caching for HTML is generally a good idea
• This is especially true if HTML isn’t truly dynamic and is static for small periods of time
• Great for server offload
• Solutions that allow granular caching of HTML
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 64
Some Examples
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 65
Before and After Waterfalls
58 roundtrips 5 roundtrips4.2 seconds 1.1 seconds
57 roundtrips 4 roundtrips3.2 seconds 0.7 seconds
First Time Visitor
Repeat Visitor
Before FEO After FEO
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 66
Cloud Connect Home Page
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 67
Cloud Connect Home Page
5.63 sec
2.8 sec
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 68
Cloud Connect Home Page
FEO
5.63 sec
2.8 sec
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 69
Cloud Connect Home Page
FEO
To onload Before After
Round Trips 122 58
KBytes 1024 8955.63 sec
2.8 sec
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 70
Cloud Connect Home Page
FEO
5.63 sec
3.64 sec
To onload Before After
Round Trips 122 58
KBytes 1024 895
2.8 sec
1.8sec
Start Render: +36%Doc Complete: +35.5%
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 71
What Does it Look Like?
http://youtu.be/uszBaW5yMI0
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 72
Mobile Example
• Velocity Conference 2012
• Step-wise acceleration of O’reilly’s site (for a mobile phone on 3G)– Start with the original site (purposely made
worse)– Add CDN– Add resource consolidation and payload
reduction– Add deferrals
• Examine impact of each
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 73
What Does it Look Like?
http://youtu.be/iPtbU1KvLjM
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 74
Original Site + CDN
15.29 sec 13.7 sec
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 75
Add Consolidation and Payload Reduction
13.7 sec
9.47 sec
To onload Before After
# of resources 92 28
KBytes 727 417
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 76
Add Deferral
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 77
Add Deferral
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 78
Add Deferral
9.47 sec
3.6 sec
5.56 sec
2.2 sec
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 79
What Does it Look Like?
http://youtu.be/zTTxdAtbhsg
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 80
Summing up…
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 81
Sounds Really Easy!
• It’s not!
• Some techniques are just difficult to implement
• Optimizing for performance sometimes requires significant dev resources– Mortal companies can’t afford to sacrifice new
feature cycles
• Maintenance and upkeep is a constant problem– Every version to roll out will need optimization
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 82
FEO Automation Industry
• Solutions available to automatically do this stuff
• Multiple deployment options– Software/Hardware/Service– Cloud apps will use either service or software
• The goal is to “fix the code” for performance, automatically
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 83
It Gets Complicated
• Rewriting HTML can break pages
• You have to do this stuff based on browser– Play to the strength of each browser (supported
techniques, etc)– Stay away from their weaknesses (bugs,
undocumented issues, etc)– Mobile is its own beast
• Optimizing once per page isn’t enough– First view (cold cache)– Repeat view (warm cache)– User flow
© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 84
When Looking For FEO Automation
• Do your research, and understand your needs
• Understand the deployment model and how disruptive it will be to you, if at all
• Are there provisions in place for breaking pages
• Granularity in functionality:– Browser-based optimization– mobile– first/repeat views– transaction flows
• Choose what’s right for you, based on your needs