best practices to optimize commerce site performance [webinar slides]

© 2012 Yottaa Inc. All Rights Reserved.

Yottaa Inc. http://www.yottaa.com

11 Best Practices to Optimize Commerce Site Performance

Bob BuffoneCTO & Co-Founder, Yottaa, Inc.

Ilya MirmanVP Marketing, Yottaa, Inc.

http://www.yottaa.com/

http://www.yottaa.com/

© 2012 Yottaa Inc. All Rights Reserved.22

Agenda

1. Does performance matter?

2. Commerce web: performance challenges

3. Key Metrics & reliable measurements

4. Common performance bottlenecks

5. Optimization techniques

Bob: @rockstarapps

Ilya: @IlyaMirman

We want to change the way ecommerce retailers will operate in

the future

By becoming the trusted resource

that merchants use each day to manage

and grow their business

Retailers don’t need more charts and

graphs. They need real intelligence that

drives revenue.

We Capture 100% of the DataAnd Have 100% Accuracy

• Exact, not approximate data• Account for returns, exchanges

and cancelled orders• Access to all ecommerce data• Historical orders• Customer database

Over 6000 merchants trust us to help them build their online businesses

Across many of the most powerful ecommerce platforms

© 2012 Yottaa Inc. All Rights Reserved.1111

Agenda

1. Does performance matter?

2. Commerce web: performance challenges

3. Key Metrics & reliable measurements

4. Common performance bottlenecks

5. Optimization techniques

Bob: @rockstarapps

Ilya: @IlyaMirman


User Experience:Does it Matter?

© 2011 Yottaa Inc. All Rights Reserved. 12


The Impact of Speed

Source: Why Web Performance Matters – Gomez, Inc. / Aberdeen Group

Average Impact of One Second Delay in Response Time

0%

-2%

-4%

-6%

-8%

-10%

-12%

-14%

-16%

-18%

CustomerSatisfactionConversionsPage Views

-11%

-7%

-16%• Lost revenues• Brand damage• More support calls• Increase costs


Impact of Page Load Delay…


Today’s Performance Challenges for Commerce Sites



Delivering a Good Experience is Challenging

17

DataCenters

MajorISPs

CDNs GeographyLastMile

Browsers Users

3rd Party Content

Performance Uncertainty

100+ factors can create issues for end-users


The Web Has Evolved…

Webpages yesterday = Text + Images from the same domain

Webpages today = highly distributed applications that execute in a browser

18

Yesterday’s bottleneck:The delivery of the bits

Today’s bottleneck: the execution of this distributed application (webpage) in a browser that spans

across 10+ domains

80%+ web performance is on the front end− Steve Souders, Google Web Performance expert

Yesterday: Web client = IE

Most modern Web pages are complex creations -The CNN home page, for instance, is built by the browser from 53 static images, 39 dynamic images, 3 Flash files, 30 JavaScript files, 29 HTML files and 7 CSS files - to be loaded from 18 domains

− Jeff Bezos on Amazon Silk

Today web client > 4 browsers + smart phones + tablets


Commerce Platforms

• Powerful, flexible, extensible

• If not managed properly, challenges with:– Performance– Scaling– Visibility

Site Performance:Magento vs. Avg Web Site

Time-to-Interact

Tim

e-t

o-I

nte

ract

(se

c)

Avg Web Site(Sample of3,500 Sites)

Avg Magento Site(Sample of2,000 Sites)

>90% Slower

10.0

9.0

8.0

7.0

6.0

5.0

4.0

3.0

2.0

1.0

0


Commerce Sites: Optimization Opportunities

• But plenty of performance gains left on the table through:– Front-end Optimization– Optimized Traffic Routing– Edge Caching and Delivery

of Content

• Server-side Tuning– Database and server configuration,

PHP acceleration, compiling options, add hardware, etc.

This Webinar


www.nytimes.com loads in 5.16 Seconds:• Page delivery = 0.456/5.16= 8.8%• Page execution = 91.2%

Source: http://www.yottaa.com/url/www-nytimes-com-4bdad0b4425bdb0c0300025e/page_load

nytimes.com – 91.2% Page Execution

