Firefox Articles

Friends and hackers, we have a challenge

Are you a developer who’s passionate about Mozilla’s mission on the open Web? We need your help: We’re looking for someone to build a game to help keep the Web open as it goes mobile. There’s a Firefox mobile website testing app which we think would make a nice little HTML5 game — with scoring, achievement, levels, leaderboards — and we think you have the chops to make it fun. We’ve had some success making a game of the activity within our team, but we think you could do it better.

Here’s some context. We need lots of people looking at lots of frequently visited websites to see if they look good and work well on mobile. And if they don’t, we need to figure out how to make them better: by finding the bugs and fixing our browser or by working with the developer who built the site to make it work on the open Web. Testing Fennec matters for the future of the open Web:

Fennec, Mozilla’s mobile browser, just landed in Google Play (you may remember it as the Android Marketplace). Firefox Beta for Android is better than ever! You can download it now, use it on your Android phone or tablet and share your feedback. If you get hooked on testing, you’ll want to create a bugzilla account (if you don’t have one) and start filing bugs. By

If you’d like to do a little more directed testing, check out Aaron Train’s most excellent testing app, which sends you to some of the world’s leading websites to share your feedback. This is the app we’d like to gamify, to motivate more people in the Mozilla community to help us keep improving the Firefox mobile web experience for everyone.

What matters is mobile

It’s an interesting exercise to start viewing and interacting with the world’s most frequently used websites in a mobile browser. Any mobile browser. You realize the mobile Web has a ways to go. But there’s more to it than that. David Slater, who leads Product Marketing at Mozilla put it so well that I’m just going to share a note that he sent out internally earlier this week:

The mobile Web is under threat. For 8 years Mozilla has fought to make the Web open on desktop – and won. On mobile, it’s different – the battle is underway. In order to win, we will have to make the Web on mobile devices as compelling for developers and users as native mobile apps are today. Marketplace is about doing that. Boot-to-Gecko, ultimately, is about doing that. But first, we have to break open the mobile web and expose the issues.

Today, Apple and Google – and therefore browsers based on Webkit – are dominating the mobile Web, and as a result developers are coding for a single rendering engine. Like we did with desktop, we have to ensure developers have access to truly open standards. And that means that we need to do whatever it takes to establish Gecko‘s presence on mobile – and specifically, on the Android platform which is widely forecast to grow more than any other in the next 5 years.

There are many ways you can join us in this battle, but if you’ve been wanting to test your skills by building a Web game, there’s never been a better time to try, and never for a better cause. And if you need a little help, there are many places you can ask, like our IRC channel, #devrel, the engagement-developers mailing list, or simply @mozhacks on Twitter. And, of course, if you do, we’ll make you MDN-famous, and treat you like a hero. Thank you.

Back in the fall of 2011, we took a targeted look at Firefox responsiveness issues. We identified a number of short term projects that together could achieve significant responsiveness improvements in day-to-day Firefox usage. Project Snappy kicked off at the end of the year with the goal of improving Firefox responsiveness.

Although Snappy first contributed fixes to Firefox 11, Snappy’s most noticeable contributions to date are landing with Firefox 13. Currently in beta, this release includes a number of responsiveness related fixes, most notably tabs-on-demand, cycle collector improvements, and start-up optimization.

Tabs -on-Demand

Tabs-on-demand is a feature that reduces start-up time for Firefox windows with many tabs. In Firefox 12, all tabs are loaded on start-up. For windows with many tabs this may cause a delay before you can interact with Firefox as each tab must load its content. In Firefox 13, only the active tab will load. Loading of background tabs is deferred until a tab is selected. This results in Firefox starting faster as tabs-on-demand reduces processing requirements, network usage, and memory consumption.

Cycle Collector

As you interact with the browser and Web content, memory is allocated as needed. The Firefox cycle collector works to automatically free some of this memory when it is no longer needed. This action reduces Firefox’s memory usage. In Firefox 13, the cycle collector is more efficient, spending less time examining memory that is still in use, which results in less pauses as you use Firefox.

Start-up

Firefox start-up time is visible to all users. Our investigation into start-up has identified a number of unoptimized routines in the code that executes before what we call “first paint”. “First paint” signifies when the Firefox user interface is first visible on your screen. In Firefox 13 we have optimized file calls, audio sessions, drag and drop, and overall IO, just to name a few. We are continuing to profile the Firefox start-up sequence to identify further optimizations that can be made in future releases.

