1 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.

com
Table of Contents

Introduction to Web Performance...3

Executive Summary...4
The Causes of Poor Performance...5
ROI of Web Performance...10
How to Measure Performance...12
Web Performance Metrics - Front-End...13
Web Performance Metrics - Content...14
Basic Tools - Waterfall Chart...15
How to Improve Performance...17
Methods for FEO: Issue -> Resolution...18
Ongoing Action: Website Monitoring...19
WPO Checklist + Resources...20

2 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Introduction to Web Performance
Web performance optimization (WPO) is the
science of making websites load faster and more
consistently for all visitors. The importance
of WPO has been proven repeatedly: studies
by Google, Wal-Mart, Amazon and others
show that slower web pages have a direct and
substantial impact on key business metrics such
as conversion rate and sales.

This eBook is for anyone who is entirely new to

WPO, or anyone who may be unfamiliar with its
newer, more content-centric form. We cover:

• The main causes of poor performance

• Why WPO is important from the standpoint of
marketing and web operations ROI
• How to measure performance
• How to improve performance
• How to monitor performance over time

These topics are covered at a high level, but

suggestions for more in-depth reading are
provided throughout the document. We hope
you enjoy!

3 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Executive Summary
Yottaa is a web performance optimization (WPO)
company. Site speed is constantly on our minds.
Finding new and creative ways to make sites
faster is our passion.

We recognize, however, that not everyone shares

our passion for speed. The challenges and
concerns of running a web-based business are
many. With marketing campaigns, SEO, building
new website content, and everything else that
comes with running a successful online business,
it’s no wonder that something seemingly as small
as shaving a couple seconds off page load time
often falls by the wayside.

In this eBook we hope to convince you

otherwise: that web performance can and should
be as integral as your other business processes.
WPO is wide ranging field that has something
for everyone. Whether your site has big images
in need of compression, needs help to defend
against the effects of sudden traffic spikes, or
faster content delivery for visitors from the other
side of the world, there is a tailor-made solution.

On the following pages we will describe how

the industry has transitioned in focus over the
years, and how the overwhelming bottleneck
for performance is now related to content on
your website. We’ll review the ROI of WPO,
backed up by metrics from the most successful
web businesses. Then we’ll cover the basics of
how to find problems on your site, how to fix
the problems, and what you can do to ensure
continued performance over time.

We hope you enjoy reading and hope we can

help you to speed up your website!

4 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

The Causes of Poor Performance

Performance problems stem from one of three

stages in a website’s journey to the visitor.

The first stage is datacenter performance -- also

Backend known as “backend performance.” This involves
• DNS Lookup the server processing the request sent by the
• Server connection browser and in turn sending out the correct
• Server response website content.

The hangup: Heavy website traffic overloading

servers, code bugs, inefficient code.

The second stage is the “middle mile,” where

Middle Mile
the content travels from the datacenter to the
• Content travels visitor’s browser.
through networks
to user
The hangup: When packets of information have
to travel via inefficient routes and across great
distances to arrive at the browser.

The final stage is “front-end performance.” This

Front-end
stage consists of the visitor’s browser rendering
• Browser download the page’s content once the HTML file has been
• Browser rendering delivered.

The hangup: Downloading and rendering

complex website content: numerous assets,
heavy assets, and third party assets all result in
problems.

5 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

The Causes of Poor Performance
What poor performance looked like: 1998

Sites should ideally load in 2 seconds or less

to keep up with rising user expectations. Most
sites do not. Here’s what an average site’s load
process looked like in 1998. Middle-mile was
by far the longest part of the process, because
no solution had yet been invented to speed up
delivery. In addition, the content of the sites
was simple (primarily images and static HTML)
so it was easy for browsers to render the content
quickly. That’s why the front-end only took 1-2
seconds.

1s 6s 2s

Total: 9s (avg)

Key
Backend Middle Mile Front-end
• DNS Lookup • Content travels • Browser download
• Server connection through networks • Browser rendering
• Server response to user

6 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

The Causes of Poor Performance

2000’s - transition period

In the past decade, improvements to web

infrastructure have made fast delivery across the
“middle mile” easily achievable, particularly for
sites willing to pay for add-on infrastructure
services. This is mostly thanks to the
Evolution of website content: massive growth creation and widespread adoption of
Growth of Webpage Footprint & Number
in weightofand number of assets per page
Requests (1995 to 2012) content delivery networks (CDNs), which
bypass much of the middle mile by delivering
website assets from “edge locations” much
closer to the visitor.

