10 Years of Chrome DevTools
* { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; }
In the beginning, there was Firebug
- Sprinkle window.alert() calls throughout your code.
- Comment out sections of code.
- Stare at the code for a long time until the JavaScript gods bless you with a solution.
Firebug was a Firefox extension that let you debug, edit, and monitor pages in real-time. As a web developer suddenly you went from having no visibility into your pages to having what are essentially the core features of modern developer tools. The ability to understand exactly why Firefox was behaving as it was unleashed a flood of creativity on the web. Without Firebug, the Web 2.0 era wouldn’t have been possible.
WebKit Web Inspector
Around the same time as Firebug’s launch, a few Google engineers started working on a project which would eventually lead to Chrome. From the start, Chrome was a mashup of different code libraries. For rendering the Chrome engineers opted for WebKit, which is the open-source project that still powers Safari to this day. An added bonus of using WebKit was that it came with a handy tool called the Web Inspector.
The “Inspect Element” era
Chrome brought many innovative ideas to the browser ecosystem, such as the omnibox that combined search and the address bar, and a multi-process architecture that prevented one hanging tab from crashing the entire browser. But the innovation we like the most was providing developer tools in every build to every user, exposed with the click of a mouse.
Before Chrome, developer tooling was an opt-in experience. You either had to install an extension, like Firebug, or enable some flags, as is still the case in Safari today. Chrome was the first browser to make developer tooling accessible from every browser instance. We’d like to claim that we had a grand vision for creating a developer-friendly browser from the start, but the reality is that Chrome had a lot of compatibility issues in its early days (which makes sense, since no one was building for it) and we needed to give web developers an easy way to fix these issues. Web developers told us that it was a useful feature, and we kept it.
The mobile era
- Precisely emulating the mobile viewport, simulating touch-based input and device orientation.
- Throttling the network connection to simulate 3G and CPU to simulate less-powerful mobile hardware.
- Spoofing user agent, geolocation, accelerometer data and more.
An early prototype of Device Mode
The performance era
These tools were a step in the right direction, but in order to spot optimization opportunities you needed to learn the nitty-gritty details about how browsers work and sift through a lot of data. Lately we’ve been building on this foundation to provide more guided performance insights. The new Lighthouse engine powers the Audits panel, and is also available as a Node module for integration with CI systems.
The Node.js era
Up until 2014 or so, we mainly thought of DevTools as a tool for building great experiences on Chrome. The rise of Node prompted us to rethink our role in the web ecosystem.
For the first few years of Node’s existence, Node developers were in a situation similar to that of web developers before Firebug, or Gmail developers before the Timeline panel: the scale of Node apps outpaced the scale of Node tools. Given that Node runs on Chrome’s JavaScript engine, V8, DevTools was a natural candidate to fill the gap. Support for debugging Node with DevTools landed in 2016 and includes the usual DevTools features, such as breakpoints, code stepping, blackboxing, source maps for transpiled code, and so on.
The DevTools protocol ecosystem
The name Chrome DevTools Protocol (CDP) suggests an API that only DevTools can use. The reality is more general than that: it’s the API that enables programmatic access to Chrome. Over the last few years, we’ve seen a few third-party libraries and applications join the protocol ecosystem:
- chrome-remote-interface provides low level JavaScript access to the protocol
- Puppeteer brings it to the next level of abstraction and enables automation of the evergreen headless Chrome browser with modern JavaScript API
- Lighthouse automates the process of finding ways to improve the performance and quality of pages
What’s next?
- Stay up-to-date on new features with our What’s New posts
- Propose new features on the mailing list
- File bugs in Chromium Bug Tracker
- Follow us on Twitter to discover new features and bite-sized workflows
- Ask questions on Stack Overflow to get help with using DevTools
- Take matters into your own hands and contribute to DevTools