3 ms·

Please forgive me, but I'll use this post to ask a question I've been wondering for a while. Is it better to use a minified js/css of all pages of the website o

by phzbOx 15y ago

Please forgive me, but I'll use this post to ask a question I've been wondering for a while. Is it better to use a minified js/css of all pages of the website or to make each pages as minimal as possible? For instance, if I use 4 jquery plugins on a splash page, 2 jquery plugins in the "signup" part and 5 other jquery plugins a little bit everywhere.. should I bundle all these plugins into one big .js, minified it and put it on the splash page so that it is cached?

zecho 15y ago
jQuery is modular. You can minify the plugins. For the sake of maintenance, clarity and speed of your documents, I think it's best to use plugins only as needed.
exogen 15y ago
It is probably best to bundle all of your application code and plugins into one big JavaScript file, while loading jQuery itself from one of the CDNs (and excluding it from the bundle). I think it's only when this bundle file gets massive or initial page load time is critical that it makes sense to load individual modules on-demand. When your application gets so big that it uses a dozen plugins and a dozen of its own files, the HTTP requests caused my loading them individually will start to hurt.
cheald 15y ago
I'm a fan of the "package once, use everywhere" approach. Clients will use exactly 1 HTTP connection to download exactly 1 gzipped file, which is then cached and recalled from the cache for every subsequent pageview. HTTP overhead is significant! Furthermore, if you have everything in one scope, a Javascript minifier is going to be able to crunch it down significantly more than it could if you have a bunch of separate files in separate scopes. What you want to avoid doing is executing a ton of JS in the top-level scope. JQuery plugins are great examples here, because they are often function definitions which require parsing, but are not executed until invoked. If you're worried about how much code you're executing per page, you can segment it by creating functions for your individual pages, and then calling the appropriate function on document.ready. If you end up with 3MB of JS/CSS, then that's probably something that needs to be split up, but for a lot of use cases, combined is just fine. When in doubt, test it on a smartphone over a mobile data connection and see how it feels.
FuzzyDunlop 15y ago
It depends on how big it all is when it comes together. For example, you'll have 7 plugins (and associated code that runs them) that won't be used at all on the splash screen. That's going to increase load-time when someone hits that page. If someone hits a page direct and avoids the splash screen, it's not going to be cached in the first place so it'll all be loaded. Only this time they're loading 4 plugins and the related code that won't even be used. IMO you should compress what's needed for each page. Several smaller downloads is often better than one large download, and you shouldn't be relying on a user's cache to gauge your own site's performance. If you're not going to use it, don't include it.

by phzbOx 15y ago

zecho 15y ago

jQuery is modular. You can minify the plugins. For the sake of maintenance, clarity and speed of your documents, I think it's best to use plugins only as needed.

exogen 15y ago

It is probably best to bundle all of your application code and plugins into one big JavaScript file, while loading jQuery itself from one of the CDNs (and excluding it from the bundle). I think it's only when this bundle file gets massive or initial page load time is critical that it makes sense to load individual modules on-demand. When your application gets so big that it uses a dozen plugins and a dozen of its own files, the HTTP requests caused my loading them individually will start to hurt.

cheald 15y ago

I'm a fan of the "package once, use everywhere" approach. Clients will use exactly 1 HTTP connection to download exactly 1 gzipped file, which is then cached and recalled from the cache for every subsequent pageview. HTTP overhead is significant! Furthermore, if you have everything in one scope, a Javascript minifier is going to be able to crunch it down significantly more than it could if you have a bunch of separate files in separate scopes. What you want to avoid doing is executing a ton of JS in the top-level scope. JQuery plugins are great examples here, because they are often function definitions which require parsing, but are not executed until invoked. If you're worried about how much code you're executing per page, you can segment it by creating functions for your individual pages, and then calling the appropriate function on document.ready. If you end up with 3MB of JS/CSS, then that's probably something that needs to be split up, but for a lot of use cases, combined is just fine. When in doubt, test it on a smartphone over a mobile data connection and see how it feels.

FuzzyDunlop 15y ago

It depends on how big it all is when it comes together. For example, you'll have 7 plugins (and associated code that runs them) that won't be used at all on the splash screen. That's going to increase load-time when someone hits that page. If someone hits a page direct and avoids the splash screen, it's not going to be cached in the first place so it'll all be loaded. Only this time they're loading 4 plugins and the related code that won't even be used. IMO you should compress what's needed for each page. Several smaller downloads is often better than one large download, and you shouldn't be relying on a user's cache to gauge your own site's performance. If you're not going to use it, don't include it.