Since I started self-hosting this blog again on August 6 2008, I have been trying to find more ways to pull traffic toward the content that I put up. Like all bloggers, I feel that I have important things to say (at least in the area of Web performance), and ideas that should be read by as many people as possible.

As well, I have realized that if I invest some time and effort into this blog, it can be a small revenue source that could get me that much closer to my dream of a MacBook Pro.

The Analysis

In a post yesterday morning, Darren Rowse had some advice on when the best time to release new post is. Using his ideas as the framework, I pulled the data out of my own tracking database and came up with the chart below. This shows the page view data between September 1 2007 and September 15 2008 based on the day of the week vistors came to the site.

Using this data and the general framework that Darren subscribes to, I should be releasing my best and newest thoughts in a week on Monday and Tuesday (GMT).

After Wednesday, I should release only less in-depth articles, with a focus on commentary on news and events. And I must learn to breathe, as I suffer from an ailment all to common in bipolars: a lack of patience.

A new post doesn’t immediately find its target audience unless you have hundreds or thousands (Tens? Ones?) of readers who are influential. If you are luckyin this regard, then these folks will leave useful comments, and through their own attention, help gently show people that a new post is something they should devote their valuable attention towards.

It takes a while for any post to percolate through the intertubes. So patience you must have.

Front-loaded v Long-tailed

Unless, of course, your traffic model is completely different than a popular blogger.

The one issue that I had with Darren’s guidance is that it applies only to blogs that are front-loaded. A front-loaded blog is one that is incredibly popular, or has a devoted, active audience who help push page views toward the most recent 3-5 posts. Once the wave has crested, or the blogger has posted something new, the volume of traffic to older posts falls off exponentially, except in the few cases of profound or controversial topics.

When I analyzed my own traffic, I found that the most of my traffic volume was aimed toward posts from 2005 and 2006. In fact, more recent posts are nowhere near as popular as these older posts. In contrast to the front-loaded blog, mine is long-tailed.

There are a number of influential items in my blog which have proven staying power, which draw people from around the world. They have had deep penetration into search engines, and are relvant to some aspect of peoples’ lives that keeps pulling them back.

Summary

I would highly recommend analyzing your traffic to see it is front-loaded or long-tailed. I know that I wish that this blog  was more front-loaded, with an active community of readers and commentators. However, I am also happy to see that I have created a few sparks of content that keep people returning again and again. If your blog is  long-tailed, then when you post becomes far less relevant than ensuring the freshness and validity of those few popular posts. Ensure that these are maintained and current so that they remain relevant to as many people as possible.

Tags: analysis, analytics, blog posts, Blogging, content creation, content release, current, Darren Rowse, freshness, front-loaded, hits, long tail, maintain, page views, posting, search engines, statistics, traffic, update, Web Performance

Part of the problem with making a lot of East to West trips across the US is that the flights back are a nightmare for timing. You either lose most of a day or have to take a red-eye.

Well, taking the red-eye has only one advantage: you get to camp in the airline lounge and get some work done that you have been too tired/jetlagged to deal with.

I am in the United Red Carpet Lounge. It is 18:33 PDT, and my flight boards at 22:00 PDT. I have been here since 15:00 PDT. I have caught up with a client project, completed my (dreaded) weekly timesheet, booked accommodation for my Columbus, OH trip, and tidied up an analysis script that I use to process client measurement data.

Seems odd that this is the most productive time of the week.

This trip is a 48-hour turnaround from Boston to LA to finish up the project for a large client. The first half was handled by some colleagues, and was detailed here.

Then,when I get home, I have to go to NYC (Long Island City actually) for the day on Monday. And, as I mentioned above, Columbus which is set for the middle of the month.

Compared to some jet-setters out there, this is nothing. But I travelled so much between August 15 and November 15 that I went from 2,000 miles on United to well into Premier (24,000+ miles). This trip makes the fourth cross-country trip in 2.5 months. Not bad for a homebody.

I have three more hours. Think I will sit back and watch Trois Couleurs: Blanc.

Tags: analysis, blog, book, Boston, business, client, cro, data, EAD, HTTP, IE, IM, IP, it, LAN, measurement, Om, One, pr

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.

Tags: analysis, Consistency, HTTP, measurement, performance, Reliability, Web Performance

In the last article in this series, the concept of baselining your measurements was discussed. This is vital, in order for you and your organization to be able to identify the particular performance patterns associated with your site.

Now that’s under control, you’re done, right?

Not a chance. Remember that your site is not the only Web site your customers visit. So, how are you doing against all of those other sites?

Let’s take a simple example of the performance for one week for one of the search firms. This is simply an example; I am just too lazy to change the names to protect the innocent.

Doesn’t look too bad. An easily understood pattern of slower performance during peak business hours appears in the data, presenting a predictable pattern which would serve as a great baseline for any firm. However, this baseline lacks context. If anyone tries to use a graph like this, the next question you should ask is “So what?”.

What makes a graph like this interesting but useless? That’s easy: A baseline graph is only the first step in the information process. A graph of your performance tells you how your site is doing. There is, however, no indication of whether this performance trend is good or bad.

Examining the performance of the same firm within a competitive and comparative context, the predictable baseline performance still appears predictable, but not as good as it could be. The graph shows that most of the other firms in the same vertical, performing the identical search, over the same period of time, and from the same measurement locations, do not show the same daytime pattern of performance degradation.

The context provided by benchmarking now becomes a critical factor. By putting the site side-by-side with other sites delivering the same service, an organization can now question the traditional belief that the site is doing well because we can predict how it will behave.

