Success Stories of Software Engineer: Performance Measurement Website:Part 1

Your website is undoubtedly one of your most valuable marketing channels for your business and therefore it’s important to know exactly how well it is achieving your goals and where you need to make improvements. - See more at: http://demon.net/blog/monitor-website-performance-5-key-metrics/#sthash.blR6SU4W.dpuf

I love to Cook. Cooking is a precise science, so I learned early on that I needed different measurement tools if I wanted to avoid demoralizing kitchen fails. See-through Pyrex cups for measuring liquids or melting butter in the microwave. Measuring scoops in a variety of sizes for dry ingredients. Scales if I’m following a European recipe. Just like there’s no one-size-fits-all measurement tool in my kitchen, there’s no miraculous all-purpose tool for measuring the performance of your website.
It always happens. Our websites get to be too slow. We keep adding features and graphics, and JavaScript doodads on our sites, and the website performance slows to a crawl. That’s an embarrassment for any web developer, especially one that is proud of creating responsive sites. Before you can speed up the website, you have to figure out exactly what’s causing the bottleneck. The first step in any sort of performance optimization is to know what is running slowly and using up resources. Fortunately, many tools are available to help you with this measurement task.
In our industry, there’s a lot of language around how we time website speed. We tend to assume that outsiders understand our language, but something I read recently indicates that the average person doesn’t. We need to fix that.
A couple of weeks ago, I came across this article written by Luxury Daily writer Rachel Lamb: Luxury marketers dramatically drop site loading times. Given our own research into web performance and luxury markets here at Strangeloop, my curiosity was piqued.
The article made this statement, based on a recent report by SmartBear:
The average luxury site’s load time went from 2.6281 seconds in the third quarter to 1.321 seconds in the fourth quarter of 2011.
Looking at the results made me laugh and cry:

Home page	Load/response time (as cited in article)
Rolls-Royce	0.169
Porsche (US)	0.256
Jaguar (US)	0.260
Mercedes-Benz (US)	3.405
Ferrari (US)	4.585
Infiniti (US)	4.154
Prada (US)	0.170
Cartier	0.244
Calvin Klein	3.742
Burberry (US)	3.548
Hugo Boss (US)	0.658

Given that the ideal load time is 2 seconds or less, this is a good-looking set of numbers — too good-looking. I did a little research of my own via WebPagetest.* the three new columns are mine.

Home page	Load/response time (as cited in article)	First byte	Start render	Load time
Rolls-Royce	0.169	0.788	2.712	13.339
Porsche (US)	0.256	0.187	0.766	4.760
Jaguar (US)	0.260	0.538	1.098	10.722
Mercedes-Benz (US)	3.405	0.380	2.274	9.507
Ferrari (US)	4.585	0.483	1.409	2.831
Infiniti (US)	4.154	0.909	2.849	15.528
Prada (US)	0.170	0.723	10.800	12.142
Cartier	0.244	0.175	0.740	1.340
Calvin Klein	3.742	0.316	0.540	0.786
Burberry (US)	3.548	0.408	2.020	6.364
Hugo Boss (US)	0.658	0.353	3.593	6.425

What do these numbers mean?

If you’re a relative newcomer to the performance scene and the tables above looks like numerical gibberish, it’s not your fault. I’ll get into the terminology later in this post. For now, suffice to say that there’s a lot of variance in these numbers.
So, you have response time, time to first byte, start render time, and load time. Which set of numbers do you rely on to answer the #1 question site owners ask:

How fast does my site load for real users?

The short answer is: None of them, totally.
The long answer is: It’s complicated. Keep reading.

If you can’t trust numbers, what can you trust?

Numbers in a spreadsheet are a good way to spot larger patterns and trends, but if you want to get a ground-zero look at your site’s performance, capturing videos and filmstrip views of your pages’ load times are one of the best ways to go.
To illustrate, let’s take a closer look at two of the top-performing sites, according to this article: Prada and Rolls-Royce.
Remember that, in the luxury website performance article, Prada was lauded as having one of the fastest sites, with a response time of 0.17 seconds? While the response time may have been quick, there’s a serious problem at the network level. If you view Prada’s page load as a filmstrip (a nifty WebPagetest feature that I don’t think gets talked about enough), you see that, from a user’s perspective, nothing happens on the page until around 10.5 seconds, which roughly correlates to the start render time of 10.8 seconds.
You can also output the filmstrip to a video:
If you view the filmstrip for Rolls-Royce, you see that nothing starts to happen until around 3 seconds, again correlating roughly to the start render time of 2.712 seconds. This might sound acceptable on paper, but note that the feature banner doesn’t load till after the 11-second mark. An eye tracking study by usability expert Jakob Nielsen found that delaying banner load by 8 seconds resulted in the banner being virtually ignored when it finally showed up.

Four key performance measurement terms explained (so that normal people can understand them)

First, I want to be straight about the fact that I don’t think SmartBear was trying to mislead anyone with their numbers. Without knowing how SmartBear defined “response time” in their tests, it’s impossible to comment on their results. Because of this vagueness, I think Ms. Lamb has made two understandable mistakes — mistakes I encounter frequently when I talk about performance outside the geek zone:

Using “response time” and “load time” interchangeably.
Not realizing that “response time” can mean any number of completely different things.

There isn’t a lot of effort to educate the lay public — such as journalists, and even customers — about what these terms mean. To address this problem, here’s a simple guide to understanding fundamental website performance measurement terms, and when and why you should care about each.

Response time

