• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Linking to so many jquery plugins

 
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

Jquery plugins are everywhere.. Including them in my JSP is just a snap.

But as I look at my head tag, there are lots of JS/CSS that were link.
I am not sure but, is there a rule of thumb on the number of plugins that you
could link.
I am quite afraid that this would burden the user's browser?
They add a lot in terms of user experience though so I am a bit hesitant in removing them

Some plugins are ajax enabled. Some are not so I would say that those where ajax is not enabled
wont add burden at the server side.

Currently, I used Jquery UI plus tons of other plugins. (Form Plugin/Grid/Tablesorter/Mask Edit/Validator/etc..).


Is there a rule of thumb regarding this?

P.S. I am not sure if my concern is really valid but I just would like to hear others opinion.

Thanks.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chrome has some great tools for seeing how long resources are taking to dowload.
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The best answer is to follow typical web app guidelines: minimize the number and size of downloads, and if they're cacheable, make sure they're actually cacheable.

There are any number of ways to do all this, but on productions sites, JS and CSS can be minimized, can be sent zipped (as can the rest of the content), and so on.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

JS and CSS can be minimized, can be sent zipped



Ahh yes, I saw that in jquery files where every plugin has minified versions.

But I was thinking, the file size might be less but the amount of HTTP request remains the same since browser still needs to fetch all the
required files.

I was thinking (I know this might sound silly?? ) , what if I merge the other js file into the other js file? Form Plugin mixed up with Validator Plugin and the
like??

And thanks again David.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you perhaps suffering from premature optimization?
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

mark wrote:what if I merge the other js file into the other js file

David Newton wrote:The best answer is to follow typical web app guidelines: minimize the number and size of downloads [...]


That's what I said :)

But as Bear hints--do you actually have any performance issues?
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is in my main layout file.



This does not include scripts I pull in on a page by page basis. I don't seem to have any performance issues.
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Too many! :p

For development and low-usage website that's probably okay (although I'd still avoid it-it'd cause a browser to block a few times unless they're getting good bandwidth and could delay initial rendering, no?) but this would never fly on a high-volume site... Even with a static content provider that's really pushing it--although wi correct caching you wouldn't necessarily see the hit past first load.

Curious what your typical page load and render times are, though.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I haven't had a chance to test the times outside of localhost, so it won't count anyway. By the time we launch, all these will be nicely compressed into something more manageable. But if you need them, how is it too many? We use every single plugin I have listed throughout the site. The majority of the site never requires a full page refresh so they are only really pulled down once anyway (caching aside).
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, sure, if you're a single-page site, no issue (most sites aren't, though, in the interests of bookmarking, unless you deal with that as well).

It's not the quantity of *plugins*, it's the quantity of *requests* -- while I"m not using as many as you, I'm 2/3 of the way there, but we're multi-page, and have enough users that a few dozen downloads per page wouldn't work (JS, CSS, images, HTML) even when GZIPped.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I assume Gregg will merge those into less JavaScript files and not just minify before production. Then it goes back to file size rather than just number of plugins.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

This is in my main layout file



Hi Greg, Wow! I havent reach half of that yet. To think these are only JS files. My thoughts are both on CSS and JS files and image files added by the jquery ui.
This would double the number of HTTP request during page load..

Are you perhaps suffering from premature optimization?



Hi Bear, I was just thinking fast-forward perhaps.. Maybe I will post again after my project is set on line

Thanks all..
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's a good thing to think about in advance, but I usually don't do anything overt until there is a demonstrable performance problem.
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do not agree
My personal opinion is linking to that many JavaScript and CSS resources is a very bad idea and waiting for a problem is also another bad idea. One of my jobs was to decrease the load time of a website. The first time the page loaded, it took the site about 45 seconds to fully load. Who in their right mind would wait that long for a website? lol. I got the website to load under 10 seconds, I could have gone further, but the head guys refused to lazy load content.

