As part of ShowSlow project I’m working on making it easier to get the technical answers, but my experience with real world web development projects and Web Performance Meetups movement is showing that business answer is often more important then technology answer here as ultimate requirements of performance are not technical (like in scalability, for example), but psychological.

But I’d like to look at this business problem from a new perspective that is different from traditional tweaking / improvements / benefit approach. I think that speed of interaction is such an essential product quality that by breaking traditional web performance barriers companies can create fundamentally new products and make completely new things possible in the cloud-based web application space.

Of course I’m talking about today’s Google Instant announcement. New user experience they introduced completely breaks traditional search paradigm similar to how AdWords broke advertising paradigm. More over, achieving this technical goal and building the system of this complexity is extremely hard, but this is exactly what makes it easier for them to keep competition at bay.

Google is not the first company to bake web performance into a new product. Facebook before them created new experience with their activity feed pages using various innovative technologies like BigPipe and HipHop, for example. Incredible statistics that brought them to the leading positions on the charts of the web heavily depend on ability to deliver next level of quality for their social product. Both Facebook and Google, invested in many backend and front end technologies that improve web performance and that allows them to keep unprecedented levels of user engagement.

It is great to see that competition between the two giants is moving web performance to the next level!

Again, competitive advantage cab be built by close attention to web application performance as well as new kind of products that would be impossible to develop with common latency levels and speed of interaction. To get to next levels of usability and to provide new experiences, companies must embrace web performance as a critical element in their product development.

What do you think? How can other big companies on the web change their products using high performance and get ahead of competition? Can you do that at your company?

September 15 at 5:45PM (time is updated) at Logicworks:

RSVP here: http://www.meetup.com/Web-Performance-NY/calendar/14568561/

Philip Tellis (@bluesmoon) will be speaking at New York Web Performance group about Boomerang!

Philip is a self described geek working for Yahoo! who recently presented Latency: Why You Should Worry and What You Can Do About It (video) at Velocity 2010.

His accomplishments include, but not limited to:

• Member of the Yahoo! Exceptional Performance Group and Yahoo! Security Group
• Creator of open source application Boomerang (a RUM javascript beacon)
• Author of the 4.01 Strict web comic

Topic:
Philip will be presenting his new open source project Boomerang.js. Why it was written, how to implement it, and what can be done with the data.

For a little background on Boomerang.js:
Boomerang is a piece of JavaScript that you add to your web pages, where it measures the performance of your website from your end user’s point of view. It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is.<

This is an excellent example of RUM (real user monitoring) that allows sites to effectively and actively measure real page performance for their actual users as they see it.

Boomerang is open source and released under the BSD license.

Agenda: (time is updated)
5:45 – arrive to the event, meet other members
6:00 – Introductions & Boomerang presentation by Philip Tellis
6:45 – Q&A
7:00 – Open Discussion, Networking

Location:
LogicWorks
155 Avenue of the Americas
Fifth Floor
New York, NY 10013

Directions: http://bit.ly/cK9cQx
Entrance View: http://bit.ly/a4DwrM

See you all there!

github.com/sergeychernyshev/.htaccess

Go, fork it! We have a lot of work to do:

• Stoyan Stephanov suggested that we should move to whitelisting for gzip
• Paul Irish also shared .htaccess he created as part of HTML5 boilerplate project
• since I posted about this to Apache mailing list, I was also hoping to create fast-httpd.conf similar to fast-nginx.conf with a set of instructions for fast by default web servers

Check out the issue tracker, add your own suggestions / bug reports and vote for those that you think are important.

P.S. If you’d like to include sample .htaccess file with your Subversion project, just run

svn propedit svn:externals .

and add following line to it:

sample.htaccess http://svn.github.com/sergeychernyshev/.htaccess.git

I did this in SVN Assets.

RSVP: http://www.meetup.com/Web-Performance-NY/calendar/14209517/

Bring your laptop and we’ll work together on optimizing our sites!

