In this article, we’ll cover Firefox Web Developer Tools (“DevTools”) — a set of tools designed to help developers inspect, debug, profile and optimize the performance of websites and web applications. We’ll particularly look at the tools related to performance, but we’ll also see how to get started using DevTools in general, and learn about some useful settings.
You can access DevTools in different ways:
- click on the hamburger menu at the right of the navigation toolbar, click on Web Developer, then choose the sub-tool you want to use
- use keyboard combinations, such as Shift+F5 (Windows and macOS) for the Performance tool and Ctrl+Shift+E (Windows) or Cmd+Option+E (macOS) for the Network tool
- right-click anywhere in the page a choose Inspect Element.
The Firefox DevTools have many options that help developers customize their experience, such as the option to Enable time-stamps in the Web Console, or to Disable HTTP Cache, which is used to simulate first-load performance in all pages that have DevTools open.
You can access the DevTools Settings panel in different ways:
Start by opening DevTools, next:
- either click the Settings button in the toolbar
F1to show the Settings panel on top of any current tool
- press Ctrl+Shift+O (Windows and Linux), Cmd+Shift+O (macOS) to show the Settings panel.
Here you can choose your default tools, the buttons you want to show in the toolbox, themes (dark-light-Firebug) and other advanced settings.
When analyzing the performance of a web application, you need to differentiate between load-time performance and run-time performance.
Let’s look at the Network Monitor and the Performance Tool.
The Network Monitor
The Network Monitor shows you a tabular view of all network requests that Firefox made (for example, when it’s loading a page, or sending
XMLHttpRequests, Fetch API requests etc.).
It can also display request-related HTTP headers, HTTP responses and cookies, and let you search through them. You can also use it to perform, display and save a performance analysis of the current page load.
In a nutshell, this tool can be used to determine how long the browser takes to download different assets of a web page.
You can also use this tool to monitor and single out requests that are slowing or blocking the web page’s fast loading. The Network panel shows you when principal events are fired (
Each request in the network list has a timeline column which displays timing information related to the request, such as the total time taken to load the resource.
DevTools marks major life-cycle events in the report, like
DOMContentLoaded, and page
load. The blue refers to the time when the event
DOMContentLoaded is fired; the purple line refers to the time when the page’s
load event is fired.
DOMContentLoaded vs Load Events
DOMContentLoaded event fires right when the HTML document is completely loaded and parsed, not including CSS style sheets, images, and frames.
load fires when the HTML document and all associated style sheets, images and frames are completely loaded.
Request Details Panel
Once you click on a request in the requests list, you can a see right-docked details pane which has many different tabs such as headers, params, response, timings and security.
For performance, we’ll particularly look at the timing information.
In this pane, there are many timing metrics related to each request:
Blocked is the time spent in a queue waiting for a network connection.
Sending is the time taken for sending the request to the server.
Receiving is the time taken to receive the response from the server or (if it’s cached) to read it from the cache.
Waiting is the total time waited by the client before the first byte has been received. In other performance analysis tools like WebPageTest.org or Chrome’s DevTools, this is called TTFB or Time to First Byte.
There’s also DNS resolution, which is the time taken to resolve the host name of the server, and Connecting, which is the time taken to open a TCP connection.
How to analyze the load time performance
The Network Monitor integrates a performance analysis tool that can be used to analyze the load-time performance of your web page.
To start analyzing the load-time performance, you can:
- click the Analyze icon in the bottom status bar
- reload your page or make a network request while your Network monitor is open (actually this is going only to show tabular information about requests not do a load-time performance analysis).
- number of cached responses
- total requests
- transferred size
- loading time
The web page is tested with an empty cache, and with a primed cache.
First load performance
Firefox’s DevTools allow you to analyze the performance of your web application in two different situations:
- Without caching, which emulates the first-time visit when assets are still not cached.
- With caching, which emulates the second-time visits. The browser has already cached the app’s assets, eliminating many round-trips to the server.
You can also use the Disable Cache setting to emulate the first-time load of a web page when the DevTools are open on any tab.
This single thread is responsible for running all the work the browser is doing such as layout rendering, calculating styles and collecting garbage.
Also methods such
setTimeout, events such
The Performance tool
With the Performance tool, you can start a performance analysis of your currently opened web page over a period of time that you can control with start and stop recording buttons. The tool then shows you a summary, and tabular and graph views of the operations the browser was doing to render your page.
You can look for and detect long-running pieces of code that block the single thread using the Performance tool.
How to use the Performance tool
The steps to use the performance tool are quite easy:
- open your web page, open the Performance panel, then start recording the performance
- wait a few seconds, also make sure to interact with your page during the profiling, then stop the recording
- look for any long-running functions or events, and focus (zoom in) on the time portions where FPS is low.
- when you find any activities that can be targeted for further optimization, you can use other sub-tools to get detailed information about where to take action.
Make sure to follow some user interaction scenarios and interact with the different parts of your app’s UI during the profiling process, particularly the parts you want to optimize. Also avoid unnecessary extra actions: for example, don’t interact with the parts you’re not trying to analyze, since they’ll just add more noise to your report’s results.
Selecting the Time Range
Firefox’s DevTools support selecting or narrowing the time range over the profile’s time. You can click on the timeline or the FPS chart section, then drag your mouse to select a span of time. Once you stop dragging, DevTools updates the other views and charts to only display information about events that happened during that time span.
The FPS chart
The frame-rate chart displays the frames per second over the period of the recording. When the recording is running, this chart acts like an FPS meter with live values.
The FPS chart shows the max, min values of FPS and the average FPS value over the time of profiling. All these values can quickly tell you if you have any performance bottlenecks.
If you’re running any animations, the FPS should be 60 fps. Watch this video to understand why this value is important:
You can use this chart to quickly spot visual gaps (collapses) and inconsistencies that denote severe drops of the frame rate (meaning the browser is having performance bottlenecks).
You can see from this screenshot an FPS chart with collapses:
The Waterfall chart
Wikipedia explains a waterfall chart as:
a form of data visualization that helps in understanding the cumulative effect of sequentially introduced positive or negative values. The waterfall chart is also known as a flying bricks chart or Mario chart due to the apparent suspension of columns (bricks) in mid-air.
In the case of the Performance tool, the Waterfall chart displays a breakdown of the activities and browser-specific events the browser was performing, such as:
- layout rendering or laying out elements (called also reflows)
- animation frames requests
- repaints or pixels drawing
- garbage collecting etc.
Layout operations or reflows and style calculations are expensive, so these can be potential areas for optimization. See this Google article for more details.
Here’s a screenshot of the waterfall chart of an example application:
The Call Tree view
Self time refers to the time taken solely by the operation without considering the functions it calls.
Total time refers to the time taken by the operation and the functions it calls.
The Call Tree tells you, statistically, in which functions (aggregated) your browser is spending most of the time across a recording.
The JS Flame Chart
A Flame Chart enables most of the hot code-paths to be identified quickly and accurately.
Stacked bars mean that the top operation, which exists directly in the CPU, invoked the bottom operation.
You can read more about Flame charts here.
The Flame Chart shows you the state of the call stack of particular functions at particular times of the recording.
The Flame Chart has tons of data, so to get meaningful readings you need to zoom in until you select a few milliseconds.
You can use colors to distinguish between operations in different views, quickly spot the type of the operation causing issues, and to keep up with the operations’s types when switching between different perspectives.
You can filter out the single activities that you want to see in your charts and views via this menu, where you can also see the different colors associated with the different operations.
For example, if you’re working with CSS animations, what you need to focus on are activities such as Recalculate Style, Apply Style Changes, Layout and Paint. You can filter out the other activities for less noise.
In this article, we’ve seen how to get started with Firefox’s DevTools and how to use different performance-related sub-tools. Firefox’s DevTools are incredibly comprehensive, and with Firefox’s recent performance upgrade, it’s all the more able to accurately identify truly problematic areas of a website’s rendering processes. We encourage you to explore further on your own, now that you’re familiar with the terminology and know what to look for.