A simple benchmark such as the one above forces a company to ask hard questions, and should lead to reflection and re-examination of what the predictable baseline really means. A benchmark result should always lead a company to ask if their performance is good enough, and if they want to get better, what will it take.

Benchmarking relies on the idea of a business process. The old approach to benchmarks only considered firms in the narrowly defined scope of the industry verticals; another approach considers company homepages without any context or reliable comparative structure in place to compensate for the differences between pages and sites.

It is not difficult to define a benchmark that allows for the comparison of a major bank to a major retailer, and a major social networking site, and a major online mail provider. By clearly defining a business process that these sites share (in this case let’s take the user-authentication process) you can compare companies across industry verticals.

This cross-discipline comparison is crucial. Your customers do this with your site every single day. They visit your site, and tens, maybe hundreds, of other sites every week. They don’t limit their comparison to sites in the same industry vertical; they perform cross-vertical business process critiques intuitively, and then share these results with others anecdotally.

In many cases, a cross-vertical performance comparison cannot be performed, as there are too many variables and differences to perform a head-to-head speed analysis. Luckily for the Web performance field, speed is only one metric that can be used for comparison. By stretching Web site performance analysis beyond speed, comparing sites with vastly different business processes and industries can be done in a way that treats all sites equally. The decade-long focus on speed and performance has allowed other metrics to be pushed aside.

Having a fast site is good. But that’s not all there is to Web performance. If you were to compare the state of Web performance benchmarking to the car-buying public, the industry has been stuck in the role of a power-hungry, horsepower-obsessed teenage boy for too long. Just as your automobile needs and requirements evolve (ok, maybe this doesn’t apply to everyone), so do your Web performance requirements.

Technorati Tags: Web+performance, benchmarking, performance+benchmarking, evolution

Tags: analysis, benchmarking, evolution, performance benchmarking, Web Performance

I have a shiny new Canadian passport that I want to fill with stamps.

Anyone in London need a Web performance analysis from an expert in the field? A detailed examination of your site and a comparison with other national, regional and internationl competitors, complete with a rockin’ statistical breakdown of key metrics?

Daddy needs some airline miles…

Technorati Tags: Passport, Canada, travel, business travel, London

Tags: analysis, business, Canada, HTTP, IE, it, metrics, Om, One, performance, Technorati, web, Web Performance, Web performance analysis

You’ll notice that I have added the SiteMeter and StatCounter logos to the sidebar. Yes, I am a stats freak, but I also wanted to monitor how quickly each of these two services can deliver a page of basic stats to someone who clicks on the links.

So far, you can see the performance difference here.

I know that there are other services out there, and if you can think of one you use that i have forgotten, drop an e-mail or a comment. I want to create a site analytics benchmark, and also do some analysis of the differences in values captured by each of the services.

UPDATE [17:31 GMT]: I added OneStat to the list. New graph is here.

UPDATE [18:01 GMT]: I added ShinyStat to the list. New graph is here.

Technorati Tags: Web analytics, hit tracking, visitor tracking

Tags: analysis, analytics, GrabPERF, GrabPERF.org, HTTP, it, live, Om, One, performance, PHP, Technorati, tracking, update, web, Web analytics

Yes, I know. For the fourth time in a week, this is a post with a link to my resume.

But last night, while I was writing an e-mail to someone about the long-term future of GrabPERF, I wrote something that I had to read twice when it came out.

GrabPERF is my resume.

How can a simple Web application be a resume?

In my case, it highlights all of the things that I am interested in:

• Web performance
• Statistical analysis
• Clear presentation of data and information
• Web development skills
• Database administration skills
• System administration skills
• Distributed systems

GrabPERF showcases everything that I have taught myself over the last seven years. And I am proud of it.

So, what do you use for your resume?

Technorati Tags: GrabPERF, resume

Tags: analysis, app, application, data, database, EAD, GrabPERF, GrabPERF.org, HTML, HTTP, IE, IM, information, it, Om, One, performance, pr, Technorati, web, web app, web application, Web Performance

Dave Sifry released a state of the search post yesterday. Between re-building my laptop and getting a client project out, I missed the original post.[here]

Thanks Dave! And continued success.

Technorati: Technorati, Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis

IceRocket: Technorati, Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis

Tags: analysis, blog, client, GrabPERF, HTML, HTTP, IE, IM, improvement, it, LAN, Om, performance, pr, search, seo, Technorati, the Origin, traffic, web, web 2.0, Web Performance, Web+performance

Ping-O-Matic. Weblogs.com.

Two of the sites that have seen surges in Web traffic recently.

My unsubstantiated theory is that as summer ends, Web traffic is seeing its usual surge, amplified by the new interest in blogs and Web 2.0 properties.

For the small companies who have effectively had the summer off, it’s time to re-adjust your capacity-planning estimates…upward.

Why? Rising oil prices will reduce travel. Disenchantment with movies will reduce going out. Gourmet take-home will reduce restaurant visitation. And increasing broadband access will increase demand for online services.

Be afraid…and get ready for more traffic. Lots more traffic.

Have you optimized your site for maximum performance yet?

Technorati: Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis

IceRocket: Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis

Tags: analysis, blog, broadband, EAD, HTTP, IE, IM, it, LAN, Om, online, optimize, performance, pr, seo, Technorati, traffic, web, web 2.0, Web Performance, Web+performance

Yikes!!!

Can you say capacity planning nightmare?

Technorati: Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis, ping-o-matic, pingomatic

IceRocket: Web Performance, Capacity Planning, Web 2.0, SEO, traffic analysis ping-o-matic, pingomatic

Tags: analysis, blog, HTTP, IM, it, LAN, media, Om, performance, seo, Technorati, traffic, web, web 2.0, Web Performance, Web+performance