Cloud Connect Santa Clara 2013: Web Acceleration and Front-End Optimization (Hooman Beheshti)

Web Acceleration and Front End
Optimization
Cloud Connect 2013 Santa Clara

Hooman Beheshti
VP Technology, Strangeloop
hooman@strangeloopnetworks.com

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. 2

Better Performance = Better Business


Impact of page load time on average daily
searches per user
0.00%

-0.10%

-0.20%

-0.30%

-0.40%

-0.50%

-0.60%

-0.70%
50ms pre- 100ms pre- 200ms 200ms post- 400ms post-
header header post-header ads header


Impact of additional delay on business metrics

0.00%
-0.50%
Percent change

-1.00%
-1.50%
-2.00%
-2.50%
-3.00%
-3.50%
-4.00%
-4.50%
-5.00%
50 200 500 1000 2000
Added delay

Queries per visitor Query refinement Revenue per visitor
Any clicks Satisfaction


Shopzilla had another angle
 Big, high-traffic site  16 month re-
◦ 100M impressions a engineering
day ◦ Page load from 6 seconds
to 1.2
◦ 8,000 searches a ◦ Uptime from 99.65% to
second 99.97%
◦ 20-29M unique visitors ◦ 10% of previous hardware
a month needs
◦ 100M products

© 2010 Strangeloop Networks http://en.oreilly.com/velocity2009/public/schedule/detail/7709
Strangeloop. Faster Websites. Automatically. 9

5-12% increase in revenue


Mobile Case Study


Customer Profile

• Top 200 Internet retailer, US based
• Target geography: US and Europe
• $3B in revenue
• 30,000 employees


Page Views by Mobile Device


Experiment

• Induce delay on HTML
– 200msec, 500msec, 1000msec

• Apply to small percentage of traffic

• 12 weeks

• Monitor impact on key business metrics


Results


Impact on Bounce Rate


Impact on Returning Visitors


More Details

• http://www.webperformancetoday.com/2011/11/2
3/case-study-slow-page-load-mobile-business-
metrics/

• http://velocityconf.com/velocityeu/public/schedul
e/detail/21632


What Is FEO?


What Is FEO?

0 6 12

What Is FEO?

DNS TTFB

TCP Download
Connection

0 6 12

What Is FEO?
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)
0 6 12

Google’s Waterfall Chart


Measurement/Tools


Waterfall Analysis

• Best way to address front-end problems is to
diagnose your site/application through waterfall
analysis


Waterfall Tools: webpagetest.org


Waterfall Tools: HTTPWatch


Waterfall Tools: Firebug


Waterfall Tools: WebKit Dev Tools


Waterfall Tools: PCAP2HAR


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


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!


W3C’s Navigation Timing

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html


Front End Problems


Front End Performance Problems



• Latency:
– every round trip incurs a latency
penalty



• Latency:
penalty

• Payload:
– last mile bandwidth isn’t infinite



• Latency:
penalty

• Payload:

• Caching:
– coming back to the page must be
much faster



• Latency:
penalty

• Payload:

• Caching:
– coming back to the page must be
much faster

• Rendering:
– browser work takes time


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


Addressing Front End Problems


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


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


CDN

Edge Cache
Edge Cache

Origin
Origin
Edge Cache Data Center

Edge Cache


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
Origi
– More expensive n
Da


CDN

Per object TTFB savings of
~50%


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


Mobile Networks (3G example)


Resource Consolidation

• Eliminating round trips altogether also fights the
latency problem, often more effectively

Combine images
into fewer
"packages"


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


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)


Payload Reduction

• Any reduction in bytes will make pages load
faster

• This is particularly important with mobile clients


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


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


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


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

“The HTML Problem”


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
some business logic

time to first byte


some business logic

• This is typically observed as B
“server think time”, which affects L
time to first byte O
C
K
E
D


some business logic

B
L
time to first byte O
C
• Not always logic related: could K
be caused by issues within the E
cloud infrastructure itself D

• HTML is often seen as dynamic

• Cannot be cached, anywhere in
the network


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


Some Examples


Before and After Waterfalls

Before FEO After FEO

First Time Visitor

58 roundtrips  5 roundtrips
4.2 seconds  1.1 seconds

Repeat Visitor
57 roundtrips  4 roundtrips
3.2 seconds  0.7 seconds


Cloud Connect Home Page



2.8 sec

5.63 sec



FEO

2.8 sec

5.63 sec



FEO

2.8 sec

To onload Before After
Round Trips 122 58
5.63 sec KBytes 1024 895



FEO

Start Render: +36% 1.8
Doc Complete: +35.5% se
c

2.8 sec
3.64
sec

Round Trips 122 58
5.63 sec KBytes 1024 895


What Does it Look Like?

http://youtu.be/uszBaW5yMI0


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



http://youtu.be/iPtbU1KvLjM


Original Site + CDN

15.29 sec 13.7 sec


Add Consolidation and Payload Reduction

9.47 sec


13.7 sec # of resources 92 28
KBytes 727 417


Add Deferral


Add Deferral

2.2
sec
3.6 sec

9.47 sec 5.56 sec



http://youtu.be/zTTxdAtbhsg


Summing up…


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


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


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


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


Thank You
hooman@strangeloopnetworks.com

85

Cloud Connect Santa Clara 2013: Web Acceleration and Front-End Optimization (Hooman Beheshti)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Cloud Connect Santa Clara 2013: Web Acceleration and Front-End Optimization (Hooman Beheshti)

Semelhante a Cloud Connect Santa Clara 2013: Web Acceleration and Front-End Optimization (Hooman Beheshti) (20)

Último

Último (20)

Cloud Connect Santa Clara 2013: Web Acceleration and Front-End Optimization (Hooman Beheshti)