Nothing Special   »   [go: up one dir, main page]

Since we first introduced Google Chrome's developer tools, we've been busy adding more functionality to them.

First, our tools benefited from improvements that the WebKit team made to Web Inspector (our developer tools are partially based on Web Inspector). Second, from our end, we recently released the heap profiler and the timeline tab in Google Chrome's Developer Channel.

With the heap profiler you can now take a snapshot of the JavaScript heap at any point in time. A heap snapshot helps you understand memory usage, and by comparing snapshots you can also follow memory usage over time. You will find the heap profiler in the profiles tab along with the sample-based CPU profiler.

The new timeline view gives you a complete overview of where time is spent when loading a web app. All events -- ranging from loading resources over parsing and executing JavaScript to calculating styles and repainting -- are plotted on a timeline.

Besides these product improvements, we've tried to make the Google Chrome Developer tools easier to find and understand by putting together a mini site with tutorials and videos.



To take our newest release for a spin, get Google Chrome from the Developer Channel and you'll automatically be brought up to date. We welcome your feedback and your contributions to improve developer tools in WebKit and Google Chrome even more.


During the last few months, our team has been working hard to support extensions in Google Chrome's beta channel. Today, we are getting one step closer to this goal; developers can now upload their extensions to Google Chrome's extension gallery. We are making the upload flow available early to make sure that developers have the time to publish their extensions ahead of our full launch.

You can find all the info to write an extension in our docs. Once your extension is ready for the gallery, you'll need to upload a zip file of your code and an icon that helps users distinguish your extension. You'll also have the option to submit text, screenshots and/or YouTube videos that describe the functionality of your extension. All types of extensions are welcome in the gallery, provided they comply with our Terms of Service.

For most extensions, the review process is fully automated. The only extensions we'll review manually are those that include an NPAPI component and all content scripts that affect "file://" URLs. For security reasons, developers of these types of extensions will need to provide some additional information before they can post them in the gallery.

Once an extension is uploaded, our gallery takes care of packaging and signing. Updating an extension is also incredibly easy — all a developer needs to do is to upload a new file in the gallery. Finally, to further help developers, in the next few days, we plan to open up the gallery to a small group of trusted testers. They will provide developers with insights and bug reports that will help them polish their extensions ahead of our beta launch.

We can't wait to share all the great extensions that you'll submit with all of Google Chrome's users. In the meantime, we encourage you to submit any bugs you find in the upload process to our Issue Tracker and to ask all relevant questions in our discussion group.

Today we announced the Chromium OS project on the Official Google Blog. This release of Chromium OS includes:
We are doing this early, almost a year before Google Chrome OS will be ready for users, because we are eager to engage with open source developers. There are many of you who share our passion for creating a new model of computing. Chromium OS makes it possible for any interested developer to contribute code, ideas and designs to help shape the future of personal computing.

Speed, simplicity and security are fundamental to Chrome OS. We wanted to talk about these areas in a bit more detail.

Speed


Simplicity


Security


Open Source


We expect to publish additional design docs and documentation in the upcoming few months. You can track what we're doing on this blog and we hope you will join us in this effort.

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.


This post is cross-posted at the Google Research Blog