ProjectX Blog

The Velocity conference on web performance and operations is in full swing there are a wealth of information in the slides.

Here is a selection of the most interesting presentations:

• AOL PageTest – AOL have created an opensource tool call PageTest to test performance on IE 7/8 and they have created a online page test to show the performance of your website from East coast USA (Slides)
• High performance Ajax application – Yahoo. Another awesome slide deck from the Yahoo performance team. (Slides)
• Improving Netflix performance – Mesuring and testing performance at Netflix (Slides)
• Jiffy open source performance measuring tool – a new tools to measure the performance of your javascript. (Zip of Slides)
• Profiling Dynamic Web Applications in Firebug – (Slides)

Enjoy!

Its official, Google are now giving priority to faster sites. (As mentioned a month ago) Slow sites risk their “Quality” score being reduced.

So its important to Google….

Larry and Sergey, articulated this philosophy in Ten things Google has found to be true. One of these principles is “Fast is better than slow.” We’ve found this rule to be especially applicable to the landing pages of AdWords ads. When a user clicks an ad, a landing page that loads quickly provides a better user experience than a landing page that loads slowly.

So here’s the rub.

Starting today, this load time factor will be incorporated into your keywords’ Quality Scores. Keywords with landing pages that load slowly may get lower Quality Scores (and thus higher minimum bids).

Now that your Google ads monies at risk, there’s never better a time to speed up your pages.

Firefox 3 has been officially released and looking under the hood it has been tweaked for faster page loading.

Here are the key connection values in Firefox 2 and 3.

As we can see the maximum number of connections and number of connections per server has been increased. So that’s good news for more parallel downloading. And they’ve also increased the number of persistance connections so that future requests will be a bit faster. Another interesting thing is that http pipelining is turned off by default.

So far Firefox 3 has been snappier and more memory efficient! Download Firefox 3 today and squeeze a bit more performance from your bandwidth!

The team from ActionThis have created a new product called Runtime Page Optimizer that will dynamically optimise your webpages at runtime. It looks like a fantastic product to solve a lot of the problems highlight by the NZ Homepage hall of shame.

Runtime Page Optimiser features:

• Combines all javascript and css on the fly
• Generates CSS sprites on the fly
• No code modifications required!
• Runs on ASP.net 2 and and IIS 6/7
• Compatible with IE6/7 , Firefox 2/3, Safari 3

The product is currently in Beta and from the demos it already looking really great.

Well done guys, I look forward to seeing this product hit 1.0!

In the latest in the speeding up NZ Internet series, I’ve just finished retesting the web performance of top 75 NZ homepages. I’m in the processing of processing all of the results and generating the tables.

I’ve capture more data to include DSL download time, caching stats of the pages and total number of HTTP requests.

One month on here are the key stats:

Averages:

• 305.1K for the Homepage size (Up from 304.9K)
• 50 secs for estimated download time for dialup.
• 6.81 secs for download time on DSL
• 56 HTTP requests / files per page
• 20% of the homepage in size is cached. (Indicating bad caching)
• 76% of HTTP request are rechecked against cache (Indicating bad caching)
• 53.8 Yslow score

Other stats:

• 49% of websites use no web compression
• Only two sites have homepages over 1000K
• Top YSlow site has rating of 85
• Worst YSlow has a rating of 29

I’ll post the complete findings shortly.

New iPhone 3G features

• 3g – Cool
• GPS – Awesome
• App store – Fantastic
• Price – Brilliant
• Available in NZ – Can’t wait

So what’s wrong with this picture ????

5 hours of talk time from 10 hours 🙁

We’ve been on mod_rails for nearly a week and I’ve been noticing a couple of strange problems.

First, every once and while I’d hit a page and it would come up blank. Second, looking at google’s sitemaps status page told me that certain pages were getting a connection refused error. Also, I noticed the number of requests per minute from Google had dropped. (We use gl_tail for real-time monitoring of our apache logs.)

Then I started thinking that maybe the application instances are taking too long to spin up? I hit one of our staging services which was not active under mod_rails and I got a blank page 🙁 . So I started combing the user documentation looking for something to set the minimum number of instances. (A quick google and I found that others have made similar requests.)

So then I discovered you can control when mod_rails chooses to shutdown idle instances using RailPoolIdleTime. We had were using the default of 120 seconds. It recommends you set the Idle time to 2 x average number of seconds a user spends on a page. With a little bit of playing around we set it to 600 seconds and found that to work best.

The results were almost instanteous, it took about 15 minutes before Google started crawling at the normal rate.

Mod_rails has been really easy to use so far. We’ve been happy with the performance (now that we’ve got some of the glitches out of the system) and we’re still hanging out for rubyentreprise.

We switched ZoomIn from Apache + mongrel stack to mod_rails on the weekend. The transitition was a breeze. The configuration for mod_rails is super easy !

We’ve noticed the webserver is chewing through a lot less memory on the server and it scales up as demand grows.

Hanging out for ruby enterprise edition !

I had an interesting chat with Jason Roks over the weekend, who was here for the Xmedia labs.

He made this comment that stuck with me.

prednisone coupon

The only people who benefit financially from torrenting is the telecom’s companies.

ie. The content provider doesn’t get anything from torrents, only the comms companies get money for usage of bandwidth.

It makes you think…

When you have ‘cost per Gb’ charging system, its hard for companies to make money for offering downloadable content.

Nat Torkington posted about this presentation by Cloudfour on their research of the mobile web – Going fast on the Mobile Web. It contains some fantastic insights of how iPhone is changing the way that people are using the mobile web.



It also outlines their research into how mobile browsers deal with compression and caching. And details 8 tips on how to deliver content on the mobile web.

lowest price on non generic levitra

And tips for the iPhone.

When you partner that with Steve Sounders research on iPhone caching.

The iPhone cache experiment suggests an additional performance rule specific for developing web sites for the iPhone:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior.

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world…

Also, the maximum cache limit of all components is 475 – 500 KB. Minify all the JavaScript, CSS and HTML.

The future of the mobile internet is small webpages.

Finally, here is the slide deck, its well worth a read.

| View | Upload your own