Category: The Web

Effective Web Performance: The Wrong 80 Percent

2009-09-10 / spierzchala / 3 Comments

Steve Souders is the current king of Web performance gurus. His mantra, which is sound and can be borne out by empirical evidence, is that 80% of performance issues occur between the Web server and the Web browser. He offers a fantastically detailed methodology for approaching these issues. But fixing the 80% of performance issues that occur on the front-end of a Web site doesn’t fix the 80% of the problems that occur in the company that created the Web site. Huh? Well, as Inigo Montoya would say, let me explain.

The front-end of a Web site is the final product of a process, (hopefully) shaped by a vision, developed by a company delivering a service or product. It’s the process, that 80% of Web site development that is not Web site development, that let a Web site with high response times and poor user experience get out the door in the first place.

Shouldn’t the main concern of any organization be to understand why the process for creating, managing, and measuring Web sites is such that after expending substantial effort and treasure to create a Web site, it has to be fixed because of performance issues detected only after the process is complete?

Souders’ 80% will fix the immediate problem, and the Web site will end up being measurably faster in a short period of time. The caveat to the technical fix is that unless you can step back and determine how a Web site that needed to be fixed was released in the first place, there is a strong likelihood that the old habits will appear again.

Yahoo! and Google are organizations that are fanatically focused on performance. So, in some respects, it’s understandable how someone (like Steve Souders) who comes out of a performance culture can see all issues as technical issues. I started out in a technical environment, and when I locked myself in that silo, every Web performance issue had a technical solution.

I’ve talked about culture and web performance before, but the message bears repeating. A web performance problem can be fixed with a technical solution. But patching the hole in the dike doesn’t stop you from eventually having to look at why the dike got a hole in the first place.

Solving performance Web problems starts with not tolerating them in the first place. Focusing on solving the technical 80% of Web performance leaves the other 80% of the problem, the culture and processes that originally created the performance issues, untouched.

Does the browser really matter?

2009-02-25 / spierzchala / 5 Comments

Last fall it was Chrome. Now it’s Safari 4 Beta. Soon it will be Firefox 3.1 and IE 8.

Each browser has its harsh critics and fervent supporters. But in the end, does the browser really matter?

The answer to this question depends on who you speak to. Developers will say yes, because browsers make their lives hell, as none of them subscribe to the same set of standards for display, rendering, or code processing. I would bet that if you asked any developer, they would prefer that only one browser existed and was used by everyone.

The people at the end of the browser chain, you and I, don’t really care either. We only care when the browser drops an unexpected rendering surprise on us, or doesn’t work because the JavaScript functions were designed with Browser A and B in mind and we use C and the submit button on our purchase doesn’t work.
The question isn’t Does the browser matter? but Why does the browser still matter?

There is no reason to have five large browsers out there. There is no reason why they should all behave differently, render pages in their own unique way.

And while people will say that having multiple versions of multiple generations of uniquely developed browsers drives innovation and prevent stagnation in Web development, I say enough is enough.

There is no reason to have yet another browser. The browser doesn’t matter.

The content matters.

And when you switch the perspective around to that view, you should easily realize that the browser, any browser, is simply a window into the content being created for and by us. It should not matter to anyone that I use Opera, Safari, Firefox, IE, Camino, Chrome, or Lynx.

What does matter is that the content can be delivered to me the way I want it. Not the way the browser wants it.

What we need to realize is that browsers no longer matter. They are software. They are portals into what we are trying to do and say.

The browser is not the application; the Web is the application.

DNS: Without it, your site does not exist

2008-09-05 / spierzchala / 0 Comments

In my presentations and consultations on Web performance, I emphasize the importance of a correctly configured DNS system with the phrase: “If people can’t resolve your hostname, your site is dead in the water”.

Yesterday, it appears that the large anti-virus and security firm Sophos discovered this lesson the hard way.

Of course hindsight is perfect, so I won’t dwell for too long on this single incident. The lesson to be learned here is that DNS is complex and critical, yet is sometimes overlooked when considered the core issues of Web performance and end-user experience.

This complexity means that if an organization is not comfortable managing their own DNS, or want to broaden and deepen their DNS infrastructure, there are a large number of firms who will assist with this process. These firms whose entire business is based on managing large-scale DNS implementations for organizations.

DNS is critical. Never take it for granted.

Google Chrome: One thing we do know… (HTTP Pipelining)

2008-09-02 / spierzchala / 7 Comments