http://www.nytimes.com/

http://www.yottaa.com/url/www-nytimes-com-4bdad0b4425bdb0c0300025e/page_load

http://www.yottaa.com/url/www-mlb-com-4bdb9216425bdb10b10000dc/page_load


Establish a Performance Baseline Best Practice #1

“If you cannot measure it, you cannot improve it.”

Lord Kelvin


Front End User Experience

Best Practice #1


Characterizing User Experience


Front End Metrics: A Slice of the Web… 50th percentile 80th percentile 95th percentile

Time to Title (msec) 1,259 2,368 4,647 Time to Render (msec) 2,420 4,071 7,160 Time to Display (msec) 5,168 8,780 15,254 Time to Interact (msec) 6,263 10,643 18,494

Source: Yottaa measurement of 3,500 websites, Aug. 2012

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0

50

100

150

200

250

300

350

400

450

500

Time to Interact (sec.)

Time to Interact

Frequency

Cumulative %


Visualizing the User Experience

Page loading screenshots

Video of page loading sequence


FREE TOOL: websitetest.com


Visualizing the User Experience

Yottaa’s Interactive Waterfall


Statistically Significant Testing: Why bother?

• Everyone else is not 10 feet away from your server

• The internet is a dynamic beast

• If you want confidence in your decisions, you need confidence in your measurements


Variability Across the World

Example: Amazon.com


Variability in Connectivity

Connectivity makes a big difference. Think about your experience on your phone compared to your office.


Variability in Browser

Browser differences can create surprising differences • Connection Management • JavaScript Engines• Rendering Speed


Back End Performance


Back End Performance Metrics

• DNS time (~60 msec):– The length of time the browser required to resolve host name(s) to IP

addresses• Connect time (~140 msec):

– The length of time spent creating the initial connection to the site• Waiting time (~400 msec):

– The length of time spent waiting for the server to begin sending data.• Time to First byte (~500 msec):

– The length of time before the first byte of data is received from the server.• Time to last byte (~700 msec):

– The length of time before the last byte of the initial request is delivered.


A Sample of the Web…

50th percentile 80th percentile 95th percentile DNS Time (msec) 60 149 413 Connect Time (msec) 144 188 227 Time to First Byte (msec) 533 1,090 2,418 Time to Last Byte (msec) 721 1,412 3,105



Example: Bad DNS Lookup Times

• Reasons– Bad DNS Provider (Not use IP Anycast)– Misconfigured TTL or Records

• Finding the problem– Continuous Monitoring– Online DNS Tools (www.dnsstuff.com/)

• Fixing it– Choose a good DNS Provider


Content Size & Complexity


Summary Metrics: A Sample of the Web…

50th percentile 80th percentile 95th percentile Domains 6 17 33 Asset Count 47 84 152 Asset Weight (Bytes) 690,779 1,557,812 3,393,192 JS Count 8 19 33 JS Size (Bytes) 119,378 346,852 586,442 CSS Count 3 8 16 CSS Size (Bytes) 18,134 60,265 120,000 Image Count 25 48 87 Image Size (Bytes) 318,788 895,948 2,056,237



Continuous Monitoring Best Practice #1


THINGS THAT MAKE YOUR WEBSITE SLOW



Lots of Requests

• Product owners want rich websites– Rich in User Experience– Rich in Visual Presentation

• Achieving richness requires more resources to be downloaded to the client– CSS– HTML– JavaScript– Images


Content Breakdown


More Requests Slower Performance


Source code of the Website


Combine Scripts & CSSto Reduce Requests

Best Practice #2

Before optimization we have 26 JS files!After optimization we have one JS file that provides a huge performance benefit


Combine Images with Spritesto Reduce Requests

.arrowbutton{ display: block; height: 23px; line-height: 22px; font-size: 12px; width: 96px; background: url("<%= image_path('icons/ico.png') %>") no-repeat -49px -8px ;color: #FFFFFF;cursor: pointer;

}

Best Practice #3


Sprites in Action…

Yottaa homepagethat leverages the sprite

CSS sprite


Employ Data URIsto Reduce Requests

Best Practice #4

