Saturday, November 20, 2010

[Gd] App Permissions

| More

Chromium Blog: App Permissions

This is part of a series of blog posts that provide tips and tricks on how to create better web apps as well as insights behind the technology of the Chrome Web Store - Ed.

Web development sure got fun recently, right? Local storage, notifications, new form controls, geolocation, inline multimedia... the list goes on and on. These new capabilities can help web developers build powerful new features in their apps.

However, many of these new additions to the web platform are not allowed to web pages by default. For example, to protect a user’s privacy, browsers do not allow web pages to use the geolocation API to access a user’s location unless they prompt the user. Browsers show these prompts each time a web page tries to use a potentially invasive or unsafe capability:

But these prompts can be quite annoying, especially when one web page asks for several of them. And some of these privileges are relatively obscure or incomprehensible to the user. As a result they end up being ignored or scare users from allowing a particular functionality. Most people don’t know what a “clipboard” is, so asking them about access to it is not that informative or helpful.

Now in the Chrome Web Store, developers can create “apps” that group together multiple privilege requests for a single site. Apps have a lightweight installation step that displays the privileges the app requests all together. Once an app is installed, it can use the privileges it requested during the installation process without any further nagging.

Some privileges are relatively low-risk, so we infer permission to use them from the act of installing the application. An example of this is the notifications API. The only reason it isn’t allowed to normal web sites by default is that it could be used annoyingly. When a user installs an app, we interpret that as a sign of at least some trust, and allow that application to use the Notifications API without additional prompting. If users do not like the notifications that the application generates, they can either disable them in the app’s notification UI or they can simply uninstall the app.

In this first version of apps for the Chrome Web Store, we support permission request declarations for the geolocation, notifications, and unlimited storage privileges. Over time we’ll be adding even more.

To learn more about how to build apps for the Chrome Web Store, visit the developer documentation at

Posted by Aaron Boodman, Software Engineer

Friday, November 19, 2010

[Gd] HTML5, browsers, and books, twenty years later

| More

Google Code Blog: HTML5, browsers, and books, twenty years later

