Introducing SymPullCDN: Getting Free Bandwidth From Google

That’s an excellent question. While I thought of this solution as well, I choose not to use it. Here are three key reasons I choose to do it this way instead:

Speed

While it can be argued that serving the files statically will cause an increase in speed, due to the script itself not being loaded, this is questionable. Google does not do 304 negotiations, and uses cache-control: no-cache when serving static files. These default settings will increase the amount of requests sent to GAE, and cause the browser to do more work, and handle more bandwidth for any user who loads a page more than once. My solution supports 304 negotiations on both sides of the cache.

Control

Serving the files statically gives up control of the HTTP headers. SymPullCDN forwards all headers from the origin. By using the static file handlers you give up the ability to control some important headers, such as Cache-Control and Expires.

Usability

I’m using SymPullCDN side-by-side with wordpress. It’s caching files from my origin, and wordpress is sending all requests for /wp-include/, /wp-content/, and /s/ (static files) to SymPullCDN. If I change the template, add static files to the site, or do anything else (installing plugins, for instance) I don’t want to have to investigate which files are in my origin that are not on the cache side, download them to my laptop and upload them to google. Having the cache downloading from my origin is a crucial usability issue for me.

At the end of the day, this is something I wrote for myself, to meet the needs I have; however, I feel others might find useful, so I released it to GitHub and did a little write up about it.

I know from experience that image delivery times are significantly reduced using the get_serving_url method, so it could be a killer feature.

The hard bit will be that the cdn distributed URLs are not guessable, so you would need to communicate the cdn URL back to the app.