DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> UsageNotes/Images - Facebook Developers Wiki

UsageNotes/Images

From Facebook Developers Wiki

Jump to: navigation, search

Contents

[edit] Images

Facebook Platform handles img tags in a special manner. When publishing a page, Facebook servers request any image URLs and then serves these images, rewriting the src attribute of all img tags using a *.facebook.com domain. This protects the privacy of Facebook's users and allows them to better control the quality of service of their images.

Note: The src attribute of img tags must be an absolute URL from your domain, not a URL from the Facebook domain.

Facebook's cache of images displays a blank image if there is a problem. You can request your image be recached by using facebook.fbml.refreshImgSrc('imgURL').

[edit] More Details about the Facebook Image Cache

There are several reasons for the existence of the image cache:

  • We need a way to ensure some degree of quality and uniformity in the images displayed on users' profiles (no animated images, no 50 MB images, etc.)
  • We need to protect users' privacy and not allow malicious applications to extract information from image requests made directly from a viewing user's browser
  • Probably most important to you, the image cache shields developers from the potentially enormous load of serving these images, putting the burden on Facebook's resources instead

The way the image cache works is that at the time you publish FBML to Facebook through pertinent API methods (such as profile.setFBML, notifications.send, and feed.publishActionOfUser), the Facebook servers parse the FBML for images to be displayed and then immediately fetch those images from your server, caching them for display. Subsequent FBML method calls that refer to the same image do not require that the image get fetched and cached again. As long as that image is viewed by users in a certain range of time, it stays in our cache. If, after a certain amount of time, an image does not appear to be used or referenced anymore, then the image may fall out of cache, but it will get refetched and recached if it ever needs to be displayed again. We designed the caching system so that it's as seamless and painless for you to use -- many developers aren't even aware that their images are being cached at all.

The main issues with the image cache almost all arise in that first step -- when the image is being fetched from your server. If that request fails for whatever reason (the request times out, your server is unavailable, the target image source does not exist, or does not exist yet, etc.), then the Facebook servers cache an empty image. If that occurs, Facebook servers try to fetch the image three more times over a window of time in case the root cause was just temporary. If you detect that the image did not get cached correctly (for example, you or one of your users notice that a blank spacer.gif image appears in the profile instead), you can manually force a recache of the image by using fbml.refreshImgSrc.

This method is also useful if there is an image on users' profiles that needs to change -- rather than generate and track a new image location, you need only update the old image on your server, and then call this method.

Note: Facebook image caching doesn't support the .ico image format. It will replace any such images with an empty .gif spacer. You will need to convert the .ico to .png, .gif, or .jpg.

[edit] Putting Cachebreakers in the URL

When encountering issues with the image cache, some developers choose to just republish the FBML, with a random GET string at the end of each image source URL, which causes the Facebook servers to treat it as a new image and consequently do a new fetch. While this appears to solve the issues, this actually does several detrimental things:

  • If many of your FBML method calls use the same image, like a standard button or logo on all of your users' profiles, then the random string prevents multiple users' profiles from sharing that same image. Instead, since each user's profile has a separate copy of that image, you actually increase the likelihood that some of those images don't get cached successfully, and it is much harder for you to ensure a uniform experience for your users. It is almost impossible for you to track down which users are having problems, if every one of them has a different base set of images. By contrast, if all those users' profiles used the same image source, then that image just needs to be cached successfully once and never needs to get cached again to display correctly.
  • If your application updates images frequently, updating the image source and then passing a random GET string at the end is one way to force a refetch, but it does not degenerate gracefully -- if the new image does not get cached successfully, then the user will be left with a blank spot where the image should be. In contrast, if you publish FBML with the same image source as before, and then follow that call with a call to fbml.refreshImgSrc, then if the image doesn't get recached successfully, it will at least fall back to the old image.
  • It causes Facebook to potentially cache many, possibly millions of, copies of the same image, which fills our image cache, increases network traffic between our servers and yours as we refetch the image each time, and generally hinders our ability to help serve you better.

In short, please don't append these "cachebreaker" strings to the end of your image source strings. We will continue to work on improving the robustness and quality of service of our image cache and finding better ways to ensure that your images are displayed correctly.

[edit] Getting More Help

If you have any questions on this article, or if you are having other issues with the cache, please submit a bug at http://bugs.developers.facebook.com/.