User First Web

Tonight we launched CloudFour.com. Tomorrow we pick up the keys to our new office. Friday we start painting and assembling furniture. If all goes well, we’ll open doors on Monday and start planning our office warming party.

We’re overwhelmed, excited, and anxious. What a remarkable thing it is to start a company. There is really nothing that compares.

So why another web development company? Here’s why.

First, my co-founders and I have spent the last several years doing very similar work, but for a very specific market. In some ways, we’re just continuing what we’ve always been doing, but with a larger public presence and in a different location.

Second, we’re see new opportunities in spaces outside of the niche market we worked in. We see opportunities to:

• provide web site optimization services to people who want to make their sites faster;
• help companies determine their new media direction and emerging technology strategy;
• and develop applications for the 2.7 billion mobile devices in the world—it won’t be long before others realize that 2008 is going to be the Year of the Mobile Web.

We’ve also got some exciting side projects. More on that later. ;-)

Finally, we’re thrilled by the idea of building a business and a culture together, continuing to work closely with our former colleagues, and meeting new people tackling interesting challenges.

It’s been three fast months since Guy Kawasaki’s video kept me awake with the realization that I wanted to start my own company. I’m proud to be working with such an amazing group of co-founders, and I’m pleased that we’re all sharing equaling in the creation of the company. We have an all-star team. If this was a pick-up basketball game, I’d feel guilty for having so much talent on one squad.

Most importantly, I find myself going back to what inspired me about that video and what compelled me to choose a different, more risky direction. I believe we have a chance to make meaning—to make an impact—in the lives of others. That means a lot to me.

So that’s what Cloud Four is about. We’ll have more to discuss in the coming months. If you know of someone who can use our services, we would appreciate you pointing them in our direction.

Last night I pooh poohed a Slashdot article talking about the frailty caused by relying on TinyURL.

Less than 12 hours after I wrote my post, TinyURL.com started returning 404 errors prompting real concern from netizens.

Steve Rubel wrote, “The thought of an evaporating TinyURL…is all more than a little bit frightening, yet fascinating.” Marshall Kirkpatrick wrote about the dangers of using TinyURL and then jokingly harassed people on twitter who used TinyURL.

Everyone is missing the boat on this story. Less than 24 hours after a Slashdot article raising the alarm, the service that has been reliable for years goes down? Sounds like conspiracy to me.

Could it be that someone felt it necessary to prove a point about the dangers of TinyURL by taking the service to its knees? Or has the most unprobable outcome occurred and the long forgotten Slashdot effect finally returned? :-)

“There was a day when Web development was in a sad state of affairs. The majority of developers laughed at JavaScript, and were focusing on a killer new server-side web framework, or a new ORM library. The consensus was that that browser was dumb. The modern TN3270 if you will…

…We finally feel that the time has come for mobile phones to be the major device that users have for accessing their data and getting things done. You only have to travel around the world to see that already happening. Now, with the iPhone, a decent Java system, and more, we see the toolkits that will allow developers to build fantastic applications on the phone.”

Source: Devphone.com

Some recent news on web site performance:

• I got a chance to present to a class of web developers at PSU on site performance. I gave a variant of the presentation I gave a DevGroup NW. The presentation was video-taped and will be posted online soon. I enjoyed the class and had some great conversations after the presentation.
• Yahoo is using AJAX in an interesting way to speed up their site by pre-loading stylesheets for search results pages once someone starts typing in the search box.
• OReilly has announced a conference focusing on web performance called Velocity. Velocity will take place June 23-24, 2008 at the San Francisco Airport Marriott in Burlingame, California. They are currently soliciting proposals for presentations. I’ve got a topic in mind for a new presentation, and am thinking about pitching a session.

Getting a chance to present again was a lot of fun. I forget how much energy I get from talking to people about web technology. I want to thank Richard Appleyard again for the opportunity.

Ajaxian pointed to a post by Ned Batchelder on relative urls. I almost didn’t click through to the post because I didn’t think there was anything new to learn about URL syntax. Boy was I wrong.

Have you ever seen a url that looks like this?

• <img src=’//fast.cdn.net/pix/smiley.jpg’ />

We’ve also created links that started from the first slash and dropped the domain, but I’ve never seen links that dropped the http or the https from the link. Ned explains the benefits of this technique thusly:

Here, we’ve left off the protocol scheme, but included a host name. In this case, the protocol scheme from the displayed page will be used, but against the host in the URL. The relative URL system is still in play here: omitted portions of the URL at the beginning are taken from the base page, and the relative URL takes over whereever it starts. On an HTTPS page, this will be an HTTPS request to the CDN, on an HTTP page, it will be an HTTP request.

I love it when I learn something new about a piece of technology I’ve taken for granted for years.

One of the big features in HTML5 has been implemented by the Safari developers and it’s a doozy that I wasn’t aware of: client-side database storage.

From the Surfin’ Safari blog:

The client-side database storage API allows web applications to store structured data locally using a medium many web developers are already familiar with - SQL.

Like cookies, you can store the databases per domain. I’m struggling to determine if the persistent storage in Firefox is the same thing. Firefox’s implementation states clearly that it isn’t available to web pages (only “trusted callers”). IE seems to be (per usual) implementing something similar, but slightly different.

Niell Kennedy wrote a good summary of the different techniques for boosting Ajax performance using local storage and why this would be beneficial.

I’m starting to get excited about HTML5. This database feature could be very useful for web applications.

Later this morning, I fly to Dallas for Storage Networking World (SNW). I’m going to visit the Storage Networking Industry Alliance (SNIA) who is one of the sponsors of SNW.

