Minify the JavaScript (save time and money)
Are you guys loading both prototype and YUI into your feedback widget? I loaded up the javascript to find that your loading in a 8000+ lines of JavaScript. No wonder it takes so long to load.
Firstly for that tiny piece of code you don't really need a framework. But I appreciate you don't have much time, so why don't you minify the javascript (reducing it's size) pull in the frameworks from Google Code (saving you money in bandwidth) and just generally removing everything you don't need.
Firstly for that tiny piece of code you don't really need a framework. But I appreciate you don't have much time, so why don't you minify the javascript (reducing it's size) pull in the frameworks from Google Code (saving you money in bandwidth) and just generally removing everything you don't need.
5
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this under consideration.
-
Inappropriate?Thanks for the suggestions! It's important to note that the feedback widget is very dependent upon existing code that we have built up in Get Satisfaction proper. Things like login functions, error notifications, tooltips and positioning helpers are all leveraged in the JS used for the feedback widget. Those features that we developed are in the main javascript bundle for getsatisfaction and depend upon it, and separating them out would be a very hard task given the time constraints we were under.
For the record, I definitely think that we can improve our asset serving. We'll continually improve, and I appreciate your suggesstion.
Note, We only load the Connection portion of yui, to support ajax file uploading.
Now that the google ajax libraries API exists (It didn't when we built all of this), it makes more sense to use that for our libraries.
Minified code is hard to debug, in my experience, and we *always* have bugs. It makes more sense for us, as a small team, to optimize for developer productivity, at the expense of (in my experiments) 10-20 Kb saved for only one request (since we use long-lived client side cache).
---
In my perfect world, our stable, battle-tested code would get loaded off of a CDN, be minified and gzipped (where possible), and we would leverage google loader for our base framework. YUI would go away, as we redo the pages that have AJAX file uploads... since Flash 10 breaks flash uploaders, who knows if that will get fixed and we could use that as an alternative. As our site's features have less churn, we can start to separate code into fragments that each page leverages individually.
We're already moving in that direction for our CSS, and we'll get their eventually for our JS.
Thanks!
I’m confident
The company and 1 other person think
this is one of the best points
-
Inappropriate?Hi Scott,
Thanks for the detailed reply. It's great to know that you are planning on improving the JavaScript, and I understand how much pressure you are under to stay at the forefront of this type of technology.
meaning we have the full version on our local machines to debug.
Daniel -
Inappropriate?I second this.. The javascript being served up from s3.amazonaws.com has no expires header and is not minified. In addition, the images loaded by the script also have no expires header. This usually makes the clients browser download the javascript and images on every load of every page using the feedback widget.
I’m frustrated
Loading Profile...



EMPLOYEE
