Introducing Page Speed Online, with mobile support

By Andrew Oates and Richard Rabbat, Page Speed Team

At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.



In addition, we’ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.

Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.

Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.

Blogs are for people

By Scott Knaster, Google Developer Relations

Hello, esteemed Google Code Blog readers! My name is Scott Knaster, and I’m the new editor of this blog. I’m interrupting the usual flow of posts to let you know about some new things happening around here. This blog has the company’s name on it, but of course, like all blogs, it’s written by individual people, to be read by other individual people, like you. We want to do a little more to celebrate that, starting with these small steps:

• We’re adding a photo and some info about each post’s author. Googlers get around, to hackathons, conferences, and GTUGs, and now you’ll have faces to match up with names when we meet in real life.
• We’ll spend more time responding to comments. As always, we encourage and appreciate your thoughtful, on-topic comments.
• We’ll be tweeting more at @googlecode over on Twitter, too. And you can find a list of Google developer-related Twitter accounts here (choose Developers from the Category drop-down).
• I’ll be hanging around here a lot. Think of me as the host of a big, geeky dinner party. Mostly I’ll be helping edit posts written by others—experts who work on the products they post about—but I’ll also write a few posts myself.

I’ve been working with APIs and platforms for a long time, mostly by writing docs about how to use them. Platforms are full of promise, but they’re only interesting and worthwhile when people build on them.

Please email me at sknaster@google.com if you have any thoughts or feedback for improving this blog. Or, just leave a comment on this post.

Thanks for being here!

Student applications now being accepted for Google Summer of Code

(Cross-posted with the Google Open Source Blog.)

Today marks the start of the 2011 Google Summer of Code student application period.

Google Summer of Code is a global program where university students are given a stipend to write code for open source projects over a three month period. Through Google Summer of Code, accepted students are paired with a mentor from the participating projects, gaining exposure to real-world software development and the opportunity for employment in areas related to their academic pursuits. Best of all, more source code is created and released for the use and benefit of all.

Google Summer of Code is a highly competitive program with a limited number of students being accepted. We are pleased to announce that this year we have enlarged the program so that we can accept as many as 150 additional students. We hope all interested students will apply!

Now it is time for the students to submit their proposals to the accepted mentoring organizations via the Google Summer of Code program website from today through Friday, April 8th 19:00 UTC. For the past 10 days students have had the opportunity to review the Ideas pages for this year’s 175 accepted projects and to research which projects they would like to contribute to for this year’s Google Summer of Code.

Every year we have thousands of students who apply for the Google Summer of Code program but due to the limited number of slots many students are not able to be a part of the program. The quality of your proposal is what will make you stand out from your peers. Students should consult the Google Summer of Code student manual for suggestions on how to write a proposal that will grab the attention of the mentoring organizations. Multiple proposals are allowed but we highly recommend focusing on quality over quantity. The mentoring organizations have many proposals to review, so it is important to follow each organization’s specific guidelines or templates and we advise you to submit your proposal early so you can receive timely feedback.

For more tips, see a list of some helpful dos and don’ts for successful student participation written by a group of experienced Google Summer of Code administrators, our user’s guide for the program site, Frequently Asked Questions and timeline. You can also stay up-to-date on all things Google Summer of Code on our Google Open Source blog, mailing lists or on IRC at #gsoc on Freenode.

Good luck students and remember to submit your proposals early–you only have until April 8!

By Stephanie Taylor, Open Source Programs Office

Page Speed for Chrome, and in 40 languages!

(Cross-posted from the Google Webmaster Central Blog.)

Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

By Matthew Steele and Richard Rabbat, Page Speed Team

Google I/O extends virtually around the world

In celebration of Google I/O 2011, many Google offices around the world, as well as GTUG partners and Student Ambassadors, are hosting free viewing parties of Google I/O sessions. If you can't attend Google I/O in person, these events are a way to connect with other talented developers and watch live feeds of the conference.

Part viewing party and part community building, Google I/O Extended events are free and worldwide, focused on bringing the developer community together to live-stream the keynote and other major sessions of Google I/O. Each location’s event will be a little different, so check the registration page of the closest location to see what they have planned. With limited space, registration is required. Learn more and find an I/O Extended event near you on the I/O Extended site. These events are being organized by local developer community leaders and university ambassadors, so please reach out to them specifically if you have any questions about the details.

Here are just a few of the locations hosting an I/O Extended event:

Africa

• Cairo, Egypt

Asia

• Manila, Philippines
• Pune, India
• Taipei, Taiwan

Europe

• Aachen, Germany
• Barcelona, Spain
• Berlin, Germany
• Brussels, Belgium
• Bucharest, Romania
• Dublin, Ireland
• London, England
• Madrid, Spain
• Malaga, Spain
• Istanbul, Turkey
• Kyiv, Ukraine
• Munich, Germany
• Murcia, Spain
• Vienna, Austria
• Warsaw, Poland

North America