(Updated 10:05am PST: Corrected link to

Twenty years ago this month, Tim Berners-Lee published his proposal for the World Wide Web. Since then, web browsers and web programming languages have come a long way. A few of us on the Chrome team decided to write an online guide for everyday users who are curious about the basics of how browsers and the web work, and how their evolution has changed the way we work and play online. Called "20 Things I Learned about Browsers and the Web," this online guidebook is illustrated by Christoph Niemann, and built in HTML5, JavaScript and CSS3, with our friends at Fi.

In building an online book app, HTML5, JavaScript and CSS3 gave us the ability to bring to life features that hearken back to what we love about books with the best aspects of the open web: the app works everywhere, and on any device with a modern browser. Here are a few features of the book experience that we’re particularly excited about:

  • After the app has been visited once, you can also take the experience with you offline, thanks to the Application Cache API.
  • You can resume reading where you had left off as the book remembers your progress using the Local Storage API. We also mark the chapters that have previously been read by folding the top right corner of the page in the navigation.
  • The app utilizes the History API to provide a clutter-free URL structure that can be indexed by search engines.
  • The HTML5 canvas element is used to enhance the experience with transitions between the hard cover and soft pages of the book. The page flips, including all shadows and highlights, are generated procedurally through JavaScript and drawn on canvas.
  • The canvas element is also used to animate some of the illustrations in the book.
  • CSS3 features such as web fonts, animations, gradients and shadows are used to enhance the visual appeal of the app.

This illustrated guidebook is best experienced in Chrome or any up-to-date, HTML5-compliant modern browser. We hope you enjoy the read as much as we did creating it, at or

By Min Li Chan, Google Chrome Team

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Chrome Beta channel has been updated to 8.0.552.208 for Mac and Linux.

This release contains a number of stability and UI improvements.  Full details about the changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Chrome Beta channel has been updated to 8.0.552.208 for Mac and Linux.

This release contains a number of stability and UI improvements.  Full details about the changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 9.0.587.0 for Windows, Mac, Linux, and Chrome Frame

  • GPU Related Fixes
  • Crash Fixes
  • Instant Fixes
  • [r65953] Move click-to-play to about:flags. (Issue: 62091)
More details about additional changes are available in the svn log of all revision.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome

[Gd] This Week's Wave Protocol Summit: Updates

| More

Google Wave Developer Blog: This Week's Wave Protocol Summit: Updates

We've just wrapped up day 3 of this week's Wave Protocol Summit in San Francisco. Developers and industry partners have gathered from all over the world to discuss the architecture of Wave, opportunities for use in enterprise, government, and consumer technology, and the future of the open source project. The last few days have included a great mix of architecture presentations, technical discussions, and interesting demos using Wave technology (WaveLook, Novell Vibe,, and others).

Since the Wave in a Box announcement in September, progress has been rapid. We've recently added:

Wave in a Box "out of the box"

You can keep up to date by following the Progress Reports wave.

For the rest of this week we'll be hacking on Wave in a Box, helping new contributors tackle some starter projects, resolving open issues, and adding even more functionality.

As a reminder, we'll continue running at least through the end of the year. We've also recently introduced a wave export feature. In addition, we're working on ways for you to access waves through Google Docs and we hope to share more on our progress soon.

If you're following along from home, we'll be sharing videos following the event -- but please join us in the Wave Protocol group.

Posted by Dan Peterson, Product Manager

Thursday, November 18, 2010

[Gd] Petits fours in your search results

| More

Official Google Webmaster Central Blog: Petits fours in your search results

Webmaster Level: All

Recently we made a change to show more results from a domain for certain types of queries -- this helped searchers get to their desired result even faster. Today we’re expanding the feature so that, when appropriate, more queries show additional results from a domain. As a webmaster, you’ll appreciate the fact that these results may bring targeted visitors directly to the pages they’re interested in.

Here’s an example: in the past, the query [moma] (the Museum of Modern Art), might have triggered two results from the official site:

With this iteration, our search results may show:
  • Up to four web results from each domain (i.e., several domains may have multiple results)
  • Single-line snippets for the additional results, to keep them compact
As before, we still provide links to results from a variety of domains to ensure people find a diverse set of sources relevant to their searches. However, when our algorithms predict pages from a particular site are likely to be most relevant, it makes sense to provide additional direct links in our search results.

Like all the hundreds of changes we make a year, we’re trying to help users quickly reach their desired result. Even though we’re constantly improving our algorithms, our general advice still holds true: create compelling, search-engine friendly sites in order to attract users, buzz, and often targeted traffic!

Written by Harvey Jones, Software Engineer

[Gd] Changes to managed placement bidding on the Display Network

| More

AdWords API Blog: Changes to managed placement bidding on the Display Network

Currently, ad groups using manual CPC bidding which contain managed placements are required to have a managed placements bid (siteMaxCpc). Today, we’re announcing that we’ll be sunsetting siteMaxCpc on March 15, 2011 to help simplify bid management on the Google Display Network (GDN).

We’re making this change in response to feedback that having multiple ad group bids for the GDN complicates bid management. Most of you using managed placements are already using placement-level bidding to control your costs on the GDN, and you’ll be able to continue to do this. In addition, the content bid (keywordContentMaxCpc) will continue to be available, offering control at the ad group level.

Here’s how this change will affect you: after March 15, we’ll stop accepting changes to ManualCpcAdGroupBids that modify siteMaxCpc to set it to anything other than 0. After that date, calls that attempt to set siteMaxCpc will return the error BiddingError.Reason.CANNOT_SET_SITE_MAX_CPC.

We’ll be announcing this change to all AdWords users early next year but wanted to let you know early so that you can prepare to modify your applications to stop accepting new siteMaxCpc bids. When we make the broader announcement, we’ll make it possible to “self-migrate” existing managed placements bids by setting them to zero and modifying their other bids as appropriate. In March, when we stop accepting changes to these bids entirely, we’ll migrate any remaining bids to the placement level, according to clear rules which we’ll share with you in a blog post in January.

If you have any questions about this change, we’ll be happy to answer them on our forum.

Posted by Prabhu Balasubramanian, Product Manager

Wednesday, November 17, 2010

[Gd] Compatibility Issues With EMET

| More

Chromium Blog: Compatibility Issues With EMET

We have discovered compatibility issues between Google Chrome and Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). EMET is used to deploy and configure security mitigation technologies, often for legacy software. However, because Chrome already uses many of the same techniques (and more), EMET does not provide any additional protection for Chrome. In fact, the current version of EMET interferes with Chrome’s security and prevents Chrome from updating.

