As part of Google’s initiative to make the web faster, over the past few months we have released a number of tools to help site owners speed up their websites. We launched the Page Speed Firefox extension to evaluate the performance of web pages and to get suggestions on how to improve them, we introduced the Speed Tracer Chrome extension to help identify and fix performance problems in web applications, and we released a set of closure tools to help build rich web applications with fully optimized JavaScript code. While these tools have been incredibly successful in helping developers optimize their sites, as we’ve evaluated our progress, we continue to notice a single component of web pages is consistently responsible for the majority of the latency on pages across the web: images.

Most of the common image formats on the web today were established over a decade ago and are based on technology from around that time. Some engineers at Google decided to figure out if there was a way to further compress lossy images like JPEG to make them load faster, while still preserving quality and resolution. As part of this effort, we are releasing a developer preview of a new image format, WebP, that promises to significantly reduce the byte size of photos on the web, allowing web sites to load faster than before.

Images and photos make up about 65% of the bytes transmitted per web page today. They can significantly slow down a user’s web experience, especially on bandwidth-constrained networks such as a mobile network. Images on the web consist primarily of lossy formats such as JPEG, and to a lesser extent lossless formats such as PNG and GIF. Our team focused on improving compression of the lossy images, which constitute the larger percentage of images on the web today.

To improve on the compression that JPEG provides, we used an image compressor based on the VP8 codec that Google open-sourced in May 2010. We applied the techniques from VP8 video intra frame coding to push the envelope in still image coding. We also adapted a very lightweight container based on RIFF. While this container format contributes a minimal overhead of only 20 bytes per image, it is extensible to allow authors to save meta-data they would like to store.

