Whether your web app involves scrolling down a long list of news headlines or a game with flying birds and crumbling structures, you want your web app to look as smooth as native apps. It used to be tricky to chase down the cause of animation jitter and lag in user actions with Chrome Developer Tools. This is why we’ve added the Frame Mode to our Timeline panel to help you pinpoint offending long frames and understand what’s causing them to run slowly.

So, what’s a frame? A frame includes all the tasks that the browser needs to perform in order to update the screen upon a user action or a tick of the animation timer. A complex, but not uncommon, sequence might be:

1. run JavaScript animations and other event handlers 
2. update CSS animations 
3. recalculate styles and lay out the elements in the DOM 
4. re-paint the updated layers of the page 
5. compose them and present to the user 

Delivering a butter-smooth animation means completing all of the above in less than 16.6ms (common 60Hz refresh rate). If you are not done by then, you’ll miss the frame and the animation will appear janky.

To see how using Timeline can help you, run your favorite browser-based game, then open Developer Tools and record the Timeline while the game is running some animation. The Timeline Frame mode will now show you colored bars, each representing a frame. The colors correspond to different types of timeline events:

• network activity and HTML parsing (blue) 
• running JavaScript (yellow) 
• performing style recalculation and layout (violet) 
• painting and compositing (green) 

You can zoom in by selecting several frames or by clicking on a particular frame of interest. Looking at a specific frame in detailed view will show you the frame duration, and you can find more detailed statistics by hovering on it.



Even if your web app doesn’t have animation in it, the notion of a frame is still useful because the browser performs a repeated sequence of actions while processing input events such as keypress, mouse actions, scrolling etc. Leaving enough time to process such events inside a frame makes your app more responsive and interactive, resulting in a better overall experience for users.

In large web applications with huge DOM trees, layout typically takes time and resources. Doing it in a loop makes things much worse. So we’ve added a warning mark on layouts that were forced, by requesting positional properties (e.g. offsetWidth and offsetHeight) of DOM elements from JavaScript. If you hover over the layout event, you can see two stacks -- one that invalidated the DOM and another that caused layout synchronously. You can also see the area that had to be re-laid highlighted on the screen.



Finally, don’t forget that the best practice for dealing with animations is to use the requestAnimationFrame API, which guarantees that Chromium will call back your animation code in sync with the display refresh.

You can learn more about optimizing rendering performance of a page in Tom Wiltzius’ article on html5rocks.com. Follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on Chrome Developer Tools.

Posted by Andrey Kosyakov, Software Engineer

The Chrome Developer Tools team recently launched new features and made several UI changes to improve your development and debugging workflow.

Develop for mobile 

Since we launched Chrome for Android, you’ve been able to use Chrome Developer Tools to debug and profile mobile web pages and web apps.

Today, we take this feature one step further by introducing device emulation support in Chrome Developer Tools. Device emulation includes, among other things, native User Agent and dimension overriding. This allows developers to debug mobile browsers on different devices and operating systems via the Settings Menu. So, now, you can emulate the exact device metrics of devices like the Galaxy Nexus and the iPhone to test your media query-driven design.

Chrome Developer Tools also supports single touch event emulation to make it easier to debug mobile applications on the desktop.

Profile rendering performance 

The Timeline’s Frame Mode feature now allows you to profile Chrome’s rendering performance, remove the jank and deliver the silky smooth performance users expect from your apps. To learn more about this topic, check out the recent "Jank Busters" video from Google I/O.



Preview your log items

The console now prints a user-friendly snapshot of the object properties taken at log time, whereas by expanding the object manually, you can still see its live content. This is especially useful when logging an object in a loop and observing its mutation. With this change, we resolved a longstanding bug many of you prioritized on crbug.com.



Play with experimental features

You can now try new experimental features in Chrome Developer Tools by visiting chrome:flags and enabling them there. Once you do that, a new tab called “Experiments” will be visible in the settings menu, allowing you to enable and use any of the following experiments:

• Snippets (essentially multi-line console on steroids) 
• Source mapping support for SASS 
• Native memory profiling 
• Geolocation / orientation override 
• FileSystem inspection 
• Canvas inspection 
• CPU activity in Timeline 
• CSS Regions support 