We are working closely with Microsoft on a solution to these issues. In the meantime, we advise users and enterprises not to attempt to configure EMET to work with Chrome.

Posted by Ian Fette, Product Manager and Carlos Pizano, Software Engineer

Tuesday, November 16, 2010

[Gd] [Libraries][Update] Prototype

| More

Google AJAX API Alerts: [Libraries][Update] Prototype

Prototype has been updated to

[Gd] Be part of improving Google Person Finder

| More

Google Code Blog: Be part of improving Google Person Finder

(Cross-posted from the Blog)

Google Person Finder has become a useful tool in responding to natural disasters by reconnecting people with their family and friends. We’ve been looking at the next phase of Google Person Finder and decided to begin hosting the open source project at Google Code. We’re inviting the developer community to help improve Google Person Finder and the PFIF data format.

Google Person Finder provides a common place to search for, comment on, and connect records from many missing person registries. After the January 12th earthquake in Haiti, a team of Googlers worked with the U.S. Department of State to quickly create a site that helped people who were affected by the disaster. The site was used heavily after the Chile earthquake in February and put in action again in April after the Qinghai earthquake in China and in August for the Pakistan floods.

The software powering Google Person Finder is open source so we’re listing the open issues and feature requests we’ve received over the past few months in hopes the community can help us improve the code. We’ve created a Developer Guide to help developers get started. As always, we invite those interested to post questions on our public Person Finder discussion group. Those who are interested in improving the PFIF data format can also join the PFIF discussion group.

In addition to opening our product for developers, we’ve decided it’s now time to turn off our Google Person Finder instances for Haiti, Chile, China, and Pakistan. It doesn’t seem useful to be serving these missing person records on the Internet indefinitely, so we intend for each instance of Google Person Finder to be running for a limited time. Once an instance has served its purpose, we will archive the PFIF records in a secure location for historical preservation for one year while we work to identify a permanent owner for these records. Assuming a long-term owner cannot be found, we will delete the records after one calendar year. For more information, please feel free to review the Google Person Finder FAQ.

By Prem Ramaswami, Crisis Response Team


[Gd] Instant Previews: Under the hood

| More

Google Code Blog: Instant Previews: Under the hood

If you’ve used Google Search recently, you may have noticed a new feature that we’re calling Instant Previews. By clicking on the (sprited) magnifying glass icon next to a search result you see a preview of that page, often with the relevant content highlighted. Once activated, you can mouse over the rest of the results and quickly (instantly!) see previews of those search results, too.

Adding this feature to Google Search involved a lot of client-side Javascript. Being Google, we had to make sure we could deliver this feature without slowing down the page. We know our users want their results fast. So we thought we’d share some techniques involved in making this new feature fast.

JavaScript compilation

This is nothing new for Google Search: all our Javascript is compiled to make it as small as possible. We use the open-sourced Closure Compiler. In addition to minimizing the Javascript code, it also re-writes expressions, reuses variables, and prunes out code that is not being used. The Javascript on the search results page is deferred, and also cached very aggressively on the client side so that it’s not downloaded more than once per version.

On-demand JSONP

When you activate Instant Previews, the result previews are requested by your web browser.There are several ways to fetch the data we need using Javascript. The most popular techniques are XmlHttpRequest (XHR) and JSONP. XHR generally gives you better control and error-handling, but it has two drawbacks: browsers caching tends to be less reliable, and only same-origin requests are permitted (this is starting to change with modern browsers and cross-origin resource sharing, though). With JSONP, on the other hand, the requested script returns the desired data as a JSON object wrapped in a Javascript callback function, which in our case looks something like


Although error handling with JSONP is a bit harder to do compared to XHR (not all browsers support onerror events), JSONP can be cached aggressively by the browser, and is not subject to same-origin restrictions. This last point is important for Instant Previews because web browsers restrict the number of concurrent requests that they send to any one host. Using a different host for the preview requests means that we don’t block other requests in the page.