• Boise, ID, USA
• Charlotte, NC, USA
• Maui, HI, USA
• San Jose, CA, USA
• Twin Cities, MN, USA
• Washington, DC, USA
• Waterloo, Ontario, Canada (link updated)

South America and Central America

• Belo Horizonte, Brazil
• Buenos Aires, Argentina
• Guatemala City, Guatemala

See more locations on the map and register for a Google I/O Extended event in your area.

We look forward to having you join us for Google I/O Extended!

By Amy Walgenbach, Google I/O Team

Your Web, Half a Second Sooner

At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.

The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.

How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.

The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.

And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.

By Michael Kleber, Ads Latency Team

Best Practices for User Authentication

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:


Error=BadAuthentication
Info=InvalidSecondFactor


There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

Improving the security of Google APIs with SSL

We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.

Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.

Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.

This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.

Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.

If you have any questions or concerns about this change, please follow up in the forums of the API you are using.

By Adam Feldman, Google Developer Team

Last Call for Google I/O kicks off tomorrow at 9:00 A.M. PDT

As Vic announced last week, we will be kicking off our Last Call for Google I/O contest tomorrow. We will be starting promptly at 9:00 A.M. PDT on March 16th with our Android challenge. As a reminder, here’s the contest schedule again:

March 16 - Android, 9:00 am
March 17 - Chrome, 9:00 am
March 18 - App Engine, 9:00 am
March 21 - YouTube APIs, 9:00 am
March 22 - Game Developers, 9:00 am
March 23 - Google Maps / Geo, 4:00 pm
March 24 - Commerce, 9:00 am
March 25 - Developer Tools / GWT, 9:00 am
March 28 - Accessibility, 4:00 pm
March 29 - Google Apps / Enterprise, 4:00 pm

All times are listed in PDT

When you visit the site tomorrow morning, you will see a tab in the navigation that reads “Android”--that’s where you will find all of the questions and submission forms for Round I. We’re excited to see what everyone comes up with!

By Monica Tran, Google I/O Team

Making auth easier: OAuth 2.0 for Google APIs

One of the most exciting things about the architecture of the web is how easily it supports mashups—URLs, IFRAMEs, XHR, and more make it easy to build great new services on top of building blocks from others. As more and more people use the web for non-public data, we need new techniques to secure those building blocks. That’s where OAuth comes in—an open, standard way for users to grant permission for an application to access part of their account.

Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.

In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:


Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.

By Andrew Wansley, Google Developer Team

Finding success in the Chrome Web Store

Even though the Chrome Web Store launched in the US just a few months ago, some developers are already seeing great results. From games to productivity apps, the store has helped all kinds of web applications grow.

Our friends from World Golf Tour, Sliderocket, Wikinvest, Todo.ly and Springpad share their experiences with the Chrome Web Store through five brand new case studies. While each of these developers has a unique view point, some common themes have surfaced:

1. The Chrome Web Store can help you acquire more users really fast: For example for Todo.ly, users of the Chrome Web Store app account for more than 50% of the web site’s traffic.
   
2. Chrome Web Store users are very engaged with apps: Springpad and Wikinvest report that Chrome app users spend up to 100% more time interacting with the app, than a typical visitor spends on their regular website.
   
3. You can improve the monetization of your app through the Chrome Web Store: Premium apps like the World Golf Tour and Sliderocket report significantly higher conversion rates for Chrome app users than the rest of the user base and a growing percentage of business leads originating from the store respectively.
   
4. Posting your app in the store requires relatively little effort: The app publishing process in the store is smooth and required little to no custom work for all the developers, profiled in the case studies.
   

If you are interested in publishing your app in the Chrome Web Store or learning more about how the Chrome Web Store can help your business, explore our developer documentation and join us in our developer forum.

By Christos Apartoglou, Product Marketing

Last Call for Google I/O

For those of you who were quick to register, we thank you for continuing to support our developer initiatives -- this year's I/O is slated to be one of our best yet. For the rest of our developers, we weren’t kidding when we told you we <3 our developers.

Starting Wednesday, March 16, we will be launching Last Call for Google I/O: A contest that spans 10 days, 10 developer challenges and 100 chances to win tickets to attend the now-sold-out Google I/O 2011.

Here’s how it works. We will announce a new challenge on the contest site on select dates at either 9am or 4pm PDT, that will last for 24 hours each. There will be 10 days of challenges with 10 winners on each day, spanning the following developer products:

• March 16 - Android, 9:00 am
• March 17 - Chrome, 9:00 am
• March 18 - App Engine, 9:00 am
• March 21 - YouTube APIs, 9:00 am
• March 22 - Game Developers, 9:00 am
• March 23 - Google Maps / Geo, 4:00 pm
• March 24 - Commerce, 9:00 am
• March 25 - Developer Tools / GWT, 9:00 am
• March 28 - Accessibility, 4:00 pm
• March 29 - Google Apps / Enterprise, 4:00 pm

Each of the challenges will focus on one of our developer products and has two rounds. Plan to be in front of your computers for the first half-hour that the challenge starts to complete a series of questions for Round I, which will qualify you for the main coding challenge in Round II. You will have a little over 20hrs to complete Round II.