Some of these experimental features are almost ready while others have just landed and need some more refining. In either case, we’d love your feedback before we bake these fully in Chrome Developer Tools. You can also read our recently updated contribution guide if you’re interested in helping us make the tools better.

To get more information on all of Chrome Developer Tools features, check out our “Chrome Developer Tools Evolution” talk at the I/O 2012. You can also follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on changes landing in Chrome Developer Tools.

Posted by Stefano Cazzulani, Product Manager

Cross-posted from the Google Developers Blog.

A year ago, we released a preview of the PageSpeed Insights Chrome Developer Tools extension, which analyzes the performance of web pages and provides suggestions to make them faster. Today, we’re releasing version 2.0 of the PageSpeed Insights extension, available in the Chrome Web Store.

PageSpeed Insights analyzes all aspects of a web page load and points out the specific things you can do to make your page faster. For instance, PageSpeed Insights can inform you about an expensive JavaScript call that blocks the renderer for too long, remind you about that new photo on the front page of your web site that you might have forgotten to resize or optimize, or recommend changing the way you load third-party content so it no longer blocks the page load.

PageSpeed Insights for Chrome is a Chrome Developer Tools extension that analyzes all aspects of the page load, including resources, network, DOM, and the timeline. If you're already familiar with Chrome Developer Tools, you'll find that PageSpeed Insights integrates with a toolset you're already using.



Using technologies like Native Client, PageSpeed Insights is able to run the open-source PageSpeed Insights SDK securely and with the performance of native code. Leveraging the Insights SDK enables the Chrome extension to automatically optimize the images, CSS, JavaScript and HTML resources on your web page and provide versions of those resources that you can easily deploy on your website.

We hope you’ll give PageSpeed Insights for Chrome a try and start optimizing your web pages today. We’d love to hear from you, as always. Please try PageSpeed Insights for Chrome, and give us feedback on our mailing list with questions, comments, and new features you’d like to see.


Posted by Libo Song and Bryan McQuade, Software Engineers

Like with other multithreaded applications, debugging Web Workers may be a tricky task and having good instruments makes this process much easier. Chrome Developer Tools provides full debugging support for scripts running in both dedicated and shared workers.

You can now use the powerful Scripts, Timeline, Profiles and Console panels to develop Web Workers:



All dedicated workers running in the inspected page are listed in the Scripts panel, under the Workers section. Clicking on a worker URL will open a new Developer Tools window attached to the worker. If you need to debug a dedicated worker’s initialization, there is also an option to pause workers on start. This will suspend the execution in all starting dedicated workers at the very first statement.



Shared workers are more independent than dedicated ones as they can be used concurrently by several pages. All running shared workers can be discovered through the chrome://inspect page. Each shared worker listed there has inspect and terminate links next to its URL. These links allow you to launch a Developer Tools window attached to that worker or terminate the worker respectively.

When you need to debug a shared worker initialization, it is enough to terminate the current instance of the worker leaving the Developer Tools window open and reload one of the worker clients. The worker will restart and Developer Tools window will automatically re-attach to the new instance.

To learn more on Developer Tools check out our documentation or ask us a question on Google+ and our discussion group.

Posted by Yury Semikhatsky, Software Engineer

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.



The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:

• Use the dev channel of Chrome as the APIs are still under development;
• Enable experimental extension APIs using the chrome://flags page;
• List experimental in the permissions list of your extension;
• Add a devtools_page field to your extension’s manifest, e.g:

{

"name": ...

"minimum_chrome_version": "14.0",

"devtools_page": "devtools.html",

"permissions": [ "experimental" ... ],

...

}

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We’re looking forward to seeing your feedback on the APIs and, of course, cool extensions coming to life!

Posted by Andrey Kosyakov, Software Engineer

Modern web applications are becoming increasingly complex. To achieve functionality previously only available in desktop applications, they often comprise many frameworks glued together. As a result, memory usage by an application can grow unexpectedly. That’s why it is important to keep memory usage under control from the moment you start building it. In this post, we will cover four tools in Google Chrome that can help you understand how your application makes use of JavaScript memory.
The simplest one is the built-in Task Manager. It is available under > Tools > Task Manager. The “JavaScript memory” column isn't visible by default, but you can turn it on via the context menu [1]:


The numbers are updated in the real time.

If you’d like to visualise memory usage over time, try the Memory Graph of Chrome Developer Tools’ Timeline panel. To start using it, open Developer Tools, switch to the Timeline panel, and click on the “Memory” item. After you start capturing Timeline events, the graph starts updating itself:

The most functional tool in controlling JavaScript memory usage and finding leaks is the new powerful Heap Profiler available in Chrome Dev Channel. To get a heap snapshot, open the Profiles panel in Developer Tools and press the “Take heap snapshot” button:

Snapshots contain every object from the JavaScript heap, so you can explore them in detail and find out how much memory every object of your application consumes. The heap profiler also offers the following features:

• snapshots diffing
• grouping objects by constructor
• calculating retained sizes of objects
• showing dominators tree
• revealing paths to GC roots or window objects

In addition, the heap profiler takes into account native DOM nodes, and allows you to uncover DOM-related memory leaks.

It is also possible to measure how much JavaScript memory is currently used from within the page itself. You can sample values from the performance.memory window property at different points of your application lifetime. Please note, that the property does not report anything, unless you run Chrome with --enable-memory-info command-line argument.

For a more complete reference on working with the Chrome Developer Tools heap profiler, check out the tutorial.

---

[1]: How to invoke the context menu in the Chrome Task Manager:

• Windows: Right click on any part of the grid;
• Linux: Right click on the grid itself;
• Mac: Ctrl+Right click on column headers

Posted by Mikhail Naganov, Software Engineer

Google Chrome Developer Tools (or DevTools) front-end is implemented as an HTML + CSS + JavaScript web application. It uses a serialized message channel in order to communicate with the inspected page. Originally, we were working on establishing this serialized asynchronous interaction in order to bring DevTools front-end out of the inspected page process. But once it was done, we could take it even further and run DevTools front-end outside the browser. Here is how you can give it a try:

• Run the Chrome instance that you will be debugging remotely with the remote debugging command line switch: chrome.exe --remote-debugging-port=9222 --user-data-dir=remote-profile. It is essential that you use a different instance of Chrome for the remote session and that is why we run it with the --user-data-dir argument.
• Navigate to the pages you intend to debug.
• Now run a regular (client) Chrome instance and navigate to http://localhost:9222 there.

You will see a number of links that will bring you to the remote debugging sessions for the corresponding pages. Click them and enjoy debugging your Chrome pages over the wire:

We implemented the remote debugging infrastructure in the WebKit repository (or as we say “upstream”), so that other WebKit port owners could expose remote debugging capabilities with a minimal effort. See more information on remote debugging in our WebKit blog post. For more information on the remote debugging and Chrome Developer Tools in general, see our documentation page.

Posted by Pavel Feldman, Software Engineer

One of the biggest challenges in JavaScript development is dealing with script errors. We’ve been working hard to improve and extend the set of tools that lets you better understand how your JavaScript code works. Let’s have a quick look at five features of Google Chrome Developer Tools that can help you work with exceptions and stack traces more efficiently:

• Exception call stack. When something goes wrong, you can open the developer tools console. There you’ll find a number of uncaught JavaScript exception messages there. Each message has a link to the file name with the line number you can navigate to. However, there might be several execution paths that lead to the error and it’s not always obvious which one of them has happened. Exceptions in the console are now accompanied with the complete JavaScript call stacks after the developer tools window has been opened.
• Pause on exception. The developer tools’ Scripts panel enables you to pause JavaScript execution each time an exception is thrown and inspect its call stack, scope variables and state of your app. You can choose whether to pause only on uncaught exceptions or on all exceptions.
• Logging stack traces. Printing log messages to the developer tools console is also very helpful in understanding how your application behaves. Now you can make the log entries even more informative by including associated stack traces. You can instrument your code with console.trace() calls that would print current JavaScript call stack. Moreover, you can check that some invariants are true using console.assert() which prints a full stack trace when its conditional expression passed as first parameter evaluate to false.



• Error.stack. Each Error object has a property named “stack” that contains the stack trace.
• Handler function for window.onerror. Recently we’ve added support for setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception’s message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server.

