NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Sunday, March 18, 2007

Index of Migrated Posts

All posts from this site have now been migrated to their new locations at Web Performance Matters. This index is a cross-reference to the new site for anyone who arrives here from an old link.

My previous post (see below) also lists new locations for a few recent items that are not included in this list.


Foundations



Performance as an Aspect of Usability



Web Usability Books



SLM Overview



Managing Rich Internet Applications



Web Performance Engineering: Building in Performance



Setting Performance Objectives



Capacity Planning and Load Testing



Measuring Performance



Detecting, Diagnosing, and Fixing Problems



Reporting on Performance



SLM Cost/Benefit Analysis



Performance in the News



Labels:

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Wednesday, February 28, 2007

Recent posts now migrated

I have completed the migration of these posts to my new blog, located at webperformancematters.com:

Understanding Web Usability

One of the great things about the Web has always been its democratic nature. Anyone can participate. But once you do, your contributions are wide open to public scrutiny. Good or bad, someone will evaluate your Web content.


Tags: , , , , , , .

See the new site, here.


Web Design and Mouse Rage Syndrome

Have you ever been frustrated at a Web site that downloads with the speed of an Alaskan glacier? Or become angry when a favorite site, or your Internet connection, is down. Have you experienced any of these symptoms:

  • Faster heart rate?
  • Increased sweating?
  • Furious clicking of the mouse?
  • Simultaneous clicking and cursing the screen?
  • Bashing the mouse?
Come on now -- admit it! Maybe some of them, just once or twice? Because if any of this sounds familiar, you're not alone.
Tags: , , , , , , , .

See the new site, here.



Yahoo! on Web Page Performance

A recent post by Tenni Theurer, who works in a performance team at Yahoo!, appeared in the Yahoo! User Interface Blog. The post begins with the claim that ...

... most of web page performance is affected by front-end engineering, that is, the user interface design and development.
Theurer introduces the Pareto Principle, commonly known as the 80/20 rule, which states that 80% of the consequences come from 20% of the causes. In the case of Web page download time, she argues that the backend systems which generate an HTML document -- apache, C++, databases, etc. -- should be regarded as the 80% of causes that account for only 20% of download time. The other 80% of download time is spent fetching the elements that make up the page, such as images, scripts, and stylesheets.


Tags: , , , , , ,, , , , , .

See the new site, here.




ITIL Crash Course

Anyone involved with IT these days knows that ITIL is a hot topic, and one that seems to get hotter every month. ITIL, the Information Technology Infrastructure Library, has evolved from work sponsored by the UK Government in the late 1980's. According to the official ITIL site, it is "the most widely accepted approach to IT service management in the world".


Tags: , , , , , , .

See the new site, here.




101 Essential Checklists

Continuing my series of posts on Web performance guidelines, today I'm reviewing one chapter of a new book, Deliver First Class Web Sites: 101 Essential Checklists, by Shirley Kaiser of SKDesigns, published by Sitepoint in July 2006.


Tags: , , , , , , , , , , , , , .

See the new site, here.



Are Online Retailers Ready for Business?

Every year, more and more shoppers turn to the Web for their holiday shopping, with total sales in 2006 projected to be in the multi-billion dollar range. But will online retailers be up to the task? Our recent study suggests that many will not...


Tags: , , , , , , , , , .

See the new site, here.

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Thursday, February 22, 2007

Performance Matters has moved

I have joined UpRight Marketing as a partner, and after a lot of site design and development work, Performance Matters is now being transformed into a new journal with its own domain, at WebPerformanceMatters.com.

I built both sites myself using the Squarespace platform, and I'm now in the process of migrating all the old posts. Other than details of the progress of the migration, I won't be posting anything new here. But check out this post on the new site for all the details of the changes I'm implementing on the new platform.

See you there!
--Chris

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Monday, December 18, 2006

Understanding Web Usability

One of the great things about the Web has always been its democratic nature. Anyone can participate. But once you do, your contributions are wide open to public scrutiny. Good or bad, someone will evaluate your Web content.

People Recognize Poor Design
In the Web's early days, when people were adjusting to this new medium, most online critiques applied to a site's design. If you created a really ugly site, before long your handiwork would end being featured on a site dedicated to bad design, or even included on someone's all-time list of bad sites. Today, the collaborative features of the Web 2.0 environment such as blogs, forums, and widely used folksonomies practically guarantee that truly awful design will receive the recognition it deserves. Such criticism can be constructive; people can learn from good examples of what NOT to do.

