How browsers work

December 4, 2009 1:11 pm | 2 Comments

My initial work on the Web was on the backend – C++, Java, databases, Apache, etc. In 2005, I started focusing on web performance. To get a better idea of what made them slow, I surfed numerous web sites with a packet sniffer open. That’s when I discovered that a bulk of the time spent loading a web site occurs on the frontend, after the HTML document arrives at the browser.

Not knowing much about how the frontend worked, I spent a week searching for anything that could explain what was going on in the browser. The gem that I found was David Hyatt’s blog post entitled Testing Page Load Speed. His article opened my eyes to the complexity of what the browser does, and launched my foray into finding ways to optimize page load times resulting in things like YSlow and High Performance Web Sites.

Today’s post on the Chromium Blog (Technically speaking, what makes Google Chrome fast?), contains a similar gem. Mike Belshe, Chrome developer and co-creator of SPDY, talks about the performance optimizations inside of Chrome. But in so doing, he also reveals insights into how all browsers work and the challenges they face. For example, until I saw this, I didn’t have a real appreciation for the performance impact of DOM bindings – the connections between the JavaScript that modifies web pages and the C++ that implements the browser. He also talks about garbage collection, concurrent connections, lookahead parsing and downloading, domain sharding, and multiple processes.

Take 16.5 minutes and watch Mike’s video. It’s well worth it.

2 Comments

Google Analytics goes async

December 1, 2009 4:36 pm | 55 Comments

Today’s announcement that Google Analytics Launches Asynchronous Tracking is music to my ears. Not only does it make web sites faster, switching over to this async pattern improves uptime and increases the amount of analytics data gathered. I’ll touch on each of these three benefits, and wrap-up with an overview of the new code snippet.

Faster

The pain of loading JavaScript files is that they block the page from rendering and block other resources from downloading. There are workarounds to these problems. Chapter 4 of Even Faster Web Sites describes six techniques for Loading Scripts Without Blocking. One of those, the Script DOM Element approach, is the technique used in the new Google Analytics async pattern. Google Analytics’ ga.js file is a perfect example of a script that should be loaded asynchronously – it doesn’t add any content to the page, so we want to load it without blocking the images and stylesheets that give users what they really came to see.

Improved Uptime

What happens if a script takes a long time to load, or fails to load? Because scripts block rendering, users are left staring at an empty page. Google Analytics has an amazing infrastructure behind it, but any resource, especially from third parties, should be added cautiously. It’s great that the GA team is evangelizing a pattern that allows the web site to render while ga.js is being downloaded.

More Data

One workaround to the blocking problem is to move scripts to the bottom of the page. In fact, this is exactly what’s suggested in the old ga.js snippet. But this means users who leave a page quickly won’t generate any analytics data (they leave before the script at the bottom finishes loading). Moving to the async pattern and loading it at the bottom of the page’s head, as suggested, means more of these quick page views get measured. This is too good to believe – not only do you get a faster, more resilient page, but you actually get better insights into your traffic.

The Async Snippet

Just to be clear, ga.js will continue to work even if web site owners don’t make any changes. But, if you want a faster site, greater uptime, and more data, here’s what the new async snippet looks like:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-X']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script');
ga.src = ('https:' == document.location.protocol ?
    'https://ssl' : 'http://www') +
    '.google-analytics.com/ga.js';
ga.setAttribute('async', 'true');
document.documentElement.firstChild.appendChild(ga);
})();

It’s extremely cool to see this pattern being evangelized for such a major piece of the Internet. A few items of note:

  • Obviously, you have to replace “UA-XXXXX-X” with your ID.
  • Since ga.js is being loaded asynchronously, there has to be a way for web site owners to couple their desired GA functions with the code when it finishes loading. This is done by pushing commands onto the Google Analytics queue object, _gaq.
  • Once all your callback commands are queued up, the ga.js script gets loaded. This is wrapped inside an anonymous function to avoid any namespace conflicts.
  • Inside the anonymous function is where we see the Script DOM Element approach being used – with two nice improvements. A ‘script’ element is created and its SRC is set to the appropriate ga.js URL. Looking ahead to support of asynchronous scripts in HTML5, the ‘async’ attribute is set to ‘true’. Very nice! The main benefit of this is it tells the browser that subsequent scripts can be executed immediately – they don’t have to wait for ga.js. The last line adds the script element to the DOM. This is what triggers the actual download of ga.js. In most of my code I do document.getElementsByTagName(“head”)[0].appendChild, but that fails if the document doesn’t have a head element. This is a more robust implementation.