There are numerous other Snappy fixes in Firefox 13 including significant improvements to IO contention, font enumeration, and livemark overhead. All of these fixes contribute to a more responsive experience. We are already working on further responsiveness fixes for future Firefox releases. You can expect to see Snappy improvements in upcoming releases in areas such as memory usage, shutdown time, network cache and connections, menus, and graphics.

DOM Mutation Events seemed like a great idea at the time – as web developers create a more dynamic web it seems natural that we would welcome the ability to listen for changes in the DOM and react to them. In practice however DOM Mutation Events were a major performance and stability issue and have been deprecated for over a year.

The original idea behind DOM Mutation Events is still appealing, however, and so in September 2011 a group of Google and Mozilla engineers announced a new proposal that would offer similar functionality with improved performance: DOM MutationObserver. This new DOM Api is available in Firefox and Webkit nightly builds, as well as Chrome 18.

At it’s simplest, a MutationObserver implementation looks like this:

// select the target node
var target = document.querySelector('#some-id');
 
// create an observer instance
var observer = new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
        console.log(mutation.type);
    });    
});
 
// configuration of the observer:
var config = { attributes: true, childList: true, characterData: 	true }
 
// pass in the target node, as well as the observer options
observer.observe(target, config);
 
// later, you can stop observing
observer.disconnect();

The key advantage to this new specification over the deprecated DOM Mutation Events spec is one of efficiency. If you are observing a node for changes, your callback will not be fired until the DOM has finished changing. When the callback is triggered, it is supplied a list of the changes to the DOM, which you can then loop through and choose to react to.

This also means that any code you write will need to process the observer results in order to react to the changes you are looking for. Here is a compact example of an observer that listens for changes in an editable ordered list:

<!DOCTYPE html>
<ol contenteditable oninput="">
  <li>Press enter</li>
</ol>
<script>
  var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
  var list = document.querySelector('ol');
 
  var observer = new MutationObserver(function(mutations) {  
    mutations.forEach(function(mutation) {
      if (mutation.type === 'childList') {
        var list_values = [].slice.call(list.children)
            .map( function(node) { return node.innerHTML; })
            .filter( function(s) {
              if (s === '<br>') {
                return false;
              }
              else {
                return true;
              }
        });
        console.log(list_values);
      }
    });
  });
 
  observer.observe(list, {
  	attributes: true, 
  	childList: true, 
  	characterData: true
  });
</script>

If you want to see this code running, I’ve put it up on jsbin here:

http://jsbin.com/ivamoh/53/edit

If you play with the live example, you’ll notice some quirks in behaviour, in particular that the callback is triggered when you press enter in each li, in particular when the user action results in a node being added or removed from the DOM. This is an important distinction to be made from other techniques such as binding events to key presses or more common events like ‘click’. MutationObservers work differently from these techniques because they are triggered by changes in the DOM itself, not by events generated either via JS or user interaction.

So what are these good for?

I don’t expect most JS hackers are going to run out right now and start adding mutation observers to their code. Probably the biggest audience for this new api are the people that write JS frameworks, mainly to solve problems and create interactions they could not have done previously, or at least not with reasonable performance. Another use case would be situations where you are using frameworks that manipulate the DOM and need to react to these modifications efficiently ( and without setTimeout hacks! ).

Another common use of the Dom Mutation Events api is in browser extensions, and in the next week or so I’m going to publish a follow-up post on how MutationObservers are particularly useful when interacting with web content in a Firefox Add-on.

Resources

• Original Proposal
• W3C Spec
• Screencast by Rafael Weinstein
• Mutation Summary, a JS library that simplifies MutationObserver usage.

This post was originally published as A Compendium of Awesome, and is a short summary of a Firefox work week. Posted here to give an overview, with focus on some details, about things happening with Firefox developement.

Two weeks ago, the Firefox team got together for a work week in Toronto. It was amazing. Walking through a room with that many excellent people doing excellent things was inspiringhumblingunbelievable and the hits kept on rolling.

The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.

And then this happened:

Hacking