Data URI (Uniform Resource Identifier) scheme: method for including data in-line in web pages – allows normally separate elements (e.g., images, style sheets) to be fetched in a single HTTP request rather than multiple.


Large Resources

Ways to make your site slow:• Many of the resources that you need to

load can be made fatter than required– HTML, CSS, JavaScript – Add lots of

comments and white space– Images

• Use images that are larger than displayed on the webpage

• Always use the highest quality settings

• Turn off gzip compression on your server


Large Assets Slower Performance


Large assets take longer to download



776KB


Use Lossless Image Compressionto Reduce Asset Weight

Best Practice #7

459 KB 400 KB


Use Lossy Image Compressionto Reduce Asset Weight

Best Practice #8

459 KB 98 KB


Gzip to Reduce Asset Weight Best Practice #5


Minify Scriptsto Reduce Weight

//Get the name of the person

var full_name = “Bob Buffone”;

//Now make it awesome

full_name += “ is awesome”;

//Everyone must know this fact

$(document).ready(function(){

alert(full_name);

});

Best Practice #6

var n=“Bob Buffone”;n+=“ is awesome”;$(document).read(function(){alert(full_name);});

Browsers don’t care about

comments and easy to read code.


Problem: Serialization(e.g., 3rd Party Plugins)

• Bloggers love to make their websites slow using plugins.– Twitter, Facebook, Google Plus, LinkedIn– Photo plugins…

• Not utilizing asynchronous loading of 3rd party resources.


Marketing Loves Social

Social adds LOTS of resources -> 86 JavaScript, images and CSS.


One Facebook Image…


Load 3rd Party Assets Asynchronously Best Practice #9

<script src=“connect.facebook.net/en_US/all.js”></script>


Use Domain Sharding forParallel Processing

Best Practice #10

3 domains for asset loading


Use Intelligent Script Loadersfor Parallel Processing

Best Practice #11


Summary: Problems & Resolutions

Issue ResolutionLots of Requests Reduce # of Requests:

• Combine Scripts and Images• Combine images with Sprites• Employ data URIs

Large Assets Reduce Asset Weight:• Use Gzip• Minify Scripts• Use Lossy and Lossless Image Compression

Serialization Parallel Processing:• Load 3rd Party Assets Asynchronously• Use Domain Sharding• Use Intelligent Script Loaders


Web Site Challenges

66

• Inability to handle high traffic volume, serve users, process transactions

• An overloaded site infrastructure.Scalability

• Vulnerability to threats from bots, hackers and attacks.Security

• Site outages and page errors• Inability to serve users across geographies, devices,

browsers, platformsAvailability

• Slow web pages• Unacceptable user experience• Reduced site conversions• Poor search engine rankings

Performance


The Yottaa Web Optimization Platform

Web Optimization

Network

• Payload reduction• Request reduction• Parallel processing

Features:

Benefits:

• Improve user experience• Increase conversions• Increase search

engine rankings

• Traffic blocking and throttling• Resource and bot protection• Traffic analytics

• Improve availability, resiliency and security

• “Protection as a Service”• Elastic and adaptive

Features: Benefits:

• Content cachingand edge delivery

• IP Anycast routing• 20+ edge locations• Integrates with

any CDN

• Global IP anycast• Globally distributed

data centers• Globally redirects

request to closest geographic server

• High performance DNS service

• Enterprise-grade traffic management

• DNS Shieldfor protection

• Reduce load onyour infrastructure

• Reduce networklatency

• Improve userexperience

• End user experience monitoring

• Intuitive data analysisand visualizations

• Problem detection,alerting and diagnosis

• Ensure end userexperience and SLA

• Problem detectionand timely response

• Actionable intelligence

• Multivariate testing (locations, browsers, connection speeds, time)

• Interactive visualizations: page loading sequence, waterfall, assets)

• See what your users see

• Eliminatesampling error

• Deep insightsfor tuning site performance

Features: Benefits:

Features: Benefits:

Features:

Benefits:

Features:Benefits:


yottaa.com68

Thank You for your time!

best practices to optimize commerce site performance [webinar slides]

Documents

key metrics

common performance

optimization

reduce requests

performance

rights reserved

rockstarapps

continuous