For a more complete reference on working with the Google Chrome Developer Tools, check out our home page. We further described improvements to exception handling and stack traces in our recent WebKit blog post.

Posted by Yury Semikhatsky, Software Engineer

It’s been an exciting past few months in the Google Chrome Developer Tools world as we keep adding new features, while polishing up existing ones to respond to your feedback.

One of the areas we have focused a lot of our energy is on network instrumentation. Recently we’ve made many improvements that will hopefully improve your experience when using Chrome Developer Tools. These improvements include:

• Network aspects of your web page are now inspected in the Network panel. This gives you access to even more information at a single glance. You can sort and clear data, preserve log information upon navigation and even export network data into HAR format.
• All the timing information about your resource loads now comes from the network stack, not WebKit, so timing information now adequately represents raw network timing. You can see detailed timing for different phases of the loading by hovering over the log entry.

• We now push raw HTTP headers and status messages into Chrome Developer Tools. As a result, you now see precisely what the browser received from the server and not just how the rendering engine interpreted that information.
• Similarly to the old Resources panel, you can see syntax-highlighted resource contents.

We’ve also made CSS editing a whole lot easier. In particular, you’ll now find separate fields for property names and values instead of a single field for both. As you type, you will see suggestions of available keywords for property values.


But that’s only the tip of the iceberg. Similar to the changes in the network panel, the CSS sidebar now shows the raw information that the browser gets from the server - not the rendering engine’s interpretation of the information. As a result, you can use Chrome Developer Tools to see CSS properties that are not recognized by WebKit (e.g., engine-specific or simply erroneous properties). This finally puts an end to the nightmare of disappearing invalid properties.


For a more complete reference on working with the Chrome Developer Tools, check out our new home page. The CSS improvements that we implemented upstream in WebKit are further described in our WebKit blog post. And for even more tips on how to use Chrome Developer Tools, watch the new video below.



Posted by Pavel Feldman and Alexander Pavlov, Software Engineers

Chrome Developer Tools' Scripts panel provides a graphical JavaScript debugger and allows you to set breakpoints in the JavaScript source code. However, setting breakpoints in the source code does not always work well, especially when the application is large and you are not familiar with the entire code base. To better support this use case, we are introducing a new set of breakpoints that allow you to break on UI and network events.

Suppose you need to find the piece of code that modifies a specific node in a document. Right-click on that node in the Elements panel and select the appropriate “Break on...” context menu option and you are all set. The debugger will pause JavaScript execution right before the node gets modified next time.



To learn more about DOM breakpoints and other new kinds of breakpoints, visit our Breakpoints Tutorial page.

Posted by Pavel Podivilov, Software Engineer

At Google I/O 2010 we presented on Google Chrome’s Developer Tools and enjoyed getting the in-person feedback from developers. We wanted to list some of the new and improved features we presented at I/O that set apart our tools in helping developers become more productive.

• The Scripts panel now allows editing JavaScript without having to reload the page. Just double-click on the line in the function body while debugging and make your changes. We’ll patch the underlying optimized machine code at run-time and continue the execution. [video]
• CPU profiler captures the state of your app at a rate of 1,000 samples per second without modifications to the running optimized machine code. The resulting tree view makes it easy to find out where to focus efforts on speeding up the web app. [video]
• The new Timeline panel provides a simple view of the AJAX application execution. It records everything that happens in the browser from JavaScript execution to styles re-calculations and then visualizes it in a simple waterfall with timing information and traces to the source code. See the demo fragment at [video].
• The improved Heap profiler can take snapshots of the JavaScript heap, visualize and compare them. This makes finding and fighting memory leaks a much easier task. See the demo fragment at [video].

We also covered a number of general Inspector improvements in the WebKit blog recently. Watch them live in the DevTools panel walk through from the I/O video.

We welcome feedback: to submit a bug or feature request please use the Chromium issue tracker and mention DevTools in the summary.

We hope you like the new improved Google Chrome Developer Tools. Note that some of the features above are only available on Google Chrome’s Dev Channel at this moment. For more info please check out the DevTools site.

Posted by Pavel Feldman, Software Engineer