Even with intense competition from tools integrated into other web browsers, Firebug is arguably still the leading web development tool in use, with nearly two million active daily users. Its web site needed to reflect Firebug’s capabilities more clearly. With that in mind, the primary goals with this redesign were to make the official Firebug web site easier to use, more pleasant to look at, and give Firebug more of a traditional software-style layout to highlight its many positive qualities.

GetFirebug.com: Before

GetFirebug.com: After

It’s a fairly straightforward design, so there’s not a lot of interesting production notes to highlight, but here’s some specifics on what went into this redesign:

• The layout is roughly based on the 960 grid system. The original hope was to do the site in a fully fluid layout, but time constrains intervened.
• Headers and pull text are in the gorgeous (and open source!) Tittillium, thanks to @font-face. The body text was originally set in Droid, but due to a legibility issue on Windows machines with text-smoothing disabled, it was switched to the more common Trebuchet MS.
• The pages are build using the HTML5 doctype, with JQuery and the Fancybox plugin powering the modal pop-ups.
• The screencast on the homepage uses the Video for Everybody system to embed the OGG video, with MP4 and Flash fallback for other user agents.
• The homepage blog feed pulls in from the Firebug weblog RSS feed using SimplePie.
• For this iteration, we wanted to switch the site over to a simple content management system, and ended up settling on Perch. It has its shortcomings, but it was straightforward enough and easy enough for me (mostly a designer/UX guy) to implement.
• Sean passed along a few images that inspired the sparkly new icon. Originally, we tossed around the idea of doing something cartoony and heroic, like this lil’ dude, but ultimately decided to go with a more, well, buggier bug.
• Photographic inspiration: Bug 1 • Bug 2 • Bug 3 • Bugs!

It’s been a long time coming, and we hope you like GetFirebug.com’s new set of clothes. The content is currently being updated and will roll out as it is completed, but in the meantime, please kick the tires and let us know what you think.

• FULLTEXT indexes are only available on MyISAM tables.
• Adding FULLTEXT indexes can slow down INSERTs and UPDATEs.
• FULLTEXT indexes can span multiple columns, but not multiple tables of data.
• Searching can increase the load on your database server.

Fortunately, a search system, like Sphinx, allows you to overcome these limitations and provide powerful, flexible, and fast search solutions.

Sphinx, in particular, is easy to set up and use. It powers searches on both Addons and Support. We honestly didn’t shop around, because we found Sphinx did what we needed very well.

Because Sphinx is external to MySQL, it doesn’t care about things like what table engine you use, so you can perform fast, full-text searches on InnoDB tables. It also takes the load of searching off the database, leaving it free to retrieve all the documents your users can find. And because Sphinx finds its data via SQL queries, indexes can collate data in several tables.

How fast does Sphinx index data? For both Addons and Support, indexing is under two minutes, which includes on the order of 10^4 documents on Addons, and on the order of 10^5 on Support. This speed means we could easily double or triple the quantity of data before we’d need to rethink our search strategy.

Sphinx typically collects data by running SQL queries, so if you can write a query to get your data–possibly joining data from several tables, or small, extra queries for many-to-many relationships like tags–you’re done. If your data isn’t in a SQL database, you can feed it data in XML. If you have lots of data, or lots of old data that doesn’t change, you can break this into smaller indexes, or just look at what’s changed, and merge the data together.

The index includes all the text you select and several attributes you can define, which you can use to filter results, or to retrieve the document from the database.

Running searches from your application is very flexible. PHP, Python, Ruby, and others have ports of the search API. You can also search via a SQL interface. There’s even a command line search binary for testing. The API can do some pretty advanced things, like sorting, filtering, settings offsets and result limits, or even building excerpts for your results.

Search is an important part of data-driven web applications, and Sphinx is a powerful ally in providing search capabilities. If you’ve been relying on FULLTEXT indexes, I encourage you to try a search system like Sphinx. And if you need help, come find us in #webdev on irc.mozilla.org.

In case you didn’t already know, Personas (AKA ‘lightweight themes’) have been integrated into Firefox 3.6. With the impeding tsunami of traffic from millions of Firefox users headed towards getpersonas.com, I knew my time had come. Donning Firebug, YSlow and webpagetest.org, I set out to squeeze every last drop of performance out of it.

I knew my work would be painstaking, arduous and gut-wrenching, but I couldn’t let the fear of disappointing millions of Firefox users around the world stop me.

Minify

My first task: concatenation and minification of JavaScript and CSS. My weapon of choice: Minify.