Today, blogs and wikis extend their democratic and educational influences beyond site design to site content. This can be tough on the writer who wants to explore new ideas. But as Wikipedia, one of the best example of online collaboration, advises all contributors:
If you don't want your writing to be edited mercilessly or redistributed by others, do not submit it.
This is excellent advice, because the collaborative search for truth online is not subject to parliamentary or academic niceties. If someone advances a weak argument, people will be quick to point out its flaws. And an unpopular opinion can produce flaming responses.

Is Web Usability a Sham?
For example, last week Ryan Stewart, who has his own blog, and also writes a ZDNet blog about Rich Internet Applications (RIAs), wrote that Usability on the web is a sham, arguing that ...
While accessibility and standards are great for the Web, the concept of usability has been overblown. Usability as we define it is basically the rules for how the Web should behave while in the confines of the Web browser. But Web applications don't have to exist inside the browser and relegating them to these antiquated notions of usability is bad for progress.
To support this argument, he used the Back button as an example of a browser usability problem that RIA developers could eliminate altogether.

I think the central idea behind his argument was that the RIA technologies -- because they offer the developer more options -- can be applied to deliver usability improvements in Web-based applications. But I'm afraid he expressed it very poorly, first by over-generalizing in his criticisms of the concept of Web usability, and second by trying to use the Back button -- one of the most intuitive and widely-understood browser conventions -- as an example of poor usability.

Naturally, his post has been generating a small firestorm of responses ranging in tone from expletive-laden outrage to carefully-argued disagreement. In their different ways, both those examples (along with other responses) argue that Stewart's post is full of opinions and assertions that are not supported by any evidence, and that (to put it bluntly) Stewart doesn't really know what he's talking about.

Marshaling the Right Skills
Unfortunately, this is a common problem in the field of Web design. An effective online application must be available, responsive, easy to navigate, and deliver value to its user. This demands a wide array of skills rarely found in a single individual. As a result many sites are designed and built by people who are aware of only a small subset of the issues they should be considering. And all too often, someone in the site development process -- a business manager, someone in marketing, a Web designer, or a site developer -- makes key design decisions without understanding the consequences. And the challenges are even greater when developing a Rich Internet Application.

Simply getting more people involved isn't the solution. Some really bad Web site designs have been the result of design by committee. Even if you follow a good checklist, like this one by Vitaly Friedman, you will overlook some important aspect -- often site performance. The problem is the sheer breadth of knowledge required to do a good job. For evidence, read the Wikipedia entry on Web Design. It's an unbalanced, poorly organized, collection of information that offers little help with the process of creating an effective site.

The only answer is to get better, more knowledgeable, people involved. Start with a good overview of the process, like Usability for the Web: Designing Web Sites that Work by Tom Brinck, Darren Gergle, and Scott D. Wood. As they say in the book's introduction:
To ensure high usability on our own Web projects, we defined a development process that incorporates proven techniques from software and usability engineering, graphic design, project management, and other disciplines. The process had to be practical and lean. It had to allow us to work on multiple projects of varying sizes with fixed budgets. It had to help us keep track of the details that can kill usability and destroy profitability. This book is about that process.
Then find people who understand what the book is talking about to do the work -- and don't interfere!

Tags: , , , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Saturday, December 16, 2006

Web Design and Mouse Rage Syndrome

Have you ever been frustrated at a Web site that downloads with the speed of an Alaskan glacier? Or become angry when a favorite site, or your Internet connection, is down. Have you experienced any of these symptoms:
  • Faster heart rate?
  • Increased sweating?
  • Furious clicking of the mouse?
  • Simultaneous clicking and cursing the screen?
  • Bashing the mouse?
Come on now -- admit it! Maybe some of them, just once or twice? Because if any of this sounds familiar, you're not alone.

Mouse Rage Syndrome
The consequences of poor Web site performance don't usually make news, unless there's a big outage on Black Friday or Cyber Monday. Then the story invariably focuses on the business lost by companies whose sites were overloaded or down. But what about the effects of poor performance on customers? A recent study by the Social Issues Research Centre (SIRC), an independent, not-for-profit organisation based in Oxford, UK., provides this perspective.