While the benefits of a VP8 based image format were clear in theory, we needed to test them in the real world. In order to gauge the effectiveness of our efforts, we randomly picked about 1,000,000 images from the web (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without perceptibly compromising visual quality. This resulted in an average 39% reduction in file size. We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image.

To help you assess WebP’s performance with other formats, we have shared a selection of open-source and classic images along with file sizes so you can visually compare them on this site. We are also releasing a conversion tool that you can use to convert images to the WebP format. We’re looking forward to working with the browser and web developer community on the WebP spec and on adding native support for WebP. While WebP images can’t be viewed until browsers support the format, we are developing a patch for WebKit to provide native support for WebP in an upcoming release of Google Chrome. We plan to add support for a transparency layer, also known as alpha channel in a future update.

We’re excited to hear feedback from the developer community on our discussion group, so download the conversion tool, try it out on your favorite set of images, and let us know what you think.

Posted by Richard Rabbat, Product Manager

We’re excited to see developer interest in the upcoming Chrome Web Store, particularly around installable web apps. Many of you have also asked about how extensions and apps differ, and how apps can leverage extension behavior.

To answer these questions and more, we’ve published a new article to help you decide between building extensions and building apps. In the article, you’ll read about how apps and extensions vary from the user’s perspective and how they compare in their internal architecture and capabilities. We’ve also included a deep dive on the concept of packaged apps as a blend of app and extension behaviour.

We hope this article helps clarify the distinction between pure extensions, packaged apps, and hosted apps so that you can choose the approach that makes the most sense for your work and your users. To learn more about installable webs apps and ask questions to our team, check out our discussion group. We look forward to getting your feedback!

Posted by Michael Mahemoff, Developer Advocate

We’re excited to share with you some new features that we just added to the developer preview of the Chrome Web Store:

Starting today, you can sign up for a Google Checkout merchant account via your developer dashboard. If you’re planning to use Chrome Web Store Payments to charge for apps, you’ll need to complete this setup before you can accept payments. If you already have a merchant account with Google Checkout, you’ll be able to associate it with your items in the store. Signing up for Chrome Web Store Payments is currently available to developers based in the US who have a US bank account. We’re working hard to also enable payments for international developers and will update you with a blog post once we have more details. If you have more questions about setting up your merchant account, see this help article we created.

We also added the ability to see how your app will appear in the store. When you preview an uploaded app, you’ll see our new design of the app’s landing page. As before, your apps are only visible to you during the developer preview until the store launches later this year.

We added several options to help you customize this page with your own header image and a larger icon. You can also upload promotional images for your app now, which will appear as banners whenever your app is featured in the store. To learn more about these new options, we encourage you to read our guidelines about creating good images and icons for apps in the store.



We’ll continue to work on the web store design and add polish, but with today’s launch you can get your app’s landing page ready for the launch. For questions and feedback, we invite you to join our developer discussion group and come back to the Chromium blog for more announcements about the Chrome Web Store.

Posted by Qinming Fang, Software Engineer

Today, we’re very happy to take the Beta tag off of Google Chrome Frame and promote it to the Stable channel. This stable channel release provides our most polished version of Google Chrome Frame to date, allowing users to access modern web technologies like HTML5 on legacy browsers. You now can download the stable version of Google Chrome Frame and users of the Beta will be automatically updated to it in the days ahead. If you’re an IT administrator, we’ve also posted an MSI installer for deploying Google Chrome Frame in your network.

When Google Chrome Frame went into beta in June, the team set aggressive goals for speed and stability before delivering a stable channel release. We wanted it to start much faster and to reduce crashes by an order of magnitude. After months of polishing, Google Chrome Frame now starts three times faster on Windows Vista and Windows 7 and the most common conflicts with other plug-ins have been fixed.

Thanks in part to how simple it is to enable rendering with Google Chrome Frame, sites like DeviantART, Hootsuite, and github have added support, and Ruby on Rails is making a better-performing, more standards compliant experience the default for all users of Rails apps. Google applications like Orkut, Google Docs, and YouTube have already begun adding Google Chrome Frame support. Gmail and Google Calendar are planning to adopt Google Chrome Frame in the near future to improve performance and ease the transition for users as they drop support for legacy browsers.



A stable release is just the beginning for Google Chrome Frame. We’ve set aggressive goals for future releases: we’re working on making start-up speed even faster and removing the current requirement for administrator rights to install the plug-in. Expect more improvements and features in the near future, as we plan to release on the same schedule as Google Chrome.

We would not have made it this far without strong community support and feedback. The users and contributors to the preview versions have helped improve and shape the product in huge ways. If you’d like to get involved or just see what’s coming soon, you can subscribe to the new beta channel or if you are adventurous, try the dev channel to experience the very latest. The whole team continues to listen to your feedback through our project forum and we look forward to working with you to improve Google Chrome Frame even further.

Posted by Tomas Gunnarsson, Software Engineer and Robert Shield, Software Engineer

The Google Chrome team is hitting the road. From now through October, we’re giving 21 talks about HTML5 and related Google Chrome topics at 16 events, in 16 cities and 9 countries, and on 4 continents. Phew!

Check out our schedule below. Registration for almost all these events is open, so come say hi and learn a thing or two about HTML5.

Date	Locations	Event	Topics	Speakers
9/24	Atlanta, United States	Web Directions USA	HTML5	Michael Mahemoff
9/25	San Francisco, United States	TechCrunch Disrupt Hack Day	Chrome Web Store	Seth Ladd
9/26	Berlin, Germany	JSConf EU	HTML5	Paul Irish
9/28	Tokyo, Japan; Kyoto, Japan	Google Developer Day Japan (Japanese)	Installable Web Apps, Google Chrome Extensions, Google Chrome Developer Tools	Eiji Kitamura, Mikhail Naganov, Alexei Masterov
9/29	New York, United States	NYC GTUG Meetup	Chrome Web Store	Jan Kleinert
10/1	Taipei City, Taiwan	Google DevFest Taiwan	HTML5	Arne Roomann-Kurrik
10/2	New York, United States	Open Video Conference	HTML5	Paul Irish
10/5	Hong Kong Island, Hong Kong	Google DevFest Hong Kong	HTML5	Arne Roomann-Kurrik
10/8	Amsterdam, Netherlands	Fronteers Conference	HTML5	Paul Irish
10/8	Jakarta, Indonesia	Google DevFest Indonesia	HTML5	Arne Roomann-Kurrik
10/9	Hilversum, Netherlands; San Francisco, United States	HTML5 Game Jam	HTML5	Marcin Wichary, Paul Irish
10/9	Los Altos Hills, United States	Silicon Valley Code Camp	HTML5, Installable Web Apps, Google Chrome Extensions, Chrome Web Store, Native Client	Eric Bidelman, Ernest Delgado
10/10	Bangkok, Thailand	Google DevFest Thailand	HTML5	Arne Roomann-Kurrik
10/15	Aizu-Wakamatsu City, Japan	Aizu IT Forum (Japanese)	HTML5	Eiji Kitamura
10/16	Boston, United States	jQuery Boston Conference	HTML5	Paul Irish
10/29	São Paulo, Brazil	Google Developer Day Brazil	HTML5, Installable Web Apps, Google Chrome Extensions, Chrome Web Store, Google Chrome Developer Tools, Native Client, Google Chrome Frame	Eric Bidelman, Ernest Delgado

Posted by Brian Kennish, Developer Advocate

Since our previous post, we've made good progress on 2D graphics performance: 2D canvas acceleration is now available in trunk and the canary build by using the --enable-accelerated-2d-canvas command-line switch (coming to the developer channel shortly). We’ve also been hard at work improving our 3D graphics stack. Today, we’re excited to release a set of WebGL demos to help highlight what you can do with the API.

Chromium’s 2D canvas acceleration uses the same GPU process infrastructure as the compositor, which is designed to maintain the same stability and security Chromium has always had. In addition, this system picks the best graphics API to use on each OS that Chromium supports: Windows XP/Vista/7, Mac OS and Linux. We haven’t finished implementing accelerated 2D canvas support – there’s no Mac support and some functions are not accelerated yet – but Chromium already achieves some impressive gains on the recent IE9 Platform Preview Test Drive 2D canvas demos:

These early numbers show up to 60x speed improvement over the current version of Google Chrome. With Google Chrome’s fast release cycles, we expect to be able to get these enhancements to users quickly and add new performance improvements over time.

We’re excited to give developers fast 2D graphics, but we think truly hardware accelerating graphics on the web means giving developers access to a programmable 3D graphics pipeline with WebGL. Even with accelerated 2D canvas and SVG, it’s still not possible to achieve many graphics effects with these APIs. (To read more about the progression from dynamic 2D to CSS Transforms and WebGL, check out our recent blog post). With WebGL and 3D CSS, developers can create modern games, impressive photo galleries, 3D data visualizations, virtual environments, and whatever else they can dream up.

To give you a taste for what WebGL can do, we’ve worked with a number of talented artists and developers to create the first round of a series of demos, ranging from a realistic aquarium to a 3D wall of photos. We hope these demos help demonstrate even more immersive experiences made possible with these APIs. So check out our demo gallery with an up-to-date canary build or Chromium build and have some fun with using your GPU in the browser! For a quick peek at some of these demos, you can watch our playlist of preview videos:



Posted by James Robinson, Software Engineer and Gregg Tavares, Software Engineer

Recently, we posted about the work we’re doing to re-architect Chromium’s graphics stack and use the GPU to accelerate rendering. As we mentioned last time, this work will help ensure that developers can take full advantage of emerging graphics standards like 3D CSS and WebGL in Chromium. To get more feedback about these cool new features, we’re enabling hardware compositing along with 3D CSS transforms and WebGL on the trunk (coming soon to the dev channel). These new capabilities are major additions to the web platform, so we wanted to take the time to provide some background information and explain how these new capabilities fit into the web.

SVG and canvas: dynamic 2D

Until recently, it wasn’t possible to create any dynamic (i.e. non-image) graphics on the web without a plug-in. Starting in 2005, this began to change as browsers began to add Scalable Vector Graphics (SVG) and HTML 2D canvas element support. Both SVG and 2D canvas allow you to compose a 2D image at run time and manipulate it to achieve animation effects, but they vary greatly in their approach to specifying how you draw an image.

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC
"-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<path style="stroke-width:1; fill:rgb(246,127,0); stroke:none" d="M204.33 13..."/>
<path style="stroke-width:1; fill:rgb(0,0,0); stroke:none" d="M203.62 139.62..." />
<path style="stroke-width:1; fill:rgb(255,246,227); stroke:none"
d="M363.73 85.73 C359.27 86.29 355.23 86.73..."/>
</svg>

*note: ellipses replace many more points

d = document.getElementById("c");
c = d.getContext("2d");
...
i = 25;
while (i--) {
c.beginPath();
...
q = (R / r - 1) * t;
// create hypotrochoid from current mouse position, and setup variables (see: http://en.wikipedia.org/wiki/Hypotrochoid)
x = (R - r) * C(t) + D * C(q) + ...
y = (R - r) * S(t) - D * S(q) + ...
if (a) {
// draw once two points are set
c.moveTo(a, b);
c.lineTo(x, y)
}
c.strokeStyle = "hsla(" + (U % 360) + ",100%,50%,0.75)";
// draw rainbow hypotrochoid
c.stroke();
...
} *note: ellipses replace code

The images above were created with SVG and canvas, but as you can see from the code, they approach graphics in a very different way: SVG allows you to provide markup that describes an image, whereas canvas allows you to describe a set of sequential steps that draw an image in JavaScript. These approaches mean that a developer changes an image that’s already been drawn, such as when animating an image, in different ways. Because the browser keeps a full representation of an SVG image, changing just a parameter in the image is enough to cause the browser to redraw the image correctly. With canvas, on the other hand, the developer must clear the image and specify all the steps to draw it again with the desired changes.

Today, modern browsers, including Firefox, Safari, Opera and Google Chrome support creating 2D graphics with these technologies, and Internet Explorer is adding support for them in the upcoming version 9 release.

CSS Transforms: easy to use 2D and 3D effects

Even today, people primarily use apps that don’t strictly require advanced graphics, but eye candy like 3D transforms, transitions and reflections still help improve the experience of everyday tasks. While canvas could be used to create many of these effects, it can’t render them efficiently, and it would be hard to integrate with the other content on the page.

CSS transforms and animations, which first appeared in WebKit in 2007, allow developers to achieve commonly used effects easily by specifying parameters in CSS that are applied to content in the DOM. In 2009, WebKit began adding 3D CSS transforms and effects, which takes flat content on the page and makes it appear as if it were in 3D space.

/* CUBE */
#transitions #cube {
-webkit-transform-style: preserve-3d;
width: 600px;
height: 400px;
position: absolute;
}
#transitions #cube.active {
-webkit-animation-duration: 1s;
-webkit-animation-iteration-count: 1;
-webkit-animation-name: cubedemo;
-webkit-transform: rotateX(-90deg);
}
#transitions #cube .face {
position: absolute;
width: 600px;
height: 400px;
display: block;
overflow: hidden;
}
#transitions #cube .front {
-webkit-transform: scale3d(.835,.835,.835) translateZ(200px);
}
#transitions #cube .back {
-webkit-transform: scale3d(.835,.835,.835) rotateY(180deg) translateZ(200px);
}
#transitions #cube .top {
-webkit-transform: scale3d(.835,.835,.835) rotateX(90deg) translateZ(200px);
}