• Scratchpad backending to github gists
• Jetpacks in scratchpad
• Task-specific icons in Windows 7 jumplists
• Finalized interactions and designs for the new downloads manager
• Sync meet-up and discussion to evaluate how to move forward with a smaller core, by moving data handling to components and allowing the Sync team to concentrate on the real Sync functionality
• Session Store meet-up and discussion on how to move forward with “Speedy Session Restore” as well as SS2 (rewriting SS).
• Initial explorations of a Fennec reading mode (post-1.0)
• Implemented Windows 8 appbar
• Roll your own one-off, bespoke debuggers in the scratchpad.
• Responsive Design tool for web developers

Lightning Talks

• Honza made Firebug’s HTTP Monitor a standalone component, and it can now remote-monitor fennec, too
• Gavin gave a great talk about code review
• Tim Abraldes demoed the Web App runtime
• Margaret walked us through Hacking Fennec
• Brian Bondy updated the status of our Windows 8 work
• Felipe found and fixed memory leaks with about:cc
• Dietrich walked through the state of the browser components team
• David Dahl went meta, and talked about giving Firefox talks in our community

I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.

FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.

When we meet and talk to people, there are often questions about Firefox, how the release shedule works and what different channels we have for testing. Therefore, I’d like to introduce you to/remind you about them and also let you know where the most important testing is, both for you and for us.

Firefox release channels

Basically, we have four different Firefox release channels:

Firefox Release

The official release of Firefox.

Firefox Beta

Testing the next version of Firefox befire it becomes the official release.

Firefox Aurora

For web/platform developers and early adopters.

Firefox Nightly

Nightly releases that contains experimental features. (covered regularly on Twitter from @firefoxnightly)

Firefox release timeline

Firefox is released on a six week schedule, meaning that every sixth week there will be new versions of Firefox Release, Firefox Beta and Firefox Aurora. Nightly is, naturally, released every night.

Running multiple versions of Firefox at the same time

There are many different ways of running multiple versions of Firefox at the same time. What it all comes down to is setting up different profiles that you have per each web browser instance. The easiest way is most likely to use the Profile Manager, as described on MDN.

If you are on Mac OS X, it’s easy to use the automated version of setting up multiple profiles of Firefox.

Another option, in plain code and as outlined in Multiple Firefox Instances, is to just launch the Profile manager directly:

# On Windows click Start > Run then:
"C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote -ProfileManager
 
# Mac OS X and Linux, in Terminal
firefox -ProfileManager
 
# Depending on system/setup, you might need to do this from the directory
./firefox -ProfileManager

Testing Firefox Aurora

The version of Firefox that is the best version to test for web developers is Firefox Aurora. It is in a stable enough condition to use, but also has features at their latest stage before they become approved. Therefore, your chance to affect implementations, find bugs, improve features is when it has become Firefox Aurora – likewise, it gives us a better chance to ensure that when Firefox is officially released, all the things are in place in the best possible manner.

Therefore, please take the time to test out Firefox Aurora and new features, so we can together help Firefox and the web better!

While users of the Firefox release channel are just now getting to enjoy the Style Editor and the Page Inspector 3D (Tilt), we have a number of nice developer tools improvements that we’ve shipped to the Aurora channel for Firefox 13. Aurora users are up to 12 weeks ahead of the release channel.

Page Inspector

Styling CSS menus and other elements that are styled with the :hover, :active and :focus pseudo-classes has gotten much easier. You now have the ability to lock in a pseudo-class for the selected page element in the Page Inspector. I have made a 1 minute video to show this feature in action.

Right-click on the page element “infobar” for the selected element to toggle the pseudo-class lock. When you have selected an element in the Page Inspector, the infobar is the hovering box that has the tag name, element ID and classes. We are planning to add a convenient menu for this feature, but you can use pseudo-class locking today with a simple right-click.

When you reopen the Page Inspector, the HTML panel and Style sidebar will reopen as well, if you had them open when you last used Page Inspector. This saves you from having to press ctrl-H and ctrl-S to reopen them. If you’re wondering about those keyboard shortcuts, you can find those and other useful tips on the MDN page for the Page Inspector.

When using the Page Inspector 3D view, you can press the “f” key to bring an element back into view (focus it). Hint: if you don’t see the 3D button in the Page Inspector, you might have a blocklisted graphics driver. A simple driver update may be all you need.

The element context menu in the HTML panel now offers some handy actions.

Context menu on nodes in the HTML panel

Style Inspector

Context menu for the CSS rules view

The Style Inspector sidebar of the Page Inspector has had a number of useful upgrades.