There are a couple of tricks when using JSONP that are worth noting:

  • If you insert the script tag directly, e.g. using document.createElement, some browsers will show the page as still “loading” until all script requests are finished. To avoid that, make your DOM call to insert the script tag inside a window.setTimeout call.
  • After your requests come back and your callbacks are done, it’s a good idea to set your script src to null, and remove the tag. On some browsers, allowing too many script tags to accumulate over time may slow everything down.

Data URIs

At this point you are probably curious as to what we’re returning in our JSONP calls, and in particular, why we are using JSON and not just plain images. Perhaps you even used Firebug or your browser’s Developer Tools to examine the Instant Previews requests. If so, you will have noticed that we send back the image data as sets of data URIs. Data URIs are base64 encodings of image data, that modern browsers (IE8+, Chrome, Safari, Firefox, Opera, etc) can use to display images, instead of loading them from a server as usual.

To show previews, we need the image, and the relevant content of the page for the particular query, with bounding boxes that we draw on top of the image to show where that content appears on the page. If we used static images, we’d need to make one request for the content and one request for the image; using JSONP with data URIs, we make just one request. Data URIs are limited to 32K on IE8, so we send “slices” that are all under that limit, and then use Javascript to generate the necessary image tags to display them. And even though base64 encoding adds about 33% to the size of the image, our tests showed that gzip-compressed data URIs are comparable in size to the original JPEGs.

We use caching throughout our implementation, but it’s important to not forget about client-side caching as well. By using JSONP and data URIs, we limit the number of requests made, and also make sure that the browser will cache the data, so that if you refresh a page or redo a query, you should get the previews, well... instantly!

By Matías Pelenur, Instant Previews team

Sunday, November 14, 2010

[Gd] Web fonts on the rise

| More

Google Web Fonts: Web fonts on the rise

We launched the Google Font Directory and Google Font API to help establish a core set of web fonts that can be used openly across devices and platforms. Recently, the team took some time to reflect on our progress, the adoption of web fonts in general, and on the current limitations. We'd like to share some of the most interesting stats from our analysis:
  • The Google Font API currently serves over 17 million requests [1] a day to users across the globe.
  • We’ve seen a 30% month-over-month growth rate since we launched. (This corresponds to over 20x year-over-year growth.)
  • Roughly 400,000 unique websites [2] use the Google Font API.

The adoption of the Google Font API has been fantastic, and we think it speaks to the potential of web fonts to change the web. Google isn’t the only player in this space to see promising adoption stats. In order to fully assess the state of the web font ecosystem, we worked together with our friends at Typekit. They performed a similar analysis and their results are equally exciting.

Although there is a long way to go for comprehensive browser and device support (especially for complex scripts like Arabic), we are highly optimistic. With web font adoption quickly gaining momentum, there will be increased pressure on the browsers and platforms of the world to support web fonts in a standard and consistent manner. But we need your help! If you have interesting example uses of web fonts, feature requests for the Google Font API, or encounter problems, please let us know by posting on our feedback page. Here’s to a bright web font future!

Posted by David Wurtz, Product Manager, Google Font API

[1] A request is a single call to the Google Font API for one or more fonts.
[2] We count a unique website as unique domains, except that “www” subdomains are not counted. For example, and would count as one domain. However, and would count as two domains.


[Gd] Navigate the font directory more easily and submit your fonts

| More

Google Web Fonts: Navigate the font directory more easily and submit your fonts

To make it easier for you to navigate all the tools and documentation that are part of the Font API we have created a unified navigation for the directory.

The directory pages now show a new dropdown menu at the top that takes you to our documentation pages, blog, previewer and other tools very quickly. Don’t forget to check out our new chrome extension as well.

Submit your
font or tell us where you have used the Font API

In the new navigation you will also find two new forms we have created for you. If you are a font designer and would like to see your font as part of the directory fill out our font submission form and tell us about it.

Have you created a website and used the Font API in a creative way? We would love to hear about that, too.

We are working hard to improve our service and the directory. If you have any suggestions you can always give us feedback on our moderator page.

By Marc Tobias Kunisch, Webmaster for the Font API Team

[Gd] Interview with Danh Hong, designer of Hanuman