@-webkit-keyframes cubedemo {
0% {-webkit-transform: rotateX(0); -webkit-animation-timing-function: linear; }
50% {-webkit-transform: rotateX(-92deg);-webkit-animation-timing-function: ease-in; }
70% {-webkit-transform: rotateX(-84deg); -webkit-animation-timing-function: ease-in; }
80% {-webkit-transform: rotateX(-90deg); -webkit-animation-timing-function: ease-in; }
95% {-webkit-transform: rotateX(-88deg); -webkit-animation-timing-function: ease-in; }
100% { -webkit-transform: rotateX(-90deg); }
}

As you can see from this example, 3D CSS transforms and animations make it easy to add polished 3D effects to your app. Now that we support hardware compositing in Chromium, it’s easy to perform these transforms on the GPU and display it quickly on screen, so we’ve enabled them along with the compositor. Currently, this functionality is only available in Safari and Google Chrome but Firefox is working on an implementation as well, making it a great option to add impressive effects to your app in the future.

WebGL: Low-level dynamic 3D

While 3D CSS makes it easy to display 2D content so that it looks like it’s in a 3D space, it’s not designed for writing true 3D applications like CAD software or modern games. WebGL, on the other hand, provides access to all the functionality of OpenGL ES 2.0 from JavaScript, and is designed with exactly these types of applications in mind.

