[go: up one dir, main page]

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
Labels:

Since we announced WebP, a new image format based on WebM technology and the VP8 codec, we’ve been working hard with the open web community to improve and enhance it. Today we are happy to share news about a few new features and expanded support for WebP.

New Features

WebP's compression algorithms have been significantly improved while remaining completely
compatible with the previous releases. We hope the quality of a few sample images in the new gallery will delight you.

On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a WebP image with red edges converted from this PNG original:

Original image in PNG format
Without fancy upsampling: strong stair-like pattern
With fancy upsampling: smoother edge

We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.

On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:

The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original details of the image [2]. This is in contrast to the frequent ringing artifacts one can clearly see in JPEG images.

The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the -sns parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS, PSNR may be degraded, but the overall visual quality is much improved.

We’ve added simple encoding and decoding example binaries to the libwebp library. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it now and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.

Increased adoption

WebP is now natively supported in Chrome and Opera. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition, Google Instant Previews now store images in WebP to reduce their storage needs.

Users that want to manipulate WebP images can now do so using software developed by the community including Pixelmator, ImageMagick, the WebP format plugin for Photoshop and the Java VP8 decoder. The open-source community has also contributed support for Mac OS X with MacPorts packages, Linux Debian, OpenSUSE and Gentoo packages and the Apache HTTP Server. On Windows, users who want to view WebP images natively, can download the WebP codec. This codec brings WebP support to such software as Microsoft Office 2010, Windows Media Center and Photo Edit.

The new features, quality improvements and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the mailing list how your experiments are panning out and what new features you’d like to see in the future.

Image credits:
[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author. PNG source, and Blog post by author with comparison of JPEG and WebP.

[2]: A storm at Pors-Loubous, Plogoff, Finistère, France. Image Author: Henri Camus. Permission: CC-BY; CC-BY-1.0. Source: http://commons.wikimedia.org/wiki/File:A_storm_at_Pors-Loubous.jpg

Posted by Richard Rabbat, Product Manager and Pascal Massimino, Software Engineer
Labels:

Cross posted at the Google Code blog

We recently unveiled ChromeVox — a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.

ChromeVox is built as a Chrome extension — this means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize W3C ARIA (Access to Rich Internet Applications) to provide a rich, desktop-like experience.

ChromeVox leverages two of Chrome's experimental extension APIs, the experimental.tts API for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a simple screen reader API to web developers who wish to further customize the ChromeVox user experience. Thus, within your application, you can:
  • Automatically generate spoken messages and earcons.
  • Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive online tutorial that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our Google I/O 2011 talk for more.

Details on enabling accessibility in Chrome OS can be found on the Accessibility help page, and the Chrome extension is available for download from our Wiki page. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at http://google-axs-chrome.googlecode.com.

Posted by T.V. Raman, Research Scientist
Labels: ,

Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed SSL False Start, a client-side only change to reduce one round-trip from the SSL handshake.

We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%1. That is a big number. And reducing the cost of a SSL handshake is critical as more and more content providers move to SSL.

Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.

To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.

To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.

All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.


1Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.

Posted by Mike Belshe, Software Engineer
Labels: , ,

Since we launched the Chrome Web Store, we’ve been working on several new improvements. Today, we’re happy to share our progress towards making the Chrome Web Store available to all Chrome users worldwide and the availability of Google In-App Payments for web app developers.

First, as we announced at Google I/O, the In-App Payments API is now available for app developers. We demo-ed the way Graphicly uses this API and Angry Birds announced that they will use it to offer users the Mighty Eagle for in-app purchase on the web. Integrating the API into your app is as simple as adding a single line of code and provides a frictionless user experience for making purchases within the app. We hope to gather feedback on the API before making it fully available this summer.

Second, the Chrome Web Store is now available in 41 languages. This is our second step towards launching Chrome Web Store in 15 additional countries. Developers interested in targeting international users can now go to the Chrome Web Store and publish free apps in these countries in preparation for launch. We will also support publishing paid apps in selected countries later this year.

Localizing your apps will expose them to many more users and allow them to be featured in the local Chrome Web Store homepages. We hope this expanded functionality will allow you to create brand new international apps or to localize your existing apps.

If you have additional questions, please take a look at our FAQ or join our developer discussion group.

Posted by Alexandra Levich, Product Manager
Labels:

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
Labels:

Benchmarks are incredibly important for influencing the direction of JavaScript engines. Over the past two years, JavaScript has gotten dramatically faster across all major browsers, particularly in areas that popular benchmarks measure. As it turns out, browser developers are a competitive bunch. However, as JS engines get faster, benchmarks must evolve in order to keep pushing them in the right direction.

We’ve been constantly updating our V8 benchmark suite to force us to get faster in areas that are important to web developers. We’ve fixed bugs and added new tests for regular expressions and memory management. We’re very focused on JavaScript performance, so we scrutinize our benchmark carefully to make sure that it’s as useful a measuring stick as possible.

The two other widely cited JS benchmarks are SunSpider from Apple, and Kraken, a new benchmark from Mozilla.

SunSpider was one of the first suites of tests, first appearing in 2007. It’s done a lot to help improve JS engines, but many of the tests in the suite are less relevant to the web in 2011. Even for the more relevant tests, JavaScript has gotten so fast that many finish in only a few milliseconds. This just isn’t long enough to figure out which engine is faster--a golf cart and a Tesla will finish a 10-foot race in nearly the same time.

To make the benchmark more meaningful, we’ve experimented by making the race longer by running each of the tests in SunSpider 50 times consecutively. While repeating a trivial test many times isn’t a great solution, it does provide an opportunity for some optimization. With this change, the results begin to reflect Chrome’s true performance. It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests.

Kraken, a more modern benchmark, is in better shape. Unfortunately, the canonical version of the benchmark has not been updated to reflect all the latest changes which address at least one important bug. As a result, the benchmark is less useful and has even (mis)led us to spend time making some irrelevant optimizations in Chrome. To help us focus on the right things, we’re now testing the latest version of Kraken built directly from Mozilla’s source code repository.

We’re posting a modified version of SunSpider and the latest version of Kraken to make it easy to run the benchmarks in your own browser and compare results.

Posted by Mike Belshe, Software Engineer
Labels: ,

We’re pleased to announce that Google Chrome Canary for Mac is now available.

When we released Google Chrome Canary for Windows last year to help get more feedback on crashes from the bravest Chrome users, we weren’t sure how many people would tolerate using a completely untested build of Chrome. Since then, hundreds of thousands of Windows users have contributed to Chrome’s development by using the Canary and sending us valuable feedback. Thanks!

The Mac version of Google Chrome Canary follows the same philosophy: it automatically updates more frequently than the Dev channel, and does not undergo any manual testing before each release. Because we expect it to be unstable and, at times, unusable, you can run it concurrently with a Dev, Beta, or Stable version of Google Chrome. Your Canary data remains separate, but if you set up Sync in each version of Chrome that you use, you can automatically continue using the same set of bookmarks, extensions, themes, and more.

If you’re a Mac user and want to help us test the bleeding edge, or if you just want to see our icon in shades of yellow, take it for a spin!

Posted by Mark Mentovai, Software Engineer