My Google Alerts today picked up a post from a former colleague of mine, commenting on another post from the Yahoo! Interface blog.

I had some problems following the stream in the Performance Matters post, so I thought I would this post to clear up my thoughts.

A technical note up front: Using a waterfall chart that only shows non-persistent connections gives a very skewed view on how a modern Web page page performs. Persistent connections and modern TCP/IP stacks with fast-retransmit algorithms and window-scaling have seend a trend away from network-related performance issues in the recent past.

After the dot-bomb crash, the overabundance of bandwidth (in the form of over-built fiber-optic networks) made backbone and end-to-end connectivity issues for business and most home broadband users almost completely disappear.

The wealth of bandwidth (ok, North America consumers arethe poor cousins compared to their European and Asian counterparts) removed the veil of “it’s the network” which had been the crutch of performance engineers for many years, and exposed the effects of poor design and badly designed infrastructure.

In many cases, poor page design could be overcome. However, issues with core infrastructure and application design were (and are) notoriously difficult to resolve without spending a lot of money and investing a large amount of time and manpower.

So, when these issues were combined with the shrinking budgets and constricted IT staffing in the post-boom era, application performance issues became (and still are) the root-cause of most Web performance issues.

In recent months, as the use of Internet telephony, rich-media streaming, file-sharing, RSS, and SOA products rise nearly exponentially, the bandwidth crunch is starting to re-appear. This is something I first speculated about in October 2005 [here].

In one area, I do agree with the Performance Matters post: the larger the page, the slower download. However, the ongoing debate is one that pits the “more smaller” crown against the “fewer larger” crowd. The “fewer larger” crowd appears to be losing, given the design of most modern Web pages.

The only other comment I can fairly make here is that the majority of the sources cited in the Performance Matters post are 5-6 years old. In that time, I have learned a lot about Web performance, and that the post is more relevant to to the state of the Internet at that time, and not now.

Tags: broadband, designed infrastructure, Google, Internet telephony, IP telephony, North America, over-built fiber-optic networks, SOA, TCP/IP, Web page page, Web Performance, Yahoo!

In the Business 2.0 Blog, the author posits on the possibility that eBay may be reaching the theoretical limits of its network growth potential. In this case, I do not mean the technical TCP/IP network; I mean the business to client network that has been created around this community.

eBay has been trying to move into new markets and diversify — classifieds and rentals being two new oppotunities. And the recent price increase has infuriated some of their long-term community members.

From personal experience, the treatment that Samantha received from the PayPal division has been enough for both of us to walk away from using it.

So, eBay, what are you going to do to make your user-community ecstatic to use you again? How are you going to make yourself a place where people want to do business, not a place where they grudgingly do business because you are a near-monopoly?

How will you make your community love you again?

Tags: blog, business, client, community, HTML, HTTP, IE, IM, IP, it, monopoly, Om, personal, pr, TCP, TCP/IP