Regarding Firefox 4 support: please see the section Developer Comments below.
The plugin will add a status bar at the bottom right corner of Firefox and will display:
* TTFB: how long it took to see the first byte from remote server (from click to first byte received). This value gives a rough estimate on when the browser can start laying out the content.
* TTC: how long it took to display the page (from click to complete drawing of the page)
* Page size (number of bytes used to display the page): this value includes both bytes fetched from network and bytes fetched from the browser's cache.
* Number of requests: number of requests used to fetch the page's content (images, style-sheet, javascript ....). Again, this value include both network requests and cache requests.
Notes: that the above stat is only updated when a page is completely displayed (the progress bar is no longer displayed).
Tips
Some rule-of-thumbs on how to interpret/compare these metrics:
* For TTFB, shorter is better. Even for page that is large, a short TTFB (less then .5 sec) allows the browser opportunity to layout the page content as soon as possible. This can enhance the user's perception of responsiveness.
* TTC, obviously shorter is better. The current general agreement is that anything above the range of 7-10 seconds are perceived by user as slow.
* Page size, smaller is better. Most fast sites seem to max out around 75KB per page. Anything above 100KB tends to appear sluggish.
* Number of requests, smaller is better. Nowaday, with HTTP persitent widely supported, the cost of fetching another request no longer significant. But keep an eye for extreme cases (50+). This value tends to correlates well with the page size (large number of request -> large page size).
Keywords: timing, profile, optimize, stopwatch, measure page, http request
The plugin will add a status bar at the bottom right corner of Firefox and will display:
* TTFB: how long it took to see the first byte from remote server (from click to first byte received). This value gives a rough estimate on when the browser can start laying out the content.
* TTC: how long it took to display the page (from click to complete drawing of the page)
* Page size (number of bytes used to display the page): this value includes both bytes fetched from network and bytes fetched from the browser's cache.
* Number of requests: number of requests used to fetch the page's content (images, style-sheet, javascript ....). Again, this value include both network requests and cache requests.
Notes: that the above stat is only updated when a page is completely displayed (the progress bar is no longer displayed).
Tips
Some rule-of-thumbs on how to interpret/compare these metrics:
* For TTFB, shorter is better. Even for page that is large, a short TTFB (less then .5 sec) allows the browser opportunity to layout the page content as soon as possible. This can enhance the user's perception of responsiveness.
* TTC, obviously shorter is better. The current general agreement is that anything above the range of 7-10 seconds are perceived by user as slow.
* Page size, smaller is better. Most fast sites seem to max out around 75KB per page. Anything above 100KB tends to appear sluggish.
* Number of requests, smaller is better. Nowaday, with HTTP persitent widely supported, the cost of fetching another request no longer significant. But keep an eye for extreme cases (50+). This value tends to correlates well with the page size (large number of request -> large page size).
Keywords: timing, profile, optimize, stopwatch, measure page, http request