Using Firebug to Figure Out Why Your Website Is Running Slow

When trying to figure out why a web site is running slow, the first place I start is pulling up Firebug, a plugin for Firefox, the web developer's utility belt.

Why do I use Firebug?

Its the quickest way to narrow down your search without having to log into your web server, and we all are interested in saving time.  Its also free and it has matured so much over the years that it really is amazing how it can improve your debug skills.

How Do You Know Your Site is Slow?

So you have a slow website, but before you get started trying to speed things up, its good to have in mind what your goal is for performance is.  Most of the time, having a slow website is just a feeling, you know its slow because of your expectations on how fast a website in general is supposed to load.  We all view a lot of web pages, so our expectations are realistic and based on a ton of first-hand experience.  Trust your gut, but back it up with data.

Set a Page Load Time Goal

The first thing I do is set a goal for the page load time.  This is the time from when I type the address in and hit enter, or from when I click a link, to the time that the page is usable.  This page load time goal is different for different types of web sites.

For a standard blog or information site where you are viewing content or product pages, my goal is to be less than 4 seconds.  This isn't based in anything real scientific, just my experience.  And it is also a very achievable goal for those types of sites.  If you are not sure what feels good to you, go visit some similar sites and see what their page load time is.

Let's Get Some Numbers

To figure out what your current page load time is, open firebug, go to the Net tab, and scroll all the way to the bottom and see the times listed on the bottom right corner.  If you didn't have Firebug enabled for the site, you may have to refresh the web site after opening up Firebug for the first time.

The screenshot shows 2.01s, with an onload time of 2.19s.  The onload time is when your site is done loading everything local to your site (HTML, CSS, Javascript code, images).  The first listed time can be longer than the onload time if you are loading things in from other sites using javascript AJAX reqeusts, videos, widgets from other sites like Facebook or Twitter.  Read more about this here.

Which one of those you use for page load time kinda depends on the site, but I typically use the onload number, unless the items loaded from other sites is a large part of your page and the change is apparent to the user, like loading the thumbnail frame in a video player.

Firebug Setup - Disable Browser Cache

For doing the page load time testing, I use Firebug to disable the browser cache.  I do this because the user of my site I'm trying to please is viewing the site for the first time.  First impressions are everything.  If they come to the site, and its slow, they may not even let the page continue loading and go back to google for the next result.

So open Firebug, go to the Net panel, click on the down pointing triangle, and select "Disable Browser Cache".

Checking the performance of your site with the Browser Cache enabled like normal is important, too. You can have caching issues, but your site with caching enabled should always load faster than your un-cached page, so it will meet our page load time goal.

Breaking Down the Net Panel View

Let's look at the top of the Net Panel.  This is for my Zerrtech site which happens to be a Drupal 6 site, with PHP, Apache, and MySQL.

Notice that the first line is the web page I'm loading,, and the next lines following are CSS files.  The web page HTML has to load before the web browser knows what other assets to load, like CSS, Javascript, and image files.

Knowing this is important, you can see that it takes 107ms for the HTML itself to be generated by the server and be transferred to the web browser.  This time would include Apache handling the request, interpreting your PHP code, accessing the MySQL database.  So if that time is too long, then you have a server side performance issue.  If it is fast enough, then you know that you do not need to tweak anything on the server, this eliminates changing most PHP, Apache, or MySQL settings, which eliminates a lot.

Getting Deeper into the Timeline

Let's take a bigger look at the timeline, I'll hover over one of the timeline items to see more detail.

I want to point out the Grey color in the timeline, which shows Blocking.  This means the web browser is waiting for other requests to complete before issuing a new one.  Your web browser is configured to have a maximum number of concurrent, or simultaneous, connections to a single domain.  I'm using Firefox, and this maximum is 6 at a time.  So only 6 simultaneous requests to can be active at a time.  Different browsers have different limits, see this link on Stack Overflow for an idea how much this differs.

So notice what the picture shows.  You see the first request for, and the next 5 CSS files have no grey in their timeline, but then the next CSS file I'm hovering over has 83ms of blocking.

Reducing blocking time is the reason why it is advised to reduce the overall number of requests your site makes by combining all your CSS and Javascript files into one single file.  Doesn't affect the operation of the site, but can greatly reduce the number of requests and improve the load time.  This is a setting that is built into Drupal, clicking two options via the online admin area will combine these for you.

What Are You Waiting For?

In the Firebug timeline, the Purple part is for Waiting, and green is for Receiving.

The item that is loading here is an image.  So after the request reached the server, it waited 555ms before sending back a response, and that response took 277ms to transfer.

If you have a lot of images, you might spend a lot of time Receiving which is going to be limited by the bandwidth of your connection to the server.  This might mean you have too many images, or they are too big, or you have a slow connection to the server.

Also notice that there is a lot of blocking before this request can start.  Because images are typically the biggest assets loaded by the site, this is why a lot of people put them on a separate domain or a CDN (content delivery network) like Amazon S3.  Remember we talked about the web browser having a max of 6 requests at a time to any one domain.  If you split the images off onto a separate domain, they can start being pulled in parallel to your other requests and will avoid causing other assets to block further.  So you can then have 12 requests in parallel, 6 each to the different domains.

Also, the Waiting time would be time the server takes to pull the file off of the disk or a cache and start sending back.  If it is pulling from a slow disk on the server, or the server is under a lot of I/O load, this could further slow down that waiting time.  If the Waiting time becomes really long, like in the seconds, this can also be a symptom of the web server running into the max requests it can handle at once, in Apache, this is the MaxClients setting.  Also, if your web server is running out of memory to server the requests, it could end up using virtual memory, and that is another thing that would make the Waiting time get huge.

Another Tool to use With Firebug - YSlow

If you want to use a tool that does most of this analysis for you, without needing to know the technical details of how the Firebug Net panel works, use YSlow, which is a Firefox plugin that integrates with Firebug.

YSlow profiles your site and gives you a grade on a bunch of different optimization categories to help on the client side.  Also gives great details on the "Why?" of the optimization and ideas how to fix. But ultimately, you need to prioritize what is causing your slow site performance.  Even though YSlow might give you an F in a category, without using the Firebug Net panel, you don't really know what kind of load time hit it accounts for.  You might have more productive areas to look into.

YSlow is a great educational tool, even if your site is performing adequately, its a good idea to check your site out.

Use Firebug First Before you Waste Time

I always use Firebug before diving into tweaking things on the server.  You can waste a lot of time and not make a lot of difference, so for the sake of being efficient, start with Firebug first to narrow down your problems.