You can now select and copy a rule out of the Rules view. To make things even quicker and easier, you can copy a rule or part of a rule from the context menu. Update: due to some bugs found during Aurora, the context menu shown to the right has been backed out. You can still copy rules out of the rules view by selecting the text of the rule.

In the Computed view, the links to the CSS files now go to the Style Editor rather than View Source. This can make some workflows quicker (see the video in the Style Editor section below).

Invalid entries in the rules view are now marked with a warning sign. The tooltip can give you further information about the problem.

Invalid CSS in the rules view

Rules applied as the result of a media query will be shown with the media query.

A rule with an associated media query

Style Editor and Scratchpad

The Style Editor now saves CSS files loaded via file:// URLs without prompting. This makes the workflow for experimenting with CSS very quick. This feature actually ships in Firefox 12. It was added during the Firefox 12 Aurora cycle and wasn’t in the original notes posted here.

See the 1 minute video below to get an idea of how smooth this is.

There were a couple of notable changes to the editor code that is shared by both Scratchpad and the Style Editor. Theme add-ons can now change the editor styles and you can select a whole line of code by clicking on the line number in the gutter of the editor.

Our top secret developments

I hope you enjoy these updates. I wish I could tell you more about what’s in coming releases, but no one knows when they’ll land or has any idea what could possibly be in them. In fact, only a select few can see unfinished features and we try to ensure that our secret cabal remains impenetrable.

It’s just how we roll.

Update (April 18, 2012): Note that the context menu for rules in the Style Inspector Rules view has been removed from Firefox 13. Expect to see it return in a future Firefox.

[Also posted at brendaneich.com.]

I wrote The Open Web and Its Adversaries just over five years ago, based on the first SXSW Browser Wars panel (we just had our fifth, it was great — thanks to all who came).

Some history

The little slideshow I presented is in part quaint. WPF/E and Adobe Apollo, remember those? (Either the code names, or the extant renamed products?) The Web has come a long way since 2007.

But other parts of my slideshow are still relevant, in particular the part where Mozilla and Opera committed to an unencumbered <video> element for HTML5:

• Working with Opera via WHATWG on <video>
  • Unencumbered Ogg Theora decoder in all browsers
  • Ogg Vorbis for <audio>
  • Other formats possible
  • DHTML player controls

We did what we said we would. We fought against the odds. We carried the unencumbered HTML5 <video> torch even when it burned our hands.

We were called naive (no) idealists (yes). We were told that we were rolling a large stone up a tall hill (and how!). We were told that we could never overcome the momentum behind H.264 (possibly true, but Mozilla was not about to give up and pay off the patent rentiers).

Then in 2009 Google announced that it would acquire On2 (completed in 2010), and Opera and Mozilla had a White Knight.

At Google I/O in May 2010, Adobe announced that it would include VP8 (but not all of WebM?) support in an upcoming Flash release.

On January 11, 2011, Mike Jazayeri of Google blogged:

… we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

These changes will occur in the next couple months….

A followup post three days later confirmed that Chrome would rely on Flash fallback to play H.264 video.

Where we are today

It is now March 2012 and the changes promised by Google and Adobe have not been made.

What’s more, any such changes are irrelevant if made only on desktop Chrome — not on Google’s mobile browsers for Android — because authors typically do not encode twice (once in H.264, once in WebM), they instead write Flash fallback in an <object> tag nested inside the <video> tag. Here’s an example adapted from an Opera developer document:

<video controls poster="video.jpg" width="854" height="480">
 <source src="video.mp4" type="video/mp4">
 <object type="application/x-shockwave-flash" data="player.swf"
         width="854" height="504">
  <param name="allowfullscreen" value="true">
  <param name="allowscriptaccess" value="always">
  <param name="flashvars" value="file=video.mp4">
  <!--[if IE]><param name="movie" value="player.swf"><![endif]-->
  <img src="video.jpg" width="854" height="480" alt="Video">
  <p>Your browser can't play HTML5 video.
 </object>
</video>

The Opera doc nicely carried the unencumbered video torch by including

 <source src="video.webm" type="video/webm">

after the first <source> child in the <video> container (after the first, because of an iOS WebKit bug, the Opera doc said), but most authors do not encode twice and host two versions of their video (yes, you who do are to be commended; please don’t spam my blog with comments, you’re not typical — and YouTube is neither typical nor yet completely transcoded [1]).

