How do Facebook, Google and other large applications do their CSS and JavaScript files?

Question

Facebook: http://static.ak.fbcdn.net/rsrc.php/v1/yh/r/u2OL99TwlfU.css
Google: http://ssl.gstatic.com/gb/js/sem_cf9545d69b4bd3d22ed10206010c8b23.js

There are other

Answer 1

Facebook and Google both use a md5 suffix in their static resource file name.

First, it's a general optimization for performance, we can versioning a static resource use the md5 of its file content (after minification) and set the cache-control = 10 years (nginx or apache). If you press forward/back button on your browser or view the page second time, the file will be retrieved from your local disk, not through the network (except you press the reload button, there will be a 304).

Second, when you publish code online, you can first push all static resource, they will not conflict with old ones. And then you push all server-side code, all user will not have error access to your page.

Answer 2

(I am the original author of rsrc.php and Facebook's Haste static resource management system.)

You can find a description of some of the challenges Facebook encountered with static resource management and how it solved them here, in the Phabricator documentation:

https://secure.phabricator.com/book/phabflavor/article/soon_static_resources/

To the specific question, the rsrc.php URIs are like that (with "rsrc.php" in them) specifically because we didn't have a global Apache rewrite rule in 2007 when I wrote rsrc.php and adding, deploying and testing one for some more elegant URI didn't seem worth bothering with (in PHP, you can read the remainder of the URI after the "x.php" file part at runtime). So that part is just a PHP implementation artifact.

The other path components have been used for various things over the years, like an emergency version number we can bump globally to break everyone's caches if something goes wrong with the cache pipeline, a hash checksum so we can distinguish between valid and garbage requests for logging, internal flags which alter the cache policy of the returned resource for development, and flavors of a resource (e.g., tailored to a specific browser or localized to a specific language).