All: If you got here via a search, realize this is an old post (2008) and that Chrome now supports HTTP Pipelining and SPDY HTTP/3. Thanks, smp.

As a Web performance consultant, I view the release of Google Chrome with slightly different eyes than many. And one of the items that I look for is how the browser will affect performance, especially perceived performance on the end-user desktop.

One thing I have been able to determine is that the use of WebKit will effectively rule out (to the best of my knowledge) the availability of HTTP Pipelining in the browser.

HTTP Pipelining is the ability, defined in RFC 2616, to request multiple HTTP objects simultaneously across an open TCP connection, and then handle their downloads using the features built into the HTTP/1.1 specifications.

I had an Apple employee in a class I taught a few months back confirm that Safari (which is built on WebKit) cannot use HTTP Pipeling for reason that are known only to the OS and TCP stack developers at Apple.

Now, if the team at Google has found a way to circumvent this problem, I will be impressed.

Web Performance, Part VII: Reliability and Consistency

2006-09-07 / spierzchala / 0 Comments

In this series, the focus has been on the basic Web performance concepts, the ones that have dominated the performance management field for the last decade. It’s now time to step beyond these measures, and examine two equally important concepts, ones that allow a company to analyze their Web performance outside the constraints of performance and availability.

Reliability is often confused with availability when it is used in a Web performance context. Reliability, as a measurement and analysis concept goes far beyond the binary 0 or 1 that the term availability limits us to, and places it in the context of how availability affects the whole business.
Typical measures used in reliability include:

Minutes of outage
Number of failed measurements
Core business hours

Reliability is, by its very nature, a more complex way to examine the successful delivery of content to customers. It forces the business side of a company to define what times of day and days of the week affect the bottom-line more, and forces the technology side of the business to be able to account not simply for server uptime, but also for exact measures of when and why customers could not reach the site.
This approach almost always leads to the creation of a whole new metric, one that is uniquely tied to the expectations and demands of the business it was developed in. It may also force organizations to focus on key components of their online business, if a trend of repeated outages appears with only a few components of the Web site.

Consistency is uniquely paired with Reliability, in that it extends the concept of performance to beyond simple aggregates, and considers what the performance experience is like for the customer on each visit. Can a customer say that the site always responds the same way, or do you hear that sometimes your site is slow and unusable? Why is the performance of your site inconsistent?

A simple way to think of consistency is the old standby of the Standard Deviation. This gives the range in which the population of the measurements is clustered around the Arithmetic Mean. This value can depend on the number of measures in the population, as well as the properties of these unique measures.

Standard Deviation has a number of flaws, but provides a simple way to define consistency: a large standard deviation value indicates a high degree of inconsistency within the measurement population, whereas a low small standard deviation value indicates a higher degree of consistency.

The metric that is produced for consistency differs from the reliability metric in that it will always be measured in seconds or milliseconds. But the same insight may arise from consistency, that certain components of the Web site contribute more to the inconsistency of a Web transaction. Isolating these elements outside the context of the entire business process gives organizations the information they need to eliminate these issues more quickly.

Companies that have found that simple performance and availability metrics constrain their ability to accurately describe the performance of their Web site need to examine ways to integrate a formula for calculating Reliability, and a measure of Consistency into their performance management regime.

Amazon Adds New Server Response Header to HTTP Spec

2006-09-01 / spierzchala / 2 Comments

I like it when a major online retailer takes the initiative and extends the existing HTTP specifications.

Date: Fri, 01 Sep 2006 13:58:58 GMT
Server: Server
x-amz-id-1: 1S269NQQQYFX2DF09G7Z
x-amz-id-2: jiSzL7NRwWiEx7pM/90anU1AW9p9Qts3
Set-cookie: session-id-time=1157698800l; path=/; domain=.amazon.com; expires=Fri Sep 08 07:00:00 2006 GMT
Set-cookie: session-id=002-9480265-0783223; path=/; domain=.amazon.com; expires=Fri Sep 08 07:00:00 2006 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: text/html; charset=ISO-8859-1
nnCoection: close
Transfer-Encoding: chunked

Anyone know what the nnCoection: close header represents?

AJAX has a positive effect on Web Performance

2006-02-17 / spierzchala / 4 Comments

Or so it seems from this article!

Makes sense if you think of it. Only part of the page is updated, so less bandwidth is used. And if you compress that data as well, you save even more.

Maybe AJAX is not just a novelty.

UPDATE [Feb 17 2006]: Some great additional articles are showing up in the comments. The catalogue demonstration is very cool.

