I just got back from Berlin where I spoke at Velocity Europe as a Mozilla representative about browser performance. Instead of smothering and boring the audience with browser internals and numbers that will be outdated within a few nightly releases I took a more holistic approach to performance. Browsers should make everyboby perform better and so far we haven’t quite done that for developers yet. Check out the talk materials here.

Slides and Audio

You can see the slides here (left+right to go back and forward, down for next bullet point and N to toggle notes) or read them as an HTML page:

There is also an audio recording of the talk on archive.org:

And here are the full notes I wrote for myself before “sliding” them up:

Notes

We’re here at a performance conference where we talk a lot about how to make the web perform faster. Yet I was invited here to talk about a browser and why it is cool to use it.

You know what, that doesn’t get us anywhere. As publishers of web-based content and applications it is not our job to make browsers compete against each other on pure technical numbers and criteria. These change every few weeks and actually are not a depiction of the reality out there.

Whatever you hear here today about different browsers will not change the decisions of your end users.

If you want numbers, they are out there. Go to http://arewefastyet.com and go nuts. It shows you all the performance numbers of Firefox in the current test suites and it has pretty graphs to boot.

A browser is much more than a performing piece of software. It is the interface between our end users to the web. It is also the thing we as developers use to test what our end users see and this is where things go severely pear-shaped.

Our end users have browsers that are different to ours. No matter what we do to keep the browser fast and snappy people will find a way to mess this up.

As a Mozilla employee I get a lot of feedback on Twitter about the performance of Firefox. The first thing is always “it is too slow”. Upon investigation as to the why it is slow you do get interesting results though.

Almost all of them are based on developers doing incredibly complex things that are not meant to be. A lot is based on misunderstanding of web technologies as a necessary evil rather than really learning them.

End users on the other hand have a lot of gripes that are based on people customising their browser to the n-th degree or using the browser in a fashion that hints at superhuman powers. My favourite so far was someone who complained that startup of Firefox was annoyingly slow when you have 140 tabs open!

Analysing our user’s behaviours with their consent is a very insightful exercise. We found for example that the average usage time of private browsing mode is 5 minutes. What does that say about performance?

It means that travel web sites are very well optimised! Because we all know that this is what private browsing mode is about: booking that surprise holiday for you and your other significant half.

Seriously though, let’s talk a bit about best practices in development. Starting with Yahoo’s exceptional performance web sites and Google’s page speed and webmaster resources we threw out a lot of great documentation and solutions for developers to make their sites behave better. Do people take it on? Yes, they do. To a degree. If they can trust the information. Allowing the tools we aimed at those people to deteriorate over time doesn’t help there. I see a lot of outdated truisms making their rounds on mailing lists and forums as the original people building YSlow moved on to solve other problems.

Check web sites built with out-of-the-box CMS installs. Some of them have CSS files for every single module that just keep getting added to the document. This was the only way we learned that IE can only load 31 style sheets before giving up. Nobody would ever code this by hand and think it a good idea. That systems out-of-the-box don’t concatenate the files is ridiculous seeing that we’ve been advocating that as a best practice for years now. So I see a disconnect between the people preaching best practices in performance and those building real products.

Take a look at Github. A great web resource and probably the number one resource for open source projects these days. Let’s take a look at their CSS.

Boom! 22212 lines in 3711 selectors. We use that right now to stress test our developer tools.

Talking of which, let’s take a look at one of the main reasons why people say Firefox is slow: Add-ons that don’t perform well and complex add-ons that interfere with the rendering of the browser.

Debugging can be an incredibly disruptive thing. The other day Zynga released a great piece of software for HTML5 app development: a scroller routine that allows you to scroll and zoom a playing field or document. They announced it to be incredibly performant. Joe Hewitt released something similar before that and claimed immediately that Zynga’s code actually performs terrible on an iPad. Investigation showed that the only reason why it performed badly was because of the debugging information being shown in form fields. Turning that off meant great performance.

The learning from this is that when you give access to debugging information you are always likely to skew the results you get. Which is why a lot of performance gripes on Firefox are actually based on Firebug.

