# Firefox Profiler: Firefox Performance Analysis for Browser Engineers

> Firefox Profiler is a client-side React and Redux web application for inspecting performance profiles recorded from Gecko and compatible JSON producers. It suits engineers investigating Firefox behavior, but the repository documentation focuses on development setup rather than deployment and operational guidance.

**firefox-devtools/profiler** — Firefox Profiler — Web app for Firefox performance analysis

- Repository: https://github.com/firefox-devtools/profiler
- Website: https://profiler.firefox.com
- Stars: 1,541 · Forks: 496
- Language: TypeScript
- License: MPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/firefox-devtools-profiler

## Firefox Profiler’s Profile Analysis Boundary

Firefox Profiler solves a specific problem: turning recorded browser performance data into an interactive visual analysis. The README says the project was designed to consume profiles from the Gecko Profiler while also supporting data from any profiler that can output JSON. That makes it useful for Firefox engineers, web performance engineers, and developers who already have a profile rather than for people looking for a general application benchmark.

Mozilla develops the tool to help make Firefox fast and to investigate sites and applications. The intended workflow begins with recording a profile and ends with viewing it in the profiler. The repository does not document a built-in recording agent comparable to a complete benchmarking suite. The documentation directs users to the live site for instructions on recording and viewing profiles. A user who needs automatic load tests, application-level measurements, or repeatable experiment orchestration must supply that workflow separately.

The application is format-oriented rather than limited to one browser. Its strongest documented path is a Gecko profile, but the stated JSON compatibility means that a profile from another profiler may work if its structure follows what the application expects. The README does not define a complete schema for those external profiles, so compatibility should be checked against the actual profile data and the developer documentation rather than inferred from the file extension.

## React and Redux Client-Side Profile Inspection

Based on the repository layout, Firefox Profiler is a web application whose source is organized under `src`, with application assets under `res` and developer documentation under `docs-developer`. The README identifies React and Redux as the interface foundation and TypeScript as the language used by the project. The application runs entirely client-side, so profile analysis does not require a server-side analysis service after the application is loaded.

That architecture has practical consequences. A user can open the hosted application at `https://profiler.firefox.com/` and work with profile data in the browser. A local contributor can instead run the development application from a checkout. The repository includes `examples`, tests, configuration files, localization files, build scripts, and a dedicated `profiler-cli` directory. Those files indicate separate concerns for the browser application, command-line packaging, localization, service-worker generation, and developer tooling.

The `package.json` scripts describe several build paths. The development build uses `cross-env NODE_ENV=development node scripts/build.mjs`. Production builds additionally generate the service worker and Photon assets, while separate scripts exist for node tools, profile-query output, and the profiler CLI. This separation is useful for release engineering, but it also means that understanding the complete delivery process requires reading more than the short README. The README does not claim that the hosted application is self-hosted by default or document a reverse proxy, authentication layer, or deployment environment.

## Local Setup With Yarn 1 and Node 24

The shortest documented development path requires Git, Yarn 1 Classic, and a supported Node version. The README specifically identifies Yarn 1 as sufficient and says that version 1.10 is known to work correctly. The repository `package.json` adds a stricter runtime constraint: Node must be `>= 24 < 25`.

Clone the repository, install dependencies, and start the development server with the commands below:

```bash
git clone git@github.com:firefox-devtools/profiler.git
cd profiler
yarn install
yarn start
```

The clone command uses the SSH form shown in the README. The reader should expect the command to place the project in a `profiler` directory, install dependencies using `yarn.lock`, and invoke the project’s start script. The README does not show the script’s output or identify the port it uses, so a specific localhost address cannot be confirmed.

For contributors who want a preconfigured workspace, the README points to GitHub Codespaces and the repository’s `docs-developer/codespaces.md`. That is a separate setup path. The local commands remain the clearest documented way to build and run the application. The project’s `build` script is available for a development build, and `build-prod` performs the production build plus service-worker and Photon steps. The README does not provide deployment instructions for the production bundle.

## Hosted Analysis Versus Local Profile Handling

There are two documented ways to use the project. The hosted application is available at `https://profiler.firefox.com/`, where the site provides instructions for recording and viewing profiles. The repository is also a full development project that contributors can clone and run locally with `yarn start`. These are different approaches to the same analysis interface.