You can benefit even if you can’t edit your site right now – we will be happy to share the knowledge.

We’ll all learn how to see what’s slow and how to make it fast!

Directions:
LogicWorks
155 Avenue of the Americas
Fifth Floor
New York, NY 10013

Hope to see you all there!

dynaTrace AJAX Edition is a free tool that provides full JavaScript, Network, Rendering, DOM and XHR tracing for Internet Explorer 6, 7 & 8. With the latest version the Ajax Edition automatically analysis Best Practices in the areas of Browser Caching, Network Resources, Server-Side Activity, JavaScript/AJAX and also provides additional Key Performance Metrics that are essential for tracking the end-user perceived performance of a web site such as Time to First Impression, Time to onLoad or Time to Fully Loaded.

Agenda:
6:00 – arrive to the event, meet other members
6:30 – intro to web performance, industry updates by Sergey Chernyshev
7:15 – dynaTrace AJAX Edition presentation by Andreas Grabner
8:30 – Q&A
9:00 – Open Discussion, Networking

Time Inc. offered their Watercooler meeting to host NY Web Performance meetup.  Refreshments will be served.

Host contact: Alla Gringaus, Web Technology Fellow
Questions: 646 391 9671

Location:
Rockefeller Center
Time & Life Bldg
1271 Ave of the Americas (entrance 50th St and 6th Ave)
2nd Floor, room #1
New York, NY 10020

Nearest Transit:
50th St – 8th Ave (C, E)
50th St – Ave of the Americas (F, V, B, D)
49th St – 7th Ave (N, R, W)

Get directions on Google Maps: http://bit.ly/cNBZ28
Street View for the Entrance: http://bit.ly/d4FsVf

Come join us for a great presentation and discussion!

Please RSVP on the group page @ Meetup.com

Ads and tracking pixels, unfortunately are quite complex and changing their behavior is hard, but widgets are a bit simpler to deal with and can probably be improved.

Working on my MediaWikiWidgets.org project, I saw quite a few widgets and over time I started to realize that sales people’s magical promise of “easy integration with single line of JavaScript” which you can see on any site that provides widgets (and especially those that rely on widgets as primary method of distribution) is fundamentally flawed.

While it’s a great sales promise and simplifies integration, maintenance and gives a lot of control over user’s information, it brings slowness and introduces SPOFs to publisher’s sites.

To make people think about performance when they hear the magical sales pitch of Single line of JavaScript, I decided to abbreviate it to SLO-JS which gives a very clear impression about the performance quality of this solution.

Now, next time when you see the magical words in vendor’s proposal, there is no need to explain or complain, just abbreviate it and this will hopefully give the right impression and make people think about testing the performance of the 3rd party source.

Solutions

It would’ve been pointless if there was no alternative to the SLO-JS, but in reality, it is not the only way to include code, it’s just the oldest and there are other, more reliable and fast alternatives. All we need to do is to explain how they work and make it easy for vendors to provide these alternatives to sites that care about performance.

First alternative is quite simple – instead of copy-pasting a SLO-JS snippet, just let people copy-paste a mix of HTML, CSS (optional) and async JS call that will create a reasonable placeholder until data is loaded and will not block the rendering for the rest of the site.

A few vendors are already do that – DISQUS, for example, provides the following code:

<div id="disqus_thread"></div>
<script type="text/javascript">
  (function() {
   var dsq = document.createElement('script');
   dsq.type = 'text/javascript'; dsq.async = true;
   dsq.src = 'http://mediawikiwidgets.disqus.com/embed.js';
   (document.getElementsByTagName('head')[0]
      || document.getElementsByTagName('body')[0])
         .appendChild(dsq);
  })();
</script>

Notice that it gives you a div tag with disqus_thread id to insert into your page (in this case the placeholder is just empty) and then uses asynchronous script tag to load the data without blocking the rest of the page.

Transforming your code to take advantage of this probably requires a couple hours of work at best – just replace document.write with static HTML wrapper (with specific ID or class) and build additional DOM elements within the code, then use wrapper’s ID to insert the DOM tree and use the async tag to load all your JS code.