But as CDNs solved the middle mile

bottleneck, increasingly rich content
created a new one on the “front end”
(the browser). In recent years website
content has exploded in quantity, size, and
complexity. The popularity of Social Media
and advances in web development have
made it commonplace for sites to be full of
JavaScript, HTML5, media files, and other
dynamic content. In short, the average
website has become a complex, distributed
web application. Put in numerical terms,
Sources: Demenech 2007, Gomez 2008, Charzinski 2010, Souders 2012 the average website grew 13x between 2002
and 2012 (see left).
The growth of web pages: average number of assets
per page grew from 20 to 100 between 2002 and
Rendering hundreds of kilobytes of complex
2012. Page weight grew from 90 KB to 1114 KB.
content is a comparatively difficult task
for browsers to accomplish, and the strain
shows when one breaks down the page load
process. On today’s websites, up to 90% of page
load time is devoted to the “front-end” stage.

7 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

The Causes of Poor Performance

What poor performance looks like today

Here’s what a current major website might look

like. The front-end, with today’s heavy and
complex content, is the primary bottleneck.

.5s 2s 6s

Total: 8.5s (avg)

Key
Backend Middle Mile Front-end
• DNS Lookup • Content travels • Browser download
• Server connection through networks • Browser rendering
• Server response to user

8 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

The Causes of Poor Performance
Focusing on the “front-end” side, below are
graphs showing how the amount of assets and
weight of content on a website can directly affect
page load time. (The data was collected from a
study Yottaa conducted of over 14,000 websites.)
Larger Pages = Slower Pages

Larger Images = Slower Pages

Image size (KB)

More JavaScript = Slower Pages

9 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

ROI of Web Performance
Poor performance affects websites both in the
short run and the long run.

Visits/Person Per Month vs. Time-to-Interact

In the immediate term, a slow site can cause
1.80 the loss of a potential customer who becomes
impatient with the page load and bounces back
1.75 to the search engine results page to find another
site. A slow site can also cause a more invested
1.70
visitor to abandon a shopping cart because of
1.65 repeatedly slow page performance during the
shopping process. Customers are less willing to
1.60 trust their credit card information with a site that
is struggling to render pages.
1.55

1.50 In the longer term, repeated events like those

<4 seconds 4-12 seconds 12+ seconds
described above combine to impact business
Yottaa performed a study on over 14,000 sites metrics. Sites with worse performance will
that showed increasing page load time resulted in attract fewer visits, worse rankings in search
decreasing visits per person, per month. engines, and are more likely to be spoken poorly
of by visitors who report to friends about their
experience. In addition, studies have shown
that:

• A one second delay can reduce revenue per

visitor by 3% 1
• A one second delay reduces the number of
pages viewed per visitor by 11% 2
• Added delays result in a linear drop in visits
per month 3
• A 100 millisecond delay in page load can
cause 1% drop in revenue 4
1+2
Aberdeen Group ; 3 Yottaa; 4 Amazon.com

A study of websites from Aberdeen Group shows that

a one second delay in page load time resulted in
visitors viewing fewer pages, converting less often, and
reporting a poorer overall experience when polled.

10 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

ROI of Web Performance
If ROI statistics from web giants like Amazon seem
less applicable to your business, consider the
following case of a typical eCommerce site.

Let’s imagine our site sells clothes, earning

$10,000,000 per year in revenue. The site takes
approximately 8 seconds to load (a bit worse than
average, as we’ll show later in this eBook). And
let’s assume that as a result of traffic
spikes driven by successful marketing
campaigns, as well as traffic from bots
and crawlers, approximately 5% of the
time the site performance is particularly
slow or even experiences outages.

So, what can be the impact of a

performance improvement for this site?
Let’s assume that through a variety of
A good marketing campaign drives performance optimization techniques, we could cut
traffic, but can also drive up page the site outages in half, and reduce page load time by
load times. 2 seconds.

There are two components:

1. First, the impact of reducing site outages: if 5% of

the time the commerce site is largely unusable, that’s
a loss of $500,000 per year. Reducing site outages
by a factor of 2X would help reclaim $250,000 in
revenue.

2. There is also the impact of improving average