Researchers found that badly designed and hosted websites cause stress and anger, and coined the term "Mouse Rage Syndrome" (or MRS). They concluded that five key IT flaws in the way websites are designed and hosted may lead to harmful health effects.

Those five problems will come as no surprise to any regular user of the Web: slowly loading pages, confusing layouts, excessive pop-ups, unnecessary advertising, and site unavailability. But as I was saying in my previous post, it is not fair to blame IT for these problems, when most of them are the result of poor design choices by Web site designers and developers.

Damaging Customers' Health
The study combined data from a YouGov poll of 2,500 people with physiological tests on a separate sample of Internet users, who were asked to find information from a number of different websites. Tests measured physical and physiological reactions to website experiences, looking at brainwaves, heart-rate fluctuations, muscle tension and skin conductivity. According to the report:
When the test participants came to the 'problem' sites that we had deliberately chosen as comparisons for the 'Perfect Website' evaluation exercise [a prior study], responses changed quite dramatically in most, but not all, cases. While a few managed to stay calm and simply 'rise above' the problems presented by crazy graphics and slow-loading pages, others showed very distinct signs of stress and anxiety.

Some changes in muscle tension were quite dramatic...While this was happening, the participant's faces also tensed visibly, with the teeth clenched together and the muscles around the mouth becoming taught. These are physically uncomfortable situations that reduce concentration and increase feelings of anger.
These reactions, if not managed, can eventually lead to other, more serious, health problems.

Poor Designs Can Kill
According to the SIRC report, "users want Google-style speed, function and accuracy from all of the websites they visit, and they want it now. Unfortunately, many websites and their servers cannot deliver this". The result is consumers seeking alternative websites in a bid to avoid undue stress and Mouse Rage.

Jacques Greyling, managing director of Rackspace Managed Hosting, who commissioned the study, commented:
We believe that businesses that are selling online have a duty to their customers to ensure that the experience is as stress free as possible. The public has shown that it wants to buy online, ... (so) businesses need to provide simple and easy to navigate layouts, whilst focusing on speed and uptime.
If more studies confirm these findings, which will probably seem obvious to anyone who spends a lot of time online, maybe more Web designers will get the message that their poor designs are not just killing the business. They could be killing people -- really.

Performance Matters!

Tags: , , , , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Tuesday, December 12, 2006

Yahoo! on Web Page Performance

A recent post by Tenni Theurer, who works in a performance team at Yahoo!, appeared in the Yahoo! User Interface Blog. The post begins with the claim that ...
... most of web page performance is affected by front-end engineering, that is, the user interface design and development.
Theurer introduces the Pareto Principle, commonly known as the 80/20 rule, which states that 80% of the consequences come from 20% of the causes. In the case of Web page download time, she argues that the backend systems which generate an HTML document -- apache, C++, databases, etc. -- should be regarded as the 80% of causes that account for only 20% of download time. The other 80% of download time is spent fetching the elements that make up the page, such as images, scripts, and stylesheets.

She presents two graphics to illustrate this point. A table summarizing home page measurements of 8 popular Web sites -- Yahoo!, Google, MySpace, MSN, eBay, Amazon, YouTube, and CNN -- shows that retrieving HTML accounts for between 5% and 38% of their download times, and just 12% on average. The other 88% is taken up downloading and rendering other page elements.

Waterfall Charts
Yahoo Waterfall Chart [click to enlarge] To illustrate the reason why HTML accounts for such a small percentage of all page download time, Theurer uses the diagram shown here [click to enlarge]. I call this kind of data visualization a 'waterfall chart', because of its shape, and because it is similar to the way the waterfall model of software development has always been always depicted graphically.