When Firebug came out it was a revolution and a refreshing warm summer rain for web developers out there. For the first time in history of web development we had a chance to see what is going on and how to inspect the document after it has been modified by JavaScript. It was also a great opportunity for quick changes and previewing changes without needing to rebuild an app or transfer it to the staging servers.

Firebug became the de-facto developer tool in browsers and all the others copied it. I remember Opera coming to Yahoo and asking the web developers there what they expect from a good debugging tool. We all told them to simply to copy Firebug. So Dragonfly started looking like a clone of Firebug. The Safari developer tools and the Chrome ones did the same. So did the ones in IE.

As with any piece of software that gets a lot of excitement people started adding feature after feature as “developers want that” and nowadays all the developer tools sport lots and lots of features and become quite a confusing piece of UX. This makes the tools fatter and less performant and is counterproductive to the cause.

This is why Firefox now comes with built-in developer tools that are not Firebug. Instead of copying the Firebug way we decided to keep it simpler and let the developer choose what debugging tools they need. The very simplest is the console – something you will always need to debug and find issues in your code. JavaScript error consoles were probably the first thing people wanted.

On top of that we have a CSS style editor. This is a performance hog and will interfere with any testing. But it is pure magic for finding out why a certain style has not been applied. The new thing in the style editor is also that you see the settings the browser applied to the elements that might cause a display issue.

ALl of the features we have for developers in browsers now are debugging tools. What if we take that further and aim for developer tools in the browser?

One of those we have right now is the scratchpad. This is a simple editor in the browser that allows users to write more complex JavaScript to test on the current page and run it against it. Instead of writing a JS and setting breakpoints you can highlight parts of the script and run only those. Once done, you can save the file to your hard drive.

As a developer, this saves me a lot of time trying out new things. I don’t need to use a development server or local machine and insert a JS I need to remove later on and I don’t need to build a project to try out some new functionality. Think of it as Greasemonkey on steroids.

All of these tools are meant to make the developer perform better. End users don’t have to have these and they shouldn’t interfere with their surfing experience. It is very likely that our web sites and applications are constantly changing, which means that by giving developers the right tools to build faster and test more easily we can deliver faster and better.

We do this by separating the development tasks out into specialised tools to help debugging and developing in the browser rather than for it.

As said before, the main entry point to developing and debugging is some kind of command line. Instead of just having a JavaScript console we extended its reach to allow you to control the developer tools themselves with a series of commands. So instead of having to go through the menus or having to memorise a lot of shortcuts you can turn the different tools on and off with a set of commands.

A lot of what we do on the web these days is to replace the web native languages with more specific ones and use build scripts to concatenate and minify files.

This makes us less effective as debuggers. Most developer tools will undo these to display the code in a readable manner but won’t report you the correct location of the erroneous code.

Source Mapping will solve this. For now, our developer tools will for example allow developers to write in Coffeescript and report both the error line in the generated JavaScript and in the source. This could in the future be extended to LESS or SASS or whatever other language we will come up with to fix the inadequacies of the native ones or make it easy to write a certain CSS effect without having to repeat a lot of code with different browser prefixes.

It is also time to give people different ways to realise what they are doing wrong when it comes to making the web fast for the web. Almost every browser allows you to inspect the DOM and find issues with the structure of your document but it might not be obvious just how much your templating skills create in terms of HTML cruft.

One great new feature for that is that the next Firefox versions will show HTML5 parsing errors already in the source view. That way developers can simply find issues. With templating the source we edit is not the one the browser creates.

Tilt is a unique new way to make this more obvious to people. It displays the page as a 3D model and you can easily see where your nesting went overboard even when the HTML is minified.

All in all we aim with Firefox to be a browser that brings the web to the end user and keeps them in control of what they do on the web. This spans much further than browser performance. The performance of the base browser becomes a given, not a goal.

Instead of looking simply at how the browser behaves we are part of some much more interesting ideas how to turn the web into a development and app platform. Mozilla’s open apps for example allow you to distribute apps with any web site by adding a meta tag.

BrowserID allows end users to log into sites without usernames and passwords. For developers, you can have a verification system that uses one HTTP request and works smoothly in the background.

I think it is time we look at performance in a much larger way than just fixing what others do wrong. We need to empower web developers with good tools and systems to do things right and keep them maintainable rather than translating their work to machines for them.