What it means: Response time is incredibly tricky, and it causes a lot of the confusion I encounter. It can refer to any number of things, depending on whom you ask: server-side response time, end-user response time, HTML response time, time to last byte with no bandwidth/latency, and on and on. Long story short: There’s no single definition.
Caveats: If someone starts talking to you about response time, ask them to clarify which response time they mean. Be wary of anyone who tries to sell you on the idea that there’s only one definition. If user experience matters to you, ask how whatever type of response time you’re looking at relates to what the end user actually sees.
When it’s useful: Different types of response time measurements tell you different things, from the health of your back end to when content starts to populate the browser. As I’ve already said — and it bears repeating — you need to know what you’re measuring and why.

Time to first byte

What it means: Time to first byte is measured from the time the request is made to the host server to the time the first byte of the response is received by the browser.
Caveats: Time to first byte doesn’t really mean anything when it comes to understanding the user experience, because the user still isn’t seeing anything in the browser.
When it’s useful: For detecting back-end problems. If your website’s time to first byte is more than 100 milliseconds or so, it means you have back-end issues that need to be examined. (Web performance consultant Andrew King has written a good post about this, as has Google performance expert Pat Meenan.)

Start render

What it means: As its name suggests, “start render” indicates when content begins to display in the user’s browser. This term seems to have evolved as an alternative to “end-user response time”, but it’s not yet widely used outside of hardcore performance circles.
Caveats: Doesn’t indicate whether the first content to populate the browser is useful or important, or simply ads and widgets.
When it’s useful: When measuring large batches of pages, or performance of the same page over time, it’s good to keep an eye on this number. Ideally, visitors should start seeing usable content within 2 seconds. If your start render times are higher than this, you need to take a closer look.

Load time

What it means: The time it takes for all page resources to render in the browser — from those you can see, such as text and images, to those you can’t, such as third-party analytics scripts. (Geek version: “Load time” is also known as “document complete time” or “onLoad time”. It’s measured when the browser fires something called an “onLoad event” after all the page resources have fully loaded. No matter what you call it, it’s used as a primary measuring stick for site performance.)
Caveats: Needs to be taken with a grain of salt, because it isn’t an indicator of when a site begins to be interactive. A site with a load time of 10 seconds can be almost fully interactive in the first 5 seconds. That’s because load time can be inflated by third-party scripts, such as analytics, which users can’t even see.
When it’s useful: Load time is handy when measuring and analyzing large batches of websites, because it can give you a sense of larger performance trends.

Three things to remember:

1. There’s no single “right” way to measure performance. Each measurement tells you something meaningful about how your site performs.

2. You need to understand the different performance measurement terms so that you can interpret your own data. If you don’t, sad to say some people will take advantage of your ignorance to mislead you for their own benefit. (For example, it’s a little-known fact that some performance vendors have convinced site owners to tie bonuses for key employees to backbone test results, which do not measure real-world performance.)

3. As a matter of due course, you always need to gather large batches of data and rely on median numbers. But you also need to periodically get under the hood and take a real-world look at how your pages behave for real users.

PageSpeed’s scores are based on a number of factors, including how well your scripts are minimized, images optimized, content gzipped, tap targets being appropriately sized and landing page redirects avoided.
With 40% of people potentially abandoning pages that take more than 3 seconds to load, caring about how quickly your pages load on your users devices is increasingly becoming an essential part of our development workflow.

Performance metrics in your build process

Although manually going to the PageSpeed Insights to find out how your scores is fine, a number of developers have been asking whether it’s possible to get similar performance scoring into their build process.
The answer is: absolutely.

Introducing PSI for Node

Today we’re happy to introduce PSI for Node - a new module that works great with Gulp, Grunt and other build systems and can connect up to the PageSpeed Insights service and return a detailed report of your web performance. Let’s look at a preview of the type of reporting it enables:

The results above are good for getting a feel for the type of improvements that could be made. For example, a 5.92 for sizing content to viewport means “some” work can still be done whilst a 24 for minimizing render blocking resources may suggest you need to defer loading of JS using the async attribute.

Lowering the barrier of entry to PageSpeed Insights

If you’ve tried using the PageSpeed Insights API in the past or attempted to use any of the tools we build on top of it, you probably had to register for a dedicated API key. We know that although this just takes a few minutes, it can be a turn off for getting Insights as part of your regular workflow.
We’re happy to inform you that the PageSpeed Insights service supports making requests without an API key for up to 1 request every 5 seconds (plenty for anyone). For more regular usage or serious production builds, you’ll probably want to register for a key.
The PSI module supports both a nokey option for getting it setup in less than a few minutes and the key option for a little longer. Details on how to register for an API key are documented.

Getting started

You have two options for how you integrate PSI into your workflow. You can either integrate it into your build process or run it as a globally installed tool on your system.

Build process

Using PSI in your Grunt or Gulp build-process is fairly straight-forward. If you’re working on a Gulp project, you can install and use PSI directly.

Install

npm install grunt-pagespeed --save-dev

Then load the task in your Gruntfile:

grunt.loadNpmTasks('grunt-pagespeed');

and configure it for use:

pagespeed: {

options: {

nokey: true,

url: "https://www.html5rocks.com",

strategy: "mobile"

}

You can then run the task using:

grunt pagespeed

Installing as a global tool

You can also install PSI as a globally available tool on your system. Once again, we can use npm to install the tool:

npm
install -g psi

And via any terminal window, request PageSpeed Insights reports for a site (with the nokey option or an API specific key as follows):

psi http://www.html5rocks.com --nokey
--strategy

=mobile

or for those with a registered API key:

psi http://www.html5rocks.com --key=

YOUR_API_KEY
--strategy

=mobile

That’s it!

Go forth and make performance part of your culture

We need to start thinking more about the impact of our designs and implementations on user experience.

Solutions like PSI can keep an eye on your web performance on desktop and mobile and are useful when used as part of your regular post-deployment workflow.

Success Stories of Software Engineer

HTML Dropdown

Tuesday, 16 June 2015

Performance Measurement Website:Part 1