It’s always hard to find the right spot on the complexibility curve. This async snippet hits it just right. It’s slightly more complex than the old pattern, but not by much. Besides the benefits highlighted here, this new pattern is able to support more advanced usage patterns, including pushing an array of commands and pushing functions.

The theme driving much of my work this year is fast by default. I want high performance to be baked into the major components of the Web, so things are just fast. Seeing Google Analytics adopt this high performance async pattern is a huge win. But the proof is in the pudding. If you switch over to the new async pattern, measure how it affects your page load times and the amount of data gathered, and add a comment below. My prediction: 200ms faster and 10% more data. What do you see?

55 Comments

SPeeDY – twice as fast as HTTP

November 12, 2009 7:31 pm | 2 Comments

Mike Belshe and Roberto Peon, both from Google, just published a post entitled A 2x Faster Web. The post talks about one of the most promising web performance initiatives in recent memory – an improvement of HTTP called SPDY (pronounced “SPeeDY”). The title of their blog post comes from the impact SPDY has on page load times:

The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance – pages loaded up to 55% faster.

SPDY is an application-layer protocol, as is HTTP. The team chose to work at this layer, rather than the transport-layer of TCP, because it’s easier to deploy and has more potential for performance gains. After all, it’s been 10 years since HTTP/1.1, the most common version in use today, was defined. The main enhancements included in SPDY are summed up in three bullets:

  • Multiplexed requests – Multiple requests can be issued concurrently over a single SPDY connection.
  • Prioritized requests – Clients can request certain resources to be delivered first, for example, stylesheets as a higher priority over images.
  • Compressed headers – HTTP headers (User-Agent, cookies, etc.) represent a significant number of bytes and yet are not compressed, whereas in SPDY they are compressed.

The reason this is so exciting is because it’s an improvement to the Internet infrastructure. If SPDY is adopted by web browsers and servers, users will get a faster experience without requiring them or web developers to do any extra work. This is what I call “fast by default” and is the theme for Velocity 2010. We still need developers to build their web applications using performance best practices, but getting the basic building blocks of the Web to be as fast as possible is in a way easier to wrangle and has a wider reach.

The SPDY team has published a white paper and DRAFT protocol specification. I say “DRAFT” in all caps because this is a proposal. The team is actively looking for feedback. They’ve also released a SPDY-enabled version of Chrome, and will release an open-source web server that supports SPDY in the near future. Read the FAQ to find out more about how this relates to HTTP pipelining, TCP, SCTP, and more. (I’m not sure I buy their answer for how the name was chosen.)

This needs lots of review. Please take a look and send your feedback to the Chromium discussion group.

Update: Checkout follow-up articles from Mark Nottingham (Yahoo!, chair of the IETF HTTPBIS Working Group) and Alex Russell (Google, Dojo contributor, coined the term Comet).

2 Comments

Business impact of high performance

October 6, 2009 7:29 pm | 1 Comment

Alistair Croll adds more evidence to the business case for high performance web sites in his blog post Proof that speeding up websites improves online business. This was the primary theme of Velocity 2009, and major web destinations shared their business case studies, including Bing, Google, and Shopzilla. Alistair rounds out the stats by answering the question: How big an impact does performance optimization have on the business metrics of a typical media or e-commerce site?

Alistair worked with his friends at Strangeloop Networks to gather the data. Strangeloop makes acceleration appliances that automatically optimize dynamic web apps in real time. They left the appliance off for half of the visitors and turned it on for the other half, and compared the differences. Some highlights from what they found:

  • pages per visit grew from 11.04 to 15.64
  • time spent on the site went from 23:50 to 30:10
  • conversion rate increased 16.07%
  • order value increased 5.51%