(link requires a WebGL-enabled browser)

(link requires a WebGL-enabled browser)

With WebGL you can navigate 3D environments, rotate around objects with volume, add realistic lighting, and render shadows and reflections like those above. Creating a scene like this just wouldn’t be possible in real-time with 3D CSS, let alone a 2D canvas or SVG. To achieve these effects, you need direct access to graphics hardware – which is exactly what WebGL provides.

With power comes complexity, so there is definitely a learning curve to using WebGL. The good news is that because it’s based on OpenGL ES 2.0, it should be familiar to people with graphics programming experience. A number of JavaScript libraries that make WebGL more accessible are already available, for example, the examples above use two frameworks: SpiderGL and the WebGL implementation of O3D. As the technology matures, expect to see other tools and libraries emerge to make it even easier to author content. A popular blog in the community, Learning WebGL has done a great job of keeping up with the latest libraries, tools and demos and has a substantial archive of WebGL resources.

Mozilla, Apple, Opera and Google are all working on putting the finishing touches on the WebGL spec in a Khronos working group, which is expected to hit v1.0 by the end of the year, but we’ve turned it on by default to get early feedback on Chromium’s implementation.

Thanks for reading to the end, we hope this helps explain the current state of graphics on the Web!

Posted by Henry Bridge, Product Manager