performance from the current 8 seconds to 6
seconds. Various studies estimate the impact of
improving performance by one second as somewhere
in the 1.0%-10.0% range. Let’s take a figure from
the lower end of this estimate – a 1.5% revenue
increase for each second gained in page load speed.
In our case, the 2 second gain would translate into a
revenue increase of 3%, or $300,000.

The total gain for the site would thus be $550,000 –

clearly a sizable improvement for a modest amount
of work. WPO impacts the bottom line, even for
small or medium sized businesses!

11 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

How to Measure Performance
The first step in WPO is to learn more about
your website’s performance. A variety of
website testing and monitoring tools have been
developed to do this. Some operate online,
through your web browser, and below are a few
of our favorites from that category. Though
these will not monitor your site continuously
over time, they’ll help you kick off the process
with a baseline of information on your site’s
performance.
• Websitetest.com
• Webpagetest.org
• YSlow
• Mobitest (for mobile)

You can also check out this page on WPO guru

Steve Souders’ site for a more complete list of
available tools for testing and monitoring web
performance.

To learn about your website, a good place to

start is from the user’s perspective. This means
looking at a combination of front-end metrics
and content metrics. Front-end metrics show
what users experience on your site, and content
metrics help you understand the attributes of
your site and the keys to improving it.

In the next two sections we will provide

some basics to help you conceptualize web
performance optimization. When you’re ready
to dive deeper into performance metrics, check
out our eBook: 17 Performance Metrics You
Should Care About.

12 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Web Performance Metrics - Front-End

Time to Title is the time elapsed from the

Start moment a visitor’s browser requests your site to
Time To... Title Display Interact the moment that your site’s title appears in the
Render
tab of his or her browser.
Avg time: 1.2s 2.4s 5.2s 6.3s
Time to Start Render is the time elapsed from
the request to when the visitor sees actual
website content appear on the page. This stage
is important since it assures the visitor that your
site is loading. Nobody likes staring at a blank
page. Assuring visitors that they are in the right
place and will soon be seeing the content they
expect will promote a good perception of your
website.

Time to Display is the time elapsed from the

request to when the browser has finished
parsing the HTML page, constructed the
Document Object Model (DOM), and displayed
the HTML document. This all means that the
page will have the general appearance of a
web page, but there may yet be some images,
interactive elements, and other media that
haven’t fully loaded.

Time to Interact is the time elapsed from the

request to the moment the user can interact
with the page. (By “interact” we mean the page
will respond properly to the visitor clicking a
link, scrolling, typing into a field, or activating an
element like a hover effect). This does not mean
that the page is fully loaded, as there may be
scripts, trackers, and other assets that continue
to load in the background. But it does mean
that the visitor can use the web page, and that’s
most important. Many site owners choose Time
To Interact as the principle index for overall web
performance because of its relationship with
user experience.

13 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Web Performance Metrics - Content

Weight
The overall weight of your website -- that is, the
Typical asset weights total number of bytes of all its assets -- factors
JavaScript Overall into its speed. So does the weight of individual
116.6 KB 675 KB assets: a single heavy asset can have a negative
ripple effect on performance.
Image CSS
311.3 KB 17.7 KB Use weight metrics to identify categories of
assets that are too heavy in aggregate, then use
a waterfall chart to zero in on specific assets
within that category that can be fixed or cut.

For instance, if the total weight of your images is

much higher than is typical (see left), click to the
waterfall chart in your monitoring service and
pay particular attention to images that have long
load times. This will give you a starting point for
deciding what images to compress or delete.

Asset Count
More assets necessarily mean more weight
Typical asset counts -- that’s reason enough to keep track of asset
Overall JavaScript count. But in addition, each time a visitor’s
47 8 browser makes the trip to your origin server to
fetch an asset for your site, it adds time to the
Image CSS page load. That means no matter how small or
25 3 compressed an asset is, it still contributes to
slowing down your site to some extent. Some
types of assets can be combined so that multiple
assets load with a single request rather than
individually.

Example: pie graph, taken from the results of

a WebsiteTest.com test of CNN.com, shows the
variety of content that exists on a modern web
page.

14 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Basic Tools - Waterfall Chart
The waterfall chart is an indispensible tool for
web performance. It visually displays each and
every asset that composes a website, and uses
horizontal bars to show how long each asset took
to download. At the most basic level, a longer
bar is a longer download time.

