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:
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.
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.
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.
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.
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 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.
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.
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.
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:
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.
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:
- 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.
- 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.
- Error.stack. Each Error object has a property named “stack” that contains the stack trace.
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.
To learn more about DOM breakpoints and other new kinds of breakpoints, visit our Breakpoints Tutorial page.
- 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]