UPDATE [April 29 2022]: AJAX, in the form of Single Page Application (SPA) Frameworks won.

Is Web 2.0 Suffocating the Internet?

2005-10-21 / spierzchala / 0 Comments

At my job, I get involved in trying to solve a lot of hairball problems that seem obscure and bizarre. It’s the nature of what I do.

Over the last 3 weeks, some issues that we have been investigating as independent performance-related trends merged into a single meta-issue. I can’t go into the details right now, but what is clear to me (and some of the folks I work with are slowly starting to ascribe to this view) is that the background noise of Web 2.0 services and traffic have started to drown out, and, in some cases, overwhelm the traditional Internet traffic.

Most of the time, you can discount my hare-brained theories. But this one is backed by some really unusual trends that we found yesterday in the publicly available statistics from the Public Exchange points.

I am no network expert, but I am noticing a VERY large upward trend in the volume of traffic going into and out of these locations around the world. And these are simply the public peering exchanges; it would be interesting to see what the traffic statistics at some of the Tier 1 and Tier 2 private peering locations, and at some of the larger co-location facilities looks like.

Now to my theory.

The background noise generated by the explosion of Web 2.0 (i.e. “Always Online”) applications (RSS aggregators, Update pings, email checkers, weather updates, Adsense stats, etc., etc.) are starting to really cause a significant impact on the overall performance of the Internet as a whole.

Some of the coal-mine canaries, organizations that have extreme sensitivity to changes in overall Internet performance, are starting to notice this. Are there other anecdotal/quantitative results that people can point to? Have people trended their performance/traffic data over the last 1 to 2 years?

I may be blowing smoke, but I think that we may be quietly approaching an inflection point in the Internet’s capacity, one that sheer bandwidth itself cannot overcome. In many respects, this is a result of the commercial aspects of the Internet being attached to a notoriously inefficient application-level protocol, built on top of a best-effort delivery mechanism.

The problems with HTTP are coming back to haunt us, especially in the area of optimization. About two years ago, I attended a dinner run by an analyst firm where this subject was discussed. I wasn’t as sensitive to strategic topics as I am now, but I can see now that the topics being raised have now come to pass.

How are we going to deal with this? We can start with the easy stuff.

Persistent Connections
HTTP Compression
Explicit Caching
Minimize Bytes

The hard stuff comes after: how to we fix the underlying network? What application is going to relace HTTP?

Comments? Questions?

Geek Irony: Adult Entertainment, Bandwidth Leeching and Apache Modules

2005-06-10 / spierzchala / 0 Comments

Port80 tells a great story about a product that they had in the pipe that would prevent bandwidth leeching (defined in the post). [here]

Their observation that technology that could do this would be of particular interest to purveyors of adult-oriented sites does not surprise me. However, their rationale for stopping development was not based on any moral issues; the fact is that LAMP development platforms are preferred in this industry because of their cost.

Now, I am sure that some enterprising Apache hacker could very quickly develop a functional module that would plug right onto the server to deliver on some of the basic design elements laid out by the Port80 Team. This would be a benefit to both the IIS and Apache communities, as interest in this feature would push for a similar feature in IIS, allowing Port80 to finally release this software.

Rightly or wrongly, porn has fueled a large number of the developments in the open source community. My place is not to judge; it is to benefit from the advancements.

Google Discretely Approves Indexing of Video Porn

2005-04-06 / spierzchala / 0 Comments

No, this is not a shameless attempt to drive me to the top of the rankings. It is a legitimate comment on a quiet little secret of the new Google Video Search.

Google co-founder Larry Page has announced that the company wants the public to send in its homemade videos – and he doesn’t mind how naughty they are.
“There might be an adult section, or something like that. I don’t think that is going to be a big issue,” Page told attendees at the National Cable and Telecommunications Show in San Francisco on Monday, where he was speaking on a panel.

Ouch! John Cheesman points out the HR nightmare that this will pose.

Then again, Google is just admitting what no other respectable online firm will: Internet porn is a huge untapped market for services.

Porn has been the innovator in the internet. It was the Commercial Internet for a long time. But none of the Web services firms are willing to approach or admit that they have major online adult entertainment companies as clients.

As a Web measurement geek, I have always seen this niche as a gold mine. Adult entertainment sites live or die on Web performance. Developers for adult sites are able to push the limits and demand more from their applications. They want to know where and how people connect to their site. They need to optimize their code and image/streaming delivery like few other sites do.

It’s time to get off the ivory tower and accept that adult entertainment could drive the online services revenue opportunity for a long time to come.