Minify is a neat little PHP library that will take a list of CSS or JavaScript files, concatenate into one file, minify (remove whitespace and linebreaks) and gzip them. The plus is it doesn’t involve running any code before you push your files live, you can point your CSS & JavaScript URLs directly at Minify like so: http://getpersonas-cdn.mozilla.net/static/min/?g=css&r=59272. (g=css tells Minify I want the ‘css’ group of files)

The benefits of Minify are less HTTP requests and small file sizes due to minification and gzip. For getpersonas.com, 3 JavaScript files were reduced to 1¹.

Move JavaScript to the bottom of all pages

Next, in order to make getpersonas.com appear faster, I knew I had to move JavaScript to the bottom of every page.

From a previous test on webpagetest.org, it was apparent that users were waiting for the JavaScript in the head of the page to download before any other content. This is a well-known ‘feature’ of all web browsers. JavaScript blocks parallel downloading for all hostnames, period. The remedy? Move JavaScript to the end of the page.

Thankfully I hadn’t written any inline JavaScript, so moving the reference to the main JavaScript file to the bottom of every page was relatively simple. The benefit? Rendering of each page started 500ms earlier. While seemingly small, half a second is enough for a user to detect.

Add far-future expires headers

My next task? Adding far-future expires headers to all CSS, JS and images.

When visitors browse your website, they often view multiple pages that share common resources. Images, CSS, JavaScript, etc. Unfortunately, browsers need to check each file on every page load to see if it has changed. This requires many requests to the webserver, each incurring a non-trivial cost, sometimes in the hundreds of milliseconds. The method to avoid this is to use far-future expires headers.

Expires headers tell browsers how long they can store a file in their cache. If the expires headers tell browsers to cache a file for a long time, the browser doesn’t need to check to see if it has changed. This is what they look like:

Expires: Thu, 15 Apr 2020 20:00:00 GMT

In this case, the file doesn’t expire until April 15, 2020 at 8:00pm. Adding this to a .htaccess file in /static gave all our images proper expires headers:

<FilesMatch "\.(jpg|jpeg|png|gif|ico)$">
ExpiresActive On
ExpiresDefault "access plus 10 years"
</FilesMatch>

“But wait!”, you say. How will browsers know when the file has changed if it never checks for a new version? Easy, change the filename or append a query string. All persona images have a modified timestamp at the end of their URLs: http://getpersonas-cdn.mozilla.net/static/8/8/48888/preview.jpg?1260925626 and CSS & JavaScript have their SVN revision number instead: http://getpersonas-cdn.mozilla.net/static/min/?g=js&r=59113. (And Minify is configured to send far-future expires headers) For ‘regular’ images used throughout the site appending a new version # to the end of the url is easy enough.

For users, this means a faster overall site. Repeat view time decreased from 1.6 seconds to 0.7 seconds.

Use a CDN

Last but not least, we needed to move our content closer to users around the world. How? A content delivery network (CDN).

A big problem with the Internet is people all around the world use it. Sometimes from thousands of miles away from your webserver. Fiber optic cables under the ocean may be fast, but 50 or 100ms of round-trip time adds up when users need to download dozens of files. Short of inventing faster-than-light communication, the next easiest thing to do is move your content closer to your users.

Instead of buying our own servers and copying files to them, we’re using a CDN for getpersonas.com. A CDN has servers set up around the world and has done all the hard work for us already .

All our images, JavaScript and CSS are served from the CDN’s servers. The way we achieved this is by setting up a separate hostname that points to them (getpersonas-cdn.mozilla.net). When a browser requests a file from getpersonas-cdn.mozilla.net, the CDN fetches it from our webservers, caches it (because of our far-future expires headers ) and serves it to the browser.

Since our CDN has servers in multiple locations around the world, users download files faster and with better latency.

Results?

This post wouldn’t be worth reading without some pretty charts and graphs now would it? (Results according to webpagetest.org, a great performance tester)

Summary:

• 500ms earlier rendering start time
• 300ms shorter download time (most likely even faster for users across the globe)
• >2x increase in repeat view speed

Before:

After

One more thing:

For an overview of how much we’ve sped up getpersonas.com since October 2009, here’s a speed test from then (before a site redesign):

That’s a decrease of two seconds in download time and rendering starts 1.7 seconds earlier. Not bad, eh?

[1]: An additional JavaScript file was added between tests shown at bottom of post.

Special thanks to Stephen Donner, Krupa Raj, Jeremy Orem and Matthew Zeier for their hard work in making getpersonas.com blazing fast.

Early snapshot of the Plugin Directory

Most web browsers, including Firefox, offer the ability to install third-party plugins. These plugins enhance your browser by enabling it to handle new kinds of content—i.e. video, audio, even 3-D games and whole application platforms.