| More

Google Web Fonts: Interview with Danh Hong, designer of Hanuman

As you may know, the Google Font team recently launched a small handful of non-latin fonts in the Google Font Directory, including Cyrillic, Greek and Khmer. We recently got a hold of Khmer font designer, Danh Hong, to describe his Cambodian font Hanuman and what went into and motivated its creation.

Q: What inspired you to create the Hanuman font?
It comes from my inspiration to have high quality Khmer fonts for both computers and mobile devices. My Khmer language is complex, and the typeface is rich. So I thought the new font technology we have today can help people to use the Khmer language on their computers and devices, and can save Khmer culture in digital age. Windows ships with a Khmer font, but it is small and hard to read. However, Mac OS X and the iPhone don’t ship with a Khmer font yet, and these products are getting usage in the Cambodian market.

Q: Did you try to accomplish something specific with this font, and did you succeed?
The challenge with Khmer is that it has many levels (above and below) so Khmer paragraph’s take up more vertical space than the same paragraph in English. My goal was to compress the Khmer letters so they would be compatible or similar to the metrics of English characters. I also wanted to merge OpenType and AAT together, so this behavior works with all Windows, Linux and Mac OS X devices.

Q: What kinds of documents are most appropriate for this font?
Because it is similar size to English text, it is best for scenarios that have a mix of Khmer and English text. I think it is good for books, daily newspapers and dictionaries. And because it is serif, it looks good for formal letters as well.

Q: Designing a new font is a long journey. What inspires you to keep motivated throughout all the different stages?
The creativity makes me feel happy. I always feel good when I can do new things, and my life is meaningful.

Q: What is your favourite part of the type design process, and why?
This is a difficult question! My favorite part is always changing. For old TrueType fonts, creating new typeface is interesting, but for OpenType, the “smart” behavior embedded into fonts is my favorite. I also enjoy hinting, because it can make the text clear to read.

Q: Can you recommend how other type designers can learn the skills involved in making Khmer fonts?
I recommend that potential Khmer type designers to learn Khmer art and old text, in addition to western typography. New things sometime come from mix between the traditional and modern technology.

Q: What are your favourite fonts, and why?
My favorites are handwriting fonts, because they are very natural.

Q: What do you think could be improved about the type design process?
Hinting is always hard work. Right now, there doesn’t exist an auto hinting tool that can do better than hand, but I think it is possible in the future.

[Gd] International Fonts Launch Today

| More

Google Web Fonts: International Fonts Launch Today

Today is a big day for the Google Font API. We have officially added our first non-Latin fonts to the Google Font API and Google Font Directory. Our additions include high quality web fonts for the Cyrillic, Greek, Hebrew, and Khmer scripts. That puts our total offering at 6 scripts, with over 25 unique font families and around 60 fonts in the Directory.

This launch marks a significant milestone for the web. We believe web fonts are critical not just for Latin-based scripts, but for all the world's languages. Fonts are a means of expression, and our choice of fonts freely available on the web should be large enough to allow for many different types of communication. In the coming months, the Google Font API team plans to expand our international coverage across even more scripts.

It's easy to take the variety of Latin web fonts for granted, but we have to remember that some scripts have no web fonts available at all. In these cases, users are required to download “font packs” to display the fonts correctly or they suffer from a poor web surfing experience:

A Khmer snippet properly displayed as a web font:

A Khmer snippet when the reader's computer does not have the correct font installed:

The creation of these web fonts is a labor intensive task that takes incredible patience, attention to detail, and skill. We'd like to thank all the immensely talented type designers that contributed to this launch, including Danh Hong, SIL International, the Greek Font Society, ParaType, and Jovanny Lemonad.

If you use a script that you would like to see supported by the Google Font API, please get in touch with our team through our moderator page. If you are a type designer with experience in designing for a script and you would like to contribute an original font family, we are actively soliciting commission proposals through this Proposal Form.

[Gd] A more fontastic Google Docs

| More

Google Web Fonts: A more fontastic Google Docs

(Cross-posted from the Official Google Blog and the Google Docs Blog)

Documents without font choices are like photographs without colors. Just as shades of color can add depth to a picture, smart font choices give your text another dimension.