The hosted route does not require a source checkout or a local build. The local route gives contributors access to the source, development scripts, examples, and the ability to modify the application. Because the web app runs entirely client-side, local use does not imply that profile processing is sent to a Mozilla service, but the README does not describe all storage, caching, or privacy behavior of the hosted site. Engineers handling sensitive profiles should review the site’s own documentation before uploading them.

A real alternative is a profiler that emits JSON but does not provide Firefox Profiler’s visual Firefox and Gecko analysis workflow. The difference is not that the other profiler is automatically better. Firefox Profiler accepts compatible JSON data and supplies a React and Redux interface for examining it. A general-purpose profiler may be a better fit when its recording features, platform support, or automation model matter more than interactive profile inspection. A team should compare the profile format first, because JSON alone does not establish semantic compatibility.

## Firefox Profiler Development and Release Signals

The repository is not archived. Its last push was on 2026-10-16, which indicates recent repository activity. The recent release entries are for `profiler-cli`, including `profiler-cli-v0.11.0`, `profiler-cli-v0.10.0`, and `profiler-cli-v0.9.0`. These release dates concern the CLI package, not necessarily every deployment of the web application.

The README points contributors to `CONTRIBUTING.md`, `docs-developer`, and the source directories for additional detail. Many source folders have their own README files, so the top-level README is an entry point rather than a complete architecture guide. The repository also has a `CHANGELOG` entry that is not reproduced in the README. Upgrade notes and migration details therefore cannot be summarized reliably from the available documentation.

The `MPL-2.0` license is the main licensing implication. The README describes it as allowing contributors to share modifications while combining the code with code under other licenses with minimal restrictions. That is a repository statement about the intended licensing model, not legal advice. The README separately acknowledges the zlib compression library, so teams should review the license files and dependency notices rather than assume that every included component uses the same terms.

Upgrade work is visible in the package scripts and separate CLI releases, but the README does not provide a release checklist or state whether older profiles and saved application states remain compatible across releases. An organization adopting the code should therefore review release-specific changes before replacing an existing deployment.

## Operational Limits of the Firefox Profiler Workflow

The clearest limitation is the boundary between data collection and data display. Firefox Profiler visualizes performance data, but the README does not document a universal recorder, benchmark scheduler, or deployment automation for producing comparable profiles. Recording guidance is available on the hosted site, while the repository focuses on the viewer and development environment. Teams that need repeatable measurements must connect their own collection process to the viewer.

Profile compatibility is the second limitation. The README accepts JSON from other profilers, but it does not provide a formal compatibility table or a documented conversion command. A file that is valid JSON can still lack the markers, threads, samples, or relationships required for useful analysis. The application may therefore be able to load a profile without exposing every analysis view that a Gecko profile provides. Check the source and developer documentation for the precise format before adopting the tool for non-Gecko inputs.

Node 24 is another concrete constraint. A contributor using Node 23 or Node 25 does not meet the `package.json` engine range, even if an older development environment happens to start the scripts. Yarn 1 is also required by the documented setup. These are visible development costs, although the README does not quantify build time or runtime memory consumption.

## Conclusion

Adopt Firefox Profiler when your team needs to inspect Gecko profiles or compatible JSON performance data, especially when interactive browser-side analysis and local development control matter. Do not choose it solely as a general-purpose recording or benchmarking platform. Verify the Node 24 requirement, Yarn 1 availability, expected profile format, and whether your workflow needs the hosted site or a local build.

## FAQ

### How do I run Firefox Profiler locally?

Use Yarn 1 Classic and Node 24, then run `git clone`, `cd profiler`, `yarn install`, and `yarn start` as shown in the README. The repository requires Node `>= 24 < 25`.

### Can Firefox Profiler read profiles from other profilers?

The README says it can visualize data from any profiler that can output JSON. It does not document a complete external-profile schema, so JSON compatibility alone does not confirm that every analysis feature will work.

### Does Firefox Profiler run entirely in the browser?

Yes. The README states that the interface is a web application built with React and Redux and that it runs entirely client-side. The hosted version is available at `https://profiler.firefox.com/`.

## Sources

- [firefox-devtools/profiler on GitHub](https://github.com/firefox-devtools/profiler)
- [License: MPL-2.0](https://github.com/firefox-devtools/profiler/blob/main/LICENSE)
- [Project website](https://profiler.firefox.com)
- [README](https://github.com/firefox-devtools/profiler/blob/main/README.md)
- [Releases](https://github.com/firefox-devtools/profiler/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/firefox-devtools-profiler