Update. It seems that you can configure subversion to handle mime-types after all. I’m now serving all static content for this site from:

For popular libraries like Prototype and Dojo there is a huge benefit from serving cached and compressed JavaScript from Google’s servers.

I was looking for a way to speed up the delivery of this site by moving all static content to code.google.com . Unfortunately, all source material served from code.google.com is served with a mime-type of text-plain . Most browsers ignore CSS and images served with that mime-type. But they don’t ignore JavaScript.

Comments (49)

Leave a comment

Comment: #1 I recently switched jQuery over to using Amazon S3. I’m actually quite pleased with the results. It’s solved a lot of request and server issues that we’ve been having. For example: http://code.jquery.com/jquery-latest.js Granted, it’s not free, like Google could be, but $0.15/GB is an acceptable cost (IMO). Of course, if we could just get HGTV to stop hotlinking to jQuery directly then things wouldn’t be so bad to begin with

Comment: #2 @John – Dear God please don’t pay for hosting something that you already give away!! Move to Google quickly!

Comment: #3 You might try svn’s svn:mime-type: svn propset svn:mime-type “text/javascript” http://deanedwards.googlecode.com/svn/trunk/test.js

Comment: #4 […] Dean Edwards 最近好像很 high 的樣子，先是弄了一個 Javascript library 實做 Web Standards，現在又想要用 Google Code 提供的 Subversion Repository 惡搞：Using Google To Serve Faster JavaScript。 […]

Comment: #5 Can’t you just host your images/css/javascript on Google Pages and hotlink from there? (part of the google apps for your domain thingy)

Comment: #6 Luckily, most browsers support text/plain for JavaScript.

Comment: #7 @gslin – you’re right. I changed my subversion configuration. It seems mime-types are supported. Free hosting of static content for all!

Comment: #8 Dean, this is a great find, but I wouldn’t get too used to it. Not even Google has unlimited bandwidth — if enough people start doing this I’m sure they’ll “fix” it somehow. I’d love to have a single reliable place for Prototype that people can point their SCRIPT tags toward (like Yahoo does with YUI). I just don’t think this is that long-term solution.

Comment: #9 The Google Code Subversion server has been pretty slow, in my experience. Not sure that it would make a good candidate for serving static files…

Comment: #10 @Manuzhai – I’m using Google svn right now to serve CSS and images. It seems pretty fast to me. It was slow when google code was first launched but seems to have improved a lot. Whatever, it has to be faster than my server.

Comment: #11 Why not just use googlepages.com? I thought that allowed file uploading…

Comment: #12 @dean – I have to agree with Andrew. Google Code is too much of a wildcard; especially for something that demands a high level of availability and use. Although, I’m seriously considering it for some of my other projects. They don’t provide as much as SourceForge, but I trust them a lot more. I’m kind of surprised that you’re surprised that hosting is being paid for. $0.15/gb is a drop in the bucket for level of availability and reliability that S3 provides. The latency isn’t as low as I would’ve liked, but higher levels would be significantly more expensive. Plus, it’s something that’s easy to programmatically access (which makes for easy nightly update cronjobs). I’m also in the process of offloading the jQuery mailing list to Google Groups. Again, it’s an imperfect solution (I would’ve preferred a forum/mailing list solution that we host ourselves), but it’s one that saves us from sending our current 4.5m emails/month. I contacted the OSUOSL a while back, but they didn’t have any more space available; maybe their situation has changed. I sure would love to have people, who know what they’re doing, manage the site. I only play a sysadmin on tv.

Comment: #13 I was worried as to what http://deanedwards.googlecode.com/svn/trunk/images/nad-photo.jpeg was but it turns out to be entirely innocent I shall be interested to see if Google mind code.google being used as an edge cache. Personally, I think you’re right and John’s being far too kind not only running the jQ team but also paying for the privilege, but hey. Gives me an excuse to donate