For a long time, the set of fonts that you’ve seen when you browsed the web has been quite limited. That’s because you could only use a font that’s already been installed on your computer. So if a website designer wanted all her visitors to see the same thing, she could only use fonts that are so ubiquitous that the chances are very high that every computer will have them. And there are only a handful of fonts that fit that bill.

Thankfully, that situation is changing. All modern browsers now support the ability to download web fonts. A web font doesn’t need to be installed on your local computer—it can be read directly from a web server and used immediately on the webpage that you’re loading. In May, we launched the Google Font API, which makes it easy for website developers to include any one of an ever-growing list of web fonts on their pages. We’re already using the new API for the latest themes in Google forms.

As of today, Google documents supports web fonts (using the Google Font API) and we’re excited to announce six new fonts.

Droid Serif and Droid Sans
Android fans will already be familiar with the Droid family of fonts. Droid Serif and Droid Sans both feature strong vertical lines and a neutral, yet friendly appearance. They’re designed specifically for reading on small screens.

Calibri and Cambria
Every day we have many people import documents from Microsoft Word into Google Docs. Today we’re making import fidelity better by adding two of the most popular Microsoft Word fonts. Calibri is a beautiful sans serif font characterized by curves and soft edges. It’s designed to be high impact. Cambria is built with strong vertical serifs and subtle horizontal ones. It’s very legible when printed at small sizes.

Consolas and Corsiva
Consolas joins Courier New as the second monospaced font in Google Docs. It’s a modern monospaced font with character proportions that are similar to normal text. Finally, Corsiva is our first italic font with embellished characters and an elegant style.

Right now our font support covers most Latin and Western European character sets. However, we’ll be adding web fonts for other languages (like Hebrew and Greek) soon. If you don’t see the new fonts in your documents, check that web fonts are supported in your language and that the document language is set correctly from the File -> Language menu.

This is just the beginning of fonts in Google Docs. We added six new fonts today and we’re already testing our next batch. You’ll see many more new fonts over the next few months. And because Google Docs uses web fonts, you’ll never need to install a new font: when you load your document, the latest set of fonts will always be there, ready to use.

Finally, adding web fonts is just one of the challenges that we have been working on. If you’re interested in learning more about the challenges of building a collaborative application, check out the first post of a three-part series on collaboration posted earlier today.

Posted by: Jeremie Lenfant-Engelmann, Software Engineer

[Gd] Optimizing the use of the Google Font API

| More

Google Web Fonts: Optimizing the use of the Google Font API

At Google, we're absolutely obsessed with making the web faster, and delivering the lowest possible latency to users. Naturally, with the Google Font API, we're concerned with how to minimize the performance impact of web fonts. This post presents a number of best practices for optimizing performance and also summarizes the results of extensive measurements with real-world integrations.

First, the recommendations:

1. Combine multiple fonts into one request.

One pattern we see frequently is a separate <link> tag for each of the font requests. Many users don't seem to know that you can easily combine multiple font requests into a single tag, just separating the fonts with a | character.

So, instead of:
<link rel="stylesheet" type="text/css" href="">
<link rel="stylesheet" type="text/css" href="">

<link rel="stylesheet" type="text/css" href=" +Sans|Lobster">

This simple trick will save one roundtrip to the server for each additional font requested, and also protect against blocking on older browsers which only have 2 connections open per domain at a time.

2. Don't put the @import in an external CSS

Unfortunately, Internet Explorer has bad performance when one external CSS file links to another using an @import directive. If it weren't for performance issues, it would be good to have the extra flexibility of putting the @import in the same CSS file that uses the fonts, but for best performance, put the <link> tag in the base HTML file.

When that's done, the Font API CSS will usually load in parallel with other external CSS files in the page.

3. Put the font request early