Theurer says (in blog comment #22) she used the IBM Page Detailer tool to get the measurement data shown in this diagram. I have used this tool, and it produces a Chart Panel similar to the one above, which is a graphical representation of all of the component downloads that make up a single page.

I have not seen much documentation online, but if you take the time to register with IBM and download the software, its Help file is quite informative. It explains that the ...
... IBM Page Detailer attaches to the workstation TCP/IP socket stack and monitors all of the HTTP/HTTPS protocol based communications between your Web browser and the network. IBM Page Detailer then displays web activities in a series of color-coded bars.
It also has quite a long section on Results Analysis and other Considerations regarding Web download times.

Keynote Waterfall Chart [click to enlarge] This kind of analysis is not new. Since 1998, Keynote has offered a similar Web Content Diagnostics feature in its MyKeynote portal -- here's a datasheet describing the newest version of this service, recently released. For example, the figure on the right [click to enlarge] shows a Keynote diagnostic measurement of the Yahoo Search Marketing page.

Unlike the IBM Page Detailer, which always measures from the desktop where it is installed, Keynote's diagnostic measurements can be taken from anywhere on the company's worldwide network of 2500 measurement computers (or "agents"). This example comes from an agent located on the Verizon network in Houston.

The Lesson for Web Designers
Even without looking at the data in any detail, the message of these waterfall charts is evident from their general shape:
Web page download times rise with the number of bytes to be downloaded and with the number of separate content elements comprising a page.
This fact is not news to anyone whose job involves monitoring or managing site performance. Even for a Web page consisting only of a single HTML file, you cannot compute download time simply as page size divided by bandwidth. That's because of the way the TCP slow-start protocol works, sending one or two packets (typically 1.5Kb - 3KKb), then doubling, and doubling again, up to the receive window size of the client.

But most Web pages these days contain many imbedded graphic objects, CSS files, and script files, all of which extend download times. Most of these files are small, requiring just a few TCP packets to transmit. But every transmission requires a separate "Turn", adding another round-trip delay time (RTT) from the client (i.e. browser) to the server(s) and back. This behavior has been widely documented and is well-understood by performance specialists: Since then, many articles and papers have reiterated this message. An entire industry segment -- Application Delivery Systems -- has emerged to help organizations offset delays in delivering their Web pages and satisfy customers' expectations of responsiveness. All the same, as is clear from the comments posted to the Yahoo! User Interface Blog, some Web designers and developers still need to learn this lesson.

Tags: , , , , , ,, , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Friday, October 27, 2006

ITIL Crash Course

InfoWorld magazine cover Anyone involved with IT these days knows that ITIL is a hot topic, and one that seems to get hotter every month.

ITIL, the Information Technology Infrastructure Library, has evolved from work sponsored by the UK Government in the late 1980's. According to the official ITIL site, it is "the most widely accepted approach to IT service management in the world". For a lot more detail, see the wikipedia entry for ITIL, which describes it as "a framework of best practice approaches intended to facilitate the delivery of high quality information technology (IT) services", and goes on to explain that:
ITIL outlines an extensive set of management procedures that are intended to support businesses in achieving both quality and value for money in IT operations. These procedures are supplier independent and have been developed to provide guidance across the breadth of IT infrastructure, development, and operations.
If you subscribe to any technical magazine, newsletter or blog written for an IT audience, then you have probably seen more than one story on the benefits of adopting ITIL-based approaches to IT management. The latest publication to jump on the ITIL bandwagon is this week's InfoWorld (October 23, 2006, issue 43) -- also available online -- which contains an excellent 5-page article introducing ITIL.

The magazine cover touts the importance of ITIL today: To keep pace with business strategy, IT need a blueprint for delivering services. That's where ITIL, the modern-day bible of governance, comes in. The article itself is arranged like an interview in which the authors, Randy Steinberg and Michael Goodwin, answer ten questions. I won't list each question, because often you have to read the answers for the next question to make sense. But here's a summary.

Ten questions
Question 1 presents three examples to show how ...
ITIL raises customer satisfaction, reduces waste in the IT organization, and lowers operating costs.
Questions 2 and 3 introduce the processes that together make up the ITIL discipline of Service Support, and the related idea of a Configuration Management Database (CMDB) that provides the foundation for storing and retrieving all information about the IT infrastructure, and making timely management decisions.

Question 4 moves to the equally important discipline Service Delivery, and includes an informative diagram showing the central role of Service Level Management as the function that regulates the interface between Business and IT. [Incidentally, this highlights a perennial issue we face in high tech, where the ever-shifting meanings of common terms makes it hard for people to communicate clearly. In this instance, ITIL's definition of Service Level Management covers a narrower range of activities than my previous use of the same term here.]

Question 5 introduces the other ITIL books: Introduction to ITIL, Planning to Implement Service Management, ICT Infrastructure Management, Applications Management, The Business Perspective, Security Management, and Software Asset Management.

Question 6 asks, ITIL has been around for more than 15 years. Why is it now taking hold in the United States?, and answers:
The United States has always lagged behind Europe in the discipline of IT infrastructure management. Go to a bookstore, and you'll find precious few books on the subject. Go to the universities, and you'll visit a lot before finding one that teaches it. One reason that this is changing is the increasing impact of European- and Asian-owned companies operating in the United States, all saying, Hey, get on board! You need to be ITIL-compliant. That's how we run our shops over here.
It also refers to something I have written about here. Whereas IT customers of the past were "internal staffers, managers, and auditors" ...
these days increasing numbers of IT customers ... are external -- actual customers of the business itself, interacting via public Web sites. If systems fail, potential buyers are likely to take their business elsewhere; potential damage to corporate reputation is high.
Question 7 deals with the needs of large and small IT shops.

Questions 8 and 9 address getting started and getting outside help with your ITIL implementation.

Question 10 talks about ITIL's relationship to ISO 20000. I will discuss the relationship between ITIL, COBIT, and some ISO standards in a future post.

Summing up
The article concludes that ...
Companies that have initiated ITIL efforts are already seeing higher customer-satisfaction levels and reduced costs and labor. Although not a panacea for all IT challenges, ITIL is a fundamental conceptual change for how IT will be doing business in the 21st century. Its time has come.
From all the evidence I see, this is an accurate summary. If ITIL's time has not yet come for your organization, maybe you should expect it to arrive soon. In future posts, I'll be writing a lot more about how ITIL applies to Web Performance Management. But if you just finding out about ITIL, I recommend this InfoWorld article as a good starting point.

Tags: , , , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Monday, August 28, 2006

Web Performance Engineering [4]

Continuing my series of posts on Web performance guidelines, today I'm reviewing one chapter of a new book, Deliver First Class Web Sites: 101 Essential Checklists, by Shirley Kaiser of SKDesigns, published by Sitepoint in July 2006.

Sitepoint is known among Web developers for its practical publications, and Kaiser deserves credit for including a full chapter on site performance alongside all the other useful advice in this book.

As its title states, this book does not cover topics in great depth. Each checklist item is stated, then discussed briefly. But Kaiser does include enough detail to justify each recommendation, and often includes examples of how to do it. Chapter 11 (Web Site Optimization) is 19 pages long, presenting 41 recommendations arranged into six checklists:
Creating Clean, Lean Markup
Minimizing URLs
Optimizing CSS
Optimizing JavaScript
Supporting Speedy Server Responses
Optimizing Images, Multimedia, and Alternative Formats
However, once I started reviewing Kaiser's checklists, I soon noticed a remarkable similarity between her choice of topics and those covered in Andrew King's book, Speed Up Your Site -- the subtitle of which also happens to be Web Site Optimization.

A bit more scrutiny, summarized in this spreadsheet, revealed similarities in the naming, wording, and organization of the checklist items too. Although Kaiser cites Speed Up your Site in her first paragraph, she does not actually recommend it explicitly, or mention any collaboration with Andrew King. But she seems to have relied heavily on that one source as the main inspiration for her Web Site Optimization chapter.

To give Kaiser her due, rather than simply parroting all of King's recommendations, she has ignored the more extreme ones. All the same, her material still shares most of King's limitations and omissions, many of which I listed earlier when I reviewed his book, and which I plan to cover in future posts in this series.

In conclusion, if you'd like a handy summary of the material in King (except for his excellent discussion of the Psychology of Performance), Kaiser's book has it, plus about 300 more pages of useful checklists on other topics. I recommend it, because I don't think you can go far wrong with any book from Sitepoint. If you want to read more about the same topics, you can find Speed Up your Site on sale on Amazon these days under half price. But don't assume that either book will give you a well-rounded picture of Web Site Optimization issues and techniques.

For more ideas about that, continue reading Performance Matters, and I'll do my best to fill in the holes.

Tags: , , , , , , , , , , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Friday, August 25, 2006

Are Online Retailers Ready for Business?

Every year, more and more shoppers turn to the Web for their holiday shopping, with total sales in 2006 projected to be in the multi-billion dollar range. But will online retailers be up to the task?

My team at Keynote recently studied 25 top online retailers in three categories: Books and Music, Electronics and Apparel. The study involves measuring a typical customer's navigation path through each site -- from Home Page, to Search, to Product Details, and finally Checkout.

Using computers ("agents") that emulate the behavior of a customer using an IE browser, we measured the exact same sequence of steps on each site from 10 locations throughout the US, over various connection speeds, every hour for a month (mid-May through mid-June, 2006). This produces a large data sample (over 6,000 data points per site), which we then subject to a lot of statistical analysis. By the time we publish the report, we believe we have a reliable picture of a site's health and readiness.

This is the second year we've conducted this particular study, and the 2006 results were surprising. While the top-ranked sites continue to provide excellent service -- almost perfect availability, excellent download speeds, and very little inconsistency -- the lowest-ranked sites had some serious failings. Without doubt, the performance problems we saw were bad enough to dissatisfy customers and impact the bottom line. They fall into three general areas:
  1. Outages:
    We consider a transaction (the sequence of steps) to be unavailable if any part of the purchase path fails so that the customer is unable to complete their transaction. And when 30% or more of our measurements during an hour report a site as unavailable, we count it as an outage.

    Only 4 of the 25 measured sites registered no outages during the month, while some of the least reliable sites had more than 15 hours of downtime. These hours are during the peak period each day (8 a.m. to midnight EDT). Apparel sites were especially outage-prone, averaging over 4 outages each.

    We all know how frustrating it can be to try to buy something online only to have the process fail midway through, or to not even be able to get to the site's Home Page. I'm not sure which is the more annoying. And if these major retail sites can't stay up under relatively light summertime loads, how will they respond when their traffic increases dramatically during the holiday season? In the increasingly competitive retail marketplace, being down for even a single hour at that time of year can have a significant financial and brand impact.

  2. Load Handling:
    One area of our analysis involves a site's ability to keep up with its current load, without any performance degradation. On a site that is built with sufficient capacity, performance does not change noticeably as traffic fluctuates during the day. At this time of year, most retail sites should be idling, because traffic is light. Indeed, we saw that the best sites, Barnes and Noble and Gap, had virtually no slowdowns each day, indicating that they can handle their present load comfortably.

    Of course, it takes a controlled load-testing project to discover what happens when traffic volumes are doubled, tripled, quadrupled, and so on. But judging from our measurements, these sites do appear well prepared to handle increases in their load. In contrast, several sites already display significant load-handling issues now, slowing down as much as 100% each day. For example, a page that normally appears in 3 seconds would take 6 seconds under load. Not only does this kind of sluggish behavior annoy current customers, it suggests that these sites are highly likely to crumble under the increased load, once holiday shoppers begin to fill their online storefront -- unless something is done before then to increase capacity.

  3. Dial-Up Performance:
    While many of us can't remember the last time we used dial-up, a large percentage of users still use slower connections. These might not be dial-up, but a poor wireless connection, a slow hotel connection, or a satellite connection may not be much faster. So site designers shouldn't forget about their bandwidth-challenged customers.

    Yet that's exactly what seems to be happening. Many retail sites seem set on alienating the dial-up user. The sites we tested averaged 30-40 seconds per page, which really adds up fast in a 10-page shopping transaction. And in some cases we even clocked Home Pages taking over 100 seconds to download. A few sites got it right, Dell being a good example. They have the fastest Home Page in the study for dial-up users because they serve a slightly trimmer page for this audience.
In short, the best sites are ready, and their performance sets the standard for the retail industry. But even among the leading retailers we studied, many could do a lot to improve the quality of the online shopping experiences they offer.

More importantly, if one of these sites is struggling now, what will happen in December, when I desperately need to buy my last-minute gifts? I'm not optimistic they will be ready to take my business. And I absolutely hate fighting the crowds at the local shopping mall, so -- along with thousands of others like me -- I'll be buying from their competitor's site.

Update #1: To hear a longer (12.5 min) discussion of these results and related issues in the retail industry, listen to a StorefrontBacktalk Week In Review Audiocast discussion I took part in. Click on the link for the section on whether the major E-Commerce sites are ready for the holiday rush or the holiday crash.

Update #2: I was also interviewed about the study today (8/25) on CNBC's Closing Bell program. As you might expect, that interview was a lot shorter than the StorefrontBacktalk Audiocast. You can view a replay online; the username is keynote and password is keynote0895.

Tags: , , , , , , , , , .

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Tuesday, August 22, 2006

Web Performance Engineering [3]

Continuing my series on Web performance guidelines, today I am reviewing another book -- Speed Up Your Site, by Andrew B. King, published by New Riders in 2003.

A while back, when I was reviewing Web Usability Books, I promised to cover Speed Up Your Site, but never got around to doing so -- for reasons I will explain. A full table of contents listing all 19 chapters is available online; in summary, the book has six parts:
Part I - The Psychology of Performance (38 pages)
Part II - Optimizing Markup: HTML and XHTML (99 pages)
Part III - DHTML Optimization: CSS and JavaScript (111 pages)
Part IV - Graphics and Multimedia Optimization (85 pages)
Part V - Search Engine Optimization (39 pages)
Part VI - Advanced Optimization Techniques (79 pages)
Part of my difficulty in reviewing this book was that I have mixed feelings about it. Naturally, I am always pleased to see an entire book devoted to performance issues. Also, Part I is particularly good. Containing 77 references, it is a very well-researched survey of an important subject rarely covered in books about Usability. On the other hand, I am not nearly as impressed with the rest of its advice and guidelines, for two reasons: their correctness, and their completeness.

First correctness. Regarding the actual content, my issue is not that Speed Up Your Site contains factual errors. As far as I can tell, its content is accurate. But some of its recommendations -- although they may indeed improve performance -- are so unnatural that they are not really the correct way to tackle the problem. This concern is summarized by Alexander Bunkenburg in this review on Amazon.com:
This book concentrates almost exclusively on sending fewer bytes from the server to the browser. It gives a large collection of tricks how to write shorter html, xhtml, css, and JavaScript. Some of these tricks are useful. Others however go against standards, and some seriously go against maintainability. I'd be reluctant to give this book to my team. One may be tempted into shaving off bytes, spending a big effort and yet producing unmaintainable code.
The problems that can result from deliberately violating standards are highlighted by David Rose in another Amazon review:
In today's world, where "standards based" coding is becoming more prevalent and adherence to the W3C standards for HTML coding is being recommended, this book just grated on me. While there is a great deal of great information, there are also a large number of "gotchas" to watch out for as well.

The book proposes to use HTML tags without their corresponding closing tags, not to use required elements whenever possible, avoid using quotes in HTML tags, and many other ways of creating "non-valid" code. This will "optimize" your code a bit more by reducing the characters in it, but it will also create problems for you in the future.

In summary, while the book does give a lot of good information, it often steers you away from standard code. If you are unsure what is considered "standard" and required for creating valid XHTML/CSS, you are best served skipping this book as it will teach you to create invalid code.
Bunkenburg's review also touches on my second area of concern -- completeness. Any book about speeding up Web site performance should (in my view) at least mention all the important topics, to let the reader know what options exist. Some important topics that receive little or no coverage in Speed Up Your Site are:
  • Page Types: All pages are not created equal, and users' tolerance for delays changes depending on where they are in their interaction with a site. So a single page design approach cannot be applied to all pages.
  • Maximize content reuse: A common mistake as sites grow is to use many different names (URLs) for the same thing, reducing the efficiency of browser caching.
  • Ratio of HTML base to content: There is a significant difference between the way browsers handle the base (or index) portion of the page, and referenced content elements, which can affect page download time.
  • Image resizing: For efficient page rendering, it helps to specify HTML HEIGHT and WIDTH tags for all embedded images. And for download speed, avoid resizing images in the browser.
  • Performance of SSL: All online business sites use encryption, and pages that use SSL encryption incur significant overheads. This is an issue that demands a separate section in any book about site performance.
  • Content Delivery Networks (CDNs): Akamai went public in 1999, and was widely used by 2002. Mirror Image, Cable and Wireless (formerly Digital Island), and Speedera also offered CDN services in 2002. How can any book about speeding up your site not even mention this technology?
In fairness to King, any discussion of the book's coverage should point out the following disclaimer, which appears in its Introduction:
Although the primary emphasis is on optimizing client-side technologies, this book also covers server-side techniques and compression to squeeze the maximum performance out of your site. These are all techniques that most designers and authors can control. Instead of focusing on esoteric server-side tuning limited to system administrators, this book focuses on optimizing the content that you deliver. For a server-oriented look at performance, see Web Performance Tuning, by Patrick Killelea.
But most of the omissions I listed are not related to server-side tuning, and of the two that are (SSL and CDNs), only SSL is discussed by Patrick Killelea, and his only recommendation is to use an SSL accelerator card. And in 2002, CDN technology could hardly be considered "esoteric", especially in a book which, to quote its author, is "not for beginners".

There is a lot more to be said on most the above topics, and in future posts I will expand upon them.

Tags: , , , , , , , , , , , .