If you’re using the Google Chrome Extensions Gallery to publish your extensions, we just added support for Google Analytics, which can help you better understand how many people visit your extension pages, where they’re coming from and more.

Starting today, you can specify a Google Analytics profile for each of your extensions. This will start tracking the extension’s page in your Google Analytics account as if that page was part of your own site. See these instructions for more information on how to set this up.



You can also use Google Analytics to track the usage of your extension once it’s installed. Check out this tutorial that explains how to integrate Google Analytics such that you can analyze how users interact with the features of your extensions.

For questions about this new feature, we encourage you to visit our developer discussion group and share your feedback with us.

Posted by Qian Huang, Software Engineer

We recently released a developer preview of the Chrome Web Store, which included new documentation about our upcoming payments and licensing API. With this blog post, we wanted to share a quick overview and some tips about this API so that you can start developing your apps with it.

The Chrome Web Store will offer a built-in payments system that allows you to charge for apps, making it easy for users to pay without leaving the store. If you want to work with this payments system in your apps, you can use the Chrome Web Store Licensing API to verify whether a given user has paid and should have access to your app. Here’s how the API works:

The Licensing API has two inputs: the app ID and the user ID. The app ID is a unique identifier that’s assigned to each item uploaded to the store. You can see it most easily in the URL of your detail page—for example, .../detail/aihcahmgecmbnbcchbopgniflfhgnkff.

The user ID is the OpenID URL corresponding to the user’s Google Account. You can get the OpenID URL for the current user either by using Google App Engine’s built-in OpenID support or by using a standard OpenID library and Google’s OpenID endpoint.

Given the app ID and the user ID, you make Licensing API requests using this URI:

https://www.googleapis.com/chromewebstore/v1/licenses/<appID>/<userID>

When your app makes an HTTP request to the Licensing API, the app needs to be authenticated. The app is authenticated by matching your Google Account that uploaded the app to the Google Account used to call the API.

There are a few ways the app can indicate the Google Account used to make the API call. For the Chrome Web Store Licensing API, we highly recommend the use of OAuth for Web Applications. In this approach, OAuth access tokens are used to identify the Google Account calling the API.

You can obtain the necessary token via the Chrome Developer Dashboard by clicking the “AuthToken” link for your app. (This link appears only if your app uses Chrome Web Store Payments.) You’ll need this OAuth token to sign the HTTP requests to call the Licensing API. The best way to sign your requests is with a standard OAuth library.

The OAuth tokens that the Chrome Developer Dashboard provides are limited in scope, which means that they can only be used to make Licensing API calls. They can’t be used to make calls to other authenticated Google APIs or for anything else.

Once you’re ready to make authenticated calls, give the API a try by making your first request. For more information read the Licensing API docs, try out the Getting Started tutorial, check out the samples, and watch the video below:



Note that current version of the Licensing API is a stub, which means that it doesn’t return live data that’s based on purchases just yet. Instead, it returns dummy responses that you can use to verify the various scenarios of your implementation. However the protocol, response format, and URL endpoints of the API are all final, so your implementation shouldn’t need to change before the final launch of the store.

We look forward to receiving your feedback on the current Licensing API implementation at our developer discussion group.

Posted by Munjal Doshi, Software Engineer