Unfortunately, plugins can also introduce crashes and security vulnerabilities. And even worse: Since there’s no automatic update mechanism across plugins, it’s easy to install a one and forget it’s even there. Unless you return regularly to a plugin’s download page, you may never think to update it.

With this in mind, we launched a page a few months ago to detect outdated installations of the Adobe Flash plugin, encouraging Firefox users to download an update. Soon after, we expanded the effort by launching a general Plugin Check page to cover more plugins used with Firefox.

But, since it’s our mission to make the web a better place, we want to go even further: We want to expand this Plugin Check service to cover as many browsers and plugins as possible.

As it turns out, that’s a tall order: Competing browsers offer entirely different models of collecting information on installed plugins, and plugins themselves reveal inconsistent information from one to the next. This makes a common detection scheme across browsers and plugins somewhat challenging.

Additionally, there’s no single fresh source of information about plugins to check once the installed versions have been detected. For example, while the PluginDoc site at mozdev.org has existed for years, it tends to be out of date because it’s largely maintained manually by just a few people. And, if the information was up to date, there’s no web-based service to use for automated update checks.

So, to address these issues, the Webdev team has started work on building a new Plugin Directory. We’re in the very early stages yet, but we’re hoping to make progress on goals like the following:

• Invite plugin vendors to contribute to our database, possibly even through submissions to a web-based API as part of a release process.
• Invite users of varying levels of expertise to contribute to our plugin database, since we need a lot of help cataloging and tracking the plugins in the wild.
• Provide a human-browseable directory to explore the plugin database.
• Offer a web service enabling web pages and browsers to query our database for plugin details.
• Improve plugin detection from web pages and within browsers

We can use help on all of the above as the project progresses, so stay tuned for more details.  In the meantime, you can peek in on the progress so far by visiting the project wiki page, where you can find notes, demos, and source code:

• https://wiki.mozilla.org/Plugins:PluginDirectory

If getpersonas.com seems a little bit snappier today, there’s a reason. Last night we released a new version of the website that utilizes a Content Delivery Network (CDN) that makes browsing getpersonas.com even faster.

What’s a CDN, you ask? To put it simply, a CDN moves content that normally would be served from a website in one location and stores it all around the world, making it faster for you, the user to download it. We’re using a CDN to store images, JavaScript and CSS for getpersonas.com.

Another neat trick we are using to make the site faster is far future Expires headers. What this does is tell the browser to cache our files and not re-download them every time you visit our site, saving you bandwidth and time.

This release also contains numerous bugfixes, view the full buglist if you want to know more.

Special thanks to Stephen Donner, Krupa Raj, Jeremy Orem and Matthew Zeier for their hard work in making this release possible.

• css gradients in Firefox 3.6
• building beautiful buttons with css gradients

Really awesome stuff, looking forward to seeing more and more designs that are normally done with lots of images to be created with CSS!

]]> http://blog.mozilla.com/webdev/2009/11/30/css-gradients-tutorials/feed/ 0 http://blog.mozilla.com/webdev/2009/11/20/mozilla-launches-facebook-security-quiz/ http://blog.mozilla.com/webdev/2009/11/20/mozilla-launches-facebook-security-quiz/#comments Sat, 21 Nov 2009 05:50:58 +0000 morgamic http://blog.mozilla.com/webdev/?p=789

Are you up for the challenge?

This week Mozilla launched the security quiz on Facebook. We encourage you to take the quiz and see how much you know about web security!

Similar to our plugin checker, the security quiz is a part of our larger effort to raise awareness about web security.

Help us spread the word and make the web safer for everyone. And don’t forget to check your plugins!

]]> http://blog.mozilla.com/webdev/2009/11/20/mozilla-launches-facebook-security-quiz/feed/ 2 http://blog.mozilla.com/webdev/2009/11/18/amo-changes-for-2010/ http://blog.mozilla.com/webdev/2009/11/18/amo-changes-for-2010/#comments Wed, 18 Nov 2009 17:54:07 +0000 rdoherty http://blog.mozilla.com/webdev/?p=786 Yesterday Wil Clouser wrote up a blog post detailing infrastructure changes for addons.mozilla.org in 2010.

Notable changes are:

• Migrating from CakePHP to Django
• Moving from SVN to Git
• Continuous integration
• Faster deployment
• Processing data offline
• Improved documentation

Take a look, it’s a good overview of the technical challenges of managing a large and complex website at an enormous scale.

]]> http://blog.mozilla.com/webdev/2009/11/18/amo-changes-for-2010/feed/ 0 http://blog.mozilla.com/webdev/2009/10/13/plugin-checker-launched/ http://blog.mozilla.com/webdev/2009/10/13/plugin-checker-launched/#comments Tue, 13 Oct 2009 22:28:05 +0000 morgamic http://blog.mozilla.com/webdev/?p=731 Today we launched a Plugin Checker to help people find and update their plugins.