You should try to place the Font API link right after the opening tag. In general, the Font API link should never go after a <script> tag. As Steve Souders has pointed out in his blog post (, if there's a script tag before the @font-face declaration, Internet Explorer won't render anything on the page until the font file is done downloading.

4. Don't ask for fonts you don't use

This may seem obvious, but if you don't actually use a font, don't request it in the API. You might miss this if you do your testing in Firefox or Chrome, which only load the font files needed to render the text on the page. Internet Explorer, by contrast, loads all the fonts requested, even if they’re not actually used.

5. Use tools to analyze your page's performance

An excellent resource is, which runs your page in an instrumented IE browser, and displays waterfall graphs and other information. It’s also a great idea to use the “Inspect Element” resource graphs in Chrome. Also be sure to follow Steve Souders' blog, which contains tons of useful information about improving performance of web fonts.

Let’s take a closer look at a well-designed site, the home page of the Government of Chile ( This is a (partial) resource timeline from Inspect Element in Chrome over a 3Mbps DSL connection: </script>

The second resource (“css”) is the invocation of the Google font API. As you can see, the request is placed very early in the waterfall, and a number of other requests are served in parallel. Around the time the first round of Javascript is done loading, the page is rendered for the first time (the blue line), and a second round of resources are loaded, also in parallel, including the two “font” resources. This waterfall clearly shows that the font requests aren’t blocking any other resources on the page. If the font request had been an @import in an external CSS, the waterfall would have been different.

Running the same page on (Internet Explorer 8) shows similar results with respect to the font resources (only first 20 requests shown):

Unlike in Chrome, the Javascript requests of lines 6-9 do serialize (the fact that Chrome is much faster than IE is not just marketing!), but the font API request (line 12) and the font data (line 13) are, just as in Chrome, loaded in parallel. Rendering is, however, blocked until the font data is complete. To make font loading entirely asynchronous and avoid any possibility of blocking the rendering, use the Webfont Loader library. Note that parallel loading will not always be the case, but if you follow the recommendations above, there’s a very good chance of it, and it is always a good idea to use these tools to analyze and optimize the performance of your site.

We’re working with browser vendors (IE9 in particular) to fix the fact that rendering blocks on the font data.

A larger scale analysis of latency impact

To make sure that our recommendations are sound, and that we’re using the best strategy to serve web fonts, we did a detailed quantitative analysis of the impact of web fonts on page load time. We chose 28 popular sites that use the Google Font API, and measured the page load time both with web fonts and with the request to the Font API disabled. Each experiment ran 200 times, with three simulated network speeds: fast (roughly 100Mbps), medium (3Mbps), and slow (384kbps). All the tests were run on Internet Explorer 8, instrumented to report the page load time.

Each of the following graphs shows a distribution of the difference of the mean page load time with and without fonts. As you can see, on fast connections the distribution is consistent with a Gaussian curve centered around zero. In fact, the mean increase in page load time is 37ms (+/- 137ms), so a reasonable conclusion is that there is no measurable impact on page load time. Note that most webpages have a very high variance in page load times, so getting measurements more precise than a few hundred milliseconds is not feasible.

Fast (~100Mbps):

At medium network speeds, there seems to be a bias toward increasing page load times, with all samples save one coming in at between 0 and 500ms. Even so, the mean increase was only 34ms (+/-195ms), so the effect is barely significant.

Medium (3Mbps):

Finally, on slower connections, it is possible to see a definite impact on overall page load times, ranging from 250ms-1.5s for all but two of the samples. At these speeds, the mean increase is definitely significant, at 1016ms (+/- 302ms).

Slow (384kbps):

We wanted to find out exactly what was causing this impact on page load time on slower connections. A reasonable hypothesis is that it’s the bytes themselves. Thus, we made a scatterplot with the total (compressed) size of the fonts on the horizontal axis, and the delta page load time on the vertical. This plot shows a clear linear relationship:

Thus, users on high-bandwidth connections can enjoy web fonts with little or no impact on performance -- the web font request is served in parallel with the other elements on the page. Users on slower connections will see the impact of the additional bytes served. Fortunately, our team is working on ways of compressing font files even further, and users of the Google Font API will see the performance benefits as soon as this work is complete, with no additional effort.

By Raph Levien and Jeremie Lenfant-engelmann, Engineers on the Google Font API Team

[Gd] Welcome to the Google Web Font Blog

| More

Google Web Fonts: Welcome to the Google Web Font Blog

Since we launched the Google Font API and Font Directory at Google IO we have seen wide adoption of Google web fonts. We've also had great feedback and feature requests from across the web.

So far we've used the Google Code Blog to tell you about new developments from the web font team. Now we're introducing a dedicated blog to give you better insight into what we're up to.

Come back soon or even better subscribe to our RSS feed for more information about new features and fonts that we're working on to make the Font API work even better for you.

By Marc Tobias Kunisch, Webmaster for the Font API Team

[Gd] What a feeling! Even better indexing of SWF content

| More

Official Google Webmaster Central Blog: What a feeling! Even better indexing of SWF content

Webmaster Level: All

We often get questions from webmasters about how we index content designed for Flash Player, so we wanted to take a moment to update you on some of our latest progress.

About two years ago we announced that through a collaboration with Adobe we had significantly improved Google’s capability to index Flash technology based content. Last year we followed up with an announcement that we had added external resource loading to our SWF indexing capabilities. This work has allowed us to index all kinds of textual content in SWF files, from Flash buttons and menus to self-contained Flash technology based websites. Currently almost any text a user can see as they interact with a SWF file on your site can be indexed by Googlebot and used to generate a snippet or match query terms in Google searches. Additionally, Googlebot can also discover URLs in SWF files and follow those links, so if your SWF content contains links to pages inside your website, Google may be able to crawl and index those pages as well.

Last month we expanded our SWF indexing capabilities thanks to our continued collaboration with Adobe and a new library that is more robust and compatible with features supported by Flash Player 10.1. Additionally, thanks to improvements in the way we handle JavaScript, we are also now significantly better at recognizing and indexing sites that use JavaScript to embed SWF content. Finally, we have made improvements in our video indexing technology, resulting in better detection of when a page has a video and better extraction of metadata such as alternate thumbnails from Flash technology based videos. All in all, our SWF indexing technology now allows us to see content from SWF files on hundreds of millions of pages across the web.

While we’ve made great progress indexing SWF content over the past few years, we’re not done yet. We are continuing to work on our ability to index deep linking (content within a Flash technology based application that is linked to from the same application) as well as further improving indexing of SWF files executed through JavaScript. You can help us improve these capabilities by creating unique links for each page that is linked from within a single Flash object and by submitting a Sitemap through Google Webmaster Tools.

We’re excited about the progress we’ve made so far and we look forward to keeping you updated about further progress.

Written by Jifeng Situ and Sverre Sundsdal, Software Engineers

[Gd] Check out Google’s latest cloud technologies at Cloudstock!

| More

Google Code Blog: Check out Google’s latest cloud technologies at Cloudstock!

There’s an exciting new event happening December 6th dubbed the “Woodstock for Cloud Developers.” We’ll be participating at Cloudstock, an industry event taking place in San Francisco’s Moscone West, that brings together a growing developer community and some of the leading cloud technology companies (such as Google, vmware, and Amazon) to learn, hack and network.

Google is a strong believer in the open technologies powering the web, such as HTML5. Cloud computing is about powering innovations on the web with platforms and services that make developers like you more efficient and allow you to concentrate on solving business problems. No longer do you have to worry about the hassle of acquiring and managing servers, disks, RAM and CPU-- it’s all accessible in the cloud.

Google will be presenting the following sessions at Cloudstock:

  • Introduction to Google’s Cloud Platform Technologies (Christian Schalk)
    This talk will provide an in depth review of Google's Cloud Platform Technologies by first reviewing both Google App Engine and App Engine for Business followed by an introduction to Google's new cloud technologies: Google Storage, Google Prediction API and BigQuery. Throughout the presentation, in depth technical demonstrations will be given showing how to use these technologies together in an integrated manner.
  • Selling your Cloud App on the Google Apps Marketplace (Ryan Boyd)
    This demo-focused session will review how to integrate your app with Google Apps and sell it on the Google Apps Marketplace to reach 30 million users at 3 million businesses. It will dive into the SaaSy Voice demo application, showing how technologies like OpenID-enabled Single Sign-On, OAuth and AtomPub make it easy to create great user experiences for your customers.

We have another session which will be announced shortly-- stay tuned to this blog and the GoogleCode twitter account!

Register for the free Cloudstock event at:

Moscone West
San Francisco, CA
Monday, December 6th, 2010

Looking forward to meeting you there!

By Ryan Boyd, Google Developer Team