Comment: #14 @John – I’m going to persist with google code for a while and see how it performs. If it starts crapping out then I suppose I’ll switch to Amazon too. The thing is, we can’t really move major JS libraries to somewhere that requires payment. That was the problem I was trying to solve here. I assumed that google code servers were as reliable as the rest of their servers. Comments here are starting to persuade me otherwise. We shall see…

Comment: #15 @dean – That’s understandable, Dojo has AOL, Prototype has 37 Signals, Yahoo! UI has… Yahoo. I guess this is why services like OSUOSL exist, so open source projects don’t have to worry about this sort of thing – without taking direct corporate sponsorship. The biggest issue for us isn’t the amount of bandwidth (we have tons), money (donations cover everything), nor servers (we’ve got plenty), it’s just that JavaScript Library development doesn’t attract server side developers who are interested in contributing sysadmin skills to the project. It’s basically just me. I mean, it’s fine if there’s a flux of JavaScript developers to the project, since the project itself breeds more developers who can help – not so with CMS projects (for example). I’m not sure if that issue is unique to jQuery, or if its a larger issue amongst open source projects. (Although, there aren’t many purely-open-source JavaScript projects that don’t have Corporate sponsorship. Mootools, Mochikit?)

Comment: #16 Would really be great if a big cooperation like google would host various versions and configurations of javascript libs. I dont think this would cost that much, 2 or 3 server with a tera bandwith or something. Great way to sponsor open source javascript community

Comment: #17 Google Code isn’t made for this use, and it’s probably not something Google wants you to do.

Comment: #18 Yes I have often wondered why no one has stepped up to host all the javascript libraries. I know there is huge bandwidth requirements, but someone like Google could do it with little effort I imagine. It would benefit the internet greatly I think if we could point to one location for the same libraries everyone already uses on all their projects. With proper caching, in time this would end up saving network traffic for many servers across the internet. Anyone at Google reading this? Take it on as your personal project

Comment: #19 @sil – It’s alright, it doesn’t feel right taking in donations and not feeding it back into the project. Right now, that money has just been going to paying for servers, bandwidth – and the “jQuery Button Contest”. @pplante – I’ve been talking with a number of people (at Google, at Mozilla) and the idea definitely seems to have legs. I’ll have to keep running the idea around until it sticks with someone and they take it somewhere. I imagine that someone will provide generic hosting for JavaScript libraries, at some point; just not sure who it is or when it will be. I’ll write a blog post concerning this and see if I can find someone who’s willing to help all of us.

Comment: #20 @John, the bigger problem is not who will host the files but how to fall back if the primary host is not available. This is a hard problem. If it can be solved to everyone’s satisfaction then we might see the beginning of centrally-hosted JavaScript libraries. That’s what I am researching right now.

Comment: #21 @John/sil – I’m mostly thinking about the user’s experience. If everyone ends up with a cached version of Prototype/jQuery/YUI/Dojo on their hard disk then web apps will load with a snap that they currently lack.

Comment: #22 @dean – Sure thing – I mean, Dojo and Yahoo already have source files that you can hotlink directly from your site, and they’re hosted on massive backbones that can handle anything you throw at them (and they expect you to). For that reason, Dojo and Yahoo already have those solutions available, and ready (making the user experience really good). As far as I know, Prototype, Mochikit, and Mootools all don’t have a single point that you can host your code from. I’m content to stick with S3; it can handle any number of hits that are thrown at it, and since jQuery is so small, we can serve about 55k requests for about $0.15. I’m about ready to promote the code.jquery.com URL as a definitive source of hotlinking, for jQuery. I don’t think the important thing is centralization, so much as it’s important that there’s a definitive URL for hotlinking the source code from. Having a location to load the source from tends to show the level of dedication and strength of the open source projects associated with it. All of that being said, having a centralized host for JavaScript libraries certainly can’t hurt.