In addition, the other columns in the chart

provide information on WHAT the asset is,
WHERE the asset comes from (be it your origin
server, or a third party), how HEAVY the asset
is (in B, KB, MB), and the STATUS of the asset (if
there was an error involved or not). With all this
information you can quickly find out where the
performance bottlenecks are.

Below is an excerpt of a typical waterfall, and

on the next page are several examples of how
to identify website problems with the waterfall.
For more tips on using the chart, check out our
eBook: How To: Identify 10 Web Performance
Problems in 10 Seconds

15 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Basic Tools - Waterfall Chart

Slow Backend Performance

Look at the very first line in the waterfall chart.
If it’s longer than most of the other lines in the
chart, that’s not good. It should be very short.
Improvements to web infrastructure in the last
decade have made rapid content delivery the
Internet standard. If your “time to last byte,”
aka total delivery time, is longer than 1 second,
consider pursuing a plan to improve it.

Asset Errors
Scan the HTTP status column for any numbers
400 or over. Any time a 400- or 500-level error
occurs it’s a matter of concern since errors can
often have ripple effects on performance, aside
from the failure indicated for that one asset.
Each case begs investigation.

One Bad Asset

Look for an extremely long bar in the waterfall.
Any asset, be it a JPEG, JavaScript, or an asset
served from a third party, can drag down your
entire site. There are dozens of possible reasons
why an otherwise innocent-looking asset could
take seconds and seconds to load, but in the
short term the important thing is identifying it
and removing or fixing it so that the rest of your
site doesn’t suffer.

JavaScript Blocking Behavior

Ideally, the waterfall would be a flat diagonal
line. Unfortunately, that's almost never the
case. It’s easy to see where the smooth pattern
breaks: there’s a left-to-right gap from one line to
the next down. This gap indicates that an asset,
usually a third party script, activated blocking
behavior as it executed, which stalled other asset
downloads. This behavior can be overcome by
forcing that asset to load asynchronously.

16 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

How to Improve Performance
Once you find out what’s dragging your site’s
performance down, there are several ways to
approach improving the site.

If the bottleneck appears to be in the backend,

there are two approaches: increasing the
capacity of your servers by buying more or bigger
ones, and adding bandwidth; and optimizing
backend code. The latter includes optimizing
Bottleneck Solution the server side code (PHP, Java, Ruby, etc.) and
optimizing the database (updating indices,
Backend • Adding/Upgrading servers queries).
• Adding bandwidth
• Optimizing code/database If the problem is the middle mile, a CDN is
Middle Mile • Content Delivery Network the main solution. There’s a wide range of
(CDN) CDN solutions, and they some considerations
Front-end • Reduce Number of Requests in picking a CDN are price (which ranges from
• Reduce Page Weight hundreds per month to tens of thousands per
• Promote Serialization month), whether the CDN provides whole site
(Assets loading in parallel) delivery, and whether the CDN serves dynamic
content.

Most important is optimizing the front-end.

This is by far the most common (and most
devastating) bottleneck for web performance
today. Fortunately, while server upgrades and
CDNs have unavoidable cost, the front-end
can be mitigated manually by developers. On
the following page we explore some of these
techniques.

We explore these manual FEO

techniques and others in greater
detail in our eBook, 11 Techniques
To Make Your Website Rock.

17 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Methods for FEO: Issue -> Resolution

Issue Resolution
Reduce Number of Requests:
• Combine Scripts - Combining or “concatenating” files and scripts is accomplished by
writing a line of code that encompasses information that was previously contained in
two or more lines of code. This is a common practice that can be accomplished by a
developer or using free script-based tools.
• Combine images with sprites - A sprite is a single image that contains the visual
Lots of information of multiple images. A CSS script then positions pieces of the image
Requests where they are supposed to be on the page. This allows the developer to make a
single request for multiple images.
• Combine images etc. with “data: URIs” - A data: URI is a method of including small
images or other bits of data “inline” into an HTML file. That way, instead of loading
as a standalone request, the image will be downloaded along with the HTML file that
includes the basic framework of the page.

Reduce Asset Weight:

• Use “GZIP” Compression - GZIP is a versatile script that can be applied to almost
every asset on your website. As long as the script is called first, all files of that type
(HTML, JS, CSS) on your site will be “gzipped,” i.e. compressed and less heavy.
• Minify Scripts - Script minification is the process of stripping out whitespace,
comments, and erroneous characters from code. This makes the code more
Large Assets streamlined and less heavy.
• Use Lossy and Lossless image compression - All images on a site should be
compressed. Lossless compression can slightly reduce the weight of an image
without reducing the display quality at all. Lossy image compression slightly reduces
the display quality (though usually so little it’s not noticeable to the visitor) but can
reduce the weight of the image on the order of 50 to 90% depending on the image
and degree of loss.

Parallel Processing:
• Load 3rd party assets “asynchronously” - Social media widgets, trackers, and other
dynamic assets on your site are often hosted by third parties far and wide, on servers
you have no control over. When those widgets have performance issues, their
problems spill onto your site and drag down performance. Rewriting the script so
that it loads asynchronously can help mitigate blocking behavior so that the rest of
Serialization your site can load around the struggling asset.
• Use domain sharding - Domain sharding is a way to overcome the limitation of
browsers that only allow a handful of open connections with a server at a time. This
has largely been solved by newer editions of browsers that allow for up to 12 open
connections at a time - but not all web users are on updated browsers. To do this you
rewite an asset’s URL to include a made-up alias in the place of “www” that tricks the
browser into thinking it’s a different server.

18 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

Ongoing Action: Website Monitoring

In order to guarantee a return on the

investment of time and effort you’ve made in
web performance optimization, it’s important
to monitor website performance continuously
over time. The web is constantly shifting and
changing, and your website’s performance can
change at any moment.

There are several options for site performance

monitoring including Pingdom, Yottaa Site
Monitor, Keynote, and Gomez. Using these tools,
set up your site to be monitored in real time and
save data to show trends. With many monitoring
systems you can also arrange alerts, so that
you’re notified instantly when any of a number
of website problems that you’ve selected occur.

We recommend monitoring a sample of your

site’s pages. This would certainly include the
home page. If your site is an eCommerce site,
then product catalog pages, as well as mission-
critical pages like a shopping cart check-out are
important to monitor.

How frequently you monitor depends on how

much traffic your site receives. Some site owners
find it adequate to measure the site every 3 to 4
hours, knowing that only a few customers will be
affected. Others measure pages multiple times
an hour from a variety of locations.

To get a feel for monitoring before diving in, sign

up for a free Yottaa Site Monitor account.

19 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

WPO Checklist + Resources

WPO Checklist:

Read the Beginner’s Guide to Web Performance

Test web performance with a free tool like Yottaa

Site Monitor to identify areas for improvement
Learn more about techniques for optimization;
determine whether to perform manual
optimization or enlist an automatic WPO service
Review options for a Content Delivery Network
(CDN) if delivery is slow
Review and choose a monitoring service to
gather performance data over time
Follow the guidelines in our eBook on managing
a WPO project and put all that research to work!

Yottaa blogs and eBooks: Other Resources:

Manual FEO: SteveSouders.com - Steve’s blog, as well as
11 Techniques To Make Your Website Rock information on his books

Entry-level analysis of performance tests: Yahoo Performance Page - Tips, tools, videos, a
10 Performance Problems Identified in 10 Seconds forum and more, all dedicated to WPO

Intermediate-level analysis of performance tests Book of Speed - Stoyan Stefanov shares his
and monitoring data: expertise in this work-in-progress online book
17 Performance Metrics You Should Care About
Velocity Conference Resources - Annual
WPO project management:
conference for the WPO industry
Managing a Web Performance Optimization Project

20 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com

 About Yottaa
Yottaa is an easy-to-use cloud service that optimizes,
protects, and monitors any website.

Try it Free • 24/7 Site Monitoring is always on alert & ready

Yottaa Site Monitor to help
• Do multivariate testing & web performance
troubleshooting with real-browsers
• See what your users see from any device, any
location, & any browser

Try Yottaa Site Monitor Free

Try it Free for 7 Days

Yottaa Site Optimizer
• On-the-fly front-end optimization
techniques streamline content
• Yottaa’s hybrid-cloud network
provides infinite scalability
• Global CDN ensures great user
experience from any location

Try Yottaa Site Optimizer Free

Like this eBook? Share it!

21 Yottaa eBook: Beginner’s Guide to Web Performance www.yottaa.com