In addition to these metrics, we have data that shows improving web performance reduces operating costs. In his talk about Shopzilla’s performance improvements (video, slides), Phil Dixon mentions that the number of servers required to run their site dropped in half. Netflix’s outbound traffic dropped almost 50% as a result of the work done by Bill Scott and his team.

Web Performance Optimization improves user and business metrics. WPO also decreases operating costs by reducing hardware requirements and bandwidth, which in turn reduces carbon footprint. It’s a win on all fronts. We’re going to see even more case studies on the positive impact of performance optimization, and as a result, the interest in learning more about this field will continue to grow. In addition to speaking at Øredev, Fronteers, and JSConf.eu, I’m organizing a few other performance meetups in the next few months. Watch my blog for announcements.

1 Comment

Web Exponents speaker series

September 29, 2009 8:29 pm | 4 Comments

Earlier this year I started a speaker series at Google that I call Web Exponents. The word “exponents” is used in the context of “a person who actively supports or favors a cause”. I even have a tagline: raising web technology to a higher power. Classic.

I post about these talks on the Google Code Blog. I recommend you subscribe to that blog, but in case you don’t, I wanted to cross-post here to make sure people catch the great talk by Chris Anderson on CouchDB.

Other speakers in the Web Exponents speaker series include:

Each blog post contains links to the video and slides for each talk. Keep your eye open for upcoming speakers in the next month or two.

4 Comments

Yahoo! Search – new features, faster performance

September 28, 2009 8:24 pm | 4 Comments

My last blog post was about Mobile Gmail performance best practices. It’s nice to follow that up with a review of a recent YDN blog post: Not Just a Pretty Face: Performance and the New Yahoo! Search. It’s great to see these industry leaders sharing their performance tips with the developer community and showing the high value they put on making web pages faster.

Yahoo! Search recently added several rich new features. Along with that came many performance improvements, resulting in a launch that not only had more features but was faster than the old version. What?! More features and faster performance?! Yes, you can have your cake and eat it, too. Here are some of the performance optimizations you can find in the new Yahoo! Search:

data: URIs

Any HTML attribute that accepts a URL can also accept a data: URI – an encoded version of the actual HTTP response. This is a best practice for reducing the number of HTTP requests. Yahoo! Search converted several of their CSS background images into data: URIs. For example, the gold Search button’s background looks like this:

If you look at their stylesheet, you’ll see that the background image uses a data: URI rather than an image URL:

.sbb {background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSU...rkJggg==');}

Using data: URIs instead of separate images eliminates HTTP requests. Even better, because the data: URI is in an external stylesheet (as opposed to the HTML document itself), it can be cached.

page flushing

Flushing the document early is a best practice I evangelize in Even Faster Web Sites. Sending the HTML header and top navbar as quickly as possible allows the browser to start rendering the page more quickly. This visual feedback gives the user an experience that feels faster. If there are any resources in the head, the browser can get a jump on downloading them while the rest of page is still being stitched together. Yahoo! Search! sends down an initial chunk that includes the page header and search box. This HTML is fairly static, so the backend server can generate it quickly, before starting on the actual search results.

Yahoo! Search goes even farther. The next chunk contains the remaining visible page content, but no JavaScript. The JavaScript is downloaded last, progressively enhancing the functionality of the page. This is a pattern I’m seeing more and more, especially in JavaScript-intensive web apps.

lazy loading

Yahoo! Search divided the JavaScript and CSS in the search results page into two categories: the bare minimum required to render the basic page and additional (heavy) functionality such as Search Assist and Search Pad. This is similar to another of my performance best practices: Splitting the Initial Payload. My advice focuses on JavaScript, but Yahoo! Search has extended the optimization to include CSS.

My post on Mobile GMail talked about their approach to lazy-loading JavaScript that avoids locking up the browser. Yahoo! Search uses the Script DOM Element approach – create a script element, set its src, and append it to the head element. This is a great approach for loading scripts in parallel. Yahoo! Search lazy-loads three scripts, so parallel loading is important. This technique does cause the JavaScript to be parsed and executed immediately. This isn’t an issue if it’s a small amount of code or the functionality is needed immediately. Otherwise, downloading the JavaScript and delaying the parsing and execution might lead to an even faster user experience.

Kudos to the Yahoo! Search team. Great work, and thanks for sharing!

4 Comments

Velocity – fully programmed

June 16, 2009 3:57 pm | 2 Comments

With my book and Velocity hitting in the same month, I’ve been slammed. Even though we started the Velocity planning process eleven months ago, we’ve been tweaking the program schedule up to the last minute, making room for new products and technology breakthroughs. I’m happy to say that the slate of speakers is nailed down, and it looks awesome. Here’s a rundown of the what’s happening in the Performance track, including the most recent additions.

Workshops (Mon, June 22)

At this year’s conference, we added a day of workshops. I kick things off talking about Website Performance Analysis, where I’ll take a popular, but slow, web site and show the tools used to make it faster. Nicholas Zakas is getting into deep performance optimizations with Writing Efficient JavaScript, relevant to any web site that uses JavaScript (which is every one). I’m psyched to sit in on Nicole Sullivan’s workshop, The Fast and the Fabulous: 9 ways engineering and design come together to make your site slow. We worked together at Yahoo!, so I can vouch for her guru-ness when it comes to CSS and web design. The workshops end with Metrics that Matter by Ben Rushlo from Keynote Systems. This was a topic that was brainstormed at the Velocity Summit held earlier this year – the importance of identifying the metrics that you just have to be watching to track and improve your site’s performance.

Sessions Day 1 (Tues, June 23)

We had so many good speaker proposals, we decided to kick things off a bit earlier, starting at 8:30am. We’ll cover the exciting stuff right out of the gate – new product announcements! (My lips are sealed.) One of the most important talks of the conference is The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search – where Eric Schurman from Live Search (‘scuse me, Bing) and Jake Brutlag from Google Search co-present the results of experiments they ran measuring the impact of latency on users. Are you kidding me?! Microsoft and Google, presenting together, with hard numbers about the impact of latency, talking about experiments run on live traffic! This is unprecedented and can’t be missed. Eric and Jake are two of the smartest and nicest guys around, so grab them afterwards and ask questions.

There’s a reprise of last year’s popular browser matchup, What Makes Browsers Performant, with representatives from Internet Explorer, Firefox, and Chrome. Doug Crockford is talking about Ajax Performance, painting the landscape of how developers should view and optimize their Web 2.0 applications. Michael Carter’s presentation on Light Speed Comet will present this newer technique for high volume, low latency Ajax communication. Other performance-related presentations include a demo of Google’s new Page Speed performance tool, A Preview of MySpace’s Open-sourced Performance Tracker, The Secret Weapons of the AOL Optimization Team, Go with the Reflow by my good buddy Lindsey Simon, and Performance-Based Design – Linking Performance to Business Metrics by Aladdin Nassar.

Sessions Day 2 (Wed, June 24)

We start early again, and jump right into the good stuff. Marissa Mayer starts with a keynote talking about Google’s commitment to fast web sites, followed by lightning demos of Firebug, HttpWatch, AOL PageTest, YSlow 2.0, and Visual Round Trip Analyzer. In Shopzilla’s Site Redo, Phil Dixon delivers more killer stats about the business impact of performance, such as a “5% – 12% lift in top-line revenue”. These are the numbers developers need to be armed with when debating the priority of performance improvements within their company. The morning closes with Ben Galbraith and Dion Almaer talking about the Responsiveness of web applications.

Several afternoon sessions come from Google. Kyle Scholz and Yaron Friedman present High Performance Search at Google. These guys have to build advanced DHTML that works across a huge audience; it’ll be important to find out what worked for them. Tony Gentilcore, creator of Fasterfox, gets the conference’s Sherlock Holmes award for his discoveries about why compression doesn’t happen as often as we think, in Beyond Gzipping. Brad Chen talks about a new tact on high performance applications in the browser using Google Native Client.

Matt Mullenweg is presenting some of the recent performance enhancements baked into WordPress. It’s a real treat to have Matt on the program. Developers that have to monitor performance will want to hear MySpace.com’s talk Fistful of Sand. In addition to hearing from Google Search, we’ll also get a glimpse of Frontend Performance Engineering in Facebook. Eric Mattingly is demoing a new tool called neXpert. And the day closes with me talking about the State of Performance, and a favorite from last year, High Performance Ads – Is It Possible?.

One of the most rewarding things about Velocity 2008 was the amount of sharing that took place. Everyone was talking about the pitfalls to avoid and the successes that can be had. I see that happening again this year. All of these speakers are extremely approachable. They have great experience and are smart, too, but the key for Velocity is that you can walk up to any one of them afterward and ask for more details or share what you’ve discovered. The Web is out there. Velocity is where we work together to make it faster.

See you at Velocity!

[If you haven't registered yet, make sure to use my "vel09cmb" 15% discount code.]

2 Comments

State of Performance 2008

December 17, 2008 8:08 pm | 3 Comments

My Stanford class, CS193H High Performance Web Sites, ended last week. The last lecture was called “State of Performance”. This was my review of what happened in 2008 with regard to web performance, and my predictions and hopes for what we’ll see in 2009. You can see the slides (ppt, GDoc), but I wanted to capture the content here with more text. Let’s start with a look back at 2008.

2008

Year of the Browser
This was the year of the browser. Browser vendors have put users first, competing to make the web experience faster with each release. JavaScript got the most attention. WebKit released a new interpreter called Squirrelfish. Mozilla came out with Tracemonkey – Spidermonkey with Trace Trees added for Just-In-Time (JIT) compilation. Google released Chrome with the new V8 JavaScript engine. And new benchmarks have emerged to put these new JavaScript engines through the paces: Sunspider, V8 Benchmark, and Dromaeo.

In addition to JavaScript improvements, browser performance was boosted in terms of how web pages are loaded. IE8 Beta came out with parallel script loading, where the browser continues parsing the HTML document while downloading external scripts, rather than blocking all progress like most other browsers. WebKit, starting with version 526, has a similar feature, as does Chrome 0.5 and the most recent Firefox nightlies (Minefield 3.1). On a similar note, IE8 and Firefox 3 both increased the number of connections opened per server from 2 to 6. (Safari and Opera were already ahead with 4 connections per server.) (See my original blog posts for more information: IE8 speeds things up, Roundup on Parallel Connections, UA Profiler and Google Chrome, and Firefox 3.1: raising the bar.)

Velocity
Velocity 2008, the first conference focused on web performance and operations, launched June 23-24. Jesse Robbins and I served as co-chairs. This conference, organized by O’Reilly, was densely packed – both in terms of content and people (it sold out!). Speakers included John Allspaw (Flickr), Luiz Barroso (Google), Artur Bergman (Wikia), Paul Colton (Aptana), Stoyan Stefanov (Yahoo!), Mandi Walls (AOL), and representatives from the IE and Firefox teams. Velocity 2009 is slated for June 22-24 in San Jose and we’re currently accepting speaker proposals.
Jiffy
Improving web performance starts with measuring performance. Measurements can come from a test lab using tools like Selenium and Watir. To get measurements from geographically dispersed locations, scripted tests are possible through services like Keynote, Gomez, Webmetrics, and Pingdom. But the best data comes from measuring real user traffic. The basic idea is to measure page load times using JavaScript in the page and beacon back the results. Many web companies have rolled their own versions of this instrumentation. It isn’t that complex to build from scratch, but there are a few gotchas and it’s inefficient for everyone to reinvent the wheel. That’s where Jiffy comes in. Scott Ruthfield and folks from Whitepages.com released Jiffy at Velocity 2008. It’s Open Source and easy to use. If you don’t currently have real user load time instrumentation, take a look at Jiffy.
JavaScript: The Good Parts
Moving forward, the key to fast web pages is going to be the quality and performance of JavaScript. JavaScript luminary Doug Crockford helps lights the way with his book JavaScript: The Good Parts, published by O’Reilly. More is needed! We need books and guidelines for performance best practices and design patterns focused on JavaScript. But Doug’s book is a foundation on which to build.
smush.it
My former colleagues from the Yahoo! Exceptional Performance team, Stoyan Stefanov and Nicole Sullivan, launched smush.it. In addition to a great name and beautiful web site, smush.it packs some powerful functionality. It analyzes the images on a web page and calculates potential savings from various optimizations. Not only that, it creates the optimized versions for download. Try it now!
Google Ajax Libraries API
JavaScript frameworks are powerful and widely used. Dion Almaer and the folks at Google saw an opportunity to help the development community by launching the Ajax Libraries API. This service hosts popular frameworks including jQuery, Prototype, script.aculo.us, MooTools, Dojo, and YUI. Web sites using any of these frameworks can reference the copy hosted on Google’s worldwide server network and gain the benefit of faster downloads and cross-site caching. (Original blog post: Google AJAX Libraries API.)
UA Profiler
Okay, I’ll get a plug for my own work in here. UA Profiler looks at browser characteristics that make pages load faster, such as downloading scripts without blocking, max number of open connections, and support for “data:” URLs. The tests run automatically – all you have to do is navigate to the test page from any browser with JavaScript support. The results are available to everyone, regardless of whether you’ve run the tests. I’ve been pleased with the interest in UA Profiler. In some situations it has identified browser regressions that developers have caught and fixed.

2009

Here’s what I think and hope we’ll see in 2009 for web performance.

Visibility into the Browser
Packet sniffers (like HTTPWatch, Fiddler, and WireShark) and tools like YSlow allow developers to investigate many of the “old school” performance issues: compression, Expires headers, redirects, etc. In order to optimize Web 2.0 apps, developers need to see the impact of JavaScript and CSS as the page loads, and gather stats on CPU load and memory consumption. Eric Lawrence and Christian Stockwell’s slides from Velocity 2008 give a hint of what’s possible. Now we need developer tools that show this information.
Think “Web 2.0″
Web 2.0 pages are often developed with a Web 1.0 mentality. In Web 1.0, the amount of CSS, JavaScript, and DOM elements on your page was more tolerable because it would be cleared away with the user’s next action. That’s not the case in Web 2.0. Web 2.0 apps can persist for minutes or even hours. If there are a lot of CSS selectors that have to be parsed with each repaint - that pain is felt again and again. If we include the JavaScript for all possible user actions, the size of JavaScript bloats and increases memory consumption and garbage collection. Dynamically adding elements to the DOM slows down our CSS (more selector matching) and JavaScript (think getElementsByTagName). As developers, we need to develop a new way of thinking about the shape and behavior of our web apps in a way that addresses the long page persistence that comes with Web 2.0.
Speed as a Feature
In my second month at Google I was ecstatic to see the announcement that landing page load time was being incorporated into the quality score used by Adwords. I think we’ll see more and more that the speed of web pages will become more important to users, more important to aggregators and vendors, and subsequently more important to web publishers.
Performance Standards
As the industry becomes more focused on web performance, a need for industry standards is going to arise. Many companies, tools, and services measure “response time”, but it’s unclear that they’re all measuring the same thing. Benchmarks exist for the browser JavaScript engines, but benchmarks are needed for other aspects of browser performance, like CSS and DOM. And current benchmarks are fairly theoretical and extreme. In addition, test suites are needed that gather measurements under more real world conditions. Standard libraries for measuring performance are needed, a la Jiffy, as well as standard formats for saving and exchanging performance data.
JavaScript Help
With the emergence of Web 2.0, JavaScript is the future. The Catch-22 is that JavaScript is one of the biggest performance problems in a web page. Help is needed so JavaScript-heavy web pages can still be fast. One specific tool that’s needed is something that takes a monolithic JavaScript payload and splits into smaller modules, with the necessary logic to know what is needed when. Doloto is a project from Microsoft Research that tackles this problem, but it’s not available publicly. Razor Optimizer attacks this problem and is a good first step, but it needs to be less intrusive to incorporate this functionality.

Browsers also need to make it easier for developers to load JavaScript with less of a performance impact. I’d like to see two new attributes for the SCRIPT tag: DEFER and POSTONLOAD. DEFER isn’t really “new” – IE has had the DEFER attribute since IE 5.5. DEFER is part of the HTML 4.0 specification, and it has been added to Firefox 3.1. One problem is you can’t use DEFER with scripts that utilize document.write, and yet this is critical for mitigating the performance impact of ads. Opera has shown that it’s possible to have deferred scripts still support document.write. This is the model that all browsers should follow for implementing DEFER. The POSTONLOAD attribute would tell the browser to load this script after all other resources have finished downloading, allowing the user to see other critical content more quickly. Developers can work around these issues with more code, but we’ll see wider adoption and more fast pages if browsers can help do the heavy lifting.

Focus on Other Platforms
Most of my work has focused on the desktop browser. Certainly, more best practices and tools are needed for the mobile space. But to stay ahead of where the web is going we need to analyze the user experience in other settings including automobile, airplane, mass transit, and 3rd world. Otherwise, we’ll be playing catchup after those environments take off.
Fast by Default
I enjoy Tom Hanks’ line in A League of Their Own when Geena Davis (“Dottie”) says playing ball got too hard: “It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard… is what makes it great.” I enjoy a challenge and tackling a hard problem. But doggone it, it’s just too hard to build a high performance web site. The bar shouldn’t be this high. Apache needs to turn off ETags by default. WordPress needs to cache comments better. Browsers need to cache SSL responses when the HTTP headers say to. Squid needs to support HTTP/1.1. The world’s web developers shouldn’t have to write code that anticipates and fixes all of these issues.

Good examples of where we can go are Runtime Page Optimizer and Strangeloop appliances. RPO is an IIS module (and soon Apache) that automatically fixes web pages as they leave the server to minify and combine JavaScript and stylesheets, enable CSS spriting, inline CSS images, and load scripts asynchronously. (Original blog post: Runtime Page Optimizer.) The web appliance from Strangeloop does similar realtime fixes to improve caching and reduce payload size. Imagine combining these tools with smush.it and Doloto to automatically improve the performance of web pages. Companies like Yahoo! and Google might need more customized solutions, but for the other 99% of developers out there, it needs to be easier to make pages fast by default.

This is a long post, but I still had to leave out a lot of performance highlights from 2008 and predictions for what lies ahead. I look forward to hearing your comments.

3 Comments

Andy Hopper: Computing for the Future of the Planet

May 30, 2008 3:30 pm | Leave a comment

I recently hosted Andy Hopper (University of Cambridge) at Google to deliver his talk on Computing for the Future of the Planet (YouTube video). He covered a variety of areas that ranged from practical deployment issues that should be addressed today to futuristic concepts. The beginning of the talk, the part that was of most interest to me, was about energy efficient computing: adaptive datacentres and a “virtual battery” (moving computing tasks to where energy is available). Power consumption is certainly a key focus for Google and other large web companies. It’s intriguing to think about shifting data and processes in real time based on the cost of energy.

(more…)

Leave a comment

Google AJAX Libraries API

May 27, 2008 10:47 pm | 10 Comments

Today Dion Almaer announced the Google AJAX Libraries API. This is a great resource for developers using any of the popular JavaScript frameworks including Prototype, Script.aculo.us, jQuery, Dojo, and MooTools. Rather than downloading it to your own server and hosting it from there, you can request your preferred JavaScript library from ajax.googleapis.com:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js">
</script>

The greatest benefit in my opinion is that any developer can leverage Google’s CDN to deliver the bulk of their JavaScript. From YSlow and my book I received a lot of feedback that Rule 2: Use a CDN was out of reach for many developers. I use jQuery in one of my personal projects and serve it on my hosted web site from one geographic location. Ouch. Being able to move that 21K closer to my users is great.

(more…)

10 Comments