Why I do not agree
You may never see the problem on your network. You are sitting close to the servers that host your site and you are probably also on a fast connection. Your users might be sitting on the other side of the world on a slow connection. That is a double whammy. This means the users on the ther site of the globe will see bad performance and you will never know unless you do some fancy clientside logging [like I tend to do] or you have a helpdesk that hears complaints all the time.

Why there is a problem
The reason why we want to limit http connections is that older browsers allow only 2 concurrent connections at the same time. That means you have scripts, images, css, etc all fighting for those two open connections. BUT it is a double edge sword when you reduce the number of files by concatenating them. the reason is the file sizes increase.

The improvements
  • The first thing I would do is to make sure that you are using compressed files. This will reduce the amount of data that will be transferred. Whitespace and Comments mean nothing to the users. Also make sure you are gzipping the files.
  • The second thing is to make sure that your files are being properly cached. You do not want your users to be forced to download the files [ or check to see if they have been updated] every time the page is loaded in the browser. This way the users only have a penalty the first time they use the site.
  • The third thing I would do is create cnames. The 2 connection limit I talked about above is per domain. If you create subdomains such as static1.example.com, static2.example.com, and so on. You are getting 2 more connections per cname. Do not go all crazy an make 100's of sub domains because there is a limit to performance. Most studies said 4 is normally the sweet number. This is a big boost for most sites
  • The fourth thing is to lazy load anything that you do not need right away. If the user is not going to use script XXX as soon as the page is loaded, than why load it on the initial load. After the page is ready, add it dynamically.
  • The fifth thing is to dump window.onload and move to document.ready or loading scripts after the body content. The reason why window.onload is bad is it has to wait for EVERYTHING to load fully. That means if an image hangs for some reason, your JavaScript will sit there and wait until it times out/errors or loads. One hicccup on the server and your site can become a snail.
  • The sixth thing, load your JavaScript resources at the bottom of the body. Sounds weird, but with the way the browser renders content, it boosts performance.

  • Wrapping up
    I know I went a little overboard on this and probably answered something totally different than what was asked. Load time is very important. Why is it? First your users do not want to sit around and wait. I personally will leave a site if it takes forever to load. The second reason why website load time became even a bigger factor was when Google started to use load times as part of their ranking score. Slower sites means poorer ranking.

    Tools such as YSLow will give you guidelines to follow to speed up your site and give you a score.

    Time for me to crawl back into my hole.
    Eric
     
    Bear Bibeault
    Sheriff
    Posts: 67746
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Eric Pascarello wrote:The first time the page loaded, it took the site about 45 seconds to fully load.


    I would consider that a demonstrable performance problem.
     
    Eric Pascarello
    author
    Posts: 15385
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Bear Bibeault wrote:

    Eric Pascarello wrote:The first time the page loaded, it took the site about 45 seconds to fully load.


    I would consider that a demonstrable performance problem.



    Well a 2 second load time for you might be a 40 second load time in Cuba. [I have numbers to prove that too. They got crappy connections there lol]

     
    Mark Reyes
    Ranch Hand
    Posts: 426
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Well a 2 second load time for you might be a 40 second load time in Cuba



    Hi Eric, Wow! I wish I could create a program that could span continents someday... doing lots of SWT desktop really bores me but as they say,
    ' this is what pays the bill so I should at some way or another pay homeage to it'

    I know I went a little overboard on this



    If this is your way of being overboard... then I hopefully request with all respect that you do it as many times as you can...

    Err.. Seriously... such a very informative post..does not only answer my question but has given me enough hints to look to some other items that I havent think off yet...

    thanks..

     
    David Newton
    Author
    Posts: 12617
    IntelliJ IDE Ruby
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I often simulate a low-bandwidth connection during development just to see where I'm at. Handy. I also don't wait long to do performance testing for some projects; it can identify config, framework, schema, etc problems early, whenmaking changes is less painful. At least with JS files the solutions are easy and known.
     
    Bear Bibeault
    Sheriff
    Posts: 67746
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Indeed, great info Eric.
    reply
      Bookmark Topic Watch Topic
    • New Topic