Of course the ultimate fallback content could be a link to a video to download and view in a helper app, but that’s not “HTML5 video” and it is user-hostile (profoundly so on mobile). Flash fallback does manage to blend in with HTML5, modulo the loss of expressiveness afforded by DHTML playback controls.

Now, consider carefully where we are today.

Firefox supports only unencumbered formats from Gecko’s <video> implementation. We rely on Flash fallback that authors invariably write, as shown above. Let that sink in: we, Mozilla, rely on Flash to implement H.264 for Firefox users.

Adobe has announced that it will not develop Flash on mobile devices.

In spite of the early 2011 Google blog post, desktop Chrome still supports H.264 from <video>. Even if it were to drop that support, desktop Chrome has a custom patched Flash embedding, so the fallback shown above will work well for almost all users.

Mobile matters most

Android stock browsers (all Android versions), and Chrome on Android 4, all support H.264 from <video>. Given the devices that Android has targeted over its existence, where H.264 hardware decoding is by far the most power-efficient way to decode, how could this be otherwise? Google has to compete with Apple on mobile.

Steve Jobs may have dealt the death-blow to Flash on mobile, but he also championed and invested in H.264, and asserted that “[a]ll video codecs are covered by patents”. Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard.

Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly. Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.

So even if desktop Chrome drops H.264 support, Chrome users almost to a person won’t notice, thanks to Flash fallback. And Apple and Google, along with Microsoft and whomever else might try to gain mobile market share, will continue to ship H.264 support on all their mobile OSes and devices — hardware-implemented H.264, because that uses far less battery than alternative decoders.

Here is a chart of H.264 video in HTML5 content on the Web from MeFeedia:

And here are some charts showing the rise of mobile over desktop from The Economist:

These charts show Bell’s Law of Computer Classes in action. Bell’s Law predicts that the new class of computing devices will replace older ones.

In the face of this shift, Mozilla must advance its mission to serve users above all other agendas, and to keep the Web — including the “Mobile Web” — open, interoperable, and evolving.

What Mozilla is doing

We have successfully launched Boot to Gecko (B2G) and we’re preparing to release a new and improved Firefox for Android, to carry our mission to mobile users.

What should we do about H.264?

Andreas Gal proposes to use OS- and hardware-based H.264 decoding capabilities on Android and B2G. That thread has run to over 240 messages, and spawned some online media coverage.

Some say we should hold out longer for someone (Google? Adobe?) to change something to advance WebM over H.264.

Remember, dropping H.264 from <video> only on desktop and not on mobile doesn’t matter, because of Flash fallback.

Others say we should hold out indefinitely and by ourselves, rather than integrate OS decoders for encumbered video.

I’ve heard people blame software patents. I hate software patents too, but software isn’t even the issue on mobile. Fairly dedicated DSP hardware takes in bits and puts out pixels. H.264 decoding lives completely in hardware now.

Yes, some hardware also supports WebM decoding, or will soon. Too little, too late for HTML5 <video> as deployed and consumed this year or (for shipping devices) next.

As I wrote in the newsgroup thread, Mozilla has never ignored users or market share. We do not care only about market share, but ignoring usability and market share can easily lead to extinction. Without users our mission is meaningless and our ability to affect the evolution of open standards goes to zero.

Clearly we have principles that prohibit us from abusing users for any end (e.g., by putting ads in Firefox’s user interface to make money to sustain ourselves). But we have never rejected encumbered formats handled by plugins, and OS-dependent H.264 decoding is not different in kind from Flash-dependent H.264 decoding in my view.

We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP.

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

Our mission continues

Our mission, to promote openness, innovation, and opportunity on the Web, matters more than ever. As I said at SXSW in 2007, it obligates us to develop and promote unencumbered video. We lost one battle, but the war goes on. We will always push for open, unencumbered standards first and foremost.

In particular we must fight to keep WebRTC unencumbered. Mozilla and Opera also lost the earlier skirmish to mandate an unencumbered default format for HTML5 <video>, but WebRTC is a new front in the long war for an open and unencumbered Web.

We are researching downloadable JS decoders via Broadway.js, but fully utilizing parallel and dedicated hardware from JS for battery-friendly decoding is a ways off.

Can we win the long war? I don’t know if we’ll see a final victory, but we must fight on. Patents expire (remember the LZW patent?). They can be invalidated. (Netscape paid to do this to certain obnoxious patents, based on prior art.) They can be worked around. And patent law can be reformed.

Mozilla is here for the long haul. We will never give up, never surrender.

