Chromium Blog
News and developments from the open source browser project
Build smoother web apps with Chrome Developer Tools
Friday, November 16, 2012
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:
run JavaScript animations and other event handlers
update CSS animations
recalculate styles and lay out the elements in the DOM
re-paint the updated layers of the page
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 interactiv
e, 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
Do more with Chrome Developer Tools
Tuesday, October 23, 2012
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
Make your website faster with PageSpeed Insights
Tuesday, June 12, 2012
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
Debugging Web Workers with Chrome Developer Tools
Monday, April 30, 2012
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
New developer tools experimental APIs for Chrome extensions
Monday, October 3, 2011
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
Chrome Developer Tools: Put JavaScript memory under control
Friday, May 27, 2011
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
Remote debugging with Chrome Developer Tools
Monday, May 9, 2011
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
Chrome Developer Tools: Understanding Stack Traces
Wednesday, April 20, 2011
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
Chrome Developer Tools: Back to Basics
Thursday, February 24, 2011
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
Break on UI and network events in Chrome Developer Tools
Monday, December 13, 2010
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
Google Chrome’s Developer Tools Improve Productivity
Friday, June 4, 2010
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
Labels
accessibility
1
benchmarks
1
beta
1
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2016
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
