Performance Matters

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.

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

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: Usability, Web design, Worst website, Ryan Stewart, Rich Internet Application, RIA, performance.

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: Social Issues Research Centre, SIRC, YouGov, mouse rage, Web design, performance, Web performance management, health.

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:

In a previous post here, I described the Web Site Response Time Model and linked to the CMG2000 paper (E-Commerce Response Time: A Reference Model) in which I introduced it.
In 2001, Peter Sevcik and John Bartlett of NetForecast published their paper on Understanding Web Performance, in which they first outlined a formula for computing Web page download times based on total bytes, the number of components, and on round-trip times between browser and server(s).
That formula was simplified and explained in a highly readable paper by Alberto Savoia -- Web Page Response Time 101 -- published in July 2001 in STQE, the magazine of software testing and quality engineering (now Better Software Magazine).

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: Yahoo, Pareto principle, 80/20 Rule, performance, Web performance management, IBM Page Detailer,Keynote, page size, round trip time, RTT, TCP, slow start.

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

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: ITIL, InfoWorld, ISO 20000, performance, Web performance management, service level management, SLM.

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: Shirley Kaiser, SKDesigns, Sitepoint, performance, Web site optimization, Checklist, page design, site design, service level, SLM, optimization, Web optimization, tuning, Web tuning.

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: Andrew King, Speed up your site, performance, Web site optimization, page design, site design, service level, SLM, optimization, Web optimization, tuning, Web tuning.

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 18, 2006

Web Performance Engineering [2]

Today I'm going to look at another list of Top Ten Web Performance Tuning Tips, following up on my promise to review Web site and application performance advice.

Today's list of tuning tips was created by Patrick Killelea, the author of Web Performance Tuning, first published by O'Reilly in 1998, then revised in 2002. When the second edition came out, Patrick also updated his 1998 top ten list, presumably to reflect changes in the rapidly maturing Internet and Web environment. But O'Reilly still publishes the 1998 list alongside the 2002 list without any further explanation, even though just four recommendations appear on both lists!

I see this as evidence that publishers are a lot more interested in selling a book than they are in the usefulness of its content. So let's blame O'Reilly and give Patrick the benefit of the doubt here, and focus on his latest list only. Abbreviating his recommendations, they are:

1. Check for compliance with standards
2. Minimize use of JavaScript and style sheets
3. Turn off the Web server's reverse DNS lookups
4. Try out a free analysis tool (to find bottlenecks)
5. Use simple servlets or CGI
6. Get more memory
7. Index your database tables well
8. Make fewer database queries
9. Look for packet loss and retransmission
10. Monitor your Web site's performance

When someone publishes a top ten list, I expect it to include the ten most important and useful recommendations -- especially when its author has written the most comprehensive book available on the subject. In this case, even allowing for the maturing of the Web since 2002, I have no idea how Patrick could have come up with this list. I have three problems with it -- what's in it, what's not in it, and its order. Today I will tackle mainly the first area; here are some brief thoughts about each of his recommendations:

Check for standards compliance by using Weblint or other HTML checking tools.
Content that conforms to the HTML 4.0 standard will load faster and work in every browser because the browser then knows what to expect. Note that Microsoft-based tools create content that does not even use the standard ASCII character set, but instead uses many proprietary Microsoft characters that will display in Netscape as question marks and can slow down rendering.

performance

Watch out for Composition Tools with a Bias

Minimize the use of JavaScript and style sheets.
JavaScript is a major source of incompatibility, browser hangs, and pop-up advertising. Style sheets require separate downloads before the page can be displayed. There are some nice features to both JavaScript and style sheets, but at a big cost. Life is better without them.

Turn off reverse DNS lookups in the Web server.
If left on, reverse DNS will log a client's machine name rather than IP address, but at a large performance cost. It is better left off. You can always run log analysis tools which look up the names later.

in 1997

Prior to Apache 1.3, HostnameLookups defaulted to On. This adds latency to every request because it requires a DNS lookup to finish before the request is completed. In Apache 1.3, this setting defaults to Off.

Try out a free analysis tool.
I've provided a free analysis tool at my Web site that can tell you whether or not your bottleneck is in DNS, or because of connection time or content size, or is on the server side. Work on improving the slowest part first.

a page about his book

Use simple servlets or CGI.
Use simple servlets, CGI, or your Web server's API rather than any distributed object schemes like CORBA or EJB. Distributed object schemes are intended to improve a programmer's code-writing productivity, but they do so at an unacceptable cost in performance for end-users.

Get more memory.
Your Web server, middleware, and database all will probably do better with more memory, if they still use their hard disks frequently. Hard disks are literally about a million times slower than memory, so you should buy more memory until the disks are phased out.

Index your database tables well.
Spectacular improvements are possible if you are inadvertently doing full-table scans on every hit of a particular URL. Indexes allow you to go directly to the data you need.

spectacular improvements

Make fewer database queries.
If you can cache content in your middleware or servlets, do it. Making connections to a database and using those database connections is typically a bottleneck for performance.

doing less work

any

Look for packet loss and retransmission.
There are many network snooping and monitoring tools to help you do this. Intermittent slowness is often due to packets being lost or corrupted. This is because a time-out period needs to pass before the packet is retransmitted.

Set up monitoring and automated graphing of your Web site's performance.
This information is free online in Chapter 4 of the second edition of Web Performance Tuning.

you can't manage what you don't measure

researching it

So, to sum up my audit of Patrick's list of ten guidelines, I vote to reject two altogether (#1 and #2), downgrade one (#3) to a priority well outside my top ten, accept four (#4, #5, #6, and #7), restate two (#8 and #10) as general principles that don't belong on this list, and reserve judgment on one (#9).

That opens up 5 or 6 slots for the things that Patrick missed -- but what should they be? I will tackle that subject in a follow-up post.

Tags: Killelea, Patrick Killelea, O'Reilly, performance, Web performance, page design, site design, service level, SLM, optimization, Web optimization, tuning, Web tuning.

Performance Matters

Sunday, March 18, 2007

Index of Migrated Posts

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

Wednesday, February 28, 2007

Recent posts now migrated

Thursday, February 22, 2007

Performance Matters has moved

Monday, December 18, 2006

Understanding Web Usability

Saturday, December 16, 2006

Web Design and Mouse Rage Syndrome

Tuesday, December 12, 2006

Yahoo! on Web Page Performance

Friday, October 27, 2006

ITIL Crash Course

Monday, August 28, 2006

Web Performance Engineering [4]

Tuesday, August 22, 2006

Web Performance Engineering [3]

Friday, August 18, 2006

Web Performance Engineering [2]

Recent Posts

TABLE OF CONTENTS

Links

Monthly Archives

Contributors