/be

A lot of people are interested in Firefox, the progress that is being made and what we plan to do. Therefore, I’d like to outline the things we accomplished with Firefox in 2011, and what we have already done, and plan to do, in 2012.

Continued…

Firefox 11 contains the first Firefox implementation of the SPDY protocol. SPDY is a secure web transport protocol that encapsulates HTTP/1 while replacing its aging connection management strategies. This results in more responsive page loads today and enables better scalability with the real time web of tomorrow.

The most important goal of SPDY is to transport web content using fewer TCP connections. It does this by multiplexing large numbers of transactions onto one TLS connection. This has much better latency properties than native HTTP/1. When using SPDY a web request practically never has to wait in the browser due to connection limits being exhausted (e.g. the limit of 6 parallel HTTP/1 connections to the same host name). The request is simply multiplexed onto an existing connection.

Many web pages are full of small icons and script references. The speed of those transfers is limited by network delay instead of bandwidth. SPDY ramps up the parallelism which in turn removes the serialized delays experienced by HTTP/1 and the end result is faster page load time. By using fewer connections, SPDY also saves the time and CPU needed to establish those connections.

The page-load waterfall diagram below tells the story well. Note the large number of object requests that all hit the network at the same time. All of their individual load times are comprised exclusively of network delay and by executing them in parallel the total page load time is reduced to a single round trip.

Generally speaking, web pages on high latency connections with high numbers of embedded objects will see the biggest benefit from SPDY. That’s great because its where the web should be going. High latency mobile is a bigger part of the Internet every day, and as the Internet spreads to parts of the world where it isn’t yet common you can count on the fact that the growth will be mobile driven. Designs with large numbers of objects are also proving to be a very popular paradigm. Facebook, G+, Twitter and any avatar driven forum are clear examples of this. Rather than relying on optimization hacks such as sprites and data urls that are hard to develop and harder to maintain we can let the transport protocol do its job better.

Beyond better page load time, there is good reason to think this approach is good for the web’s foundation. The way HTTP/1 uses large numbers of small and parallel active connections creates a giant networking congestion problem. This inhibits the deployment of real time applications like WebRTC, VOIP, and some highly interactive games. SPDY’s small number of busier connections fits the congestion control model of the Internet much better and enables the transport of classic web content to cooperate better with these real time applications. Web browsers have only managed to keep the congestion problem in check with HTTP/1 through arbitrary limits on its parallelism. With SPDY we can have our parallel-cake and eat it in low latency conditions too. This property is what I find most promising about SPDY, and I’ve written about it extensively in the past.

There is a great transition path onto SPDY. It is a new protocol, but it uses the old https:// protocol scheme in URIs. No changes to markup are needed to use SPDY. Generally SPDY servers support both SPDYand HTTP/1 for use with browsers that are not SPDY capable. The protocol used is silently negotiated through a TLS extension called Next Protocol Negotiation. The great news here is that upgrading to SPDY is just a matter of an administrative server upgrade. No changes to content are needed and things like REST APIs continue to work unmodified. Indeed, a SPDY site is not visually different in any way from an HTTP/1 site.

Google did a lot of work to launch this technology and to evolve it in the open, but it isn’t a Google only project any more. Since the implementations in Chrome and various Google web services were introduced we have seen either code or commitments regarding SPDY from many other products and groups including Amazon’s tablet, node.js, an Apache module, curl, nginx, and even a couple CDNs along with Mozilla. In my opinion, that kind of reaction is because engineers have looked at this and decided that it is solves several serious problems with HTTP’s connection handling and that this is a technology well positioned for us all to cooperate on. There is also discussion and preliminary movement in all the right standardization forums such as the W3C TAG and the IETF. Open standardization of the protocol is a key condition of Mozilla’s interest in it, but it is not a precondition to using it. Gathering operational experience instead of just engineering on whiteboards, is a valuable part of how the best protocols are made. The details of SPDY can be iterated based on that experience and the standardization process. The protocol is well suited to that evolution at this stage.

SPDY needs to be explicitly enabled through about:config in Firefox 11. Go to that URL and search for network.http.spdy.enabled and set it to true. Future revisions hope to have it enabled by default.

After a little break, Mozilla Hacks Weekly is now back! More reading tips from Mozilla’s Developer Engagement team. We also have a new format for our content, so please let us know if you have any thoughts on that!

Continued…