Use this pattern for good widget development, suggest similar approach to vendors that give you the most grief, and we’ll have faster web pages pretty soon.

Another alternative I proposed at the Meetup is to download content on the back-end and insert it right into HTML with optional JavaScript used only for data load.

Most of the time content doesn’t change for each request and can be cached for minutes, hours or even days at a time. In some cases it never changes, especially for embeddable content like YouTube videos or Flickr photos.

Andrew Schaaf proposed a name for it – Fetch and store JavaScript with great “superhero” abbreviation of FAST-JS.

It is quite easy to implement them in the language of your choice and probably worthy of Open Source project that will enable appropriate caching mechanism and make it easy for people to implement fast solutions to SLO-JS.

It’s a bit harder to do then async widgets and requires some backend coding, but will allow reducing front-end complexity and amount of extra JS on the page to zero.

Ad banners, JavaScript widgets, analytics trackers – they all contribute to site’s slowness and sometimes are biggest offender.

On July 22nd, I’m going to give a presentation entitled “Taming third-party content: ads, widgets, trackers” at New York Web Performance Meetup.

If you run a web site, you most likely have 3rd party content and it’s most likely slowing you down.
Come and let’s talk how we can solve this!

Please RSVP on Meetup.com.

Please welcome automated YSlow and Page Speed monitoring using Show Slow!

Now all you need to do is to register an account and enter your URL and the rest will be taken care of. Show Slow will fire YSlow and Page Speed at your site and collect statistics on a daily basis so you can just sit back and enjoy the graphs!

You can see the results on Alexa Top 100 tab that I also added to ShowSlow.com showcase performance for most popular sites of the internet.

Due to limited resources, ShowSlow.com allows for only one URL per user account to be monitored, but I’m looking for ways to remove or at least increase this limit.

I hope you’ll enjoy the automation and please forward it to everyone around you!

On my way home today, I was thinking again about asset pre-loading (example, example with inlining) after page on-load event (for faster subsequent page loads) for ShowSlow and realized that it can be created as a very good “easily installable with one line of JavaScript” service!

I think all the key components to this technology already exist!

First we need to know what to pre-load and here comes Google Analytics API and it’s Content / ga:nextPagePath dimension that will give us all the probabilities for next pages that users visit.

Now, when we have page URLs, we need to understand which assets to load from those pages and that can be solved by running headless Firefox with Firebug and NetExport extension configured to auto-fire HAR packages at beacons on the server.

HAR contains all the assets and all kind of useful information about the contents of those files so tool can make infinitely complex decisions regarding picking the right URL to pre-load from simple “download all JS and CSS files” to “only download small assets that have infinite expiration set” and so on (this can be a key to company’s secret ingredient that is hard to replicate). This step can be done on a periodic basis as to run it in real time is just unrealistic.

The last piece is probably the most trivial – actual script tag that asynchronously loads the code from the 3rd party server with current page’s URL as parameter which in turn post-loads all the assets into hidden image objects or something to prevent asset execution (for JS and CSS).

So, all user will have to provide is site’s homepage URL and approve GA data import through OAuth. After that, data will be periodically re-synced and re-crawled for constant improvement.

Some additional calls on the pages (e.g. at the top of the page and at the end of the page) can measure load times to close feedback loop for asset picking optimization algorithm.

It can be a great service provided by Google Analytics themselves, e.g. “for $50/mo we will not only measure your site, but speed it up as well” – they already have data and tags in people’s pages, the only thing left is crawling and data crunching that they do quite successfully so far.

Anyone wants to hack it together? Please post your comments! ;)

Then I realized that apache doesn’t have any of those three modules (mod_deflate, mod_rewrite and mod_expires) enabled by default.

It means I found a first project that needs some “Fast by default” treatment!

If someone knows some Apache developers, please let me know, otherwise I’ll just send email to a mailing list (their Bugzilla is down, at the moment).