Why is this important to you?

• Crashes are the number one concern for Firefox users, and we are listening.
• At least 30% of all Firefox crashes are caused by third-party plugins.
• Many major security vulnerabilities exploit out of date plugins.

Why is this important to Mozilla?

Increasing awareness about plugins makes the web better, and that’s our mission.

• We want the web to be safer.
• We want the web to be less crashy.
• We want to help everyone — not just Firefox users — to address the plugin problem. (though admittedly it doesn’t fully work with all browsers yet, it will)

What did we do?

The plugin checker has three components:

• The Server: Plugin Finder Service (PFS2)
• The Javascript: Perfides
• The Web Page: mozilla.com

The end result is actually pretty simple — and that’s how it needs to be. Here’s your plugins, and here’s their statuses:



Putting it all together, we reach a workflow similar to the graph below. Our goal is to query a central database that contains plugin information and inform users about the status of their plugins. This was built so it could be used to support Firefox directly in the future.



What will happen next?

The three components above are a good start, but together we can do more.

• Integrate this experience with the Firefox client. Firefox will identify vulnerable plugins and help you update them.
• Create a self-service panel for vendors to update their plugin info as new releases come out.
• Create an open directory for all plugin information (sort of like Plugindoc but dynamic)
• Evangelize plugin detection via an embeddable widget — get it out on Wordpress, etc.
• Integrate with our crash reporting system so we have a report card/dashboard for which plugins are most crashy

How can you help?

This entire project is open source. You can work on any of these components to help contribute to the effort:

• View the server code for PFS2
• View the client code for Perfides
• File a bug if you find one
• Tell us about plugins we don’t know about
]]> http://blog.mozilla.com/webdev/2009/10/13/plugin-checker-launched/feed/ 10 http://blog.mozilla.com/webdev/2009/10/02/upyourplug-needs-your-help/ http://blog.mozilla.com/webdev/2009/10/02/upyourplug-needs-your-help/#comments Fri, 02 Oct 2009 23:42:57 +0000 ozten http://blog.mozilla.com/webdev/?p=662 Following up on the Flash Detection on the What’s New page, we are developing an upgrade to the Plugin Finder Service (PFS2).

We could use your help! Please hit our testing server’s Plugin Check. We will be able to capture information about plugins and help fill-out the PFS2 database. See an issue? Look through current bugs and leave feedback in Bugzilla.




Screenshot of plugin detection


If you’re a Plugin Vendor, please put the version of your plugin into the name or description field of your plugin. For example, since they don’t expose this information, the following very popular plugins cannot have their minor versions accurately detected in Firefox with JavaScript alone:
• Adobe Acrobat
• Windows Media Player Plug-in
• RealPlayer (on Mac only, Windows exposes version information)

Some plugins don’t expose a good version number in the description, but can be detected by instantiating the plugin. We’re using Eric Gerds’ PluginDetect for this type of plugin.

On the other hand, kudos go to Microsoft’s Silverlight team for the following information: name=”Silverlight Plug-In” description=”3.0.40818.0″. That’s exactly what we need to identify when a Plugin has fallen out of date.  If a vulnerability is discovered and published against 3.0.40818.0, we can alert the user to pick up the newest version.

It’s very fast and easy for us to detect your release version, when the proper information is provided by the plugin. Doing so is a win for you and your users. We’ll be encouraging Firefox users to keep their plugins updated to the latest and greatest. This means better distribution and lower support costs for you. We’re contacting many vendors right now to make this happen.

Firefox 3.6 is going to be adding enhancements to the way Plugin information is exposed to JavaScript. We’re looking forward to how this will simplify this task.

Interested in the code under development? Check out PFS2 server, PFS2 client and of course Mozilla.com where it will eventually live.

Update 10/3 @12:50 PDT: Thanks to everyone who has filed bugs! Additionally, here is the list of Plugin states, copy, and links. This is going to change, based on your feedback, but I think it will help the discussion.

Status	Copy	Button	Link
Unknown Plugin	N/A we don’t display anything	N/A	N/A
Current	You’re Safe	Learn More	Vendor URL
Old or Unknown Release	Potentially Vulnerable	Update	Vendor URL
Old with Known Exploit	Update Now	Vulnerable	Vendor URL
Current with Known Exploit	Vulnerable No Fix	Disable Now	#disable-now

I think the consensus is that the copy for Current and Old send the wrong message.

]]> http://blog.mozilla.com/webdev/2009/10/02/upyourplug-needs-your-help/feed/ 33