Chromium Blog

A 2x Faster Web

Wednesday, November 11, 2009

Today we'd like to share with the web community information about SPDY, pronounced "SPeeDY", an early-stage research project that is part of our effort to make the web faster. SPDY is at its core an application-layer protocol for transporting content over the web. It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.
We started working on SPDY while exploring ways to optimize the way browsers and servers communicate. Today, web clients and servers speak HTTP. HTTP is an elegantly simple protocol that emerged as a web standard in 1996 after a series of experiments. HTTP has served the web incredibly well. We want to continue building on the web's tradition of experimentation and optimization, to further support the evolution of websites and browsers. So over the last few months, a few of us here at Google have been experimenting with new ways for web browsers and servers to speak to each other, resulting in a prototype web server and Google Chrome client with SPDY support.
So far we have only tested SPDY in lab conditions. The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance - pages loaded up to 55% faster. There is still a lot of work we need to do to evaluate the performance of SPDY in real-world conditions. However, we believe that we have reached the stage where our small team could benefit from the active participation, feedback and assistance of the web community.
For those of you who would like to learn more and hopefully contribute to our experiment, we invite you to review our early stage documentation, look at our current code and provide feedback through the Chromium Google Group.
Posted by Mike Belshe, Software Engineer and Roberto Peon, Software Engineer This post is cross-posted at the Google Research Blog

Introducing Google Chrome Frame

Tuesday, September 22, 2009

Today, we're releasing an early version of Google Chrome Frame, an open source plug-in that brings HTML5 and other open web technologies to Internet Explorer.
We're building Google Chrome Frame to help web developers deliver faster, richer applications like Google Wave. Recent JavaScript performance improvements and the emergence of HTML5 have enabled web applications to do things that could previously only be done by desktop software. One challenge developers face in using these new technologies is that they are not yet supported by Internet Explorer. Developers can't afford to ignore IE — most people use some version of IE — so they end up spending lots of time implementing work-arounds or limiting the functionality of their apps.
With Google Chrome Frame, developers can now take advantage of the latest open web technologies, even in Internet Explorer. From a faster Javascript engine, to support for current web technologies like HTML5's offline capabilities and <canvas>, to modern CSS/Layout handling, Google Chrome Frame enables these features within IE with no additional coding or testing for different browser versions.
To start using Google Chrome Frame, all developers need to do is to add a single tag:
<meta http-equiv="X-UA-Compatible" content="chrome=1">
When Google Chrome Frame detects this tag it switches automatically to using Google Chrome's speedy WebKit-based rendering engine. It's that easy. For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using.
We believe that Google Chrome Frame makes life easier for web developers as well as users. While this is still an early version intended for developers, our team invites you to try out this for your site. You can start by reading our documentation. Please share your feedback in our discussion group and file any bugs you find through the Chromium issue tracker.

Posted by Amit Joshi, Software Engineer, Alex Russell, Software Engineer and Mike Smith, Product Manager

Extensions Status: On the Runway, Getting Ready for Take-Off

Wednesday, September 9, 2009

dev channelsample extensionsour launch processbe cautiousa few APIsdocumentationthis post about some recent changesPosted by Aaron Boodman, Software Engineer

A New FTP Implementation Goes Live

Thursday, September 3, 2009

Starting in the Dev channel release 4.0.203.2, we are using our new FTP implementation by default on Windows. (It was already enabled by default on Linux and Mac.) This switchover is an important milestone in the development of our network stack. We'd like to acknowledge two Chromium contributors who made this possible.
The new FTP implementation was initially written by Ibrar Ahmed single–handedly. It was a long journey for him because he worked on it in his spare time. Ibrar has a master's degree in computer science from International Islamic University. After working as software engineer and associate architect at other companies, he recently started his own tele-medicine company. We thank Ibrar for his contribution to the Chromium network stack!
Paweł Hajdan Jr. started to work on the new FTP code in July as one of his summer intern projects at Google. Paweł added new unit tests, fixed bugs and compatibility issues, and is taking the lead in bringing the new FTP code to production quality.
Finally, we used Mozilla code for parsing and formatting FTP directory listings (ParseFTPList.cpp), which was originally written by Cyrus Patel.
In the near term, the original WinInet-based FTP implementation will still be available as an option on Windows. Specify the --wininet-ftp command-line option to enable it. (The original --new-ftp option is now obsolete and ignored.) During this period we will fix FTP bugs only in the new FTP implementation. When we're happy with the quality of the new FTP code, we will remove the original WinInet-based implementation, finally eliminating our dependency on WinInet.
Please help us achieve that goal by testing FTP with a Dev channel release and filing bug reports. Follow these guidelines when reporting bugs:

Please don't add a comment like "Here is another URL that doesn't work for me" to a bug. Always open a new bug, and give a link to another bug if you think they are similar.
Make the steps to reproduce as detailed as possible, and always include the version number of Chrome.
Check if the problem can be reproduced with --wininet-ftp on Windows and include that information in the bug report.

Posted by Wan-Teh Chang, Software Engineer

Bookmarks Here, Bookmarks There, Bookmarks Everywhere

Monday, August 17, 2009

As of today's dev channel build, we're adding a brand new feature to Google Chrome: bookmark sync. Many users have several machines, one at home and one at work for example. This new feature makes it easy to keep the same set of bookmarks on all your machines, and stores them alongside your Google Docs for easy web access.
To activate this feature, launch Google Chrome with the --enable-sync command-line flag. Once you set up sync from the Tools menu, Chrome will then upload and store your bookmarks in your Google Account. Anytime you add or change a bookmark, your changes will be sent to the cloud and immediately broadcast to all other computers for which you've activated bookmark sync (using the same XMPP technology as Google Talk).
For more information on this, please see this email to chromium-dev.
Happy syncing!
Posted by Tim Steele, Software Engineer

Chromium Memory Usage

Thursday, August 6, 2009

There's been some public discussion lately about memory usage in Google Chrome. We think about our memory usage quite a bit so we're happy to see other people paying attention too. This has been a topic of discussion before, but our multiprocess architecture makes measuring memory utilization difficult with the standard set of tools. The crux of the problem is that Chromium goes to great lengths to share memory between processes. However, that shared memory is difficult to account for in the Windows Task Manager. On Windows XP, using the default Task Manager measurement of memory leads to double counting. On Vista, using the default view leads to under counting.
There are a couple of more accurate ways to measure memory utilization in Chromium (or Google Chrome). The easiest is to crack open the task manager that is built into Chromium which tries to account for our memory usage more holistically. If you want even more detail, you can click on "Stats for nerds" which is a link to about:memory.

If you don't fully trust Chromium's task manager or about:memory, the gold standard for measuring memory usage is to look at the system's total commit charge before, during, and after using Chromium. It's a little tricky to get right because you'll need to shut down other services that may kick in while you are running your test. Here's the basic procedure:

Shut down any unnecessary services
Reboot your computer
Using the windows task manager, measure the Total Commit Charge of the system*
Run the application you are seeking to test, in this case, Chromium
Measure the Total Commit Charge again
Close the application
Measure the Total Commit Charge one more time
Subtract your first measurement from your second, and you should have the memory used by Chromium
To validate your test, make sure that the first and last measurement are nearly identical

*On XP, Commit Charge shows up on the bottom of the Windows Task Manager. On Vista, look at the Performance tab of the Windows Task Manager and use the "Memory" number.
For more information on memory usage and how to measure it, check out the Memory Usage Backgrounder on chromium.org.
Posted by Brian Rakowski, Product Manager

Google Chrome Developer Tools for Eclipse Users

Tuesday, August 4, 2009

We recently announced the availability of developer tools for Google Chrome. We are now releasing ChromeDevTools, which enables JavaScript debugging using Eclipse.
You can set breakpoints, inspect variables and evaluate expressions all from within Eclipse. The screenshot shows the debugger in action stopped at a breakpoint.

The project is fully open sourced on a BSD-license and consists of two components, an SDK and a debugger. The SDK provides a Java API that enables communication with Google Chrome over TCP/IP. The debugger is an Eclipse plugin that uses the SDK and enables you to debug JavaScript running in Google Chrome from the Eclipse IDE.
We hope this project will help web app developers and welcome feedback as well as contributions.
Posted by Alexander Pavlov, Software Engineer