Comment: #23 That’s cool) Bandwitch problem solved by #1 internet company.

Comment: #24 @john I think that is something people would pay for it. Free would be nice, but paying a small amount wouldn’t be a big problem…

Comment: #25 […] Dean Edwards пропонує використовувати серверні потужності Google (code.google.com) для розміщення статичного контенту сайту (наприклад CSS, JavaScript, зображення): Using Google To Serve Faster JavaScript. При цьому можливе збільшення швидкості роботи сайту. […]

Comment: #26 I once asked Google if I could use their Google Code repository to serve static content (and, accidentally, also run into the mime type problem:), but they asked me not to do that. Link: http://groups.google.com/group/google-code-hosting/browse_thread/thread/ba5aa573df2ac949/a00545c1612e1598

Comment: #27 @Michal – I just got an email from Google saying that I could use their SVN repositories to serve my JavaScript library. You are probably right about hosting images and the like though. I should probably stop doing that.

Comment: #28 […] Using Google (Code) To Serve Faster JavaScript a way to speed up the delivery of this site by moving all static content to code.google.com. (tags: Google_Code Website_Ideas JavaScript) […]

Comment: #29 I believe this has potential and have therefore registered http://code.google.com/p/framework/ on Google Code for the purpose. The main issue (also mentioned here) is concerns with server-up-time. It would be perfect if we could come up with a fall-back solution. Also it should be discussed what kind of update cycles should be used. Currently, I am suggesting a third-digit version number auto-update that is defined by always being backward compatible – see more at the url above. In addition to the issues discussed here this project could need more clarification, and possibly wiki descriptions of each framework. Contact me at my gmail address “mostly” if interested in joining.

Comment: #30 Been doing this for a few months now with a little widget I created. Details here: http://myspacecivilized.blogspot.com/2006/11/myspace-95-thesis-widget.html I noticed stylesheets failed when I tried adding them into the mix — which is how I ended up here. Thanks for the tip on mime-typing.

Comment: #31 Dean: is it an idea to start using tags in subversion for a release. In that way, I could directly link in base2 in my code, without worrying if newer versions break my code.

Comment: #32 @Doeke – yes, I’ll do this eventually. base2.DOM is still not officially released (although it is not far away).

Comment: #33 I had no idea you could that! Very cool idea, I think they should allow a certain amount of static hosting, heck they have google pages now, and they already cache all of my content, so why not a little payback? Doesn’t everyone want be your static content host now, ie youtube, flickr, etc anyway..

Comment: #34 Netradiční způsob využití Google Co takhle použít Google jako server pro JS knihovny?

Comment: #35 I tried to write down what I think about it. Hope it helps.

Comment: #36 If this (pretty good) idea makes it to the masses, Google will noticeable get slower – what will they do? Will they stop it… or will they sell your code

Comment: #37 […] Update: I’m not the first to think this, apparently. Dean Edwards played around with making code.google.com serve up some static content, and the comments there confirm that others think this would be a great idea. So what about it, Google? Can you spare some change? […]

Comment: #38 lol… I thought of the same thing today, posted about it: http://www.tallent.us/blog/?p=7 …and then found this blog. Google really could step up here, and all that is needed is static hosting and *very* high expiration dates. Using folders for version numbers removes the compatibility issues of “myapp-latest.*” and the need for short-term expire headers. I just started using Ext JS, and it’s beautiful, but HUGE. Same thing with TinyMCE and the dozens of famfamfam silk icons I use. As Dean said, this is about the user experience: web apps being able to “share” the browser cache is a very good thing, and hosting on another domain offers HTTP pipelining benefits (more parallel connections from the user’s browser). With proper expiration headers, the actual bandwidth cost is minimal, or at least scales as a function of *users*, not as a function of the number of applications.

Comment: #39 […] Dean Edwards: Using Google To Serve Faster JavaScript – For popular libraries like Prototype and Dojo there is a huge benefit from serving cached and compressed JavaScript from Google?s servers. […]