We want to make sure that we provide the opportunity to attend Google I/O to as many developers as possible and hope you’re feeling up to the task. The contest is valid in the 50 United States and the District of Columbia with winners being announced on April 4. And don’t forget that we will be livestreaming the keynotes and taping sessions during Google I/O. Stay tuned!

For more information and contest rules, visit the contest site.

By Vic Gundotra, VP Engineering

Join the League of Extraordinary #H4ckers at SXSW!

Heading to Austin, TX for South by Southwest (SXSW) this week? Good — so are we. And we’re planning what I hope will be a an event for the ages!

The festivities start at 1pm on March 13 with the opening of The League of Extraordinary Hackers followed by a very special SuperHappyDevHouse at 7pm at the Speakeasy on 412 Congress Ave in Austin.

Business by day, hacking by night

From 1pm to 6pm, we’ll be hosting a series of 15-minute rapid-fire API briefings focused on Google’s latest developer offerings including: Android, Chrome, HTML5, Blogger, Google TV, Google Maps, App Engine, YouTube, Web Fonts, Cellbots, and Fusion Tables. Immediately following each talk, the speakers will be holding court during office hours in Speakeasy’s open air rooftop lounge.

At the same time, we’ll be demoing Google TV and the YouTube Leanback experience in the Leanback Lounge on the second floor. And if you’re just looking for a place to chill, meet other Google developers, or grab free WiFi and juice for your devices, we’ve got you covered in that department as well.

Yes, this is one of our drink cards.

At 7pm, we’ll welcome the SuperHappyDevHouse community for a night of hacking, lightning talks, a LEGO^® MINDSTORMS^® sumobot competition (!), steampunkery, and Google TV and Xbox 360^® Kinect^™ tomfoolery. And if a soundtrack co-curated on Rdio weren’t enough to make your booty move, then come get loosened up with League-inspired elixirs concocted by Google’s own mixologist, Daniel “Gin not Vodka” Nadasi!

This event promises to be one-of-a-kind and a rare respite from the pure partying events at SXSW. Of course it wouldn’t be possible with a great cast of sponsors including Google, Windows Live, The LEGO Group, NPR, Sencha, Red Bull Creation, Twilio, and Rdio.

Get on the list and invite your friends

Since we’re managing attendees separately, the most important links you need are the ones that get you in (and get you free drinks!):

1. RSVP for The League of Extraordinary Hackers
   
2. RSVP for SHDH@SXSW
   

You can also find these events elsewhere:

1. The League of Extraordinary Hackers is on Facebook, Plancast, and Lanyrd
   
2. SHDH@SXSW is on Facebook, Plancast, and Lanyrd
   

Not attending SXSW? No worries — follow along with the #h4ckers hashtag on March 13.

Hope to see you there!

P.S. Make sure to follow @googlesxsw for updates during the show!

— Chris Messina, Developer Relations

Introducing the Google APIs Explorer

Google is always looking for new ways to make it easier for developers to get started with our APIs. When you come across a new Google API, you often want to try it out without investing too much time. With that in mind, we are happy to announce the Google APIs Explorer, an interactive tool that lets you easily try out Google APIs right from your browser. Today, the Explorer supports over a half dozen APIs – and we expect that number to grow rapidly over the coming weeks and months.

By selecting an API you want to explore, you can see all the available methods and parameters along with inline documentation. Just fill out the parameters for the method you want to try and click “Execute”. The Explorer composes the request, executes it, and displays the response in real time. For some APIs that access private data you will need to “Switch to Private Access” and authorize the Explorer to do so.

To get you started, here are some sample requests; follow the links and press “Execute”:

• Expand a goo.gl URL using the URL Shortener API
• Translate a phrase to French using the Translate API
• List your personal Buzz posts using the Buzz API (requires private access)

The Explorer makes it easier for developers to discover what APIs we offer and get started using them within minutes. If you have any questions or comments, visit the help page or the support forum. We’d love to hear your feedback.

Happy exploring!

By Anton Lopyrev and Jason Hall, Google Developer Team

Press Start: launching Google Game Developer Central

Today, the annual Game Developers Conference (GDC) officially kicks off in San Francisco. From browser technologies to cloud storage solutions, Google has many products and services that can be useful to game developers. Until now, it was hard for developers to track down information on how Google can help them build, distribute and monetize their games. This is why we are excited to release Google Game Developer Central.

Google Game Developer Central provides an overview of Google products and services that are particularly relevant to game developers. You’ll be able to explore different platforms like Chrome, learn about technologies such as GWT, WebGL and HTML5, and check out monetization options like AdMob.

This is just the first iteration of Google Game Developer Central. In the next few months, we plan to add additional content to make this an even better resource for all game developers. If you’d like to give us feedback on how to improve the site, please join our developer forum or for those of you at GDC, stop by our booth on the expo floor. We look forward to meeting you in person!

By Ian Ni-Lewis, Game Developer Relations Team