121–130 of 130 posts
What about services like npm that distribute code? Are these analogous or do they have additional security in place?
Isn't that server side?
Likely culprits are "performance analyzers" that grade a website and report an "F" (failing) grade for not using CDN-hosted common libraries. This is a red herring: this idea that the user will already have a cached copy of CDN-hosted jQuery is bogus. Even for a common library like jQuery: the number of versions of jQuery that are in use is likely above 50, and the number of popular CDNs that host jQuery is surely ab…
> These days using them is pretty much pointless and incurs a performance penalty, yet everybody still uses them. Would you rather than when (e.g.) there is a security patch for OpenSSL, that you have to wait for all software using OpenSSL to deploy updates? Or would you rather that one update to OpenSSL (likely from your OS vendor) fixes all of the software depending on it? Edit: People seem to be commenting to this…
Would you rather that a compromised jquery.js at affect a huge number of sites? ;)
Likely culprits are "performance analyzers" that grade a website and report an "F" (failing) grade for not using CDN-hosted common libraries. This is a red herring: this idea that the user will already have a cached copy of CDN-hosted jQuery is bogus. Even for a common library like jQuery: the number of versions of jQuery that are in use is likely above 50, and the number of popular CDNs that host jQuery is surely ab…
How would the closure compiler figure out what bits and pieces of the library are triggered from the html portion of the site? (I can see how it can track the javascript bits but unless your site is entirely generated from js you'd have to start with the html)
Earlier quoted context omitted.
Can you please elaborate how using share libraries is "pretty much pointless and incurs a performance penalty"? That goes against my intuition of how they work.
Think it means that most machines are not memory or disk constrained these days, but there is extra processing to perform the dynamic linking. Sort of a cost-benefit argument it seems. Doesn't address the issue of security etc and the benefit of just having 1 instance of a library to update when maintaining a complete system however.
The extra processing is more significant than most people think. The library has to be compiled as relocatable code, which incurs a runtime performance penalty. You also lose a register, which especially on register-constrained architectures is really bad (it was a tragedy on iA32, it's less of an issue now).
Likely culprits are "performance analyzers" that grade a website and report an "F" (failing) grade for not using CDN-hosted common libraries. This is a red herring: this idea that the user will already have a cached copy of CDN-hosted jQuery is bogus. Even for a common library like jQuery: the number of versions of jQuery that are in use is likely above 50, and the number of popular CDNs that host jQuery is surely ab…
Minifying your JS and CSS files is a very good practice as it's not only secure, but also is compact. Grunt is a very powerful tool that does this.
Earlier quoted context omitted.
You annotate methods in Google-JS-Closure with @public, @protected, and @private in comments. Public methods get unmangled symbols. Everything else gets renamed to a short name to save bandwidth. Dependencies are specified with goog.require. Anything that doesn't get required with goog.require or isn't called by a public function gets culled.
While your integrating Closure Compiler's Advanced Mode, you might as well re-write your entire client side code... Because you'll likely have to.
People who write ClojureScript regularly encounter this: we get this optimized and trimmed down app, and then something needs jQuery, so we have to pull all of it in. After you've used advanced compilation for a while, it feels downright dirty and wasteful to pull in entire blobs of code, not just the function trees you actually need.
Earlier quoted context omitted.
It's maybe overkill to do it on the whole set instead of just a sample, probably the numbers would not change all that much. The 200/20 is indeed 200 Mbps down and 20 up, this little trick saturated the line pretty good though. I probably could have saved some time and bandwidth by letting phantomjs abort on image content but I was lazy.
I'm slap bang in the commuter belt round London - and broadband availability is having an actual effect on house prices and decisions to move out of the area. It's surprisingly low on the political agenda nationwide. I'm about to get all English Middle class over this Sinai will stop now :-)
This is very interesting. Will you release the data and code at some point?
Earlier quoted context omitted.
It is pretty standard practice to host assets on a "cookieless" domain you control, but not on the same domain as the original site. For example, www.example.com has all the html, but all of the images are hosted at www.images-example.com. That would skew the results considerably.
Why use another domain and not a sub-domain? I assume something to do with the cookie-less comment - but not clear what?
It seems like you're marking sites down for using a cookiless domain for resources, even though that's faster and no less secure? For example, you'd mark google down for referencing gstatic.com or facebook down for referencing fbcdn.com. I realize there's no publicly available way to tell that yahoo.com and yimg.com are the same entity, but it would be good to at least note this as an issue with the analysis.
I'll do so. Edit: done.