Oliver Nassar

I can be reached at onassar@gmail.com.

For my open source work, check out github.com/onassar


Facebook REALLY loves caching static content (css)

View more posts

I've been working on a pretty simple Facebook tab/app. It doesn't do anything fancy really. You click on the tab for a page. If you haven't yet "liked" it, you see some static content. If you have liked it, again, static content, but with a form.

Doesn't sound hard, but Facebook makes it really difficult to test. They cache your CSS hard. Here's the process and how I got around it.

First of all, was storing the css/images on S3. So I had to upload everything.

Now the way the Facebook App works is you specify a URL and when people hit the tab, FB curls (or whatever) the url you specified in the settings, and grabs the content. But you can have at most two external stylesheets, and you can't have any body/head tags in the content you're serving.

The caching issue is as follows. Lets say the address to the CSS was something like s3.amazonaws.com/styles.css.

The first time FB encounters that, they'll grab it and serve it through a proxy on their servers. But now you need to change some CSS. You'd think you could just make some changes locally, upload to S3, and refresh. But FB seems to be caching the static css based on the path that it's requesting. So it'll run into that style sheet, and load it either from their db locally or their load balancer caches or something.

The way around this, that took me way too long to figure out, was to append a string to the css file (eg. style-2.css). Then change my code to reference that.

The same goes for images. No image can be modified under the same name. Maybe FB times-out and after x hours re-requests it to see if any changes have been made, but that's not really practical for testing.

It's a rad platform, but stupidly-difficult to get simple things working. Conforming to their intricacies is very frustrating to say the least.

Hopefully that saves someone some time.