Comment: #40 There have been some suggestions of using Google Pages. Unfortunately for me (and probably some others) is that Google Pages is blocked where I work. Anytime there is a link to a Google Pages page, I can’t visit it. I can’t even access hosting companies websites, (including the one we are hosted with). The host I use for my own site got through the filters though (it isn’t a major host though).

Comment: #41 secure sites would need the content coming from Google Code to be through https. I’m not sure it offers this at the moment.

Comment: #42 @rainer – I don’t agree that the hosting performance will deteriorate as more developers host their projects with them. It is obvious that Google already know what to expect and have good scalability plans even before Google Code is opened to public. This is something I have read from http://blogoscoped.com/archive/2006-07-27-n89.html Google claims their hosting service is “simple, fast, reliable and scalable,” but also admits: Google Code will have lots of key features at launch, but we may not have all features you want or need for your project. Rather than try to offer every possible feature, we have focused on doing the most important things really well. More features will be added over time, but only when they are ready. However, we will not offer the following any time soon: shell accounts, build farm, private projects, nested projects, or multiple alternatives for each type of hosted tool. I guess this is something we should be happy for, irregardless of whether it is for hosting projects or static contents like images/other files. Even paying a small fee is totally fine with me. @Sam – yes googlepages has been blocked in some country as well as several ISPs/hosts/companies. Some even block them as personal…

Comment: #43 Guys, We will soon start hosting JS libraries on a central location: It will solve both the bandwith problem and caching problem. Expect a launch in less than a week – sign up to be notified at http://www.hosted-js.com Meanwhile you can write out what libraries you think should get hosted

Comment: #44 My suggestions: 1. Serve images via Flickr 2. Serve css / javascript via Googlepage

Comment: #45 While I’d love to be able to leverage Google’s bandwidth and the increase in simultaneous http requests to my client’s browsers, I still prefer the security of knowing where my data is (and having the only key). Can you imagine the potential damage/disaster that could come about with a code breach? Think about it. We’re talking about libraries that allow you to tie into each and every xmlhttp request… heck, every form for that matter as well. Form.extend(“submit”, ccPostToEvilURL()). How many websites use these libraries? Instead of tricking one or two users into revealing their passwords, they can now grab an entire website. A compromised Prototype, for example, even for a few minutes, could still mean potentially millions of megs of hijacked data. Give or take an order of magnitude. I just started using Ext JS, and it’s beautiful, but HUGE. Same thing with TinyMCE and the dozens of famfamfam silk icons I use. Shameless plug: I’m a big fan of the famfamfam silk icons, too. I made a reasonably cross-browser-friendly way to tile the entire icon set so you can drop icons into your HTML with happy-friendly classNames. Like this: <span class=”icon-application_xp”/> I say “reasonably” cross-browser friendly because of IE’s notorious stupidity regarding PNGs. While you can’t use background-position with their DirectX filter, you can put the image on a separate layer and then position that. Then it’s just a matter of writing the batch to generate the offsets! Anyway, if you use them anywhere near as much as I do, you’ll appreciate having them all in one place.

Comment: #46 I doubt google will let a lot of high traffic sites use their google apps for serving js … but then again …

Comment: #47 […] 直接使用以上這兩個連結合法嗎? ) update: 有興趣可以看 gslin長輩 提供的討論連結 老實說, 這兩個比不上 Google AJAX lib API 提供的, 前者用 AmazonS3 只有 ETAG , […]

Comment: #48 […] Dean Edwards: Using Google To Serve Faster JavaScript Tags: js javascript jquery google fast […]

Comment: #49 You shouldn’t use Google Code for this when you can use Google Libraries. They have commonly used javascript (like jQuery) and you can use the API to request specific versions. It’s much easier to set up If you want to server static files like images through Google’s network you can use Google App Engine.

Comments are closed.