Latency Tips for Orkut--Orkut-specific techniques

Prefetch data from orkut:

The orkut team has implemented a "pre-fetcher" that will analyze your app and attempt to load the data you need at the same time it's rendering the container page, so when your app sends a DataRequest, the response is almost instantaneous. To get the most out of this feature, follow these guidelines:

Do request data that you will always or nearly always need, even if it's not needed immediately on loading your gadget.
Do batch up multiple request items into one DataRequest.
Don't request data you don't need.
Don't add newUpdatePersonAppDataRequest to your first DataRequest.
Don't call opensocial.requestCreateActivity before sending your first DataRequest.

Preload data from your server:

If your application uses a makeRequest call to fetch data from a third party server, chances are that you've written something similar to:

function request()

{

var params = [];
....
gadgets.io.makeRequest("http://www.example.com/content.html", response, params);

};

gadgets.util.registerOnLoadHandler(request);

While this code is syntactically correct, it isn't very efficient at loading data. Users of your application will need to:

1. Wait for orkut to render your application IFrame.
2. Wait for the IFrame to finish loading so the OnLoadHandler methods will execute
3. Wait for the makeRequest call to return data from your server.

During this time, a slow application will show a loading animation in the best case, or nothing at all in the worst. To address this, orkut will offer additional syntax for preloading content from a makeRequest call while the gadget is being rendered. This feature is enabled through the addition of an extra parameter in your ModulePrefs. If your makeRequest call looks like:

var params = {};

params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.JSON;

gadgets.io.makeRequest("http://www.example.com", response, params);

You can cache the request by adding a tag:

When your application IFrame loads, you will see something similar to the following embedded in the source:

gadgets.io.preloaded_ = {"http://www.example.com":{"body":"...","rc":200}};

Where "..." is the content that exists at http://www.example.com. When your application executes the makeRequest call, this content will be returned instantly, without needing to hit your server again. Signed request calls can take advantage of preloads with a slight change to the preload syntax. If your signed request code looks like:

var params = {};

params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.JSON;

params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;

gadgets.io.makeRequest("http://www.example.com", response, params);

The corresponding preload code you should use is:

There are a few more optimizations you can use to make preloads work even better:

1. Turn off sending the viewer in signed requests. If you don't need the VIEWER ID for your signed
request, disable it by adding signViewer="false" to your tag. This will allow orkut to cache your
request for a lot more requests. This is a critical improvement for profile pages!

2. Use multiple tags if you have more than one request. You're not limited to one tag, so preload whatever you can.

3. Restrict preloads to the correct view. If you only use a certain request in a specific view, restrict
the preload to that view by adding a views attribute to your tag. For example, to restrict a
preload to the canvas view, add views="canvas" to your tag. You can also specify multiple comma
separated views, like views="canvas,profile".

What are the benefits? Users no longer need to wait for your application to finish loading on orkut before
executing a makeRequest call. Orkut will make the request and insert the response directly into the
application as it renders your application.

Cache your static content

Orkut will now rewrite the appropriate href or src attributes on HTML elements to take advantage of the
caching proxy, meaning that all non-dynamic references to remote content will automatically get the
benefit of caching.

If your source contains an image tag which looks like:

" "


Orkut will render the image tag as:

" "

What are the benefits? Users no longer need to wait for your application to finish loading on orkut before
executing a makeRequest call. Orkut will make the request and insert the response directly into
the application as it renders your application.

Cache your static content

Orkut will now rewrite the appropriate href or src attributes on HTML elements to take advantage of the
caching proxy, meaning that all non-dynamic references to remote content will automatically get the benefit
of caching.

If your source contains an image tag which looks like:

Orkut will render the image tag as:

Any HTML fetched using makeRequest or otherwise passed through the proxy will also have its links rewritten
in this manner. Caching is now automatic throughout your entire application.


However, caching can make development difficult, so if you really need to disable this automatic rewriting,
you can use the following code inside the section of your gadget spec:NONE

Keep in mind that this should only be used to help develop your application. Your production apps should not
rely on this feature!

What are the benefits? This approach can dramatically reduce the load on your server for image, CSS, and
JavaScript resources that are directly included in your application source, without you needing to
change any code at all.

Note: Orkut's rewriting is currently not compatible with the element. If you use the element to use relative
paths in your application, you will need to change your code to use fully-qualified URLs.