The SNIA is celebrating its 10 year birthday at SNW. I’ve been working with the SNIA for half of that period. I don’t think I’ve seen a period of time when the SNIA had such great sustained momentum as it does right now.

SNIA just launched a major redesign of their Website. The SNIA staff had a plan for the launch. They were organized. And they worked their tails off to make it happen. It was great to watch.

On the technology front, SNIA just announced their Green Storage Initiative. There is a lot of enthusiasm around the idea of reducing energy consumption in data centers.

The future looks very bright for the SNIA, and I couldn’t be happier for them.

On a related note, if you are going to be at SNW or live in the Dallas area, I’d love to hear from you. Drop me a line or contact me via Twitter.

I’ve been helping a customer try to understand their web statistics. They get reports from AWStats, Google Urchin and Google Analytics. Needless to say, they are confused by different numbers each system gives and want to know which one is right.

People often want the following two things from web statistics:

1. Some sort of industry benchmark that is a fair comparison to their site so they can tell how their site measures up.
2. Absolute truth in web statistics instead of approximations and interpretations.

The reality is that they will never get either one.

Page views and visitor sessions are interpretation of what happened on a site. Every analytics package measures these slightly differently.

The only statistics that matter are your own statistics. You have to measure your site consistently, make improvements to the site, and then see if the improvements result in an increase in your key performance indicators.

Think of web analytics like runners measure their personal best times. Day-in and day-out, you’re measuring yourself against your time yesterday and trying to get better. What your competition is doing doesn’t matter nearly as much as improving your own performance.

Update As pointed out in the comments, the html for this site is being delivered as gzip. The css isn’t which is why YSlow is complaining. I need to remember to look to see what YSlow is complaining about before jumping to conclusions. I also have no explanation for why I read their FAQ multiple times and didn’t see the note that they support mod_deflate. So I take it all back. Disregard this entire post.

As those who attended my presentation on site speed know, I recently changed providers for my blog to MediaTemple because I was interested in their scalable grid structure.

Unfortunately, I forgot to check until after I had signed up and moved everything to MediaTemple before I found out that MediaTemple does not support mod_gzip for Apache.

I finally remembered to send them a support request asking if they had it in the plans or if it was just too difficult to implement on a grid server.

Absent good news from their support team, I’m afraid I’m going to have to move to another hosting solution. I love the service and system that MediaTemple has, but I feel like a hypocrite when I talk about site speed when I can’t optimize my own blog. It is frustrating.

At least my web site for our pet friendly vacation rental on the Oregon coast gets a “A” rating on the YSlow plugin. Thank god for small victories.

I owe Guy Kawasaki a lot even though I’ve never met him. A month ago, I watched a video where he talked about starting a business to make meaning versus making money. That video came at just the right time for me and led me on a new path in my life.

So I’m very pleased to attempt to repay the debt. Tonight on Twitter, someone commented on Guy Kawasaki’s new adventure Truemors and the fact that the site was slow. Guy replied that they were working on it. I sent Guy Kawasaki a quick note that I thought they needed to turn on gzip, but I was reading my YSlow plugin incorrectly.

So instead of trying to provide feedback via Twitter, I thought I’d write up the things that I think will have the greatest impact for Truemors.

First, let’s look at where the greatest time is spent. Here is a graph showing the download time for Truemors:

Click image to see full size

The thing to notice about the image is that the html downloads in 2445 milliseconds on my home broadband connection. The total download time is 12,949 milliseconds. This means that the server processing and html download only account for 18% of the total download time.

This is consistent with Yahoo’s 80/20 rule and indicates that the biggest benefit will come from optimizing front-end content.

• Reduce the Number of HTTP Requests — This appears to be the place with the biggest opportunity for improvement because the Truemors home page makes 79 http requests on an empty cache.

  Keep in mind that browsers will only make two http connections to the same domain at a time. It is because of this two connection limit that most web browsing never reaches the full broadband speeds available.

  To reduce the number of http requests, I would look first at consolidating the javascript files. There are currently 20 javascript files. Javascript files also contain the added determent that the browser will not start transfering any other files until the javascript completes. This effectively reduces the browser to serial downloads for the duration of the javascript downloads. Truemors download graph shows this happening.

  It appears that reducing the number of javascript files will have the largest impact on site speed.

• Move Javascript to the Footer — Browsers will not render any content below javascript until the javascript has loaded. When a page downloads, one of the things that makes it feel faster is if the page starts rendering first. Because of the number of javascripts in the html head on Truemors, the page remains blank and then snaps into place after a wait. This is a tell-tale sign that progressive rendering is getting blocked by javascript processing.
• Add expires headers to encourage caching — On the second time the Truemors home page is viewed, it still will download 125k of files and make 64 http requests. Adding expires headers will ensure that files aren’t download unnecessarily and the browser knows that it doesn’t need to check for new files.
• Test using YSlow and Speed Up Your Site — The YSlow Firefox plugin and the Web Page Analyzer provide free tools for testing the speed.

These are the items that I believe would make the biggest difference. Looking at the Truemors example, I can see one of the disadvantages of my favorite blogging software, WordPress, and its plugin architecture.

All of the plugins are putting their own javascript, images and sometimes even css into the page. These plugins aren’t part of a cohesive vision for the page and add the code to the page where ever they like. It is clear to me that doing things like combining javascript files may require more work because the plugins are responsible for adding them to the page.

I hope Guy Kawasaki and his partners find this information useful. I owe Guy a lot for inspiring me. This post is a small token of my gratitude. Thanks for the video.