Accelerating the overall web experience
Ghandi once said that there is more to life than increasing its speed. In the same vein there is more to making a browser amazing than making it perform fast. In this talk you’ll learn what Firefox has in store for users and developers alike and get a glimpse into how a browser can blur the line between apps and the web whilst allowing you to experience the web on your own terms.
Christian Heilmann, Mozilla, Velocity Europe, November 2011
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.
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.
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.
On top of that we have a CSS style inspector. 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.
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.
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.
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.